[jira] [Commented] (CASSANDRA-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322611#comment-17322611
]
Berenguer Blasi commented on CASSANDRA-16595:
-
[~dcapwell] any chance you could share or add that ci-test sh to the circle
folder? I would have caught this when I did run some tests locally to make sure
it was working.
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-16601) Flaky CassandraIndexTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16601:
Status: Patch Available (was: Review In Progress)
> Flaky CassandraIndexTest
>
>
> Key: CASSANDRA-16601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16601
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/436/testReport/junit/org.apache.cassandra.index.internal/CassandraIndexTest/indexCorrectlyMarkedAsBuildAndRemoved_cdc/]
> {noformat}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:588)
> {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] [Commented] (CASSANDRA-16601) Flaky CassandraIndexTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322610#comment-17322610
]
Berenguer Blasi commented on CASSANDRA-16601:
-
I think removal of parallelization is already happening with CASSANDRA-16595
and the follow up tickets. So let me push a {{spinAssert}} and multiplex 200
times.
> Flaky CassandraIndexTest
>
>
> Key: CASSANDRA-16601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16601
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/436/testReport/junit/org.apache.cassandra.index.internal/CassandraIndexTest/indexCorrectlyMarkedAsBuildAndRemoved_cdc/]
> {noformat}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:588)
> {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-16601) Flaky CassandraIndexTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16601:
Status: In Progress (was: Patch Available)
> Flaky CassandraIndexTest
>
>
> Key: CASSANDRA-16601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16601
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/436/testReport/junit/org.apache.cassandra.index.internal/CassandraIndexTest/indexCorrectlyMarkedAsBuildAndRemoved_cdc/]
> {noformat}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:588)
> {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] [Commented] (CASSANDRA-16524) Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322607#comment-17322607
]
Gianluca Righetto commented on CASSANDRA-16524:
---
[~jasonstack] I went that route initially, but there's a problem with that
approach, we pass the initial buffer to the constructor of
UnpooledUnsafeDirectByteBuf and it keeps a reference to that internally:
https://github.com/netty/netty/blob/netty-4.1.58.Final/buffer/src/main/java/io/netty/buffer/UnpooledDirectByteBuf.java#L42
We would have to call setByteBuffer to replace that object, but it is not
public:
https://github.com/netty/netty/blob/netty-4.1.58.Final/buffer/src/main/java/io/netty/buffer/UnpooledDirectByteBuf.java#L114
If we don't replace that internal buffer, there will be mismatches because some
internal functions use it.
{{super.capacity(newCapacity)}} already does the right things, creates a new
buffer, copies over the bytes, releases the old one and replaces that reference.
{quote}
So we don't have to keep track of returnToPool which defeats the purpose of
reducing fragmented buffer allocation
{quote}
Right, I thought about that too and I agree, but for most cases it will behave
as before (it has been working with fixed-length buffers up until now).
Increasing the buffer capacity should be an edge case as the one reported in
the ticket.
> Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing
> with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16524
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
> Attachments: system.log.ssl-error.txt
>
>
> Hi,
> We have SSL enabled cluster running on Apache Cassandra 3.11.10 and we are
> trying to upgrade it to 4.0-beta4 as a part of testing.
> Cluster size is 3x3 and deployed on Azure IaaS.
> {noformat}
> [cassandra@cass-521828978-1-1189299202 ~]$ nodetool status
> Datacenter: southcentral
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.74.31 85.61 KiB 16 32.2%
> 6db7a7ef-3490-4823-9ff3-c60a32165124 2
> UN 10.12.74.42 263.27 KiB 16 27.6%
> 7ad99ecf-7c7d-4780-872b-7c68b6b19849 1
> UN 10.12.74.34 85.61 KiB 16 37.8%
> 41ce16b7-2ab2-44ea-a810-8391f7f3caf2 0
> Datacenter: westus
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.90.11 90.63 KiB 16 38.9%
> 8d4cdb65-ff66-4bcd-8d4b-a4a0e893a728 2
> UN 10.12.90.6 85.61 KiB 16 34.5%
> 4f8007e9-fa3e-4e99-a9f9-f7bf9625 1
> UN 10.12.89.80 94.1 KiB 16 28.9%
> 11f86cb0-c86b-440e-848f-b160118f43d5 0
> {noformat}
> We placed a new 4.0-beta4 binary on the first seed node (10.12.74.310) and
> starting Cassandra.
> It started throwing the below error:
> {noformat}
> ERROR [Messaging-EventLoop-3-11] 2021-03-15 22:10:05,188
> InboundConnectionInitiator.java:342 - Failed to properly handshake with peer
> /10.12.74.42:52356. Closing the channel.
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException:
> java.lang.IndexOutOfBoundsException: writerIndex(8560) +
> minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
>
[jira] [Comment Edited] (CASSANDRA-16524) Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322574#comment-17322574
]
Zhao Yang edited comment on CASSANDRA-16524 at 4/16/21, 2:50 AM:
-
bq. BufferPoolAllocator.Wrapped#capacity(int) is now overridden to ensure the
original ByteBuffer will be returned to the pool when the buffer is resized.
Left a comment on whether to get rid of `super.capacity(int)` which allocated
outside of pool..
https://github.com/grighetto/cassandra/pull/5/files#r614524653
[~e.dimitrova][~bereng][~gianluca] wdyt?
was (Author: jasonstack):
> BufferPoolAllocator.Wrapped#capacity(int) is now overridden to ensure the
> original ByteBuffer will be returned to the pool when the buffer is resized.
Left a comment on whether to get rid of `super.capacity(int)` which allocated
outside of pool..
https://github.com/grighetto/cassandra/pull/5/files#r614524653
[~e.dimitrova][~bereng][~gianluca] wdyt?
> Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing
> with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16524
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
> Attachments: system.log.ssl-error.txt
>
>
> Hi,
> We have SSL enabled cluster running on Apache Cassandra 3.11.10 and we are
> trying to upgrade it to 4.0-beta4 as a part of testing.
> Cluster size is 3x3 and deployed on Azure IaaS.
> {noformat}
> [cassandra@cass-521828978-1-1189299202 ~]$ nodetool status
> Datacenter: southcentral
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.74.31 85.61 KiB 16 32.2%
> 6db7a7ef-3490-4823-9ff3-c60a32165124 2
> UN 10.12.74.42 263.27 KiB 16 27.6%
> 7ad99ecf-7c7d-4780-872b-7c68b6b19849 1
> UN 10.12.74.34 85.61 KiB 16 37.8%
> 41ce16b7-2ab2-44ea-a810-8391f7f3caf2 0
> Datacenter: westus
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.90.11 90.63 KiB 16 38.9%
> 8d4cdb65-ff66-4bcd-8d4b-a4a0e893a728 2
> UN 10.12.90.6 85.61 KiB 16 34.5%
> 4f8007e9-fa3e-4e99-a9f9-f7bf9625 1
> UN 10.12.89.80 94.1 KiB 16 28.9%
> 11f86cb0-c86b-440e-848f-b160118f43d5 0
> {noformat}
> We placed a new 4.0-beta4 binary on the first seed node (10.12.74.310) and
> starting Cassandra.
> It started throwing the below error:
> {noformat}
> ERROR [Messaging-EventLoop-3-11] 2021-03-15 22:10:05,188
> InboundConnectionInitiator.java:342 - Failed to properly handshake with peer
> /10.12.74.42:52356. Closing the channel.
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException:
> java.lang.IndexOutOfBoundsException: writerIndex(8560) +
> minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
>
[jira] [Commented] (CASSANDRA-16524) Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322574#comment-17322574
]
Zhao Yang commented on CASSANDRA-16524:
---
> BufferPoolAllocator.Wrapped#capacity(int) is now overridden to ensure the
> original ByteBuffer will be returned to the pool when the buffer is resized.
Left a comment on whether to get rid of `super.capacity(int)` which allocated
outside of pool..
https://github.com/grighetto/cassandra/pull/5/files#r614524653
[~e.dimitrova][~bereng][~gianluca] wdyt?
> Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing
> with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16524
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
> Attachments: system.log.ssl-error.txt
>
>
> Hi,
> We have SSL enabled cluster running on Apache Cassandra 3.11.10 and we are
> trying to upgrade it to 4.0-beta4 as a part of testing.
> Cluster size is 3x3 and deployed on Azure IaaS.
> {noformat}
> [cassandra@cass-521828978-1-1189299202 ~]$ nodetool status
> Datacenter: southcentral
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.74.31 85.61 KiB 16 32.2%
> 6db7a7ef-3490-4823-9ff3-c60a32165124 2
> UN 10.12.74.42 263.27 KiB 16 27.6%
> 7ad99ecf-7c7d-4780-872b-7c68b6b19849 1
> UN 10.12.74.34 85.61 KiB 16 37.8%
> 41ce16b7-2ab2-44ea-a810-8391f7f3caf2 0
> Datacenter: westus
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.90.11 90.63 KiB 16 38.9%
> 8d4cdb65-ff66-4bcd-8d4b-a4a0e893a728 2
> UN 10.12.90.6 85.61 KiB 16 34.5%
> 4f8007e9-fa3e-4e99-a9f9-f7bf9625 1
> UN 10.12.89.80 94.1 KiB 16 28.9%
> 11f86cb0-c86b-440e-848f-b160118f43d5 0
> {noformat}
> We placed a new 4.0-beta4 binary on the first seed node (10.12.74.310) and
> starting Cassandra.
> It started throwing the below error:
> {noformat}
> ERROR [Messaging-EventLoop-3-11] 2021-03-15 22:10:05,188
> InboundConnectionInitiator.java:342 - Failed to properly handshake with peer
> /10.12.74.42:52356. Closing the channel.
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException:
> java.lang.IndexOutOfBoundsException: writerIndex(8560) +
> minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException:
> writerIndex(8560) +
[jira] [Updated] (CASSANDRA-16599) Use source release of python driver from pip rather than GitHub
[ https://issues.apache.org/jira/browse/CASSANDRA-16599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-16599: -- Fix Version/s: (was: 4.0-rc) 4.0-rc1 Source Control Link: https://github.com/apache/cassandra/commit/038271cc6f0dda7ca45dd3a4c52fcfd23daa2107 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Use source release of python driver from pip rather than GitHub > --- > > Key: CASSANDRA-16599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16599 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-rc1 > > Time Spent: 10m > Remaining Estimate: 0h > > We pull python driver from GitHub but we should pull it from pip 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
[cassandra] branch trunk updated: Use source release of python driver from pip rather than GitHub
This is an automated email from the ASF dual-hosted git repository. dcapwell 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 038271c Use source release of python driver from pip rather than GitHub 038271c is described below commit 038271cc6f0dda7ca45dd3a4c52fcfd23daa2107 Author: David Capwell AuthorDate: Thu Apr 15 12:04:57 2021 -0700 Use source release of python driver from pip rather than GitHub patch by David Capwell; reviewed by Adam Holmberg, Michael Semb Wever for CASSANDRA-16599 --- .build/build-resolver.xml | 6 -- .gitignore| 1 + CHANGES.txt | 1 + build.xml | 4 +++- lib/cassandra-driver-internal-only-3.25.0.zip | Bin 0 -> 345177 bytes 5 files changed, 5 insertions(+), 7 deletions(-) diff --git a/.build/build-resolver.xml b/.build/build-resolver.xml index f536dda..793937d 100644 --- a/.build/build-resolver.xml +++ b/.build/build-resolver.xml @@ -202,11 +202,6 @@ - - - - - @@ -237,7 +232,6 @@ - diff --git a/.gitignore b/.gitignore index 36d8d22..8754b17 100644 --- a/.gitignore +++ b/.gitignore @@ -9,6 +9,7 @@ data/ conf/hotspot_compiler doc/cql3/CQL.html lib/ +!lib/cassandra-driver-internal-only-*.zip # C* debs build-stamp diff --git a/CHANGES.txt b/CHANGES.txt index efd6c60..6dd8bab 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.0-rc1 + * Add back the source release of python driver in tree to avoid fetching from GitHub APIs (CASSANDRA-16599) * Fix false unavailable for queries due to cluster topology changes (CASSANDRA-16545) * Fixed a race condition issue in nodetool repair where we poll for the error before seeing the error notification, leading to a less meaningful message (CASSANDRA-16585) * Fix mixed cluster GROUP BY queries (CASSANDRA-16582) diff --git a/build.xml b/build.xml index 31c1fe9..2fddbb0 100644 --- a/build.xml +++ b/build.xml @@ -377,7 +377,9 @@ - + + + diff --git a/lib/cassandra-driver-internal-only-3.25.0.zip b/lib/cassandra-driver-internal-only-3.25.0.zip new file mode 100644 index 000..ecfd6a9 Binary files /dev/null and b/lib/cassandra-driver-internal-only-3.25.0.zip differ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16599) Use source release of python driver from pip rather than GitHub
[ https://issues.apache.org/jira/browse/CASSANDRA-16599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322444#comment-17322444 ] David Capwell edited comment on CASSANDRA-16599 at 4/16/21, 12:11 AM: -- Starting commit CI Results (pending): ||Branch||Source||Circle CI||Jenkins|| |trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-16599-trunk-422AFE21-0C41-4229-B9D8-B4CE92584A84]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16599-trunk-422AFE21-0C41-4229-B9D8-B4CE92584A84]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/676/]| was (Author: dcapwell): Starting commit CI Results (pending): ||Branch||Source||Circle CI||Jenkins|| |trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-16599-trunk-422AFE21-0C41-4229-B9D8-B4CE92584A84]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16599-trunk-422AFE21-0C41-4229-B9D8-B4CE92584A84]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/669/]| > Use source release of python driver from pip rather than GitHub > --- > > Key: CASSANDRA-16599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16599 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > We pull python driver from GitHub but we should pull it from pip 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] [Comment Edited] (CASSANDRA-16599) Use source release of python driver from pip rather than GitHub
[ https://issues.apache.org/jira/browse/CASSANDRA-16599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322542#comment-17322542 ] David Capwell edited comment on CASSANDRA-16599 at 4/16/21, 12:11 AM: -- Now that CASSANDRA-16595 is merged I rebased and kicked off ci jobs was (Author: dcapwell): Now that CASSANDRA-16595 is merged I rebased and kicked off the circle ci job > Use source release of python driver from pip rather than GitHub > --- > > Key: CASSANDRA-16599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16599 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > We pull python driver from GitHub but we should pull it from pip 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] [Commented] (CASSANDRA-16599) Use source release of python driver from pip rather than GitHub
[ https://issues.apache.org/jira/browse/CASSANDRA-16599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322542#comment-17322542 ] David Capwell commented on CASSANDRA-16599: --- Now that CASSANDRA-16595 is merged I rebased and kicked off the circle ci job > Use source release of python driver from pip rather than GitHub > --- > > Key: CASSANDRA-16599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16599 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > We pull python driver from GitHub but we should pull it from pip 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
[cassandra] branch cassandra-3.0 updated (2a6059e -> 5f1b538)
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 2a6059e Merge branch 'cassandra-2.2' into cassandra-3.0 new c52f50f Restore running each test class in its own separate jvm and cassandra directory (Remove test parallelism from ant build.xml) new 5f1b538 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: build.xml | 66 -- .../cassandra/OffsetAwareConfigurationLoader.java | 64 - 2 files changed, 49 insertions(+), 81 deletions(-) delete mode 100644 test/unit/org/apache/cassandra/OffsetAwareConfigurationLoader.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16595:
---
Source Control Link:
https://github.com/apache/cassandra/commit/1185593907ba6597c29da1dfb5e6edb121b358c5
https://github.com/apache/cassandra/commit/c52f50f046fd1a8e1c7f17d9a1952e2bd92aeb4c
(was:
https://github.com/apache/cassandra/commit/1185593907ba6597c29da1dfb5e6edb121b358c5)
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
[c52f50f046fd1a8e1c7f17d9a1952e2bd92aeb4c|https://github.com/apache/cassandra/commit/c52f50f046fd1a8e1c7f17d9a1952e2bd92aeb4c].
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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 (b915688 -> 65b6dfa)
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 b915688 Fix false unavailable for queries due to cluster topology changes new c52f50f Restore running each test class in its own separate jvm and cassandra directory (Remove test parallelism from ant build.xml) new 5f1b538 Merge branch 'cassandra-2.2' into cassandra-3.0 new cca5ce5 Merge branch 'cassandra-3.0' into cassandra-3.11 new 65b6dfa 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: build.xml | 100 .../cassandra/OffsetAwareConfigurationLoader.java | 105 - .../config/DatabaseDescriptorRefTest.java | 1 - 3 files changed, 61 insertions(+), 145 deletions(-) delete mode 100644 test/unit/org/apache/cassandra/OffsetAwareConfigurationLoader.java - 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 65b6dfa822b0ea207787790bff5acbb5d4008348 Merge: b915688 cca5ce5 Author: Mick Semb Wever AuthorDate: Fri Apr 16 00:43:30 2021 +0200 Merge branch 'cassandra-3.11' into trunk build.xml | 100 .../cassandra/OffsetAwareConfigurationLoader.java | 105 - .../config/DatabaseDescriptorRefTest.java | 1 - 3 files changed, 61 insertions(+), 145 deletions(-) diff --cc build.xml index c9f09f6,b773f0f..31c1fe9 --- a/build.xml +++ b/build.xml @@@ -1351,12 -1359,10 +1387,11 @@@ algorithm to limit the metaspace size and clean up SoftReferences more aggressively rather than waiting. See CASSANDRA-14922 for more details. --> - + + - @@@ -1392,20 -1389,11 +1427,12 @@@ - - - - - - - Failed to set File Separator. This shouldn't happen. - - - - - - - + + + ++ + + @@@ -1427,9 -1416,9 +1454,8 @@@ - - @@@ -1479,27 -1468,6 +1503,26 @@@ + + + + + + + + + + + + + + + - + + + + @@@ -1563,18 -1516,10 +1586,18 @@@ - - + + + + + + - - ++ ++ + + @@@ -1831,44 -1779,25 +1853,44 @@@ - - + + - - - + + - - - + + + + + + - - ++ ++ + + + + + + + + + + + + + + + - 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 (5b93a87 -> cca5ce5)
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 5b93a87 Merge branch 'cassandra-3.0' into cassandra-3.11 new c52f50f Restore running each test class in its own separate jvm and cassandra directory (Remove test parallelism from ant build.xml) new 5f1b538 Merge branch 'cassandra-2.2' into cassandra-3.0 new cca5ce5 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: build.xml | 87 ++ .../cassandra/OffsetAwareConfigurationLoader.java | 67 - .../config/DatabaseDescriptorRefTest.java | 1 - 3 files changed, 55 insertions(+), 100 deletions(-) delete mode 100644 test/unit/org/apache/cassandra/OffsetAwareConfigurationLoader.java - 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 cca5ce56acef05a7bbd254fff7cd08e3f8263c41
Merge: 5b93a87 5f1b538
Author: Mick Semb Wever
AuthorDate: Fri Apr 16 00:41:55 2021 +0200
Merge branch 'cassandra-3.0' into cassandra-3.11
build.xml | 87 ++
.../cassandra/OffsetAwareConfigurationLoader.java | 67 -
.../config/DatabaseDescriptorRefTest.java | 1 -
3 files changed, 55 insertions(+), 100 deletions(-)
diff --cc build.xml
index 7184d74,c6603a0..b773f0f
--- a/build.xml
+++ b/build.xml
@@@ -1353,20 -1331,9 +1388,12 @@@
+
-
-
-
-
-
-
- Failed to set File Separator. This shouldn't
happen.
-
-
-
-
-
-
+
++
+
+
++
@@@ -1422,28 -1430,6 +1447,27 @@@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+
+
+
+
@@@ -1484,18 -1475,10 +1508,18 @@@
-
-
+
+
+
+
+
+
-
-
++
++
+
+
@@@ -1764,18 -1746,10 +1787,18 @@@
-
-
+
+
+
+
+
+
-
-
++
++
+
+
diff --cc test/unit/org/apache/cassandra/config/DatabaseDescriptorRefTest.java
index 6e865ae,000..1c07a7d
mode 100644,00..100644
--- a/test/unit/org/apache/cassandra/config/DatabaseDescriptorRefTest.java
+++ b/test/unit/org/apache/cassandra/config/DatabaseDescriptorRefTest.java
@@@ -1,268 -1,0 +1,267 @@@
+/*
+ * 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.
+ */
+
+package org.apache.cassandra.config;
+
+import java.io.ByteArrayOutputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.PrintStream;
+import java.lang.management.ManagementFactory;
+import java.lang.management.ThreadInfo;
+import java.lang.management.ThreadMXBean;
+import java.lang.reflect.Method;
+import java.net.URL;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Map;
+import java.util.Set;
+
+import org.junit.Test;
+
+import org.apache.cassandra.utils.Pair;
+
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.fail;
+
+/**
+ * Verifies that {@link DatabaseDescriptor#clientInitialization()} } and a
couple of apply methods
+ * do not somehow lazily initialize any unwanted part of Cassandra like
schema, commit log or start
+ * unexpected threads.
+ *
+ * {@link DatabaseDescriptor#toolInitialization()} is tested via unit tests
extending
+ * {@link org.apache.cassandra.tools.ToolsTester}.
+ */
+public class DatabaseDescriptorRefTest
+{
+static final String[] validClasses = {
+"org.apache.cassandra.auth.IInternodeAuthenticator",
+"org.apache.cassandra.auth.IAuthenticator",
+"org.apache.cassandra.auth.IAuthorizer",
+"org.apache.cassandra.auth.IRoleManager",
+"org.apache.cassandra.config.DatabaseDescriptor",
+"org.apache.cassandra.config.ConfigurationLoader",
+"org.apache.cassandra.config.Config",
+"org.apache.cassandra.config.Config$1",
+"org.apache.cassandra.config.Config$RequestSchedulerId",
+"org.apache.cassandra.config.Config$CommitLogSync",
+"org.apache.cassandra.config.Config$DiskAccessMode",
+"org.apache.cassandra.config.Config$DiskFailurePolicy",
+"org.apache.cassandra.config.Config$CommitFailurePolicy",
+"org.apache.cassandra.config.Config$DiskOptimizationStrategy",
+"org.apache.cassandra.config.Config$InternodeCompression",
+"org.apache.cassandra.config.Config$MemtableAllocationType",
+
[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 5f1b538ef55dcebb0fa4ac0ad1728c38469cfae0 Merge: 2a6059e c52f50f Author: Mick Semb Wever AuthorDate: Fri Apr 16 00:40:53 2021 +0200 Merge branch 'cassandra-2.2' into cassandra-3.0 build.xml | 66 -- .../cassandra/OffsetAwareConfigurationLoader.java | 64 - 2 files changed, 49 insertions(+), 81 deletions(-) diff --cc build.xml index 9c778ae,95f85c0..c6603a0 --- a/build.xml +++ b/build.xml @@@ -1236,11 -1317,10 +1273,10 @@@ - - + - - + + + + + + - @@@ -1295,10 -1369,10 +1330,10 @@@ - + - - - + + + @@@ -1439,11 -1509,11 +1472,11 @@@ - + - - + + @@@ -1684,10 -1797,10 +1716,10 @@@ - + - - + + @@@ -1714,10 -1827,23 +1746,10 @@@ - - + + - - - - - - - - - - - - - - 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: Restore running each test class in its own separate jvm and cassandra directory (Remove test parallelism from ant build.xml)
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 c52f50f Restore running each test class in its own separate jvm and
cassandra directory (Remove test parallelism from ant build.xml)
c52f50f is described below
commit c52f50f046fd1a8e1c7f17d9a1952e2bd92aeb4c
Author: Mick Semb Wever
AuthorDate: Thu Apr 15 16:57:36 2021 +0200
Restore running each test class in its own separate jvm and cassandra
directory
(Remove test parallelism from ant build.xml)
patch by Mick Semb Wever; reviewed by Yifan Cai, David Capwell for
CASSANDRA-16595
---
build.xml | 66 --
.../cassandra/OffsetAwareConfigurationLoader.java | 63 -
2 files changed, 49 insertions(+), 80 deletions(-)
diff --git a/build.xml b/build.xml
index cbe45ba..95f85c0 100644
--- a/build.xml
+++ b/build.xml
@@ -1268,6 +1268,43 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1335,9 +1370,9 @@
-
-
-
+
+
+
@@ -1410,7 +1445,6 @@
-
@@ -1436,7 +1470,6 @@
-
@@ -1479,8 +1512,8 @@
-
-
+
+
@@ -1740,13 +1773,12 @@
-
@@ -1767,8 +1799,8 @@
-
-
+
+
@@ -1787,16 +1819,16 @@
-
-
+
+
-
-
+
+
diff --git a/test/unit/org/apache/cassandra/OffsetAwareConfigurationLoader.java
b/test/unit/org/apache/cassandra/OffsetAwareConfigurationLoader.java
deleted file mode 100644
index 9023b11..000
--- a/test/unit/org/apache/cassandra/OffsetAwareConfigurationLoader.java
+++ /dev/null
@@ -1,63 +0,0 @@
-/**
- * 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.
- */
-package org.apache.cassandra;
-
-import org.apache.cassandra.config.Config;
-import org.apache.cassandra.config.YamlConfigurationLoader;
-import org.apache.cassandra.exceptions.ConfigurationException;
-
-import java.io.File;
-
-
-public class OffsetAwareConfigurationLoader extends YamlConfigurationLoader
-{
-
-static final String OFFSET_PROPERTY = "cassandra.test.offsetseed";
-int offset = 0;
-
-public OffsetAwareConfigurationLoader()
-{
-String offsetStr = System.getProperty(OFFSET_PROPERTY);
-
-if (offsetStr == null)
-throw new RuntimeException("offset property is not set:
"+OFFSET_PROPERTY);
-
-offset = Integer.valueOf(offsetStr);
-
-assert offset >= 0;
-}
-
-@Override
-public Config loadConfig() throws ConfigurationException
-{
-Config config = super.loadConfig();
-
-
-config.rpc_port += offset;
-config.native_transport_port += offset;
-config.storage_port += offset;
-
-config.commitlog_directory += File.pathSeparator + offset;
-config.saved_caches_directory += File.pathSeparator + offset;
-for (int i = 0; i < config.data_file_directories.length; i++)
-config.data_file_directories[i] += File.pathSeparator + offset;
-
-
-return config;
-}
-}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16595:
---
Reviewers: Berenguer Blasi, David Capwell, Yifan Cai (was: Berenguer
Blasi, Yifan Cai)
Status: Review In Progress (was: Patch Available)
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16595:
---
Status: Ready to Commit (was: Review In Progress)
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322517#comment-17322517
]
Yifan Cai commented on CASSANDRA-16595:
---
+1
The CI/Jenkins results LGTM.
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322480#comment-17322480
]
David Capwell commented on CASSANDRA-16595:
---
tested branches 3.0, 3.11, and trunk; all passed
my test suite
{code}
$ # ci-test tries to mimic CI when running the class, so tends to have the same
behavior as circle ci and Jenkins
$ ./ci-test org/apache/cassandra/hints/HintsWriteThenReadTest && ./ci-test
org/apache/cassandra/distributed/test/LargeColumnTest --reuse &&
./ci-tes/apache/cassandra/hints/HintsServiceTest --reuse && ./ci-test
org/apache/cassandra/hints/HintsServiceTest --cdc --reuse && ./ci-test
org/apache/cassandra/hints/HintsServiceTest --compress --reuse && ./ci-test
org/apache/cassandra/hints/HintsServiceTest --compress --reuse && ./ci-test
org/apache/cassandra/hints/HintsServiceTest --compress --reuse
{code}
Didn't review the code as I have a hard time with ant, but +1 from my testing;
should work fine in CI
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-16599) Use source release of python driver from pip rather than GitHub
[ https://issues.apache.org/jira/browse/CASSANDRA-16599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322463#comment-17322463 ] David Capwell commented on CASSANDRA-16599: --- seems trunk broke, so stopped the commit; will redo once trunk is stable > Use source release of python driver from pip rather than GitHub > --- > > Key: CASSANDRA-16599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16599 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > We pull python driver from GitHub but we should pull it from pip 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] [Comment Edited] (CASSANDRA-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322458#comment-17322458
]
Michael Semb Wever edited comment on CASSANDRA-16595 at 4/15/21, 7:47 PM:
--
Patches
-
[trunk|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16595-fix/trunk]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/670/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/670/pipeline/]
-
[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/16595-fix/3.11]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/671/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/671/pipeline/]
-
[3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/16595-fix/3.0]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/672/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/672/pipeline/]
-
[2.2|https://github.com/apache/cassandra/compare/cassandra-2.2...thelastpickle:mck/16595-fix/2.2]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/675/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/675/pipeline/]
was (Author: michaelsembwever):
Patches
-
[trunk|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16595-fix/trunk]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/670/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/670/pipeline/]
-
[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/16595-fix/3.11]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/671/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/671/pipeline/]
-
[3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/16595-fix/3.0]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/672/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/672/pipeline/]
-
[2.2|https://github.com/apache/cassandra/compare/cassandra-2.2...thelastpickle:mck/16595-fix/2.2]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/674/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/674/pipeline/]
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322458#comment-17322458
]
Michael Semb Wever edited comment on CASSANDRA-16595 at 4/15/21, 7:41 PM:
--
Patches
-
[trunk|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16595-fix/trunk]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/670/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/670/pipeline/]
-
[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/16595-fix/3.11]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/671/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/671/pipeline/]
-
[3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/16595-fix/3.0]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/672/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/672/pipeline/]
-
[2.2|https://github.com/apache/cassandra/compare/cassandra-2.2...thelastpickle:mck/16595-fix/2.2]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/674/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/674/pipeline/]
was (Author: michaelsembwever):
Patches
-
[trunk|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16595-fix/trunk]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/670/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/670/pipeline/]
-
[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/16595-fix/3.11]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/671/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/671/pipeline/]
-
[3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/16595-fix/3.0]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/672/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/672/pipeline/]
-
[2.2|https://github.com/apache/cassandra/compare/cassandra-2.2...thelastpickle:mck/16595-fix/2.2]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/673/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/673/pipeline/]
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322458#comment-17322458
]
Michael Semb Wever commented on CASSANDRA-16595:
Patches
-
[trunk|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16595-fix/trunk]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/670/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/670/pipeline/]
-
[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/16595-fix/3.11]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/671/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/671/pipeline/]
-
[3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/16595-fix/3.0]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/672/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/672/pipeline/]
-
[2.2|https://github.com/apache/cassandra/compare/cassandra-2.2...thelastpickle:mck/16595-fix/2.2]
–
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/673/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/673/pipeline/]
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322446#comment-17322446
]
Michael Semb Wever commented on CASSANDRA-16595:
Tests need to run one class per JVM and in a clean cassandra directory, have
restored this functionality. (Despite other test targets that don't do this,
and also would now be broken.)
Fix is
https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16595-fix/trunk
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/670/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/670/pipeline/]
circleci:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra?branch=mck%2F16595-fix%2Ftrunk
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-16599) Use source release of python driver from pip rather than GitHub
[ https://issues.apache.org/jira/browse/CASSANDRA-16599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322444#comment-17322444 ] David Capwell commented on CASSANDRA-16599: --- Starting commit CI Results (pending): ||Branch||Source||Circle CI||Jenkins|| |trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-16599-trunk-422AFE21-0C41-4229-B9D8-B4CE92584A84]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-16599-trunk-422AFE21-0C41-4229-B9D8-B4CE92584A84]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/669/]| > Use source release of python driver from pip rather than GitHub > --- > > Key: CASSANDRA-16599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16599 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > We pull python driver from GitHub but we should pull it from pip 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] [Commented] (CASSANDRA-16561) Gossip is not populated with tokens/host_ids
[
https://issues.apache.org/jira/browse/CASSANDRA-16561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322440#comment-17322440
]
Sam Tunnicliffe commented on CASSANDRA-16561:
-
{quote}we never send them in the shadow round
{quote}
In trunk, we do include the persisted state in a shadow round response if
that's all the state we have.
We also don't init that with ({{0, 0}}) any more, but with a special value that
indicates it represents persisted, not learned state.
This all changed in CASSANDRA-16213 to help the case of replacing a down node
(possibly following a full cluster bounce) and there are comments in
{{SS::prepareForReplacement}} and {{Gossiper::examineShadowState}} describing
the rationale.
> Gossip is not populated with tokens/host_ids
>
>
> Key: CASSANDRA-16561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16561
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x
>
>
> Originally when we began persisting host information such a tokens/host_id,
> we would populate gossip with this information. At some point we began only
> populating TokenMetadata, which gives us most of the same benefit, but in a
> full ring restart where the gossip ether is empty, it populates useless info
> such as :
> {quote}
> /10.101.32.212
> generation:0
> heartbeat:0
> TOKENS: not present
> {quote}
> which is the minimum required for a state to exist. Instead we should keep
> gossip in sync with TMD when populating this information like we used to do.
--
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-16599) Use source release of python driver from pip rather than GitHub
[ https://issues.apache.org/jira/browse/CASSANDRA-16599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-16599: -- Status: Ready to Commit (was: Review In Progress) > Use source release of python driver from pip rather than GitHub > --- > > Key: CASSANDRA-16599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16599 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > We pull python driver from GitHub but we should pull it from pip 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] [Commented] (CASSANDRA-16599) Use source release of python driver from pip rather than GitHub
[ https://issues.apache.org/jira/browse/CASSANDRA-16599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322428#comment-17322428 ] David Capwell commented on CASSANDRA-16599: --- All failures are known other than CASSANDRA-16607 which I just filed. > Use source release of python driver from pip rather than GitHub > --- > > Key: CASSANDRA-16599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16599 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > We pull python driver from GitHub but we should pull it from pip 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-16607) Fix flaky test testRequestResponse – org.apache.cassandra.net.MockMessagingServiceTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16607:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Discovered By: Unit Test
Fix Version/s: 4.0-rc
Severity: Normal
Status: Open (was: Triage Needed)
> Fix flaky test testRequestResponse –
> org.apache.cassandra.net.MockMessagingServiceTest
> --
>
> Key: CASSANDRA-16607
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16607
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-rc
>
>
> https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/659/tests/
> {code}
> Error
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.net.MockMessagingServiceTest.testRequestResponse(MockMessagingServiceTest.java:81)
> 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)
> Standard Output
> INFO [main] 2021-04-15 08:22:46,838 YamlConfigurationLoader.java:93 -
> Configuration location:
> file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2021-04-15 08:22:46,840 YamlConfigurationLoader.java:112 -
> Loading settings from file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2021-04-15 08:22:46,899 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2021-04-15 08:22:46,911 PlatformDependent0.java:417 -
> -Dio.netty.noUnsaf
> ...[truncated 61235 chars]...
> te NORMAL, token [a57d4b7f61f49471614b7ac41f16477e]
> DEBUG [main] 2021-04-15 08:22:49,840 StorageService.java:2674 - New node
> /127.0.0.1:7069 at token a57d4b7f61f49471614b7ac41f16477e
> DEBUG [main] 2021-04-15 08:22:49,848 StorageService.java:2727 - Node
> /127.0.0.1:7069 state NORMAL, token [a57d4b7f61f49471614b7ac41f16477e]
> INFO [main] 2021-04-15 08:22:49,848 StorageService.java:2730 - Node
> /127.0.0.1:7069 state jump to NORMAL
> DEBUG [main] 2021-04-15 08:22:49,849 StorageService.java:1619 - NORMAL
> {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] [Created] (CASSANDRA-16607) Fix flaky test testRequestResponse – org.apache.cassandra.net.MockMessagingServiceTest
David Capwell created CASSANDRA-16607:
-
Summary: Fix flaky test testRequestResponse –
org.apache.cassandra.net.MockMessagingServiceTest
Key: CASSANDRA-16607
URL: https://issues.apache.org/jira/browse/CASSANDRA-16607
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: David Capwell
https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/659/tests/
{code}
Error
expected:<1> but was:<0>
Stacktrace
junit.framework.AssertionFailedError: expected:<1> but was:<0>
at
org.apache.cassandra.net.MockMessagingServiceTest.testRequestResponse(MockMessagingServiceTest.java:81)
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)
Standard Output
INFO [main] 2021-04-15 08:22:46,838 YamlConfigurationLoader.java:93 -
Configuration location: file:/home/cassandra/cassandra/test/conf/cassandra.yaml
DEBUG [main] 2021-04-15 08:22:46,840 YamlConfigurationLoader.java:112 - Loading
settings from file:/home/cassandra/cassandra/test/conf/cassandra.yaml
DEBUG [main] 2021-04-15 08:22:46,899 InternalLoggerFactory.java:63 - Using
SLF4J as the default logging framework
DEBUG [main] 2021-04-15 08:22:46,911 PlatformDependent0.java:417 -
-Dio.netty.noUnsaf
...[truncated 61235 chars]...
te NORMAL, token [a57d4b7f61f49471614b7ac41f16477e]
DEBUG [main] 2021-04-15 08:22:49,840 StorageService.java:2674 - New node
/127.0.0.1:7069 at token a57d4b7f61f49471614b7ac41f16477e
DEBUG [main] 2021-04-15 08:22:49,848 StorageService.java:2727 - Node
/127.0.0.1:7069 state NORMAL, token [a57d4b7f61f49471614b7ac41f16477e]
INFO [main] 2021-04-15 08:22:49,848 StorageService.java:2730 - Node
/127.0.0.1:7069 state jump to NORMAL
DEBUG [main] 2021-04-15 08:22:49,849 StorageService.java:1619 - NORMAL
{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] [Comment Edited] (CASSANDRA-16561) Gossip is not populated with tokens/host_ids
[
https://issues.apache.org/jira/browse/CASSANDRA-16561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322404#comment-17322404
]
David Capwell edited comment on CASSANDRA-16561 at 4/15/21, 6:54 PM:
-
I think I went the route of adding token/host to the empty case in
CASSANDRA-16213 on startup but there were concerns about it (I think it was
concerns about potential unknown side effects), so we limited populating this
data only when shadow round is performed to limit the possible side effects
that could happen; this has the side effect that new nodes (which join via host
replacement) sees the host_id and token in the empty state in gossip (as we
were forced to copy those values from the shadow round into normal gossip
state), but the other nodes don't (including bootstrapped nodes).
If I understand your point, the argument is to also provide this information to
bootstrapping nodes (which we do now via shadow round) *and store the results*?
If so I am in favor as it makes the cluster symmetric (all nodes match the
host replacement hosts)
was (Author: dcapwell):
I think I went the route of adding token/host to the empty case in
CASSANDRA-16213 on startup but there were concerns about it (I think it was
concerns about potential unknown side effects), so we limited populating this
data only when shadow round is performed to limit the possible side effects
that could happen; this has the side effect that new nodes (which join via host
replacement) sees the host_id and token in the empty state in gossip (as we
were forced to copy those values from the shadow round into normal gossip
state), but the other nodes don't (including bootstrapped nodes).
If I understand your point, the argument is to also provide this information to
bootstrapping nodes (which we do now via shadow round) *and store the results*?
> Gossip is not populated with tokens/host_ids
>
>
> Key: CASSANDRA-16561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16561
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x
>
>
> Originally when we began persisting host information such a tokens/host_id,
> we would populate gossip with this information. At some point we began only
> populating TokenMetadata, which gives us most of the same benefit, but in a
> full ring restart where the gossip ether is empty, it populates useless info
> such as :
> {quote}
> /10.101.32.212
> generation:0
> heartbeat:0
> TOKENS: not present
> {quote}
> which is the minimum required for a state to exist. Instead we should keep
> gossip in sync with TMD when populating this information like we used to do.
--
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-16561) Gossip is not populated with tokens/host_ids
[
https://issues.apache.org/jira/browse/CASSANDRA-16561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322404#comment-17322404
]
David Capwell commented on CASSANDRA-16561:
---
I think I went the route of adding token/host to the empty case in
CASSANDRA-16213 on startup but there were concerns about it (I think it was
concerns about potential unknown side effects), so we limited populating this
data only when shadow round is performed to limit the possible side effects
that could happen; this has the side effect that new nodes (which join via host
replacement) sees the host_id and token in the empty state in gossip (as we
were forced to copy those values from the shadow round into normal gossip
state), but the other nodes don't (including bootstrapped nodes).
If I understand your point, the argument is to also provide this information to
bootstrapping nodes (which we do now via shadow round) *and store the results*?
> Gossip is not populated with tokens/host_ids
>
>
> Key: CASSANDRA-16561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16561
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x
>
>
> Originally when we began persisting host information such a tokens/host_id,
> we would populate gossip with this information. At some point we began only
> populating TokenMetadata, which gives us most of the same benefit, but in a
> full ring restart where the gossip ether is empty, it populates useless info
> such as :
> {quote}
> /10.101.32.212
> generation:0
> heartbeat:0
> TOKENS: not present
> {quote}
> which is the minimum required for a state to exist. Instead we should keep
> gossip in sync with TMD when populating this information like we used to do.
--
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-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[
https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322388#comment-17322388
]
Andres de la Peña commented on CASSANDRA-14361:
---
[~miles.garnsey] I think this was underprioritized as an improvement for 4.0.x,
to be done after the 4.0.0 code freeze. Other than that the patch is almost
ready, on my side there is only some minor PR comments and the question about
the {{seed_provider}} section.
> Allow SimpleSeedProvider to resolve multiple IPs per DNS name
> -
>
> Key: CASSANDRA-14361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14361
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ben Bromhead
>Assignee: Ben Bromhead
>Priority: Low
> Fix For: 4.0.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently SimpleSeedProvider can accept a comma separated string of IPs or
> hostnames as the set of Cassandra seeds. hostnames are resolved via
> InetAddress.getByName, which will only return the first IP associated with an
> A, or CNAME record.
> By changing to InetAddress.getAllByName, existing behavior is preserved, but
> now Cassandra can discover multiple IP address per record, allowing seed
> discovery by DNS to be a little easier.
> Some examples of improved workflows with this change include:
> * specify the DNS name of a headless service in Kubernetes which will
> resolve to all IP addresses of pods within that service.
> * seed discovery for multi-region clusters via AWS route53, AzureDNS etc
> * Other common DNS service discovery mechanisms.
> The only behavior this is likely to impact would be where users are relying
> on the fact that getByName only returns a single IP address.
> I can't imagine any scenario where that is a sane choice. Even when that
> choice has been made, it only impacts the first startup of Cassandra and
> would not be on any critical path.
--
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-16238) Fix flaky jvm-dtests that fail with Unable to contact any seeds
[
https://issues.apache.org/jira/browse/CASSANDRA-16238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg reassigned CASSANDRA-16238:
-
Assignee: (was: Adam Holmberg)
> Fix flaky jvm-dtests that fail with Unable to contact any seeds
> ---
>
> Key: CASSANDRA-16238
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16238
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: 16238-archived-failures.txt
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4231
> {code}
> test teardown failure
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795),
> ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795)]
> {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-16238) Fix flaky jvm-dtests that fail with Unable to contact any seeds
[
https://issues.apache.org/jira/browse/CASSANDRA-16238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16238:
--
Component/s: (was: Test/dtest/python)
Test/dtest/java
> Fix flaky jvm-dtests that fail with Unable to contact any seeds
> ---
>
> Key: CASSANDRA-16238
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16238
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: 16238-archived-failures.txt
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4231
> {code}
> test teardown failure
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795),
> ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795)]
> {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-16238) Fix flaky jvm-dtests that fail with Unable to contact any seeds
[
https://issues.apache.org/jira/browse/CASSANDRA-16238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16238:
--
Summary: Fix flaky jvm-dtests that fail with Unable to contact any seeds
(was: Fix flaky test test_insert_data_during_replace_same_address -
replace_address_test.TestReplaceAddress)
> Fix flaky jvm-dtests that fail with Unable to contact any seeds
> ---
>
> Key: CASSANDRA-16238
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16238
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: 16238-archived-failures.txt
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4231
> {code}
> test teardown failure
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795),
> ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795)]
> {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-16238) Fix flaky test test_insert_data_during_replace_same_address - replace_address_test.TestReplaceAddress
[
https://issues.apache.org/jira/browse/CASSANDRA-16238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16238:
--
Resolution: (was: Cannot Reproduce)
Status: Open (was: Resolved)
I am reopening as this error impacts any multi-node jvm-dtest and not localized
to a single test
Examples:
*
https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/659/tests/
hostReplaceAbruptShutdown –
org.apache.cassandra.distributed.test.hostreplacement.HostReplacementAbruptDownedInstanceTest
{code}
java.lang.IllegalStateException: Unable to contact any seeds!
at
org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1749)
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1054)
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1015)
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:799)
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:729)
at
org.apache.cassandra.distributed.impl.Instance.lambda$startup$10(Instance.java:541)
{code}
* CASSANDRA-15239
> Fix flaky test test_insert_data_during_replace_same_address -
> replace_address_test.TestReplaceAddress
> -
>
> Key: CASSANDRA-16238
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16238
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc1, 4.0
>
> Attachments: 16238-archived-failures.txt
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4231
> {code}
> test teardown failure
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795),
> ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795)]
> {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-16238) Fix flaky test test_insert_data_during_replace_same_address - replace_address_test.TestReplaceAddress
[
https://issues.apache.org/jira/browse/CASSANDRA-16238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16238:
--
Fix Version/s: (was: 4.0-rc1)
(was: 4.0)
4.0-rc
> Fix flaky test test_insert_data_during_replace_same_address -
> replace_address_test.TestReplaceAddress
> -
>
> Key: CASSANDRA-16238
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16238
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: 16238-archived-failures.txt
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4231
> {code}
> test teardown failure
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795),
> ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795)]
> {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-16599) Use source release of python driver from pip rather than GitHub
[ https://issues.apache.org/jira/browse/CASSANDRA-16599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322334#comment-17322334 ] David Capwell commented on CASSANDRA-16599: --- [~mck] approved in GH; reviewing the Jenkins tests and they look like the normal ones I see. Once I finish review, ill make sure to file JIRAs (or link) or look see if this patch caused. > Use source release of python driver from pip rather than GitHub > --- > > Key: CASSANDRA-16599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16599 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > We pull python driver from GitHub but we should pull it from pip 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] [Comment Edited] (CASSANDRA-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322327#comment-17322327
]
Yifan Cai edited comment on CASSANDRA-16595 at 4/15/21, 5:11 PM:
-
OK on updating the circleCI yaml in CASSANDRA-16604, as long as it is planned.
The new fix solved the issue that no tests are started. The test now runs -and
passes-.
https://app.circleci.com/pipelines/github/yifan-c/cassandra/234/workflows/4db13bf2-ffa2-4a53-b88f-50627da3993d
(The front page showed a green check, but the job indicated that there were 18
failed tests)
was (Author: yifanc):
OK on updating the circleCI yaml in CASSANDRA-16604, as long as it is planned.
The new fix solved the issue that no tests are started. The test now runs and
passes.
https://app.circleci.com/pipelines/github/yifan-c/cassandra/234/workflows/4db13bf2-ffa2-4a53-b88f-50627da3993d
+1
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-16561) Gossip is not populated with tokens/host_ids
[
https://issues.apache.org/jira/browse/CASSANDRA-16561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322328#comment-17322328
]
Brandon Williams commented on CASSANDRA-16561:
--
Also note that since we init the saved state with a generation and max version
of zero, we won't send these in a digest since they won't be seen as changed.
Thus adding them is doubly useless since we never send them in the shadow
round, but if we did they wouldn't contain any information.
> Gossip is not populated with tokens/host_ids
>
>
> Key: CASSANDRA-16561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16561
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x
>
>
> Originally when we began persisting host information such a tokens/host_id,
> we would populate gossip with this information. At some point we began only
> populating TokenMetadata, which gives us most of the same benefit, but in a
> full ring restart where the gossip ether is empty, it populates useless info
> such as :
> {quote}
> /10.101.32.212
> generation:0
> heartbeat:0
> TOKENS: not present
> {quote}
> which is the minimum required for a state to exist. Instead we should keep
> gossip in sync with TMD when populating this information like we used to do.
--
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-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322327#comment-17322327
]
Yifan Cai commented on CASSANDRA-16595:
---
OK on updating the circleCI yaml in CASSANDRA-16604, as long as it is planned.
The new fix solved the issue that no tests are started. The test now runs and
passes.
https://app.circleci.com/pipelines/github/yifan-c/cassandra/234/workflows/4db13bf2-ffa2-4a53-b88f-50627da3993d
+1
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-16588) NPE getting host_id in Gossiper.isSafeForStartup
[
https://issues.apache.org/jira/browse/CASSANDRA-16588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322315#comment-17322315
]
Brandon Williams edited comment on CASSANDRA-16588 at 4/15/21, 4:53 PM:
Your 3.11 build aborted for some reason, I started it again.
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/667/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/667/pipeline]
I was a bit concerned that we could get a valid shadow ack where our own IP was
somehow missing HOST_ID, causing us to stay in shadow forever and fail startup.
In fact, our empty state from CASSANDRA-16561 would do this if not for the
fact that since the generation and version are zero, the seed will filter
sending the empty state out (by luck of neither generation nor version being
perceived as changed.) So I opted for detecting the bad ack as specifically as
possible.
That said, there may be other unintentional bad responses possible here that
your patch would catch and prevent the NPE. I'm not sure which route is best.
was (Author: brandon.williams):
Your 3.11 build aborted for some reason, I started it again.
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/666/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/666/pipeline]
I was a bit concerned that we could get a valid shadow ack where our own IP was
somehow missing HOST_ID, causing us to stay in shadow forever and fail startup.
In fact, our empty state from CASSANDRA-16561 would do this if not for the
fact that since the generation and version are zero, the seed will filter
sending the empty state out (by luck of neither generation nor version being
perceived as changed.) So I opted for detecting the bad ack as specifically as
possible.
That said, there may be other unintentional bad responses possible here that
your patch would catch and prevent the NPE. I'm not sure which route is best.
> NPE getting host_id in Gossiper.isSafeForStartup
>
>
> Key: CASSANDRA-16588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16588
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0-rc
>
>
> As seen here:
> https://ci-cassandra.apache.org/job/Cassandra-devbranch/604/testReport/junit/org.apache.cassandra.distributed.upgrade/MixedModeGossipTest/testStatusFieldShouldExistInOldVersionNodesEdgeCase/
> {noformat}
> java.lang.NullPointerException
> at org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:952)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:657)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:933)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:784)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:729)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$10(Instance.java:541)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I believe what is happening is a GossipDigestAck has been queued to ack the
> shutdown state from the node on the seed, but isn't actually sent until the
> node has restarted and gone into shadow. Since the ack contains the node's
> IP, it assumes a host_id will be there but since this is not an actual shadow
> response, it is not.
--
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-16588) NPE getting host_id in Gossiper.isSafeForStartup
[
https://issues.apache.org/jira/browse/CASSANDRA-16588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322315#comment-17322315
]
Brandon Williams commented on CASSANDRA-16588:
--
Your 3.11 build aborted for some reason, I started it again.
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/666/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/666/pipeline]
I was a bit concerned that we could get a valid shadow ack where our own IP was
somehow missing HOST_ID, causing us to stay in shadow forever and fail startup.
In fact, our empty state from CASSANDRA-16561 would do this if not for the
fact that since the generation and version are zero, the seed will filter
sending the empty state out (by luck of neither generation nor version being
perceived as changed.) So I opted for detecting the bad ack as specifically as
possible.
That said, there may be other unintentional bad responses possible here that
your patch would catch and prevent the NPE. I'm not sure which route is best.
> NPE getting host_id in Gossiper.isSafeForStartup
>
>
> Key: CASSANDRA-16588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16588
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0-rc
>
>
> As seen here:
> https://ci-cassandra.apache.org/job/Cassandra-devbranch/604/testReport/junit/org.apache.cassandra.distributed.upgrade/MixedModeGossipTest/testStatusFieldShouldExistInOldVersionNodesEdgeCase/
> {noformat}
> java.lang.NullPointerException
> at org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:952)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:657)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:933)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:784)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:729)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$10(Instance.java:541)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I believe what is happening is a GossipDigestAck has been queued to ack the
> shutdown state from the node on the seed, but isn't actually sent until the
> node has restarted and gone into shadow. Since the ack contains the node's
> IP, it assumes a host_id will be there but since this is not an actual shadow
> response, it is not.
--
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-16599) Use source release of python driver from pip rather than GitHub
[ https://issues.apache.org/jira/browse/CASSANDRA-16599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Holmberg updated CASSANDRA-16599: -- Reviewers: Adam Holmberg, Michael Semb Wever (was: Michael Semb Wever) > Use source release of python driver from pip rather than GitHub > --- > > Key: CASSANDRA-16599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16599 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > We pull python driver from GitHub but we should pull it from pip 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] [Commented] (CASSANDRA-16599) Use source release of python driver from pip rather than GitHub
[ https://issues.apache.org/jira/browse/CASSANDRA-16599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322306#comment-17322306 ] Adam Holmberg commented on CASSANDRA-16599: --- The branch looks good to me. > Use source release of python driver from pip rather than GitHub > --- > > Key: CASSANDRA-16599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16599 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > We pull python driver from GitHub but we should pull it from pip 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] [Comment Edited] (CASSANDRA-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322272#comment-17322272
]
Michael Semb Wever edited comment on CASSANDRA-16595 at 4/15/21, 4:13 PM:
--
Fix is
https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16595-fix/trunk
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/665/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/665/pipeline/]
circleci:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra?branch=mck%2F16595-fix%2Ftrunk
was (Author: michaelsembwever):
Fix is
https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16595-fix/trunk
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/664/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/664/pipeline/]
circleci:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra?branch=mck%2F16595-fix%2Ftrunk
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-16545) Cluster topology change may produce false unavailable for queries
[
https://issues.apache.org/jira/browse/CASSANDRA-16545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-16545:
--
Fix Version/s: (was: 4.0-rc2)
4.0-rc1
Since Version: 4.0-alpha1
Source Control Link:
https://github.com/apache/cassandra/commit/b915688ea878aaa284f5cedeb799c5f797c4d824
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed to trunk as
[b915688|https://github.com/apache/cassandra/commit/b915688ea878aaa284f5cedeb799c5f797c4d824]
> Cluster topology change may produce false unavailable for queries
> -
>
> Key: CASSANDRA-16545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16545
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-rc1
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When the coordinator processes a query, it first gets the
> {{ReplicationStrategy}} (RS) from the keyspace to decide the peers to
> contact. Again, it gets the RS to perform the liveness check for the
> requested CL.
> The RS is a volatile filed in Keyspace, and it is possible that those 2
> getter calls return different RS values in the presence of cluster topology
> changes, e.g. add a node, etc.
> In such scenario, the check at the second step can throw an unexpected
> unavailable. From the perspective of the query, the cluster can satisfy the
> CL.
> We should use a consistent view of RS during the peer selection and CL
> liveness check. In other word, both steps should reference to the same RS
> object. It is also more clear and easier to reason about to the clients. Such
> queries are made before the topology change.
--
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 false unavailable for queries due to cluster topology changes
This is an automated email from the ASF dual-hosted git repository.
ycai 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 b915688 Fix false unavailable for queries due to cluster topology
changes
b915688 is described below
commit b915688ea878aaa284f5cedeb799c5f797c4d824
Author: Yifan Cai
AuthorDate: Wed Apr 14 13:05:55 2021 -0700
Fix false unavailable for queries due to cluster topology changes
patch by Yifan Cai; reviewed by Aleksey Yeschenko, Andres de la Peña for
CASSANDRA-16545
---
CHANGES.txt| 1 +
.../apache/cassandra/batchlog/BatchlogManager.java | 4 +-
.../cql3/statements/ModificationStatement.java | 4 +-
.../cassandra/cql3/statements/SelectStatement.java | 2 +-
.../org/apache/cassandra/db/ConsistencyLevel.java | 71 +++--
.../org/apache/cassandra/db/CounterMutation.java | 6 +-
.../org/apache/cassandra/db/view/ViewUtils.java| 4 +-
.../apache/cassandra/locator/ReplicaLayout.java| 56 ++--
.../org/apache/cassandra/locator/ReplicaPlan.java | 43 +--
.../org/apache/cassandra/locator/ReplicaPlans.java | 112
.../apache/cassandra/locator/TokenMetadata.java| 3 +-
.../DatacenterSyncWriteResponseHandler.java| 6 +-
.../org/apache/cassandra/service/StorageProxy.java | 51 ++--
.../service/reads/ReplicaFilteringProtection.java | 6 +-
.../service/reads/repair/AbstractReadRepair.java | 2 +-
.../service/reads/repair/BlockingReadRepairs.java | 2 +-
.../apache/cassandra/db/view/ViewUtilsTest.java| 6 +-
.../locator/AssureSufficientLiveNodesTest.java | 303 +
.../service/WriteResponseHandlerTransientTest.java | 8 +-
.../cassandra/service/reads/DataResolverTest.java | 4 +-
.../service/reads/DigestResolverTest.java | 2 +-
.../cassandra/service/reads/ReadExecutorTest.java | 2 +-
.../reads/repair/AbstractReadRepairTest.java | 12 +-
.../reads/repair/BlockingReadRepairTest.java | 12 +-
.../service/reads/repair/ReadRepairTest.java | 12 +-
25 files changed, 537 insertions(+), 197 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 8551edf..efd6c60 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0-rc1
+ * Fix false unavailable for queries due to cluster topology changes
(CASSANDRA-16545)
* Fixed a race condition issue in nodetool repair where we poll for the error
before seeing the error notification, leading to a less meaningful message
(CASSANDRA-16585)
* Fix mixed cluster GROUP BY queries (CASSANDRA-16582)
* Upgrade jflex to 1.8.2 (CASSANDRA-16576)
diff --git a/src/java/org/apache/cassandra/batchlog/BatchlogManager.java
b/src/java/org/apache/cassandra/batchlog/BatchlogManager.java
index 9a009dc..65ed71e 100644
--- a/src/java/org/apache/cassandra/batchlog/BatchlogManager.java
+++ b/src/java/org/apache/cassandra/batchlog/BatchlogManager.java
@@ -489,8 +489,8 @@ public class BatchlogManager implements BatchlogManagerMBean
Hint.create(mutation, writtenAt));
}
-ReplicaPlan.ForTokenWrite replicaPlan = new
ReplicaPlan.ForTokenWrite(keyspace, ConsistencyLevel.ONE,
-liveRemoteOnly.pending(), liveRemoteOnly.all(),
liveRemoteOnly.all(), liveRemoteOnly.all());
+ReplicaPlan.ForTokenWrite replicaPlan = new
ReplicaPlan.ForTokenWrite(keyspace, liveAndDown.replicationStrategy(),
+ConsistencyLevel.ONE, liveRemoteOnly.pending(),
liveRemoteOnly.all(), liveRemoteOnly.all(), liveRemoteOnly.all());
ReplayWriteResponseHandler handler = new
ReplayWriteResponseHandler<>(replicaPlan, System.nanoTime());
Message message = Message.outWithFlag(MUTATION_REQ,
mutation, MessageFlag.CALL_BACK_ON_FAILURE);
for (Replica replica : liveRemoteOnly.all())
diff --git
a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
index 0ba105c..785e6bd 100644
--- a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
@@ -383,7 +383,7 @@ public abstract class ModificationStatement implements
CQLStatement
try
{
-cl.validateForRead(keyspace());
+cl.validateForRead();
}
catch (InvalidRequestException e)
{
@@ -463,7 +463,7 @@ public abstract class ModificationStatement implements
CQLStatement
if (isCounter())
cl.validateCounterForWrite(metadata());
else
-cl.validateForWrite(metadata.keyspace);
+cl.validateForWrite();
List mutations =
getMutations(options,
diff --git
[jira] [Comment Edited] (CASSANDRA-16545) Cluster topology change may produce false unavailable for queries
[
https://issues.apache.org/jira/browse/CASSANDRA-16545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17321293#comment-17321293
]
Yifan Cai edited comment on CASSANDRA-16545 at 4/15/21, 3:53 PM:
-
Starting commit
CI Results:
||Branch||Source||Circle CI||Jenkins||
|trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-16545-trunk-A70927C8-3771-4980-809D-C36119B6B351]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-16545-trunk-A70927C8-3771-4980-809D-C36119B6B351]|[build|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/658/pipeline]|
CI and Jenkins has a few unrelated failures.
was (Author: yifanc):
Starting commit
CI Results (pending):
|| Branch || Source || Circle CI || Jenkins ||
|trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-16545-trunk-A70927C8-3771-4980-809D-C36119B6B351]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-16545-trunk-A70927C8-3771-4980-809D-C36119B6B351]|[build|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/658/pipeline]|
> Cluster topology change may produce false unavailable for queries
> -
>
> Key: CASSANDRA-16545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16545
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-rc2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When the coordinator processes a query, it first gets the
> {{ReplicationStrategy}} (RS) from the keyspace to decide the peers to
> contact. Again, it gets the RS to perform the liveness check for the
> requested CL.
> The RS is a volatile filed in Keyspace, and it is possible that those 2
> getter calls return different RS values in the presence of cluster topology
> changes, e.g. add a node, etc.
> In such scenario, the check at the second step can throw an unexpected
> unavailable. From the perspective of the query, the cluster can satisfy the
> CL.
> We should use a consistent view of RS during the peer selection and CL
> liveness check. In other word, both steps should reference to the same RS
> object. It is also more clear and easier to reason about to the clients. Such
> queries are made before the topology change.
--
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-16603) Sporadic CQL operation timeout due to unconfigured table
[
https://issues.apache.org/jira/browse/CASSANDRA-16603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322276#comment-17322276
]
Brandon Williams commented on CASSANDRA-16603:
--
If you're injecting over 15 minutes of sleep into a call I don't think any
results here are surprising or indicative of a real problem.
> Sporadic CQL operation timeout due to unconfigured table
>
>
> Key: CASSANDRA-16603
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16603
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
>Reporter: Haoze Wu
>Priority: Normal
>
> We were doing some systematic testing in Cassandra stable release 3.11.10
> and found the disk I/O delay may cause some issues.
> We start a Cassandra cluster of 3 nodes with the default configuration,
> in node 1, we open the cqlsh shell and type in:
> {code:java}
> create keyspace ycsb WITH REPLICATION = {'class' : 'SimpleStrategy',
> 'replication_factor': 3 };
> USE ycsb;
> create table usertable (
> y_id varchar primary key,
> field0 varchar,
> field1 varchar,
> field2 varchar,
> field3 varchar,
> field4 varchar,
> field5 varchar,
> field6 varchar,
> field7 varchar,
> field8 varchar,
> field9 varchar);
> {code}
> During this process, we inject a single disk I/O delay in node 2’s
> CommitLog#add method (e.g., in Mutation.serializer.serialize).
> {code:java}
> /**
> * Add a Mutation to the commit log. If CDC is enabled, this can fail.
> *
> * @param mutation the Mutation to add to the log
> * @throws WriteTimeoutException
> */
> public CommitLogPosition add(Mutation mutation) throws
> WriteTimeoutException
> {
> assert mutation != null;
> try (DataOutputBuffer dob = DataOutputBuffer.scratchBuffer.get())
> {
> Mutation.serializer.serialize(mutation, dob,
> MessagingService.current_version);
> int size = dob.getLength();
> int totalSize = size + ENTRY_OVERHEAD_SIZE;
> if (totalSize > MAX_MUTATION_SIZE)
> {
> throw new IllegalArgumentException(String.format("Mutation of
> %s is too large for the maximum size of %s",
>
> FBUtilities.prettyPrintMemory(totalSize),
>
> FBUtilities.prettyPrintMemory(MAX_MUTATION_SIZE)));
> }
> // ...
> }
> catch (IOException e)
> {
> throw new FSWriteError(e,
> segmentManager.allocatingFrom().getPath());
> }
> }
> {code}
> In the aforementioned cqlsh shell connected to node 1, when it runs the
> command of “create table usertable ...”, it costs more time than normal, and
> finally shows a warning message:
> {code:java}
> Warning: schema version mismatch detected; check the schema versions of your
> nodes in system.local and system.peers.
> {code}
> This behavior seems reasonable because our injection affects node 2.
> When we open another cqlsh shell connecting to node 2, intent to run some
> commands on the created table:
> {code:java}
> USE ycsb;
> {code}
> The cqlsh shell shows an error message:
> {code:java}
> InvalidRequest: Error from server: code=2200 [Invalid query]
> message="unconfigured table t"
> {code}
> It seems reasonable, too, because our injection affects node 2. However,
> when we run a cqlsh shell connecting to node 1 again, and try to run some
> commands like:
> {code:java}
> USE ycsb;
> SELECT * FROM usertable;
> {code}
> Most of the time, the result is shown immediately. However, sometimes it
> gets stuck for a few seconds, and shows the error message:
> {code:java}
> ReadTimeout: Error from server: code=1200 [Coordinator node timed out waiting
> for replica nodes' responses] message="Operation timed out - received only 0
> responses." info={'received_responses': 0, 'required_responses': 1,
> 'consistency': 'ONE'}
> {code}
> A more reliable way to reproduce this failure is using our client based
> on datastax (see [https://github.com/functioner/datastax-cassandra-client]).
> We have dump the jstack for node 2 when the issue happens:
> {code:java}
> "MutationStage-1" #90 daemon prio=5 os_prio=0 tid=0x7f858429c880
> nid=0x6f23 waiting on condition [0x7f856889e000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:246)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:593)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:470)
> at
[jira] [Updated] (CASSANDRA-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16595:
---
Status: Patch Available (was: In Progress)
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322272#comment-17322272
]
Michael Semb Wever edited comment on CASSANDRA-16595 at 4/15/21, 3:29 PM:
--
Fix is
https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16595-fix/trunk
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/664/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/664/pipeline/]
circleci:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra?branch=mck%2F16595-fix%2Ftrunk
was (Author: michaelsembwever):
Fix is
https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16595-fix/trunk
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/664/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/664/pipeline/]
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322272#comment-17322272
]
Michael Semb Wever commented on CASSANDRA-16595:
Fix is
https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16595-fix/trunk
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/664/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/664/pipeline/]
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-16524) Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16524:
Reviewers: Berenguer Blasi, Ekaterina Dimitrova, Zhao Yang (was: Berenguer
Blasi, Zhao Yang)
> Upgrading SSL enabled Cassandra cluster from 3.11.10 to 4.0-beta4 failing
> with javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16524
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
> Attachments: system.log.ssl-error.txt
>
>
> Hi,
> We have SSL enabled cluster running on Apache Cassandra 3.11.10 and we are
> trying to upgrade it to 4.0-beta4 as a part of testing.
> Cluster size is 3x3 and deployed on Azure IaaS.
> {noformat}
> [cassandra@cass-521828978-1-1189299202 ~]$ nodetool status
> Datacenter: southcentral
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.74.31 85.61 KiB 16 32.2%
> 6db7a7ef-3490-4823-9ff3-c60a32165124 2
> UN 10.12.74.42 263.27 KiB 16 27.6%
> 7ad99ecf-7c7d-4780-872b-7c68b6b19849 1
> UN 10.12.74.34 85.61 KiB 16 37.8%
> 41ce16b7-2ab2-44ea-a810-8391f7f3caf2 0
> Datacenter: westus
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 10.12.90.11 90.63 KiB 16 38.9%
> 8d4cdb65-ff66-4bcd-8d4b-a4a0e893a728 2
> UN 10.12.90.6 85.61 KiB 16 34.5%
> 4f8007e9-fa3e-4e99-a9f9-f7bf9625 1
> UN 10.12.89.80 94.1 KiB 16 28.9%
> 11f86cb0-c86b-440e-848f-b160118f43d5 0
> {noformat}
> We placed a new 4.0-beta4 binary on the first seed node (10.12.74.310) and
> starting Cassandra.
> It started throwing the below error:
> {noformat}
> ERROR [Messaging-EventLoop-3-11] 2021-03-15 22:10:05,188
> InboundConnectionInitiator.java:342 - Failed to properly handshake with peer
> /10.12.74.42:52356. Closing the channel.
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException:
> java.lang.IndexOutOfBoundsException: writerIndex(8560) +
> minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException:
> writerIndex(8560) + minWritableBytes(1977) exceeds maxCapacity(10240):
> BufferPoolAllocator$Wrapped(ridx: 0, widx: 8560, cap: 10240/10240)
> at
> io.netty.handler.ssl.OpenSslKeyMaterialManager.setKeyMaterial(OpenSslKeyMaterialManager.java:115)
> at
>
[jira] [Comment Edited] (CASSANDRA-16603) Sporadic CQL operation timeout due to unconfigured table
[
https://issues.apache.org/jira/browse/CASSANDRA-16603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322242#comment-17322242
]
Haoze Wu edited comment on CASSANDRA-16603 at 4/15/21, 2:52 PM:
Suppose you have 3 source repo (src-1, src-2, src-3) for node 1, 2, 3. All of
them are Cassandra-3.11.10.
In src-2, org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:237),
add the following code:
{code:java}
StackTraceElement[] es = Thread.currentThread().getStackTrace();
String[] s = new String[es.length];
for (int i = 0; i < es.length; i++) {
s[i] = es[i].getClassName() + "," + es[i].getMethodName() + "," +
es[i].getLineNumber();
}
String st = java.util.Arrays.toString(s);
if (st.contains("SystemKeyspace,lambda$updatePeerInfo$1") && ++cc == 22) {
logger.info("my injection " + st);
try {Thread.sleep(100);} catch(Exception e){}
}
{code}
Also, in src-2 CommitLog.java, remember to add:
{code:java}
private static volatile int cc = 0;
{code}
The intention is to inject a delay in the 22th invocation from
`SystemKeyspace,lambda$updatePeerInfo$1`, when running our provided client
workload.
Then compile the code and start the Cassandra cluster. We basically use the
default configuration, and we've just pushed our configuration conf-1, conf-2,
conf-3 in [https://github.com/functioner/datastax-cassandra-client] for the
reference.
Then follow the instructions in
[https://github.com/functioner/datastax-cassandra-client], and observe
`client-create.out`, `client-read-$i.out` and `client-read-$i.out`.
It can reliably reproduce the issue.
was (Author: functioner):
Suppose you have 3 source repo (src-1, src-2, src-3) for node 1, 2, 3. All of
them are Cassandra-3.11.10.
In src-2, org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:237),
add the following code:
{code:java}
StackTraceElement[] es = Thread.currentThread().getStackTrace();
String[] s = new String[es.length];
for (int i = 0; i < es.length; i++) {
s[i] = es[i].getClassName() + "," + es[i].getMethodName() + "," +
es[i].getLineNumber();
}
String st = java.util.Arrays.toString(s);
if (st.contains("SystemKeyspace,lambda$updatePeerInfo$1") && ++cc == 22) {
logger.info("whz qwer inject " + st);
try {Thread.sleep(100);} catch(Exception e){}
}
{code}
Also, in src-2 CommitLog.java, remember to add:
{code:java}
private static volatile int cc = 0;
{code}
The intention is to inject a delay in the 22th invocation from
`SystemKeyspace,lambda$updatePeerInfo$1`, when running our provided client
workload.
Then compile the code and start the Cassandra cluster. We basically use the
default configuration, and we've just pushed our configuration conf-1, conf-2,
conf-3 in [https://github.com/functioner/datastax-cassandra-client] for the
reference.
Then follow the instructions in
[https://github.com/functioner/datastax-cassandra-client], and observe
`client-create.out`, `client-read-$i.out` and `client-read-$i.out`.
It can reliably reproduce the issue.
> Sporadic CQL operation timeout due to unconfigured table
>
>
> Key: CASSANDRA-16603
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16603
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
>Reporter: Haoze Wu
>Priority: Normal
>
> We were doing some systematic testing in Cassandra stable release 3.11.10
> and found the disk I/O delay may cause some issues.
> We start a Cassandra cluster of 3 nodes with the default configuration,
> in node 1, we open the cqlsh shell and type in:
> {code:java}
> create keyspace ycsb WITH REPLICATION = {'class' : 'SimpleStrategy',
> 'replication_factor': 3 };
> USE ycsb;
> create table usertable (
> y_id varchar primary key,
> field0 varchar,
> field1 varchar,
> field2 varchar,
> field3 varchar,
> field4 varchar,
> field5 varchar,
> field6 varchar,
> field7 varchar,
> field8 varchar,
> field9 varchar);
> {code}
> During this process, we inject a single disk I/O delay in node 2’s
> CommitLog#add method (e.g., in Mutation.serializer.serialize).
> {code:java}
> /**
> * Add a Mutation to the commit log. If CDC is enabled, this can fail.
> *
> * @param mutation the Mutation to add to the log
> * @throws WriteTimeoutException
> */
> public CommitLogPosition add(Mutation mutation) throws
> WriteTimeoutException
> {
> assert mutation != null;
> try (DataOutputBuffer dob = DataOutputBuffer.scratchBuffer.get())
> {
> Mutation.serializer.serialize(mutation, dob,
> MessagingService.current_version);
> int size =
[jira] [Commented] (CASSANDRA-16603) Sporadic CQL operation timeout due to unconfigured table
[
https://issues.apache.org/jira/browse/CASSANDRA-16603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322242#comment-17322242
]
Haoze Wu commented on CASSANDRA-16603:
--
Suppose you have 3 source repo (src-1, src-2, src-3) for node 1, 2, 3. All of
them are Cassandra-3.11.10.
In src-2, org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:237),
add the following code:
{code:java}
StackTraceElement[] es = Thread.currentThread().getStackTrace();
String[] s = new String[es.length];
for (int i = 0; i < es.length; i++) {
s[i] = es[i].getClassName() + "," + es[i].getMethodName() + "," +
es[i].getLineNumber();
}
String st = java.util.Arrays.toString(s);
if (st.contains("SystemKeyspace,lambda$updatePeerInfo$1") && ++cc == 22) {
logger.info("whz qwer inject " + st);
try {Thread.sleep(100);} catch(Exception e){}
}
{code}
Also, in src-2 CommitLog.java, remember to add:
{code:java}
private static volatile int cc = 0;
{code}
The intention is to inject a delay in the 22th invocation from
`SystemKeyspace,lambda$updatePeerInfo$1`, when running our provided client
workload.
Then compile the code and start the Cassandra cluster. We basically use the
default configuration, and we've just pushed our configuration conf-1, conf-2,
conf-3 in [https://github.com/functioner/datastax-cassandra-client] for the
reference.
Then follow the instructions in
[https://github.com/functioner/datastax-cassandra-client], and observe
`client-create.out`, `client-read-$i.out` and `client-read-$i.out`.
It can reliably reproduce the issue.
> Sporadic CQL operation timeout due to unconfigured table
>
>
> Key: CASSANDRA-16603
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16603
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
>Reporter: Haoze Wu
>Priority: Normal
>
> We were doing some systematic testing in Cassandra stable release 3.11.10
> and found the disk I/O delay may cause some issues.
> We start a Cassandra cluster of 3 nodes with the default configuration,
> in node 1, we open the cqlsh shell and type in:
> {code:java}
> create keyspace ycsb WITH REPLICATION = {'class' : 'SimpleStrategy',
> 'replication_factor': 3 };
> USE ycsb;
> create table usertable (
> y_id varchar primary key,
> field0 varchar,
> field1 varchar,
> field2 varchar,
> field3 varchar,
> field4 varchar,
> field5 varchar,
> field6 varchar,
> field7 varchar,
> field8 varchar,
> field9 varchar);
> {code}
> During this process, we inject a single disk I/O delay in node 2’s
> CommitLog#add method (e.g., in Mutation.serializer.serialize).
> {code:java}
> /**
> * Add a Mutation to the commit log. If CDC is enabled, this can fail.
> *
> * @param mutation the Mutation to add to the log
> * @throws WriteTimeoutException
> */
> public CommitLogPosition add(Mutation mutation) throws
> WriteTimeoutException
> {
> assert mutation != null;
> try (DataOutputBuffer dob = DataOutputBuffer.scratchBuffer.get())
> {
> Mutation.serializer.serialize(mutation, dob,
> MessagingService.current_version);
> int size = dob.getLength();
> int totalSize = size + ENTRY_OVERHEAD_SIZE;
> if (totalSize > MAX_MUTATION_SIZE)
> {
> throw new IllegalArgumentException(String.format("Mutation of
> %s is too large for the maximum size of %s",
>
> FBUtilities.prettyPrintMemory(totalSize),
>
> FBUtilities.prettyPrintMemory(MAX_MUTATION_SIZE)));
> }
> // ...
> }
> catch (IOException e)
> {
> throw new FSWriteError(e,
> segmentManager.allocatingFrom().getPath());
> }
> }
> {code}
> In the aforementioned cqlsh shell connected to node 1, when it runs the
> command of “create table usertable ...”, it costs more time than normal, and
> finally shows a warning message:
> {code:java}
> Warning: schema version mismatch detected; check the schema versions of your
> nodes in system.local and system.peers.
> {code}
> This behavior seems reasonable because our injection affects node 2.
> When we open another cqlsh shell connecting to node 2, intent to run some
> commands on the created table:
> {code:java}
> USE ycsb;
> {code}
> The cqlsh shell shows an error message:
> {code:java}
> InvalidRequest: Error from server: code=2200 [Invalid query]
> message="unconfigured table t"
> {code}
> It seems reasonable, too, because our injection affects node 2. However,
> when we run
[jira] [Commented] (CASSANDRA-16603) Sporadic CQL operation timeout due to unconfigured table
[
https://issues.apache.org/jira/browse/CASSANDRA-16603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1735#comment-1735
]
Brandon Williams commented on CASSANDRA-16603:
--
I meant the modification to the server.
> Sporadic CQL operation timeout due to unconfigured table
>
>
> Key: CASSANDRA-16603
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16603
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
>Reporter: Haoze Wu
>Priority: Normal
>
> We were doing some systematic testing in Cassandra stable release 3.11.10
> and found the disk I/O delay may cause some issues.
> We start a Cassandra cluster of 3 nodes with the default configuration,
> in node 1, we open the cqlsh shell and type in:
> {code:java}
> create keyspace ycsb WITH REPLICATION = {'class' : 'SimpleStrategy',
> 'replication_factor': 3 };
> USE ycsb;
> create table usertable (
> y_id varchar primary key,
> field0 varchar,
> field1 varchar,
> field2 varchar,
> field3 varchar,
> field4 varchar,
> field5 varchar,
> field6 varchar,
> field7 varchar,
> field8 varchar,
> field9 varchar);
> {code}
> During this process, we inject a single disk I/O delay in node 2’s
> CommitLog#add method (e.g., in Mutation.serializer.serialize).
> {code:java}
> /**
> * Add a Mutation to the commit log. If CDC is enabled, this can fail.
> *
> * @param mutation the Mutation to add to the log
> * @throws WriteTimeoutException
> */
> public CommitLogPosition add(Mutation mutation) throws
> WriteTimeoutException
> {
> assert mutation != null;
> try (DataOutputBuffer dob = DataOutputBuffer.scratchBuffer.get())
> {
> Mutation.serializer.serialize(mutation, dob,
> MessagingService.current_version);
> int size = dob.getLength();
> int totalSize = size + ENTRY_OVERHEAD_SIZE;
> if (totalSize > MAX_MUTATION_SIZE)
> {
> throw new IllegalArgumentException(String.format("Mutation of
> %s is too large for the maximum size of %s",
>
> FBUtilities.prettyPrintMemory(totalSize),
>
> FBUtilities.prettyPrintMemory(MAX_MUTATION_SIZE)));
> }
> // ...
> }
> catch (IOException e)
> {
> throw new FSWriteError(e,
> segmentManager.allocatingFrom().getPath());
> }
> }
> {code}
> In the aforementioned cqlsh shell connected to node 1, when it runs the
> command of “create table usertable ...”, it costs more time than normal, and
> finally shows a warning message:
> {code:java}
> Warning: schema version mismatch detected; check the schema versions of your
> nodes in system.local and system.peers.
> {code}
> This behavior seems reasonable because our injection affects node 2.
> When we open another cqlsh shell connecting to node 2, intent to run some
> commands on the created table:
> {code:java}
> USE ycsb;
> {code}
> The cqlsh shell shows an error message:
> {code:java}
> InvalidRequest: Error from server: code=2200 [Invalid query]
> message="unconfigured table t"
> {code}
> It seems reasonable, too, because our injection affects node 2. However,
> when we run a cqlsh shell connecting to node 1 again, and try to run some
> commands like:
> {code:java}
> USE ycsb;
> SELECT * FROM usertable;
> {code}
> Most of the time, the result is shown immediately. However, sometimes it
> gets stuck for a few seconds, and shows the error message:
> {code:java}
> ReadTimeout: Error from server: code=1200 [Coordinator node timed out waiting
> for replica nodes' responses] message="Operation timed out - received only 0
> responses." info={'received_responses': 0, 'required_responses': 1,
> 'consistency': 'ONE'}
> {code}
> A more reliable way to reproduce this failure is using our client based
> on datastax (see [https://github.com/functioner/datastax-cassandra-client]).
> We have dump the jstack for node 2 when the issue happens:
> {code:java}
> "MutationStage-1" #90 daemon prio=5 os_prio=0 tid=0x7f858429c880
> nid=0x6f23 waiting on condition [0x7f856889e000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:246)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:593)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:470)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:250)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:255)
> at
[jira] [Commented] (CASSANDRA-16603) Sporadic CQL operation timeout due to unconfigured table
[
https://issues.apache.org/jira/browse/CASSANDRA-16603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1730#comment-1730
]
Haoze Wu commented on CASSANDRA-16603:
--
The client code is [https://github.com/functioner/datastax-cassandra-client]
> Sporadic CQL operation timeout due to unconfigured table
>
>
> Key: CASSANDRA-16603
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16603
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
>Reporter: Haoze Wu
>Priority: Normal
>
> We were doing some systematic testing in Cassandra stable release 3.11.10
> and found the disk I/O delay may cause some issues.
> We start a Cassandra cluster of 3 nodes with the default configuration,
> in node 1, we open the cqlsh shell and type in:
> {code:java}
> create keyspace ycsb WITH REPLICATION = {'class' : 'SimpleStrategy',
> 'replication_factor': 3 };
> USE ycsb;
> create table usertable (
> y_id varchar primary key,
> field0 varchar,
> field1 varchar,
> field2 varchar,
> field3 varchar,
> field4 varchar,
> field5 varchar,
> field6 varchar,
> field7 varchar,
> field8 varchar,
> field9 varchar);
> {code}
> During this process, we inject a single disk I/O delay in node 2’s
> CommitLog#add method (e.g., in Mutation.serializer.serialize).
> {code:java}
> /**
> * Add a Mutation to the commit log. If CDC is enabled, this can fail.
> *
> * @param mutation the Mutation to add to the log
> * @throws WriteTimeoutException
> */
> public CommitLogPosition add(Mutation mutation) throws
> WriteTimeoutException
> {
> assert mutation != null;
> try (DataOutputBuffer dob = DataOutputBuffer.scratchBuffer.get())
> {
> Mutation.serializer.serialize(mutation, dob,
> MessagingService.current_version);
> int size = dob.getLength();
> int totalSize = size + ENTRY_OVERHEAD_SIZE;
> if (totalSize > MAX_MUTATION_SIZE)
> {
> throw new IllegalArgumentException(String.format("Mutation of
> %s is too large for the maximum size of %s",
>
> FBUtilities.prettyPrintMemory(totalSize),
>
> FBUtilities.prettyPrintMemory(MAX_MUTATION_SIZE)));
> }
> // ...
> }
> catch (IOException e)
> {
> throw new FSWriteError(e,
> segmentManager.allocatingFrom().getPath());
> }
> }
> {code}
> In the aforementioned cqlsh shell connected to node 1, when it runs the
> command of “create table usertable ...”, it costs more time than normal, and
> finally shows a warning message:
> {code:java}
> Warning: schema version mismatch detected; check the schema versions of your
> nodes in system.local and system.peers.
> {code}
> This behavior seems reasonable because our injection affects node 2.
> When we open another cqlsh shell connecting to node 2, intent to run some
> commands on the created table:
> {code:java}
> USE ycsb;
> {code}
> The cqlsh shell shows an error message:
> {code:java}
> InvalidRequest: Error from server: code=2200 [Invalid query]
> message="unconfigured table t"
> {code}
> It seems reasonable, too, because our injection affects node 2. However,
> when we run a cqlsh shell connecting to node 1 again, and try to run some
> commands like:
> {code:java}
> USE ycsb;
> SELECT * FROM usertable;
> {code}
> Most of the time, the result is shown immediately. However, sometimes it
> gets stuck for a few seconds, and shows the error message:
> {code:java}
> ReadTimeout: Error from server: code=1200 [Coordinator node timed out waiting
> for replica nodes' responses] message="Operation timed out - received only 0
> responses." info={'received_responses': 0, 'required_responses': 1,
> 'consistency': 'ONE'}
> {code}
> A more reliable way to reproduce this failure is using our client based
> on datastax (see [https://github.com/functioner/datastax-cassandra-client]).
> We have dump the jstack for node 2 when the issue happens:
> {code:java}
> "MutationStage-1" #90 daemon prio=5 os_prio=0 tid=0x7f858429c880
> nid=0x6f23 waiting on condition [0x7f856889e000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:246)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:593)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:470)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:250)
> at
[jira] [Updated] (CASSANDRA-16606) Update libthrift jar to at least 0.14.0
[ https://issues.apache.org/jira/browse/CASSANDRA-16606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16606: - Complexity: Low Hanging Fruit Component/s: Messaging/Thrift Discovered By: User Report Fix Version/s: 3.11.x 3.0.x 2.2.x Severity: Normal Status: Open (was: Triage Needed) > Update libthrift jar to at least 0.14.0 > --- > > Key: CASSANDRA-16606 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16606 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Thrift >Reporter: Mark Denihan >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x > > > Cassandra 3.x and 2.x uses libthrift 0.9.2, which has a number of > vulnerabilities associated with it which are applicable to Cassandra; > CVE-2015-3254 > CVE-2018-1320 (CASSANDRA-15424) > CVE-2019-0205 (CASSANDRA-15420) > Updating to 0.9.3-1 will mitigate these, however that branch suffers > CVE-2020-13949. > To mitigate risks from using out of date libthrift versions, Cassandra should > be updated to use 0.14.0 -- 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-16603) Sporadic CQL operation timeout due to unconfigured table
[
https://issues.apache.org/jira/browse/CASSANDRA-16603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16603:
-
Bug Category: Parent values: Availability(12983)
Complexity: Challenging
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Sporadic CQL operation timeout due to unconfigured table
>
>
> Key: CASSANDRA-16603
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16603
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
>Reporter: Haoze Wu
>Priority: Normal
>
> We were doing some systematic testing in Cassandra stable release 3.11.10
> and found the disk I/O delay may cause some issues.
> We start a Cassandra cluster of 3 nodes with the default configuration,
> in node 1, we open the cqlsh shell and type in:
> {code:java}
> create keyspace ycsb WITH REPLICATION = {'class' : 'SimpleStrategy',
> 'replication_factor': 3 };
> USE ycsb;
> create table usertable (
> y_id varchar primary key,
> field0 varchar,
> field1 varchar,
> field2 varchar,
> field3 varchar,
> field4 varchar,
> field5 varchar,
> field6 varchar,
> field7 varchar,
> field8 varchar,
> field9 varchar);
> {code}
> During this process, we inject a single disk I/O delay in node 2’s
> CommitLog#add method (e.g., in Mutation.serializer.serialize).
> {code:java}
> /**
> * Add a Mutation to the commit log. If CDC is enabled, this can fail.
> *
> * @param mutation the Mutation to add to the log
> * @throws WriteTimeoutException
> */
> public CommitLogPosition add(Mutation mutation) throws
> WriteTimeoutException
> {
> assert mutation != null;
> try (DataOutputBuffer dob = DataOutputBuffer.scratchBuffer.get())
> {
> Mutation.serializer.serialize(mutation, dob,
> MessagingService.current_version);
> int size = dob.getLength();
> int totalSize = size + ENTRY_OVERHEAD_SIZE;
> if (totalSize > MAX_MUTATION_SIZE)
> {
> throw new IllegalArgumentException(String.format("Mutation of
> %s is too large for the maximum size of %s",
>
> FBUtilities.prettyPrintMemory(totalSize),
>
> FBUtilities.prettyPrintMemory(MAX_MUTATION_SIZE)));
> }
> // ...
> }
> catch (IOException e)
> {
> throw new FSWriteError(e,
> segmentManager.allocatingFrom().getPath());
> }
> }
> {code}
> In the aforementioned cqlsh shell connected to node 1, when it runs the
> command of “create table usertable ...”, it costs more time than normal, and
> finally shows a warning message:
> {code:java}
> Warning: schema version mismatch detected; check the schema versions of your
> nodes in system.local and system.peers.
> {code}
> This behavior seems reasonable because our injection affects node 2.
> When we open another cqlsh shell connecting to node 2, intent to run some
> commands on the created table:
> {code:java}
> USE ycsb;
> {code}
> The cqlsh shell shows an error message:
> {code:java}
> InvalidRequest: Error from server: code=2200 [Invalid query]
> message="unconfigured table t"
> {code}
> It seems reasonable, too, because our injection affects node 2. However,
> when we run a cqlsh shell connecting to node 1 again, and try to run some
> commands like:
> {code:java}
> USE ycsb;
> SELECT * FROM usertable;
> {code}
> Most of the time, the result is shown immediately. However, sometimes it
> gets stuck for a few seconds, and shows the error message:
> {code:java}
> ReadTimeout: Error from server: code=1200 [Coordinator node timed out waiting
> for replica nodes' responses] message="Operation timed out - received only 0
> responses." info={'received_responses': 0, 'required_responses': 1,
> 'consistency': 'ONE'}
> {code}
> A more reliable way to reproduce this failure is using our client based
> on datastax (see [https://github.com/functioner/datastax-cassandra-client]).
> We have dump the jstack for node 2 when the issue happens:
> {code:java}
> "MutationStage-1" #90 daemon prio=5 os_prio=0 tid=0x7f858429c880
> nid=0x6f23 waiting on condition [0x7f856889e000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:246)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:593)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:470)
> at
[jira] [Commented] (CASSANDRA-16603) Sporadic CQL operation timeout due to unconfigured table
[
https://issues.apache.org/jira/browse/CASSANDRA-16603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322219#comment-17322219
]
Brandon Williams commented on CASSANDRA-16603:
--
Can you share your reproduction code?
> Sporadic CQL operation timeout due to unconfigured table
>
>
> Key: CASSANDRA-16603
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16603
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
>Reporter: Haoze Wu
>Priority: Normal
>
> We were doing some systematic testing in Cassandra stable release 3.11.10
> and found the disk I/O delay may cause some issues.
> We start a Cassandra cluster of 3 nodes with the default configuration,
> in node 1, we open the cqlsh shell and type in:
> {code:java}
> create keyspace ycsb WITH REPLICATION = {'class' : 'SimpleStrategy',
> 'replication_factor': 3 };
> USE ycsb;
> create table usertable (
> y_id varchar primary key,
> field0 varchar,
> field1 varchar,
> field2 varchar,
> field3 varchar,
> field4 varchar,
> field5 varchar,
> field6 varchar,
> field7 varchar,
> field8 varchar,
> field9 varchar);
> {code}
> During this process, we inject a single disk I/O delay in node 2’s
> CommitLog#add method (e.g., in Mutation.serializer.serialize).
> {code:java}
> /**
> * Add a Mutation to the commit log. If CDC is enabled, this can fail.
> *
> * @param mutation the Mutation to add to the log
> * @throws WriteTimeoutException
> */
> public CommitLogPosition add(Mutation mutation) throws
> WriteTimeoutException
> {
> assert mutation != null;
> try (DataOutputBuffer dob = DataOutputBuffer.scratchBuffer.get())
> {
> Mutation.serializer.serialize(mutation, dob,
> MessagingService.current_version);
> int size = dob.getLength();
> int totalSize = size + ENTRY_OVERHEAD_SIZE;
> if (totalSize > MAX_MUTATION_SIZE)
> {
> throw new IllegalArgumentException(String.format("Mutation of
> %s is too large for the maximum size of %s",
>
> FBUtilities.prettyPrintMemory(totalSize),
>
> FBUtilities.prettyPrintMemory(MAX_MUTATION_SIZE)));
> }
> // ...
> }
> catch (IOException e)
> {
> throw new FSWriteError(e,
> segmentManager.allocatingFrom().getPath());
> }
> }
> {code}
> In the aforementioned cqlsh shell connected to node 1, when it runs the
> command of “create table usertable ...”, it costs more time than normal, and
> finally shows a warning message:
> {code:java}
> Warning: schema version mismatch detected; check the schema versions of your
> nodes in system.local and system.peers.
> {code}
> This behavior seems reasonable because our injection affects node 2.
> When we open another cqlsh shell connecting to node 2, intent to run some
> commands on the created table:
> {code:java}
> USE ycsb;
> {code}
> The cqlsh shell shows an error message:
> {code:java}
> InvalidRequest: Error from server: code=2200 [Invalid query]
> message="unconfigured table t"
> {code}
> It seems reasonable, too, because our injection affects node 2. However,
> when we run a cqlsh shell connecting to node 1 again, and try to run some
> commands like:
> {code:java}
> USE ycsb;
> SELECT * FROM usertable;
> {code}
> Most of the time, the result is shown immediately. However, sometimes it
> gets stuck for a few seconds, and shows the error message:
> {code:java}
> ReadTimeout: Error from server: code=1200 [Coordinator node timed out waiting
> for replica nodes' responses] message="Operation timed out - received only 0
> responses." info={'received_responses': 0, 'required_responses': 1,
> 'consistency': 'ONE'}
> {code}
> A more reliable way to reproduce this failure is using our client based
> on datastax (see [https://github.com/functioner/datastax-cassandra-client]).
> We have dump the jstack for node 2 when the issue happens:
> {code:java}
> "MutationStage-1" #90 daemon prio=5 os_prio=0 tid=0x7f858429c880
> nid=0x6f23 waiting on condition [0x7f856889e000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:246)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:593)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:470)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:250)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:255)
> at
[jira] [Commented] (CASSANDRA-16603) Sporadic CQL operation timeout due to unconfigured table
[
https://issues.apache.org/jira/browse/CASSANDRA-16603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322218#comment-17322218
]
Haoze Wu commented on CASSANDRA-16603:
--
[~brandon.williams] After the injection, the node never fully recovers from it
> Sporadic CQL operation timeout due to unconfigured table
>
>
> Key: CASSANDRA-16603
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16603
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
>Reporter: Haoze Wu
>Priority: Normal
>
> We were doing some systematic testing in Cassandra stable release 3.11.10
> and found the disk I/O delay may cause some issues.
> We start a Cassandra cluster of 3 nodes with the default configuration,
> in node 1, we open the cqlsh shell and type in:
> {code:java}
> create keyspace ycsb WITH REPLICATION = {'class' : 'SimpleStrategy',
> 'replication_factor': 3 };
> USE ycsb;
> create table usertable (
> y_id varchar primary key,
> field0 varchar,
> field1 varchar,
> field2 varchar,
> field3 varchar,
> field4 varchar,
> field5 varchar,
> field6 varchar,
> field7 varchar,
> field8 varchar,
> field9 varchar);
> {code}
> During this process, we inject a single disk I/O delay in node 2’s
> CommitLog#add method (e.g., in Mutation.serializer.serialize).
> {code:java}
> /**
> * Add a Mutation to the commit log. If CDC is enabled, this can fail.
> *
> * @param mutation the Mutation to add to the log
> * @throws WriteTimeoutException
> */
> public CommitLogPosition add(Mutation mutation) throws
> WriteTimeoutException
> {
> assert mutation != null;
> try (DataOutputBuffer dob = DataOutputBuffer.scratchBuffer.get())
> {
> Mutation.serializer.serialize(mutation, dob,
> MessagingService.current_version);
> int size = dob.getLength();
> int totalSize = size + ENTRY_OVERHEAD_SIZE;
> if (totalSize > MAX_MUTATION_SIZE)
> {
> throw new IllegalArgumentException(String.format("Mutation of
> %s is too large for the maximum size of %s",
>
> FBUtilities.prettyPrintMemory(totalSize),
>
> FBUtilities.prettyPrintMemory(MAX_MUTATION_SIZE)));
> }
> // ...
> }
> catch (IOException e)
> {
> throw new FSWriteError(e,
> segmentManager.allocatingFrom().getPath());
> }
> }
> {code}
> In the aforementioned cqlsh shell connected to node 1, when it runs the
> command of “create table usertable ...”, it costs more time than normal, and
> finally shows a warning message:
> {code:java}
> Warning: schema version mismatch detected; check the schema versions of your
> nodes in system.local and system.peers.
> {code}
> This behavior seems reasonable because our injection affects node 2.
> When we open another cqlsh shell connecting to node 2, intent to run some
> commands on the created table:
> {code:java}
> USE ycsb;
> {code}
> The cqlsh shell shows an error message:
> {code:java}
> InvalidRequest: Error from server: code=2200 [Invalid query]
> message="unconfigured table t"
> {code}
> It seems reasonable, too, because our injection affects node 2. However,
> when we run a cqlsh shell connecting to node 1 again, and try to run some
> commands like:
> {code:java}
> USE ycsb;
> SELECT * FROM usertable;
> {code}
> Most of the time, the result is shown immediately. However, sometimes it
> gets stuck for a few seconds, and shows the error message:
> {code:java}
> ReadTimeout: Error from server: code=1200 [Coordinator node timed out waiting
> for replica nodes' responses] message="Operation timed out - received only 0
> responses." info={'received_responses': 0, 'required_responses': 1,
> 'consistency': 'ONE'}
> {code}
> A more reliable way to reproduce this failure is using our client based
> on datastax (see [https://github.com/functioner/datastax-cassandra-client]).
> We have dump the jstack for node 2 when the issue happens:
> {code:java}
> "MutationStage-1" #90 daemon prio=5 os_prio=0 tid=0x7f858429c880
> nid=0x6f23 waiting on condition [0x7f856889e000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:246)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:593)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:470)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:250)
> at
[jira] [Updated] (CASSANDRA-15420) CVE-2019-0205(Apache Thrift all versions up to and including 0.12.0) on version Cassendra 3.11.4
[ https://issues.apache.org/jira/browse/CASSANDRA-15420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15420: - Bug Category: Parent values: Security(12985) Complexity: Low Hanging Fruit Component/s: Messaging/Thrift Discovered By: User Report Fix Version/s: 3.11.x 3.0.x 2.2.x Severity: Normal Status: Open (was: Triage Needed) > CVE-2019-0205(Apache Thrift all versions up to and including 0.12.0) on > version Cassendra 3.11.4 > > > Key: CASSANDRA-15420 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15420 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Thrift >Reporter: Abhishek Singh >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x > > > *Description :**Description :* *Severity :* CVE CVSS 3: 7.5Sonatype CVSS 3: > 7.5 > > *Weakness :* CVE CWE: 835 > > *Source :* National Vulnerability Database > > *Categories :* Data > *Description from CVE :* In Apache Thrift all versions up to and including > 0.12.0, a server or client may run into an endless loop when feed with > specific input data. Because the issue had already been partially fixed in > version 0.11.0, depending on the installed version it affects only certain > language bindings. > > *Explanation :* This issue has undergone the Sonatype Fast-Track process. > For more information, please see the Sonatype Knowledge Base Guide. > *Detection :* The application is vulnerable by using this component. > *Recommendation :* We recommend upgrading to a version of this component > that is not vulnerable to this specific issue.Note: If this component is > included as a bundled/transitive dependency of another component, there may > not be an upgrade path. In this instance, we recommend contacting the > maintainers who included the vulnerable package. Alternatively, we recommend > investigating alternative components or a potential mitigating control. > *Advisories :* Project: > http://mail-archives.apache.org/mod_mbox/thrift-dev/201910.m… > > *CVSS Details :* CVE CVSS 3: 7.5CVSS Vector: > CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H > *Occurences (Paths) :* ["apache-cassandra.zip" ; "apache-cassandra.zip"] > *CVE :* CVE-2019-0205 > *URL :* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0205 > *Remediation :* This component does not have any non-vulnerable Version. > Please contact the vendor to get this vulnerability fixed. -- 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-15424) CVE-2018-1320 (The libthrift component is vulnerable to Improper Access Control)
[ https://issues.apache.org/jira/browse/CASSANDRA-15424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15424: - Bug Category: Parent values: Security(12985) Complexity: Low Hanging Fruit Component/s: Messaging/Thrift Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > CVE-2018-1320 (The libthrift component is vulnerable to Improper Access > Control) > > > Key: CASSANDRA-15424 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15424 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Thrift >Reporter: Abhishek Singh >Priority: Normal > > *Description :**Description :* *Severity :* CVE CVSS 3.0: 7.5Sonatype CVSS > 3.0: 8.2 > > *Weakness :* CVE CWE: 20 > > *Source :* National Vulnerability Database > > *Categories :* Data > *Description from CVE :* Apache Thrift Java client library versions 0.5.0 > through 0.11.0 can bypass SASL negotiation isComplete validation in the > org.apache.thrift.transport.TSaslTransport class. An assert used to determine > if the SASL handshake had successfully completed could be disabled in > production settings making the validation incomplete. > > *Explanation :* The libthrift component is vulnerable to Improper Access > Control. The open() method of the TSaslTransport class incorrectly uses an > assertion to validate whether or not the SASL handshake has successfully > completed. In some cases, such as production builds, the assertion > functionality can be disabled rendering the validation incomplete. In such a > case, an attacker can exploit this by being able to login without actually > successfully completing the SASL handshake. > *Detection :* The application is vulnerable by using this component. > *Recommendation :* We recommend upgrading to a version of this component > that is not vulnerable to this specific issue. > *Root Cause :* Cassandra-2.2.5.nupkgTSaslTransport.class : [0.5.0, 0.12.0) > > *Advisories :* Project: > https://lists.apache.org/thread.html/da5234b5e78f1c99190407f... > > *CVSS Details :* CVE CVSS 3.0: 7.5 > *Occurences (Paths) :* [" apache-cassandra.zip/bin/cassandra.in.bat" ; " > apache-cassandra.zip/bin/cassandra.in.sh" ; " > apache-cassandra.zip/bin/cqlsh.bat" ; " > apache-cassandra.zip/bin/debug-cql.bat" ; " > apache-cassandra.zip/bin/source-conf.ps1" ; " > apache-cassandra.zip/bin/sstableloader.bat" ; " > apache-cassandra.zip/bin/sstablescrub.bat" ; " > apache-cassandra.zip/bin/sstableupgrade.bat" ; " > apache-cassandra.zip/bin/sstableverify.bat" ; " > apache-cassandra.zip/bin/stop-server" ; " > apache-cassandra.zip/bin/stop-server.bat" ; " > apache-cassandra.zip/bin/stop-server.ps1" ; " > apache-cassandra.zip/conf/README.txt" ; " > apache-cassandra.zip/conf/cassandra-rackdc.properties" ; " > apache-cassandra.zip/conf/cassandra-topology.properties" ; " > apache-cassandra.zip/conf/commitlog_archiving.properties" ; " > apache-cassandra.zip/conf/triggers/README.txt" ; " > apache-cassandra.zip/lib/ST4-4.0.8.jar" ; " > apache-cassandra.zip/lib/airline-0.6.jar" ; " > apache-cassandra.zip/lib/antlr-runtime-3.5.2.jar" ; " > apache-cassandra.zip/lib/commons-cli-1.1.jar" ; " > apache-cassandra.zip/lib/commons-lang3-3.1.jar" ; " > apache-cassandra.zip/lib/commons-math3-3.2.jar" ; " > apache-cassandra.zip/lib/compress-lzf-0.8.4.jar" ; " > apache-cassandra.zip/lib/concurrentlinkedhashmap-lru-1.4.jar" ; " > apache-cassandra.zip/lib/disruptor-3.0.1.jar" ; " > apache-cassandra.zip/lib/ecj-4.4.2.jar" ; " > apache-cassandra.zip/lib/futures-2.1.6-py2.py3-none-any.zip" ; " > apache-cassandra.zip/lib/high-scale-lib-1.0.6.jar" ; " > apache-cassandra.zip/lib/jamm-0.3.0.jar" ; " > apache-cassandra.zip/lib/javax.inject.jar" ; " > apache-cassandra.zip/lib/jbcrypt-0.3m.jar" ; " > apache-cassandra.zip/lib/jcl-over-slf4j-1.7.7.jar" ; " > apache-cassandra.zip/lib/joda-time-2.4.jar" ; " > apache-cassandra.zip/lib/json-simple-1.1.jar" ; " > apache-cassandra.zip/lib/libthrift-0.9.2.jar" ; " > apache-cassandra.zip/lib/licenses/ST4-4.0.8.txt" ; " > apache-cassandra.zip/lib/licenses/antlr-runtime-3.5.2.txt" ; " > apache-cassandra.zip/lib/licenses/compress-lzf-0.8.4.txt" ; " > apache-cassandra.zip/lib/licenses/concurrent-trees-2.4.0.txt" ; " > apache-cassandra.zip/lib/licenses/ecj-4.4.2.txt" ; " > apache-cassandra.zip/lib/licenses/futures-2.1.6.txt" ; " > apache-cassandra.zip/lib/licenses/high-scale-lib-1.0.6.txt" ; " > apache-cassandra.zip/lib/licenses/jbcrypt-0.3m.txt" ; " > apache-cassandra.zip/lib/licenses/jcl-over-slf4j-1.7.7.txt" ; " > apache-cassandra.zip/lib/licenses/jna-4.2.2.txt" ; " >
[jira] [Updated] (CASSANDRA-15424) CVE-2018-1320 (The libthrift component is vulnerable to Improper Access Control)
[ https://issues.apache.org/jira/browse/CASSANDRA-15424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15424: - Fix Version/s: 3.11.x 3.0.x 2.2.x > CVE-2018-1320 (The libthrift component is vulnerable to Improper Access > Control) > > > Key: CASSANDRA-15424 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15424 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Thrift >Reporter: Abhishek Singh >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x > > > *Description :**Description :* *Severity :* CVE CVSS 3.0: 7.5Sonatype CVSS > 3.0: 8.2 > > *Weakness :* CVE CWE: 20 > > *Source :* National Vulnerability Database > > *Categories :* Data > *Description from CVE :* Apache Thrift Java client library versions 0.5.0 > through 0.11.0 can bypass SASL negotiation isComplete validation in the > org.apache.thrift.transport.TSaslTransport class. An assert used to determine > if the SASL handshake had successfully completed could be disabled in > production settings making the validation incomplete. > > *Explanation :* The libthrift component is vulnerable to Improper Access > Control. The open() method of the TSaslTransport class incorrectly uses an > assertion to validate whether or not the SASL handshake has successfully > completed. In some cases, such as production builds, the assertion > functionality can be disabled rendering the validation incomplete. In such a > case, an attacker can exploit this by being able to login without actually > successfully completing the SASL handshake. > *Detection :* The application is vulnerable by using this component. > *Recommendation :* We recommend upgrading to a version of this component > that is not vulnerable to this specific issue. > *Root Cause :* Cassandra-2.2.5.nupkgTSaslTransport.class : [0.5.0, 0.12.0) > > *Advisories :* Project: > https://lists.apache.org/thread.html/da5234b5e78f1c99190407f... > > *CVSS Details :* CVE CVSS 3.0: 7.5 > *Occurences (Paths) :* [" apache-cassandra.zip/bin/cassandra.in.bat" ; " > apache-cassandra.zip/bin/cassandra.in.sh" ; " > apache-cassandra.zip/bin/cqlsh.bat" ; " > apache-cassandra.zip/bin/debug-cql.bat" ; " > apache-cassandra.zip/bin/source-conf.ps1" ; " > apache-cassandra.zip/bin/sstableloader.bat" ; " > apache-cassandra.zip/bin/sstablescrub.bat" ; " > apache-cassandra.zip/bin/sstableupgrade.bat" ; " > apache-cassandra.zip/bin/sstableverify.bat" ; " > apache-cassandra.zip/bin/stop-server" ; " > apache-cassandra.zip/bin/stop-server.bat" ; " > apache-cassandra.zip/bin/stop-server.ps1" ; " > apache-cassandra.zip/conf/README.txt" ; " > apache-cassandra.zip/conf/cassandra-rackdc.properties" ; " > apache-cassandra.zip/conf/cassandra-topology.properties" ; " > apache-cassandra.zip/conf/commitlog_archiving.properties" ; " > apache-cassandra.zip/conf/triggers/README.txt" ; " > apache-cassandra.zip/lib/ST4-4.0.8.jar" ; " > apache-cassandra.zip/lib/airline-0.6.jar" ; " > apache-cassandra.zip/lib/antlr-runtime-3.5.2.jar" ; " > apache-cassandra.zip/lib/commons-cli-1.1.jar" ; " > apache-cassandra.zip/lib/commons-lang3-3.1.jar" ; " > apache-cassandra.zip/lib/commons-math3-3.2.jar" ; " > apache-cassandra.zip/lib/compress-lzf-0.8.4.jar" ; " > apache-cassandra.zip/lib/concurrentlinkedhashmap-lru-1.4.jar" ; " > apache-cassandra.zip/lib/disruptor-3.0.1.jar" ; " > apache-cassandra.zip/lib/ecj-4.4.2.jar" ; " > apache-cassandra.zip/lib/futures-2.1.6-py2.py3-none-any.zip" ; " > apache-cassandra.zip/lib/high-scale-lib-1.0.6.jar" ; " > apache-cassandra.zip/lib/jamm-0.3.0.jar" ; " > apache-cassandra.zip/lib/javax.inject.jar" ; " > apache-cassandra.zip/lib/jbcrypt-0.3m.jar" ; " > apache-cassandra.zip/lib/jcl-over-slf4j-1.7.7.jar" ; " > apache-cassandra.zip/lib/joda-time-2.4.jar" ; " > apache-cassandra.zip/lib/json-simple-1.1.jar" ; " > apache-cassandra.zip/lib/libthrift-0.9.2.jar" ; " > apache-cassandra.zip/lib/licenses/ST4-4.0.8.txt" ; " > apache-cassandra.zip/lib/licenses/antlr-runtime-3.5.2.txt" ; " > apache-cassandra.zip/lib/licenses/compress-lzf-0.8.4.txt" ; " > apache-cassandra.zip/lib/licenses/concurrent-trees-2.4.0.txt" ; " > apache-cassandra.zip/lib/licenses/ecj-4.4.2.txt" ; " > apache-cassandra.zip/lib/licenses/futures-2.1.6.txt" ; " > apache-cassandra.zip/lib/licenses/high-scale-lib-1.0.6.txt" ; " > apache-cassandra.zip/lib/licenses/jbcrypt-0.3m.txt" ; " > apache-cassandra.zip/lib/licenses/jcl-over-slf4j-1.7.7.txt" ; " > apache-cassandra.zip/lib/licenses/jna-4.2.2.txt" ; " > apache-cassandra.zip/lib/licenses/jstackjunit-0.0.1.txt" ; " > apache-cassandra.zip/lib/licenses/log4j-over-slf4j-1.7.7.txt" ; " >
[jira] [Updated] (CASSANDRA-16606) Update libthrift jar to at least 0.14.0
[ https://issues.apache.org/jira/browse/CASSANDRA-16606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Denihan updated CASSANDRA-16606: - Summary: Update libthrift jar to at least 0.14.0 (was: Update libthrift jar to 0.14.0) > Update libthrift jar to at least 0.14.0 > --- > > Key: CASSANDRA-16606 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16606 > Project: Cassandra > Issue Type: Bug >Reporter: Mark Denihan >Priority: Normal > > Cassandra 3.x and 2.x uses libthrift 0.9.2, which has a number of > vulnerabilities associated with it which are applicable to Cassandra; > CVE-2015-3254 > CVE-2018-1320 (CASSANDRA-15424) > CVE-2019-0205 (CASSANDRA-15420) > Updating to 0.9.3-1 will mitigate these, however that branch suffers > CVE-2020-13949. > To mitigate risks from using out of date libthrift versions, Cassandra should > be updated to use 0.14.0 -- 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-16603) Sporadic CQL operation timeout due to unconfigured table
[
https://issues.apache.org/jira/browse/CASSANDRA-16603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322211#comment-17322211
]
Brandon Williams commented on CASSANDRA-16603:
--
Are you saying after you inject the delay, the node never fully recovers from
it?
> Sporadic CQL operation timeout due to unconfigured table
>
>
> Key: CASSANDRA-16603
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16603
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
>Reporter: Haoze Wu
>Priority: Normal
>
> We were doing some systematic testing in Cassandra stable release 3.11.10
> and found the disk I/O delay may cause some issues.
> We start a Cassandra cluster of 3 nodes with the default configuration,
> in node 1, we open the cqlsh shell and type in:
> {code:java}
> create keyspace ycsb WITH REPLICATION = {'class' : 'SimpleStrategy',
> 'replication_factor': 3 };
> USE ycsb;
> create table usertable (
> y_id varchar primary key,
> field0 varchar,
> field1 varchar,
> field2 varchar,
> field3 varchar,
> field4 varchar,
> field5 varchar,
> field6 varchar,
> field7 varchar,
> field8 varchar,
> field9 varchar);
> {code}
> During this process, we inject a single disk I/O delay in node 2’s
> CommitLog#add method (e.g., in Mutation.serializer.serialize).
> {code:java}
> /**
> * Add a Mutation to the commit log. If CDC is enabled, this can fail.
> *
> * @param mutation the Mutation to add to the log
> * @throws WriteTimeoutException
> */
> public CommitLogPosition add(Mutation mutation) throws
> WriteTimeoutException
> {
> assert mutation != null;
> try (DataOutputBuffer dob = DataOutputBuffer.scratchBuffer.get())
> {
> Mutation.serializer.serialize(mutation, dob,
> MessagingService.current_version);
> int size = dob.getLength();
> int totalSize = size + ENTRY_OVERHEAD_SIZE;
> if (totalSize > MAX_MUTATION_SIZE)
> {
> throw new IllegalArgumentException(String.format("Mutation of
> %s is too large for the maximum size of %s",
>
> FBUtilities.prettyPrintMemory(totalSize),
>
> FBUtilities.prettyPrintMemory(MAX_MUTATION_SIZE)));
> }
> // ...
> }
> catch (IOException e)
> {
> throw new FSWriteError(e,
> segmentManager.allocatingFrom().getPath());
> }
> }
> {code}
> In the aforementioned cqlsh shell connected to node 1, when it runs the
> command of “create table usertable ...”, it costs more time than normal, and
> finally shows a warning message:
> {code:java}
> Warning: schema version mismatch detected; check the schema versions of your
> nodes in system.local and system.peers.
> {code}
> This behavior seems reasonable because our injection affects node 2.
> When we open another cqlsh shell connecting to node 2, intent to run some
> commands on the created table:
> {code:java}
> USE ycsb;
> {code}
> The cqlsh shell shows an error message:
> {code:java}
> InvalidRequest: Error from server: code=2200 [Invalid query]
> message="unconfigured table t"
> {code}
> It seems reasonable, too, because our injection affects node 2. However,
> when we run a cqlsh shell connecting to node 1 again, and try to run some
> commands like:
> {code:java}
> USE ycsb;
> SELECT * FROM usertable;
> {code}
> Most of the time, the result is shown immediately. However, sometimes it
> gets stuck for a few seconds, and shows the error message:
> {code:java}
> ReadTimeout: Error from server: code=1200 [Coordinator node timed out waiting
> for replica nodes' responses] message="Operation timed out - received only 0
> responses." info={'received_responses': 0, 'required_responses': 1,
> 'consistency': 'ONE'}
> {code}
> A more reliable way to reproduce this failure is using our client based
> on datastax (see [https://github.com/functioner/datastax-cassandra-client]).
> We have dump the jstack for node 2 when the issue happens:
> {code:java}
> "MutationStage-1" #90 daemon prio=5 os_prio=0 tid=0x7f858429c880
> nid=0x6f23 waiting on condition [0x7f856889e000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:246)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:593)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:470)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:250)
> at
[jira] [Updated] (CASSANDRA-16606) Update libthrift jar to 0.14.0
[ https://issues.apache.org/jira/browse/CASSANDRA-16606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Denihan updated CASSANDRA-16606: - Bug Category: Parent values: Security(12985)Level 1 values: Denial of Service(13001) > Update libthrift jar to 0.14.0 > -- > > Key: CASSANDRA-16606 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16606 > Project: Cassandra > Issue Type: Bug >Reporter: Mark Denihan >Priority: Normal > > Cassandra 3.x and 2.x uses libthrift 0.9.2, which has a number of > vulnerabilities associated with it which are applicable to Cassandra; > CVE-2015-3254 > CVE-2018-1320 (CASSANDRA-15424) > CVE-2019-0205 (CASSANDRA-15420) > Updating to 0.9.3-1 will mitigate these, however that branch suffers > CVE-2020-13949. > To mitigate risks from using out of date libthrift versions, Cassandra should > be updated to use 0.14.0 -- 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-16606) Update libthrift jar to 0.14.0
Mark Denihan created CASSANDRA-16606: Summary: Update libthrift jar to 0.14.0 Key: CASSANDRA-16606 URL: https://issues.apache.org/jira/browse/CASSANDRA-16606 Project: Cassandra Issue Type: Bug Reporter: Mark Denihan Cassandra 3.x and 2.x uses libthrift 0.9.2, which has a number of vulnerabilities associated with it which are applicable to Cassandra; CVE-2015-3254 CVE-2018-1320 (CASSANDRA-15424) CVE-2019-0205 (CASSANDRA-15420) Updating to 0.9.3-1 will mitigate these, however that branch suffers CVE-2020-13949. To mitigate risks from using out of date libthrift versions, Cassandra should be updated to use 0.14.0 -- 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-16588) NPE getting host_id in Gossiper.isSafeForStartup
[
https://issues.apache.org/jira/browse/CASSANDRA-16588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322206#comment-17322206
]
Sam Tunnicliffe commented on CASSANDRA-16588:
-
I realised I'd made a mistake in those last patches by ANDing when I should've
ORed. Pushed and restarted CI.
||patch||CI||Circle||
|[3.11|https://github.com/beobal/cassandra/tree/CASSANDRA-16588]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/662/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/662/pipeline]|[pipeline|https://app.circleci.com/pipelines/github/beobal/cassandra?branch=CASSANDRA-16588]|
|[trunk|https://github.com/beobal/cassandra/tree/CASSANDRA-16588-trunk]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/663/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/663/pipeline]|[pipeline|https://app.circleci.com/pipelines/github/beobal/cassandra?branch=CASSANDRA-16588-trunk]|
> NPE getting host_id in Gossiper.isSafeForStartup
>
>
> Key: CASSANDRA-16588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16588
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0-rc
>
>
> As seen here:
> https://ci-cassandra.apache.org/job/Cassandra-devbranch/604/testReport/junit/org.apache.cassandra.distributed.upgrade/MixedModeGossipTest/testStatusFieldShouldExistInOldVersionNodesEdgeCase/
> {noformat}
> java.lang.NullPointerException
> at org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:952)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:657)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:933)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:784)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:729)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$10(Instance.java:541)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I believe what is happening is a GossipDigestAck has been queued to ack the
> shutdown state from the node on the seed, but isn't actually sent until the
> node has restarted and gone into shadow. Since the ack contains the node's
> IP, it assumes a host_id will be there but since this is not an actual shadow
> response, it is not.
--
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-15424) CVE-2018-1320 (The libthrift component is vulnerable to Improper Access Control)
[ https://issues.apache.org/jira/browse/CASSANDRA-15424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322202#comment-17322202 ] Mark Denihan commented on CASSANDRA-15424: -- This could be fixed by updating libthrift to 0.9.3-1 > CVE-2018-1320 (The libthrift component is vulnerable to Improper Access > Control) > > > Key: CASSANDRA-15424 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15424 > Project: Cassandra > Issue Type: Bug >Reporter: Abhishek Singh >Priority: Normal > > *Description :**Description :* *Severity :* CVE CVSS 3.0: 7.5Sonatype CVSS > 3.0: 8.2 > > *Weakness :* CVE CWE: 20 > > *Source :* National Vulnerability Database > > *Categories :* Data > *Description from CVE :* Apache Thrift Java client library versions 0.5.0 > through 0.11.0 can bypass SASL negotiation isComplete validation in the > org.apache.thrift.transport.TSaslTransport class. An assert used to determine > if the SASL handshake had successfully completed could be disabled in > production settings making the validation incomplete. > > *Explanation :* The libthrift component is vulnerable to Improper Access > Control. The open() method of the TSaslTransport class incorrectly uses an > assertion to validate whether or not the SASL handshake has successfully > completed. In some cases, such as production builds, the assertion > functionality can be disabled rendering the validation incomplete. In such a > case, an attacker can exploit this by being able to login without actually > successfully completing the SASL handshake. > *Detection :* The application is vulnerable by using this component. > *Recommendation :* We recommend upgrading to a version of this component > that is not vulnerable to this specific issue. > *Root Cause :* Cassandra-2.2.5.nupkgTSaslTransport.class : [0.5.0, 0.12.0) > > *Advisories :* Project: > https://lists.apache.org/thread.html/da5234b5e78f1c99190407f... > > *CVSS Details :* CVE CVSS 3.0: 7.5 > *Occurences (Paths) :* [" apache-cassandra.zip/bin/cassandra.in.bat" ; " > apache-cassandra.zip/bin/cassandra.in.sh" ; " > apache-cassandra.zip/bin/cqlsh.bat" ; " > apache-cassandra.zip/bin/debug-cql.bat" ; " > apache-cassandra.zip/bin/source-conf.ps1" ; " > apache-cassandra.zip/bin/sstableloader.bat" ; " > apache-cassandra.zip/bin/sstablescrub.bat" ; " > apache-cassandra.zip/bin/sstableupgrade.bat" ; " > apache-cassandra.zip/bin/sstableverify.bat" ; " > apache-cassandra.zip/bin/stop-server" ; " > apache-cassandra.zip/bin/stop-server.bat" ; " > apache-cassandra.zip/bin/stop-server.ps1" ; " > apache-cassandra.zip/conf/README.txt" ; " > apache-cassandra.zip/conf/cassandra-rackdc.properties" ; " > apache-cassandra.zip/conf/cassandra-topology.properties" ; " > apache-cassandra.zip/conf/commitlog_archiving.properties" ; " > apache-cassandra.zip/conf/triggers/README.txt" ; " > apache-cassandra.zip/lib/ST4-4.0.8.jar" ; " > apache-cassandra.zip/lib/airline-0.6.jar" ; " > apache-cassandra.zip/lib/antlr-runtime-3.5.2.jar" ; " > apache-cassandra.zip/lib/commons-cli-1.1.jar" ; " > apache-cassandra.zip/lib/commons-lang3-3.1.jar" ; " > apache-cassandra.zip/lib/commons-math3-3.2.jar" ; " > apache-cassandra.zip/lib/compress-lzf-0.8.4.jar" ; " > apache-cassandra.zip/lib/concurrentlinkedhashmap-lru-1.4.jar" ; " > apache-cassandra.zip/lib/disruptor-3.0.1.jar" ; " > apache-cassandra.zip/lib/ecj-4.4.2.jar" ; " > apache-cassandra.zip/lib/futures-2.1.6-py2.py3-none-any.zip" ; " > apache-cassandra.zip/lib/high-scale-lib-1.0.6.jar" ; " > apache-cassandra.zip/lib/jamm-0.3.0.jar" ; " > apache-cassandra.zip/lib/javax.inject.jar" ; " > apache-cassandra.zip/lib/jbcrypt-0.3m.jar" ; " > apache-cassandra.zip/lib/jcl-over-slf4j-1.7.7.jar" ; " > apache-cassandra.zip/lib/joda-time-2.4.jar" ; " > apache-cassandra.zip/lib/json-simple-1.1.jar" ; " > apache-cassandra.zip/lib/libthrift-0.9.2.jar" ; " > apache-cassandra.zip/lib/licenses/ST4-4.0.8.txt" ; " > apache-cassandra.zip/lib/licenses/antlr-runtime-3.5.2.txt" ; " > apache-cassandra.zip/lib/licenses/compress-lzf-0.8.4.txt" ; " > apache-cassandra.zip/lib/licenses/concurrent-trees-2.4.0.txt" ; " > apache-cassandra.zip/lib/licenses/ecj-4.4.2.txt" ; " > apache-cassandra.zip/lib/licenses/futures-2.1.6.txt" ; " > apache-cassandra.zip/lib/licenses/high-scale-lib-1.0.6.txt" ; " > apache-cassandra.zip/lib/licenses/jbcrypt-0.3m.txt" ; " > apache-cassandra.zip/lib/licenses/jcl-over-slf4j-1.7.7.txt" ; " > apache-cassandra.zip/lib/licenses/jna-4.2.2.txt" ; " > apache-cassandra.zip/lib/licenses/jstackjunit-0.0.1.txt" ; " > apache-cassandra.zip/lib/licenses/log4j-over-slf4j-1.7.7.txt" ; " > apache-cassandra.zip/lib/licenses/logback-classic-1.1.3.txt" ; " >
[jira] [Comment Edited] (CASSANDRA-15424) CVE-2018-1320 (The libthrift component is vulnerable to Improper Access Control)
[ https://issues.apache.org/jira/browse/CASSANDRA-15424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322202#comment-17322202 ] Mark Denihan edited comment on CASSANDRA-15424 at 4/15/21, 2:06 PM: This could be fixed by updating libthrift to 0.9.3-1 https://issues.apache.org/jira/browse/THRIFT-4506 https://github.com/apache/thrift/pull/1771/files was (Author: mdenihan): This could be fixed by updating libthrift to 0.9.3-1 > CVE-2018-1320 (The libthrift component is vulnerable to Improper Access > Control) > > > Key: CASSANDRA-15424 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15424 > Project: Cassandra > Issue Type: Bug >Reporter: Abhishek Singh >Priority: Normal > > *Description :**Description :* *Severity :* CVE CVSS 3.0: 7.5Sonatype CVSS > 3.0: 8.2 > > *Weakness :* CVE CWE: 20 > > *Source :* National Vulnerability Database > > *Categories :* Data > *Description from CVE :* Apache Thrift Java client library versions 0.5.0 > through 0.11.0 can bypass SASL negotiation isComplete validation in the > org.apache.thrift.transport.TSaslTransport class. An assert used to determine > if the SASL handshake had successfully completed could be disabled in > production settings making the validation incomplete. > > *Explanation :* The libthrift component is vulnerable to Improper Access > Control. The open() method of the TSaslTransport class incorrectly uses an > assertion to validate whether or not the SASL handshake has successfully > completed. In some cases, such as production builds, the assertion > functionality can be disabled rendering the validation incomplete. In such a > case, an attacker can exploit this by being able to login without actually > successfully completing the SASL handshake. > *Detection :* The application is vulnerable by using this component. > *Recommendation :* We recommend upgrading to a version of this component > that is not vulnerable to this specific issue. > *Root Cause :* Cassandra-2.2.5.nupkgTSaslTransport.class : [0.5.0, 0.12.0) > > *Advisories :* Project: > https://lists.apache.org/thread.html/da5234b5e78f1c99190407f... > > *CVSS Details :* CVE CVSS 3.0: 7.5 > *Occurences (Paths) :* [" apache-cassandra.zip/bin/cassandra.in.bat" ; " > apache-cassandra.zip/bin/cassandra.in.sh" ; " > apache-cassandra.zip/bin/cqlsh.bat" ; " > apache-cassandra.zip/bin/debug-cql.bat" ; " > apache-cassandra.zip/bin/source-conf.ps1" ; " > apache-cassandra.zip/bin/sstableloader.bat" ; " > apache-cassandra.zip/bin/sstablescrub.bat" ; " > apache-cassandra.zip/bin/sstableupgrade.bat" ; " > apache-cassandra.zip/bin/sstableverify.bat" ; " > apache-cassandra.zip/bin/stop-server" ; " > apache-cassandra.zip/bin/stop-server.bat" ; " > apache-cassandra.zip/bin/stop-server.ps1" ; " > apache-cassandra.zip/conf/README.txt" ; " > apache-cassandra.zip/conf/cassandra-rackdc.properties" ; " > apache-cassandra.zip/conf/cassandra-topology.properties" ; " > apache-cassandra.zip/conf/commitlog_archiving.properties" ; " > apache-cassandra.zip/conf/triggers/README.txt" ; " > apache-cassandra.zip/lib/ST4-4.0.8.jar" ; " > apache-cassandra.zip/lib/airline-0.6.jar" ; " > apache-cassandra.zip/lib/antlr-runtime-3.5.2.jar" ; " > apache-cassandra.zip/lib/commons-cli-1.1.jar" ; " > apache-cassandra.zip/lib/commons-lang3-3.1.jar" ; " > apache-cassandra.zip/lib/commons-math3-3.2.jar" ; " > apache-cassandra.zip/lib/compress-lzf-0.8.4.jar" ; " > apache-cassandra.zip/lib/concurrentlinkedhashmap-lru-1.4.jar" ; " > apache-cassandra.zip/lib/disruptor-3.0.1.jar" ; " > apache-cassandra.zip/lib/ecj-4.4.2.jar" ; " > apache-cassandra.zip/lib/futures-2.1.6-py2.py3-none-any.zip" ; " > apache-cassandra.zip/lib/high-scale-lib-1.0.6.jar" ; " > apache-cassandra.zip/lib/jamm-0.3.0.jar" ; " > apache-cassandra.zip/lib/javax.inject.jar" ; " > apache-cassandra.zip/lib/jbcrypt-0.3m.jar" ; " > apache-cassandra.zip/lib/jcl-over-slf4j-1.7.7.jar" ; " > apache-cassandra.zip/lib/joda-time-2.4.jar" ; " > apache-cassandra.zip/lib/json-simple-1.1.jar" ; " > apache-cassandra.zip/lib/libthrift-0.9.2.jar" ; " > apache-cassandra.zip/lib/licenses/ST4-4.0.8.txt" ; " > apache-cassandra.zip/lib/licenses/antlr-runtime-3.5.2.txt" ; " > apache-cassandra.zip/lib/licenses/compress-lzf-0.8.4.txt" ; " > apache-cassandra.zip/lib/licenses/concurrent-trees-2.4.0.txt" ; " > apache-cassandra.zip/lib/licenses/ecj-4.4.2.txt" ; " > apache-cassandra.zip/lib/licenses/futures-2.1.6.txt" ; " > apache-cassandra.zip/lib/licenses/high-scale-lib-1.0.6.txt" ; " > apache-cassandra.zip/lib/licenses/jbcrypt-0.3m.txt" ; " > apache-cassandra.zip/lib/licenses/jcl-over-slf4j-1.7.7.txt" ; " > apache-cassandra.zip/lib/licenses/jna-4.2.2.txt" ; " >
[jira] [Commented] (CASSANDRA-15420) CVE-2019-0205(Apache Thrift all versions up to and including 0.12.0) on version Cassendra 3.11.4
[ https://issues.apache.org/jira/browse/CASSANDRA-15420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322201#comment-17322201 ] Mark Denihan commented on CASSANDRA-15420: -- This could be resolved by updating the libthrift jar to 0.9.3-1 Reference https://issues.apache.org/jira/browse/THRIFT-5075 https://github.com/apache/thrift/pull/1993 > CVE-2019-0205(Apache Thrift all versions up to and including 0.12.0) on > version Cassendra 3.11.4 > > > Key: CASSANDRA-15420 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15420 > Project: Cassandra > Issue Type: Bug >Reporter: Abhishek Singh >Priority: Normal > > *Description :**Description :* *Severity :* CVE CVSS 3: 7.5Sonatype CVSS 3: > 7.5 > > *Weakness :* CVE CWE: 835 > > *Source :* National Vulnerability Database > > *Categories :* Data > *Description from CVE :* In Apache Thrift all versions up to and including > 0.12.0, a server or client may run into an endless loop when feed with > specific input data. Because the issue had already been partially fixed in > version 0.11.0, depending on the installed version it affects only certain > language bindings. > > *Explanation :* This issue has undergone the Sonatype Fast-Track process. > For more information, please see the Sonatype Knowledge Base Guide. > *Detection :* The application is vulnerable by using this component. > *Recommendation :* We recommend upgrading to a version of this component > that is not vulnerable to this specific issue.Note: If this component is > included as a bundled/transitive dependency of another component, there may > not be an upgrade path. In this instance, we recommend contacting the > maintainers who included the vulnerable package. Alternatively, we recommend > investigating alternative components or a potential mitigating control. > *Advisories :* Project: > http://mail-archives.apache.org/mod_mbox/thrift-dev/201910.m… > > *CVSS Details :* CVE CVSS 3: 7.5CVSS Vector: > CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H > *Occurences (Paths) :* ["apache-cassandra.zip" ; "apache-cassandra.zip"] > *CVE :* CVE-2019-0205 > *URL :* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0205 > *Remediation :* This component does not have any non-vulnerable Version. > Please contact the vendor to get this vulnerability fixed. -- 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-16601) Flaky CassandraIndexTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322182#comment-17322182
]
Andres de la Peña commented on CASSANDRA-16601:
---
Good idea, {{spinAssert}} can also do the trick more easily that waiting for
the cleanup tasks, although perhaps it's less reusable than
{{waitForSchemaCleanups}}. Anyway, I think both approaches assume that there
aren't other tests running parallely in the same JVM, and we are still
discussing in the mail list whether to remove that. I'm not sure whether we
should add this test to the ones that don't work with parallel runners or use
the slower but safer dtest approach.
> Flaky CassandraIndexTest
>
>
> Key: CASSANDRA-16601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16601
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/436/testReport/junit/org.apache.cassandra.index.internal/CassandraIndexTest/indexCorrectlyMarkedAsBuildAndRemoved_cdc/]
> {noformat}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:588)
> {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] [Commented] (CASSANDRA-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322178#comment-17322178
]
Michael Semb Wever commented on CASSANDRA-16595:
Broke CI, investigating…
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16595:
---
Resolution: (was: Fixed)
Status: Open (was: Resolved)
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-16588) NPE getting host_id in Gossiper.isSafeForStartup
[
https://issues.apache.org/jira/browse/CASSANDRA-16588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16588:
Reviewers: Sam Tunnicliffe (was: Ekaterina Dimitrova, Sam Tunnicliffe)
> NPE getting host_id in Gossiper.isSafeForStartup
>
>
> Key: CASSANDRA-16588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16588
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0-rc
>
>
> As seen here:
> https://ci-cassandra.apache.org/job/Cassandra-devbranch/604/testReport/junit/org.apache.cassandra.distributed.upgrade/MixedModeGossipTest/testStatusFieldShouldExistInOldVersionNodesEdgeCase/
> {noformat}
> java.lang.NullPointerException
> at org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:952)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:657)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:933)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:784)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:729)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$10(Instance.java:541)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I believe what is happening is a GossipDigestAck has been queued to ack the
> shutdown state from the node on the seed, but isn't actually sent until the
> node has restarted and gone into shadow. Since the ack contains the node's
> IP, it assumes a host_id will be there but since this is not an actual shadow
> response, it is not.
--
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-16601) Flaky CassandraIndexTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322170#comment-17322170
]
Berenguer Blasi commented on CASSANDRA-16601:
-
Ah good I didn't manage to repro that repeatedly. What about a spinAssert for
{{IndexInfo}} to be empty at the beginning of the test? :thinking:...
> Flaky CassandraIndexTest
>
>
> Key: CASSANDRA-16601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16601
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/436/testReport/junit/org.apache.cassandra.index.internal/CassandraIndexTest/indexCorrectlyMarkedAsBuildAndRemoved_cdc/]
> {noformat}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:588)
> {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] [Commented] (CASSANDRA-16598) Fix flaky test testMetricsWithRepairAndStreamingFromTwoNodes - org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322164#comment-17322164
]
Ekaterina Dimitrova commented on CASSANDRA-16598:
-
I was looping them overnight and didn't manage to reproduce anything on my
machine
> Fix flaky test testMetricsWithRepairAndStreamingFromTwoNodes -
> org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest
> -
>
> Key: CASSANDRA-16598
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16598
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/java
>Reporter: David Capwell
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-rc
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/882/workflows/8e34d09d-5908-495f-baac-5402e0c8e6ee/jobs/5276
> {code}
> junit.framework.AssertionFailedError: expected:<[0]> but was:<[2]>
> at
> org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest.testMetricsWithStreamingFromTwoNodes(StreamingMetricsTest.java:88)
> at
> org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest.testMetricsWithRepairAndStreamingFromTwoNodes(StreamingMetricsTest.java:48)
> {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] [Assigned] (CASSANDRA-16598) Fix flaky test testMetricsWithRepairAndStreamingFromTwoNodes - org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña reassigned CASSANDRA-16598:
-
Assignee: Andres de la Peña
> Fix flaky test testMetricsWithRepairAndStreamingFromTwoNodes -
> org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest
> -
>
> Key: CASSANDRA-16598
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16598
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/java
>Reporter: David Capwell
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-rc
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/882/workflows/8e34d09d-5908-495f-baac-5402e0c8e6ee/jobs/5276
> {code}
> junit.framework.AssertionFailedError: expected:<[0]> but was:<[2]>
> at
> org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest.testMetricsWithStreamingFromTwoNodes(StreamingMetricsTest.java:88)
> at
> org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest.testMetricsWithRepairAndStreamingFromTwoNodes(StreamingMetricsTest.java:48)
> {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-16587) flaky AntiCompactionBytemanTest.testRedundantTransitions byteman Connection refused
[
https://issues.apache.org/jira/browse/CASSANDRA-16587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16587:
---
Resolution: Won't Fix
Status: Resolved (was: Open)
> flaky AntiCompactionBytemanTest.testRedundantTransitions byteman Connection
> refused
> ---
>
> Key: CASSANDRA-16587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16587
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Failing occasionally with
> {noformat}
> java.net.ConnectException: Connection refused (Connection refused)
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:607)
> at java.net.Socket.connect(Socket.java:556)
> at java.net.Socket.(Socket.java:452)
> at java.net.Socket.(Socket.java:229)
> at org.jboss.byteman.agent.submit.Submit$Comm.(Submit.java:881)
> at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:787)
> at org.jboss.byteman.agent.submit.Submit.addScripts(Submit.java:603)
> at
> org.jboss.byteman.contrib.bmunit.BMUnit.loadScriptText(BMUnit.java:291)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$9.evaluate(BMUnitRunner.java:362)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
> {noformat}
> Looking through the [logs
> |https://nightlies.apache.org/cassandra/trunk/Cassandra-trunk-test-cdc/650/Cassandra-trunk-test-cdc/jdk=jdk_11_latest,label=cassandra,split=6/build/test/logs/cdc/TEST-org.apache.cassandra.db.compaction.AntiCompactionBytemanTest.log.xz]
> this correlates to
> {noformat}
> Setting org.jboss.byteman.allow.config.update=true
> TransformListener() : unexpected exception opening server socket
> java.net.BindException: Address already in use (Bind failed)
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:390)
> at java.net.ServerSocket.bind(ServerSocket.java:344)
> at
> org.jboss.byteman.agent.TransformListener.initialize(TransformListener.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.byteman.agent.Main.premain(Main.java:286)
> at org.jboss.byteman.agent.Main.agentmain(Main.java:309)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:386)
> at
> sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:411)
> {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] [Comment Edited] (CASSANDRA-16601) Flaky CassandraIndexTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322106#comment-17322106
]
Andres de la Peña edited comment on CASSANDRA-16601 at 4/15/21, 11:36 AM:
--
I have managed to reproduce the failure running the entire test class in our
internal multiplexer, with 22 failures in 200 runs
([here|https://jenkins-dse.build.dsinternal.org/view/Parameterized/job/parameterized-testall/789/]).
Indeed the problem is that the other tests also write entries in the
{{system.IndexInfo}} table and, since {{CQLTester.afterTest}} cleanup is
asynchronous, that table can change in any moment. CASSANDRA-15565 solved the
problem of having indexes from previous tests in the table by taking note of
how many indexes were in the table at the beginning of the test. The missed
part was that {{CQLTester.afterTest}} can remove them in the middle of the test.
The proposed PR indeed avoids that risk by just checking the specific entry for
the tested index, but I think it defeats part of the purpose of the test, which
aims to verify that creating, rebuilding and dropping an index doesn't create
unexpected entries in {{system.IndexInfo}}. If we wish to not do this check, we
should probably get rid of the calls to {{assertRowsIgnoringOrderAndExtra}},
the picking of the initial query size (which is always zero), and the comments
of the form {{"check that there are no other rows in the built indexes table"}}.
Alternatively, if we want to keep checking that no unexpected entries are added
to {{system.IndexInfo}}, we should make sure that no other test writes in that
table while we do our checks. The simplest way I can think of is making the
test a dtest, since those use a dedicated cluster. I gave it a go
[here|https://github.com/adelapena/cassandra/commit/1efcc5781bdfebc39692da6ea49bfbde7e49f866].
Also, now that we are probably going to get rid of parallel test execution, we
could add a method in {{CQLTester}} to wait for the cleanup tasks of previous
tests, which should guarantee us an empty {{system.IndexInfo}}, as it's done
[here|https://github.com/adelapena/cassandra/commit/8cf7145b8437f616e8085169cc3829197961031c].
That method could also be helpful for other similar tests, and will allow us
to restore the simpler pre-15565 shape of the test.
wdyt?
was (Author: adelapena):
I have managed to reproduce the failure running the entire test class in our
internal multiplexer, with 22 failures in 200 runs
([here|https://jenkins-dse.build.dsinternal.org/view/Parameterized/job/parameterized-testall/789/]).
Indeed the problem is that the other tests also write entries in the
{{system.IndexInfo}} table and, since {{CQLTester.afterTest}} cleanup is
asynchronous, that table can change in any moment. CASSANDRA-15565 solved the
problem of having indexes from previous tests in the table by taking note of
how many indexes were in the table at the beginning of the test. The missed
part was that {{CQLTester.afterTest}} can remove them in the middle of the test.
The proposed PR indeed avoids that risk by just checking the specific entry for
the tested index, but I think it defeats part of the purpose of the test, which
aims to verify that creating, rebuilding and dropping an index doesn't create
unexpected entries in {{system.IndexInfo}}. If we wish to not do this check, we
should probably get rid of the calls to {{assertRowsIgnoringOrderAndExtra}},
the picking of the initial query size (which is always zero), and the comments
of the form {{"check that there are no other rows in the built indexes table"}}.
Alternatively, if we want to keep checking that no unexpected entries are added
to {{system.IndexInfo}}, we should make sure that no other test writes in that
table while we do our checks. The simplest way I can think of is making the
test a dtest, since those use a dedicated cluster. I gave it a go
[here|https://github.com/adelapena/cassandra/commit/1efcc5781bdfebc39692da6ea49bfbde7e49f866].
Also, now that we are probably going to get rid of parallel test execution, we
could add a method in {{CQLTester}} to wait for the cleanup tasks of previous
tests, which should guarantee us an empty {{system.IndexInfo}}, as it's done
[here|https://github.com/adelapena/cassandra/commit/8cf7145b8437f616e8085169cc3829197961031c].
wdyt?
> Flaky CassandraIndexTest
>
>
> Key: CASSANDRA-16601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16601
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See failure
>
[jira] [Updated] (CASSANDRA-16587) flaky AntiCompactionBytemanTest.testRedundantTransitions byteman Connection refused
[
https://issues.apache.org/jira/browse/CASSANDRA-16587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16587:
---
Status: In Progress (was: Patch Available)
> flaky AntiCompactionBytemanTest.testRedundantTransitions byteman Connection
> refused
> ---
>
> Key: CASSANDRA-16587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16587
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Failing occasionally with
> {noformat}
> java.net.ConnectException: Connection refused (Connection refused)
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:607)
> at java.net.Socket.connect(Socket.java:556)
> at java.net.Socket.(Socket.java:452)
> at java.net.Socket.(Socket.java:229)
> at org.jboss.byteman.agent.submit.Submit$Comm.(Submit.java:881)
> at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:787)
> at org.jboss.byteman.agent.submit.Submit.addScripts(Submit.java:603)
> at
> org.jboss.byteman.contrib.bmunit.BMUnit.loadScriptText(BMUnit.java:291)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$9.evaluate(BMUnitRunner.java:362)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
> {noformat}
> Looking through the [logs
> |https://nightlies.apache.org/cassandra/trunk/Cassandra-trunk-test-cdc/650/Cassandra-trunk-test-cdc/jdk=jdk_11_latest,label=cassandra,split=6/build/test/logs/cdc/TEST-org.apache.cassandra.db.compaction.AntiCompactionBytemanTest.log.xz]
> this correlates to
> {noformat}
> Setting org.jboss.byteman.allow.config.update=true
> TransformListener() : unexpected exception opening server socket
> java.net.BindException: Address already in use (Bind failed)
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:390)
> at java.net.ServerSocket.bind(ServerSocket.java:344)
> at
> org.jboss.byteman.agent.TransformListener.initialize(TransformListener.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.byteman.agent.Main.premain(Main.java:286)
> at org.jboss.byteman.agent.Main.agentmain(Main.java:309)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:386)
> at
> sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:411)
> {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-16587) flaky AntiCompactionBytemanTest.testRedundantTransitions byteman Connection refused
[
https://issues.apache.org/jira/browse/CASSANDRA-16587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16587:
---
Status: Patch Available (was: Review In Progress)
> flaky AntiCompactionBytemanTest.testRedundantTransitions byteman Connection
> refused
> ---
>
> Key: CASSANDRA-16587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16587
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Failing occasionally with
> {noformat}
> java.net.ConnectException: Connection refused (Connection refused)
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:607)
> at java.net.Socket.connect(Socket.java:556)
> at java.net.Socket.(Socket.java:452)
> at java.net.Socket.(Socket.java:229)
> at org.jboss.byteman.agent.submit.Submit$Comm.(Submit.java:881)
> at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:787)
> at org.jboss.byteman.agent.submit.Submit.addScripts(Submit.java:603)
> at
> org.jboss.byteman.contrib.bmunit.BMUnit.loadScriptText(BMUnit.java:291)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$9.evaluate(BMUnitRunner.java:362)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
> {noformat}
> Looking through the [logs
> |https://nightlies.apache.org/cassandra/trunk/Cassandra-trunk-test-cdc/650/Cassandra-trunk-test-cdc/jdk=jdk_11_latest,label=cassandra,split=6/build/test/logs/cdc/TEST-org.apache.cassandra.db.compaction.AntiCompactionBytemanTest.log.xz]
> this correlates to
> {noformat}
> Setting org.jboss.byteman.allow.config.update=true
> TransformListener() : unexpected exception opening server socket
> java.net.BindException: Address already in use (Bind failed)
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:390)
> at java.net.ServerSocket.bind(ServerSocket.java:344)
> at
> org.jboss.byteman.agent.TransformListener.initialize(TransformListener.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.byteman.agent.Main.premain(Main.java:286)
> at org.jboss.byteman.agent.Main.agentmain(Main.java:309)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:386)
> at
> sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:411)
> {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-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16595:
---
Fix Version/s: (was: 4.0.x)
(was: 3.11.x)
(was: 3.0.x)
(was: 2.2.x)
4.0
4.0-rc1
3.11.11
3.0.25
2.2.20
Source Control Link:
https://github.com/apache/cassandra/commit/1185593907ba6597c29da1dfb5e6edb121b358c5
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
[1185593907ba6597c29da1dfb5e6edb121b358c5|https://github.com/apache/cassandra/commit/1185593907ba6597c29da1dfb5e6edb121b358c5].
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc1, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-16601) Flaky CassandraIndexTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322106#comment-17322106
]
Andres de la Peña commented on CASSANDRA-16601:
---
I have managed to reproduce the failure running the entire test class in our
internal multiplexer, with 22 failures in 200 runs
([here|https://jenkins-dse.build.dsinternal.org/view/Parameterized/job/parameterized-testall/789/]).
Indeed the problem is that the other tests also write entries in the
{{system.IndexInfo}} table and, since {{CQLTester.afterTest}} cleanup is
asynchronous, that table can change in any moment. CASSANDRA-15565 solved the
problem of having indexes from previous tests in the table by taking note of
how many indexes were in the table at the beginning of the test. The missed
part was that {{CQLTester.afterTest}} can remove them in the middle of the test.
The proposed PR indeed avoids that risk by just checking the specific entry for
the tested index, but I think it defeats part of the purpose of the test, which
aims to verify that creating, rebuilding and dropping an index doesn't create
unexpected entries in {{system.IndexInfo}}. If we wish to not do this check, we
should probably get rid of the calls to {{assertRowsIgnoringOrderAndExtra}},
the picking of the initial query size (which is always zero), and the comments
of the form {{"check that there are no other rows in the built indexes table"}}.
Alternatively, if we want to keep checking that no unexpected entries are added
to {{system.IndexInfo}}, we should make sure that no other test writes in that
table while we do our checks. The simplest way I can think of is making the
test a dtest, since those use a dedicated cluster. I gave it a go
[here|https://github.com/adelapena/cassandra/commit/1efcc5781bdfebc39692da6ea49bfbde7e49f866].
Also, now that we are probably going to get rid of parallel test execution, we
could add a method in {{CQLTester}} to wait for the cleanup tasks of previous
tests, which should guarantee us an empty {{system.IndexInfo}}, as it's done
[here|https://github.com/adelapena/cassandra/commit/8cf7145b8437f616e8085169cc3829197961031c].
wdyt?
> Flaky CassandraIndexTest
>
>
> Key: CASSANDRA-16601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16601
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/436/testReport/junit/org.apache.cassandra.index.internal/CassandraIndexTest/indexCorrectlyMarkedAsBuildAndRemoved_cdc/]
> {noformat}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:588)
> {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-16588) NPE getting host_id in Gossiper.isSafeForStartup
[
https://issues.apache.org/jira/browse/CASSANDRA-16588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-16588:
Status: Changes Suggested (was: Review In Progress)
> NPE getting host_id in Gossiper.isSafeForStartup
>
>
> Key: CASSANDRA-16588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16588
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0-rc
>
>
> As seen here:
> https://ci-cassandra.apache.org/job/Cassandra-devbranch/604/testReport/junit/org.apache.cassandra.distributed.upgrade/MixedModeGossipTest/testStatusFieldShouldExistInOldVersionNodesEdgeCase/
> {noformat}
> java.lang.NullPointerException
> at org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:952)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:657)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:933)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:784)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:729)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$10(Instance.java:541)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I believe what is happening is a GossipDigestAck has been queued to ack the
> shutdown state from the node on the seed, but isn't actually sent until the
> node has restarted and gone into shadow. Since the ack contains the node's
> IP, it assumes a host_id will be there but since this is not an actual shadow
> response, it is not.
--
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-16588) NPE getting host_id in Gossiper.isSafeForStartup
[
https://issues.apache.org/jira/browse/CASSANDRA-16588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322096#comment-17322096
]
Sam Tunnicliffe commented on CASSANDRA-16588:
-
This is a dupe of CASSANDRA-14155 and your diagnosis corresponds with Ariel's
there. IDK why that stalled, but his proposal is essentially the same as yours:
bq. it seems to me that we should be able to ignore messages received during
the shadow round that don't have the information we are looking for without
erroring out.
Rather than checking on the number of epstates returned, I'd go for verifying
that the states we do require for the collision check are present. I've pushed
a couple of commits which do that, wdyt?
||patch||CI||Circle||
|[3.11|https://github.com/beobal/cassandra/tree/CASSANDRA-16588]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/661/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/661/pipeline]|[pipeline|https://app.circleci.com/pipelines/github/beobal/cassandra?branch=CASSANDRA-16588]|
|[trunk|https://github.com/beobal/cassandra/tree/CASSANDRA-16588-trunk]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/660/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/660/pipeline]|[pipeline|https://app.circleci.com/pipelines/github/beobal/cassandra?branch=CASSANDRA-16588-trunk]|
> NPE getting host_id in Gossiper.isSafeForStartup
>
>
> Key: CASSANDRA-16588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16588
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0-rc
>
>
> As seen here:
> https://ci-cassandra.apache.org/job/Cassandra-devbranch/604/testReport/junit/org.apache.cassandra.distributed.upgrade/MixedModeGossipTest/testStatusFieldShouldExistInOldVersionNodesEdgeCase/
> {noformat}
> java.lang.NullPointerException
> at org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:952)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:657)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:933)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:784)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:729)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$10(Instance.java:541)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I believe what is happening is a GossipDigestAck has been queued to ack the
> shutdown state from the node on the seed, but isn't actually sent until the
> node has restarted and gone into shadow. Since the ack contains the node's
> IP, it assumes a host_id will be there but since this is not an actual shadow
> response, it is not.
--
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-16595) Remove test parallelism from ant build.xml in all branches
[
https://issues.apache.org/jira/browse/CASSANDRA-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16595:
---
Status: Ready to Commit (was: Review In Progress)
> Remove test parallelism from ant build.xml in all branches
> --
>
> Key: CASSANDRA-16595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16595
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra's build.xml supports parallel test runners. This functionality is
> available through {{`-Dtest.runners`}} and the {{`testparallel`}} ant macro.
> Having not been actively used and atrophied over time, it breaks a number of
> tests. The distributed in-jvm tests don't work at all with parallel runners
> (currently they need `-Dtest.runners=1` specified to work). And there are
> plenty of flakies, from where
> tests use fixed ports (StorageServiceServerTest), to byteman (eg
> BMUnitRunner), and around conf files on disk.
> This was raised on the dev ML, where the consensus was to remove it:
> https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E
> The idea is to then replace ant test parallelism with docker container
> parallelism.
--
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-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 2a6059ef4ae0bcf491aa81a3eab9325282617381 Merge: 4164313 1185593 Author: Mick Semb Wever AuthorDate: Thu Apr 15 12:58:59 2021 +0200 Merge branch 'cassandra-2.2' into cassandra-3.0 build.xml | 139 -- 1 file changed, 18 insertions(+), 121 deletions(-) diff --cc build.xml index ad40e59,cbe45ba..9c778ae --- a/build.xml +++ b/build.xml @@@ -1355,18 -1394,19 +1354,16 @@@ - - - + - + - - + - @@@ -1383,11 -1422,10 +1379,10 @@@ - - + + - @@@ -1444,11 -1476,11 +1439,11 @@@ - + - - + + @@@ -1687,111 -1763,12 +1682,12 @@@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + - + - - + + @@@ -1817,10 -1795,23 +1714,10 @@@ - - + + - - - - - - - - - - - - - - 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 (c729318 -> 5b93a87)
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 c729318 Merge branch 'cassandra-3.0' into cassandra-3.11 new 1185593 Remove test parallelism from ant build.xml new 2a6059e Merge branch 'cassandra-2.2' into cassandra-3.0 new 5b93a87 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: build.xml | 153 ++ 1 file changed, 25 insertions(+), 128 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-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 5b93a87a6f9305409b4b22d975b0a1d46379cee8 Merge: c729318 2a6059e Author: Mick Semb Wever AuthorDate: Thu Apr 15 13:05:40 2021 +0200 Merge branch 'cassandra-3.0' into cassandra-3.11 build.xml | 153 ++ 1 file changed, 25 insertions(+), 128 deletions(-) diff --cc build.xml index 68f7556,9c778ae..7184d74 --- a/build.xml +++ b/build.xml @@@ -1427,29 -1397,6 +1422,28 @@@ + + - + + + + + + - + + + + + + + + + + + + @@@ -1490,18 -1442,10 +1484,18 @@@ - - + + + + + + - - ++ ++ + + @@@ -1868,17 -1714,10 +1764,18 @@@ - - + + - + ++ + + + - - ++ ++ + + - 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 (4164313 -> 2a6059e)
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 4164313 Don't wait for migrations from removed nodes, mention flag to skip new 1185593 Remove test parallelism from ant build.xml new 2a6059e 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: build.xml | 139 -- 1 file changed, 18 insertions(+), 121 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (5cbdb2e -> 94603c6)
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 5cbdb2e Periodic failures in *RepairCoordinator*Test caused by race condition with nodetool repair new 1185593 Remove test parallelism from ant build.xml new 2a6059e Merge branch 'cassandra-2.2' into cassandra-3.0 new 5b93a87 Merge branch 'cassandra-3.0' into cassandra-3.11 new 94603c6 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: .circleci/config-2_1.yml | 6 +- .circleci/config.yml | 12 ++-- .circleci/config.yml.HIGHRES | 12 ++-- .circleci/config.yml.LOWRES | 12 ++-- .circleci/config.yml.MIDRES | 6 +- build.xml| 164 --- 6 files changed, 53 insertions(+), 159 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
