[jira] [Updated] (CASSANDRA-17954) fgrtytyt
[ https://issues.apache.org/jira/browse/CASSANDRA-17954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-17954: - Epic Link: (was: CASSANDRA-17940) Description: (was: [https://wiki.opendaylight.org/plugins/viewsource/viewpagesrc.action?pageId=27067621] [https://wiki.onap.org/plugins/viewsource/viewpagesrc.action?pageId=149030291] [https://wiki.tungsten.io/plugins/viewsource/viewpagesrc.action?pageId=62718075] [https://wiki.lfnetworking.org/plugins/viewsource/viewpagesrc.action?pageId=74648204] [https://goframe.org/plugins/viewsource/viewpagesrc.action?pageId=62103043] [https://wiki.openidl.org/plugins/viewsource/viewpagesrc.action?pageId=24053543] [https://wiki.odim.io/plugins/viewsource/viewpagesrc.action?pageId=25165947] [https://wiki.aswf.io/plugins/viewsource/viewpagesrc.action?pageId=43410883] [https://wiki.trustoverip.org/plugins/viewsource/viewpagesrc.action?pageId=27723250]) > fgrtytyt > > > Key: CASSANDRA-17954 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17954 > Project: Cassandra > Issue Type: Bug >Reporter: akian uba >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17954) fgrtytyt
[ https://issues.apache.org/jira/browse/CASSANDRA-17954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-17954: - Resolution: Invalid Status: Resolved (was: Triage Needed) > fgrtytyt > > > Key: CASSANDRA-17954 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17954 > Project: Cassandra > Issue Type: Bug >Reporter: akian uba >Priority: Normal > > [https://wiki.opendaylight.org/plugins/viewsource/viewpagesrc.action?pageId=27067621] > [https://wiki.onap.org/plugins/viewsource/viewpagesrc.action?pageId=149030291] > [https://wiki.tungsten.io/plugins/viewsource/viewpagesrc.action?pageId=62718075] > [https://wiki.lfnetworking.org/plugins/viewsource/viewpagesrc.action?pageId=74648204] > [https://goframe.org/plugins/viewsource/viewpagesrc.action?pageId=62103043] > [https://wiki.openidl.org/plugins/viewsource/viewpagesrc.action?pageId=24053543] > [https://wiki.odim.io/plugins/viewsource/viewpagesrc.action?pageId=25165947] > [https://wiki.aswf.io/plugins/viewsource/viewpagesrc.action?pageId=43410883] > [https://wiki.trustoverip.org/plugins/viewsource/viewpagesrc.action?pageId=27723250] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17954) fgrtytyt
akian uba created CASSANDRA-17954: - Summary: fgrtytyt Key: CASSANDRA-17954 URL: https://issues.apache.org/jira/browse/CASSANDRA-17954 Project: Cassandra Issue Type: Bug Reporter: akian uba [https://wiki.opendaylight.org/plugins/viewsource/viewpagesrc.action?pageId=27067621] [https://wiki.onap.org/plugins/viewsource/viewpagesrc.action?pageId=149030291] [https://wiki.tungsten.io/plugins/viewsource/viewpagesrc.action?pageId=62718075] [https://wiki.lfnetworking.org/plugins/viewsource/viewpagesrc.action?pageId=74648204] [https://goframe.org/plugins/viewsource/viewpagesrc.action?pageId=62103043] [https://wiki.openidl.org/plugins/viewsource/viewpagesrc.action?pageId=24053543] [https://wiki.odim.io/plugins/viewsource/viewpagesrc.action?pageId=25165947] [https://wiki.aswf.io/plugins/viewsource/viewpagesrc.action?pageId=43410883] [https://wiki.trustoverip.org/plugins/viewsource/viewpagesrc.action?pageId=27723250] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (9a0677dd -> 18e5a4f9)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 9a0677dd generate docs for 2af01b8f new 18e5a4f9 generate docs for 2af01b8f This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (9a0677dd) \ N -- N -- N refs/heads/asf-staging (18e5a4f9) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 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: site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17885) Add solution for CASSANDRA-17581 to older branches for tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614311#comment-17614311 ] Brandon Williams commented on CASSANDRA-17885: -- Jenkins: * [3.0|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1985/] * [3.11|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1986/] * [4.0|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1960/] * [4.1|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1961/] * [trunk|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1988/] Circle: * [3.0|https://app.circleci.com/pipelines/github/driftx/cassandra/653/workflows/366b631d-2c88-44d2-8b9f-def7ce52bd43/jobs/7387] * [3.11|https://app.circleci.com/pipelines/github/driftx/cassandra/654/workflows/722c3d56-8a3f-4df2-b357-439c80e469d5/jobs/7389] * [4.0|https://app.circleci.com/pipelines/github/driftx/cassandra/663/workflows/e86ddc84-75a2-4ff1-8359-693e19fa663a/jobs/7406] * [4.1|https://app.circleci.com/pipelines/github/driftx/cassandra/662/workflows/7a25751d-7123-49aa-b7f1-930d7142e577/jobs/7407] * [trunk|https://app.circleci.com/pipelines/github/driftx/cassandra/652/workflows/08651048-223e-4af0-ba3a-5739f11c0f59/jobs/7367] There are existing failures, but none due to nodetool. > Add solution for CASSANDRA-17581 to older branches for tests > > > Key: CASSANDRA-17885 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17885 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x > > > Some of our tests use old branches for the purposes of testing upgrades and > behavior in mixed versions, but those lacking CASSANDRA-17581 will fail on > nodetool with a modern JDK. We can port this fix to those branches and > adjust the tests to use the newest version of them to solve this going > forward. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-43) Introduce new handler for schema retrieval operations
[ https://issues.apache.org/jira/browse/CASSANDRASC-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRASC-43: -- Labels: pull-request-available (was: ) > Introduce new handler for schema retrieval operations > - > > Key: CASSANDRASC-43 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-43 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > Schema information is used when performing bulk reads/writes from Cassandra. > The information retrieved is used to map datatypes to other systems such as > Spark. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17923) Mixed mode support for internode authentication during TLS upgrades
[ https://issues.apache.org/jira/browse/CASSANDRA-17923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614295#comment-17614295 ] Yifan Cai commented on CASSANDRA-17923: --- Committed into trunk as [ca75ffe4|https://github.com/apache/cassandra/commit/ca75ffe4d09a3e7b26a56345c0bdacaa284eaab7] > Mixed mode support for internode authentication during TLS upgrades > --- > > Key: CASSANDRA-17923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17923 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Internode >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.2 > > > During upgrades from "non-ssl -> ssl" or "ssl-mTLS" the cluster should be > able to function in mixed mode with some nodes supporting "non-ssl" > authentication and the new nodes supporting "mTLS" authentication. Currently > we do not have this supported and because of which upgrades are not possible > for upgrading internode authentication strategies. > If a node is configured in optional mode for internode connections, retry > with other SSL strategies If the node is not able to connect to other nodes > due to authentication problems. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17923) Mixed mode support for internode authentication during TLS upgrades
[ https://issues.apache.org/jira/browse/CASSANDRA-17923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-17923: -- Fix Version/s: 4.2 Source Control Link: https://github.com/apache/cassandra/commit/ca75ffe4d09a3e7b26a56345c0bdacaa284eaab7 (was: https://github.com/apache/cassandra/pull/1884) Resolution: Fixed Status: Resolved (was: Ready to Commit) > Mixed mode support for internode authentication during TLS upgrades > --- > > Key: CASSANDRA-17923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17923 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Internode >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.2 > > > During upgrades from "non-ssl -> ssl" or "ssl-mTLS" the cluster should be > able to function in mixed mode with some nodes supporting "non-ssl" > authentication and the new nodes supporting "mTLS" authentication. Currently > we do not have this supported and because of which upgrades are not possible > for upgrading internode authentication strategies. > If a node is configured in optional mode for internode connections, retry > with other SSL strategies If the node is not able to connect to other nodes > due to authentication problems. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Mixed mode support for internode authentication during TLS upgrades
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 ca75ffe4d0 Mixed mode support for internode authentication during TLS
upgrades
ca75ffe4d0 is described below
commit ca75ffe4d09a3e7b26a56345c0bdacaa284eaab7
Author: Jyothsna Konisa
AuthorDate: Fri Oct 7 10:03:16 2022 -0700
Mixed mode support for internode authentication during TLS upgrades
patch by Jyothsna Konisa; reviewed by Jon Meredith, Yifan Cai for
CASSANDRA-17923
---
CHANGES.txt| 1 +
.../cassandra/net/InternodeConnectionUtils.java| 11 +-
.../apache/cassandra/net/OutboundConnection.java | 23 ++-
.../cassandra/net/OutboundConnectionInitiator.java | 43 -
.../async/NettyStreamingConnectionFactory.java | 45 +++--
test/conf/cassandra_ssl_test.truststore| Bin 992 -> 3240 bytes
.../test/InternodeEncryptionEnforcementTest.java | 8 +-
.../org/apache/cassandra/net/HandshakeTest.java| 185 -
8 files changed, 282 insertions(+), 34 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index c418c48ba9..85fdae62e8 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.2
+ * Mixed mode support for internode authentication during TLS upgrades
(CASSANDRA-17923)
* Revert Mockito downgrade from CASSANDRA-17750 (CASSANDRA-17496)
* Add --older-than and --older-than-timestamp options for nodetool
clearsnapshots (CASSANDRA-16860)
* Fix "open RT bound as its last item" exception (CASSANDRA-17810)
diff --git a/src/java/org/apache/cassandra/net/InternodeConnectionUtils.java
b/src/java/org/apache/cassandra/net/InternodeConnectionUtils.java
index 39a087960b..fd3d1bd69e 100644
--- a/src/java/org/apache/cassandra/net/InternodeConnectionUtils.java
+++ b/src/java/org/apache/cassandra/net/InternodeConnectionUtils.java
@@ -18,6 +18,7 @@
package org.apache.cassandra.net;
+import java.nio.channels.ClosedChannelException;
import java.security.cert.Certificate;
import javax.net.ssl.SSLPeerUnverifiedException;
@@ -33,7 +34,7 @@ import io.netty.handler.ssl.SslHandler;
/**
* Class that contains certificate utility methods.
*/
-class InternodeConnectionUtils
+public class InternodeConnectionUtils
{
public static String SSL_HANDLER_NAME = "ssl";
public static String DISCARD_HANDLER_NAME = "discard";
@@ -59,6 +60,14 @@ class InternodeConnectionUtils
return certificates;
}
+public static boolean isSSLError(final Throwable cause)
+{
+return (cause instanceof ClosedChannelException)
+ && cause.getCause() == null
+ &&
cause.getStackTrace()[0].getClassName().contains("SslHandler")
+ &&
cause.getStackTrace()[0].getMethodName().contains("channelInactive");
+}
+
/**
* Discard handler releases the received data silently. when internode
authentication fails, the channel is closed,
* but the pending buffered data may still be fired through the pipeline.
To avoid that, authentication handler is
diff --git a/src/java/org/apache/cassandra/net/OutboundConnection.java
b/src/java/org/apache/cassandra/net/OutboundConnection.java
index 821521bfb9..2af6d3b01d 100644
--- a/src/java/org/apache/cassandra/net/OutboundConnection.java
+++ b/src/java/org/apache/cassandra/net/OutboundConnection.java
@@ -61,6 +61,7 @@ import
org.apache.cassandra.utils.concurrent.UncheckedInterruptedException;
import static java.lang.Math.max;
import static java.lang.Math.min;
import static java.util.concurrent.TimeUnit.MILLISECONDS;
+import static org.apache.cassandra.net.InternodeConnectionUtils.isSSLError;
import static org.apache.cassandra.net.MessagingService.current_version;
import static org.apache.cassandra.net.OutboundConnectionInitiator.*;
import static
org.apache.cassandra.net.OutboundConnections.LARGE_MESSAGE_THRESHOLD;
@@ -1100,8 +1101,9 @@ public class OutboundConnection
if (hasPending())
{
+boolean isSSLFailure = isSSLError(cause);
Promise> result =
AsyncPromise.withExecutor(eventLoop);
-state = new Connecting(state.disconnected(), result,
eventLoop.schedule(() -> attempt(result), max(100, retryRateMillis),
MILLISECONDS));
+state = new Connecting(state.disconnected(), result,
eventLoop.schedule(() -> attempt(result, isSSLFailure), max(100,
retryRateMillis), MILLISECONDS));
retryRateMillis = min(1000, retryRateMillis * 2);
}
else
@@ -1189,7 +1191,7 @@ public class OutboundConnection
*
* Note: this should only be invoked on the event loop.
*/
-private void attempt(Promise> result)
+private void attempt(Promise> result,
bool
[jira] [Comment Edited] (CASSANDRA-17923) Mixed mode support for internode authentication during TLS upgrades
[ https://issues.apache.org/jira/browse/CASSANDRA-17923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614167#comment-17614167 ] Yifan Cai edited comment on CASSANDRA-17923 at 10/7/22 10:20 PM: - Starting commit CI Results: ||Branch||Source||Circle CI|| |trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17923-trunk-3D0B6138-8009-49D8-83CA-F3C64D96A833]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17923-trunk-3D0B6138-8009-49D8-83CA-F3C64D96A833]| CI run looks green. There is a test failure from the BufferPoolTest. There is a ticket CASSANDRA-16681 tracking the issue already. I am going to commit the patch. was (Author: yifanc): Starting commit CI Results (pending): ||Branch||Source||Circle CI|| |trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17923-trunk-3D0B6138-8009-49D8-83CA-F3C64D96A833]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17923-trunk-3D0B6138-8009-49D8-83CA-F3C64D96A833]| > Mixed mode support for internode authentication during TLS upgrades > --- > > Key: CASSANDRA-17923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17923 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Internode >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > > During upgrades from "non-ssl -> ssl" or "ssl-mTLS" the cluster should be > able to function in mixed mode with some nodes supporting "non-ssl" > authentication and the new nodes supporting "mTLS" authentication. Currently > we do not have this supported and because of which upgrades are not possible > for upgrading internode authentication strategies. > If a node is configured in optional mode for internode connections, retry > with other SSL strategies If the node is not able to connect to other nodes > due to authentication problems. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17915) Confusing error message when using ? with functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614252#comment-17614252
]
Natnael Adere commented on CASSANDRA-17915:
---
[~blerer] waiting to run CircleCI but the tests were passing.
Will give an update when it is ready and thanks for the tip.
> Confusing error message when using ? with functions
> ---
>
> Key: CASSANDRA-17915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17915
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: David Capwell
>Assignee: Natnael Adere
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> INSERT INTO %S (a, b, c) VALUES (? + 1, ?, ?)
> {code}
> Errors saying
> {code}
> Ambiguous '+' operation with args ? and 1: use type casts to disambiguate
> {code}
> Now, if you google “type casts CQL” you get
> https://docs.datastax.com/en/dse/5.1/cql/cql/cql_reference/refCqlFunction.html
> which says to do
> {code}
> CAST( selector AS to_type )
> {code}
> But this also fails!
> {code}
> InvalidRequestException: Ambiguous call to function system.castAsFloat (can
> be matched by following signatures: system."castAsFloat" : (bigint) -> float,
> system."castAsFloat" : (counter) -> float, system."castAsFloat" : (double) ->
> float, system."castAsFloat" : (int) -> float, system."castAsFloat" :
> (tinyint) -> float, system."castAsFloat" : (varint) -> float,
> system."castAsFloat" : (decimal) -> float, system."castAsFloat" : (smallint)
> -> float): use type casts to disambiguate
> {code}
> What we have to do is
> {code}
> INSERT INTO %S (a, b, c) VALUES ((int) ? + 1, ?, ?)
> {code}
> We should improve the error message to show the expected syntax (or fix CAST
> to work in this case).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17922) Jolokia agent fails to connect though port is available
[
https://issues.apache.org/jira/browse/CASSANDRA-17922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614220#comment-17614220
]
Brandon Williams commented on CASSANDRA-17922:
--
bq. /sad
And I've never been able to reproduce either of these issues.
bq. Looks like the patch doesn't raise an exception anymore
Nope, good catch, let me correct that.
> Jolokia agent fails to connect though port is available
> ---
>
> Key: CASSANDRA-17922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17922
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> In CASSANDRA-17872 we added protection around failures similar to this,
> caused by the port being in use, which is no longer the case:
> {code}
> subprocess.CalledProcessError: Command
> '('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '{-}cp',
> '/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
> 'org.jolokia.jvmagent.client.AgentLauncher', '{-}{-}host', '127.0.0.2',
> '{-}-port', '8778', 'start', '1123')' returned non-zero exit status 1.
> {code}
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/junit/dtest-novnode.auth_test/TestNetworkAuth/test_revoked_dc_access/]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17922) Jolokia agent fails to connect though port is available
[
https://issues.apache.org/jira/browse/CASSANDRA-17922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17922:
-
Status: Open (was: Patch Available)
> Jolokia agent fails to connect though port is available
> ---
>
> Key: CASSANDRA-17922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17922
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> In CASSANDRA-17872 we added protection around failures similar to this,
> caused by the port being in use, which is no longer the case:
> {code}
> subprocess.CalledProcessError: Command
> '('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '{-}cp',
> '/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
> 'org.jolokia.jvmagent.client.AgentLauncher', '{-}{-}host', '127.0.0.2',
> '{-}-port', '8778', 'start', '1123')' returned non-zero exit status 1.
> {code}
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/junit/dtest-novnode.auth_test/TestNetworkAuth/test_revoked_dc_access/]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17922) Jolokia agent fails to connect though port is available
[
https://issues.apache.org/jira/browse/CASSANDRA-17922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614219#comment-17614219
]
Josh McKenzie commented on CASSANDRA-17922:
---
bq. it's down to some internal java agent thing
1. Ew
2. /sad
3. Looks like the patch doesn't raise an exception anymore after complete
failure to start the agent - was that intentional?
> Jolokia agent fails to connect though port is available
> ---
>
> Key: CASSANDRA-17922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17922
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> In CASSANDRA-17872 we added protection around failures similar to this,
> caused by the port being in use, which is no longer the case:
> {code}
> subprocess.CalledProcessError: Command
> '('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '{-}cp',
> '/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
> 'org.jolokia.jvmagent.client.AgentLauncher', '{-}{-}host', '127.0.0.2',
> '{-}-port', '8778', 'start', '1123')' returned non-zero exit status 1.
> {code}
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/junit/dtest-novnode.auth_test/TestNetworkAuth/test_revoked_dc_access/]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17922) Jolokia agent fails to connect though port is available
[
https://issues.apache.org/jira/browse/CASSANDRA-17922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17922:
--
Reviewers: Josh McKenzie
> Jolokia agent fails to connect though port is available
> ---
>
> Key: CASSANDRA-17922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17922
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> In CASSANDRA-17872 we added protection around failures similar to this,
> caused by the port being in use, which is no longer the case:
> {code}
> subprocess.CalledProcessError: Command
> '('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '{-}cp',
> '/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
> 'org.jolokia.jvmagent.client.AgentLauncher', '{-}{-}host', '127.0.0.2',
> '{-}-port', '8778', 'start', '1123')' returned non-zero exit status 1.
> {code}
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/junit/dtest-novnode.auth_test/TestNetworkAuth/test_revoked_dc_access/]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17923) Mixed mode support for internode authentication during TLS upgrades
[ https://issues.apache.org/jira/browse/CASSANDRA-17923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-17923: -- Status: Ready to Commit (was: Review In Progress) Starting commit CI Results (pending): ||Branch||Source||Circle CI|| |trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17923-trunk-3D0B6138-8009-49D8-83CA-F3C64D96A833]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17923-trunk-3D0B6138-8009-49D8-83CA-F3C64D96A833]| > Mixed mode support for internode authentication during TLS upgrades > --- > > Key: CASSANDRA-17923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17923 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Internode >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > > During upgrades from "non-ssl -> ssl" or "ssl-mTLS" the cluster should be > able to function in mixed mode with some nodes supporting "non-ssl" > authentication and the new nodes supporting "mTLS" authentication. Currently > we do not have this supported and because of which upgrades are not possible > for upgrading internode authentication strategies. > If a node is configured in optional mode for internode connections, retry > with other SSL strategies If the node is not able to connect to other nodes > due to authentication problems. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17939) CircleCI: Automatically detect and repeat new or modified JUnit tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614138#comment-17614138
]
Andres de la Peña commented on CASSANDRA-17939:
---
I have updated the PR adding support for specifying multiple Python dtests,
which are specified in the env var {{REPEATED_DTESTS}} as a comma-separated
list:
{code:java}
-e
REPEATED_DTESTS=cfid_test.py,pending_range_test.py::TestPendingRangeMovements::test_pending_range,cdc_test.py
{code}
I have also rearranged the optional steps so the pre-commit workflows is as
simple as possible. As for the separate workflows, I have added approval steps
so the multiplexer jobs can be started individually. With those changes the new
jobs can mostly replace the old multiplexer, which was only able to run a type
of test at a time.
The old dtest multiplexer has been divided into two companion jobs, so we can
start runs with and without vnodes into the same push. The old utest
multiplexer job is renamed from "repeated_utest" to "repeated_ant_test",
because its only purpose is running ant targets that are not covered by other
tests. The new name should make it easier to distinguish it from the new jobs.
I have also slightly altered the names of some job in order to standarize the
names of the jobs.
The proposed changes in CircleCI config are relatively broad, and they require
to pass different arguments to the {{generate.sh}} script. However, I think
that the new workflow contains all we need to make sure that a single push can
contain all the test repetitions that we need. Most of the tests will be
automatically detected by {{{}git diff{}}}, and specifying whatever other tests
are relevant should be relatively easy:
{code:java}
.circleci/generate.sh -m \
-e REPEATED_TESTS_COUNT=5 \
-e
REPEATED_UTESTS=org.apache.cassandra.cql3.DurationTest,org.apache.cassandra.cql3.validation.entities.DateTypeTest
\
-e
REPEATED_JVM_DTESTS=org.apache.cassandra.distributed.test.AlterTest#getAndSetCompressionParametersTest
\
-e
REPEATED_UTESTS_LONG=org.apache.cassandra.io.sstable.CQLSSTableWriterLongTest#testWideRow
\
-e
REPEATED_DTESTS=cfid_test.py,pending_range_test.py::TestPendingRangeMovements::test_pending_range
{code}
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1899]|[j8_pre-commit|https://app.circleci.com/pipelines/github/adelapena/cassandra/2194/workflows/f5476f5b-0a57-4be6-a091-480e0e4eb1a2]
[j11_pre-commit|https://app.circleci.com/pipelines/github/adelapena/cassandra/2194/workflows/9b9efedd-cf5c-4b1c-bbef-7f2dba772642]
[j8_separate|https://app.circleci.com/pipelines/github/adelapena/cassandra/2193/workflows/cceb3619-78cd-4495-9a11-1819205255de]
[j11_separate|https://app.circleci.com/pipelines/github/adelapena/cassandra/2193/workflows/a9467538-0d5c-4538-b6d5-1d3139dd4dba]|
> CircleCI: Automatically detect and repeat new or modified JUnit tests
> -
>
> Key: CASSANDRA-17939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17939
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> The purpose of this ticket is adding a new CircleCI job that automatically
> detects new or modified test classes and runs them repeatedly. That way we
> wouldn't need to manually specify those tests with {{.circleci/generate.sh}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17933) Zero length file in Audit log folder, prevents a node from starting
[
https://issues.apache.org/jira/browse/CASSANDRA-17933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614126#comment-17614126
]
Caleb Rackliffe commented on CASSANDRA-17933:
-
+1 on the 4.0 PR
> Zero length file in Audit log folder, prevents a node from starting
> ---
>
> Key: CASSANDRA-17933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17933
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Andrew Hogg
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> We have encountered a 4.0.3 cluster where the audit log folder had a zero
> byte length file within it after the node had stopped. It is not clear how
> Cassandra got to the point of this file existing. On restarting the node, the
> node will not start and throws the following stack trace.
> {code:java}
> ERROR [main] 2022-09-26 14:01:27,892 CassandraDaemon.java:911 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:468)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
> Caused by: org.apache.cassandra.exceptions.ConfigurationException: Unable to
> create instance of IAuditLogger.
> at
> org.apache.cassandra.utils.FBUtilities.newAuditLogger(FBUtilities.java:686)
> at
> org.apache.cassandra.audit.AuditLogManager.getAuditLogger(AuditLogManager.java:95)
> at
> org.apache.cassandra.audit.AuditLogManager.(AuditLogManager.java:74)
> at
> org.apache.cassandra.audit.AuditLogManager.(AuditLogManager.java:60)
> ... 3 common frames omitted
> Caused by: java.lang.reflect.InvocationTargetException: null
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.cassandra.utils.FBUtilities.newAuditLogger(FBUtilities.java:682)
> ... 6 common frames omitted
> Caused by: java.nio.channels.OverlappingFileLockException: null
> at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255)
> at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152)
> at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1068)
> at java.nio.channels.FileChannel.lock(FileChannel.java:1053)
> at
> net.openhft.chronicle.bytes.MappedFile.resizeRafIfTooSmall(MappedFile.java:369)
> at
> net.openhft.chronicle.bytes.MappedFile.acquireByteStore(MappedFile.java:307)
> at
> net.openhft.chronicle.bytes.MappedFile.acquireByteStore(MappedFile.java:269)
> at
> net.openhft.chronicle.bytes.MappedBytes.acquireNextByteStore0(MappedBytes.java:434)
> at
> net.openhft.chronicle.bytes.MappedBytes.readVolatileInt(MappedBytes.java:792)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue$StoreSupplier.headerRecovery(SingleChronicleQueue.java:1027)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue$StoreSupplier.acquire(SingleChronicleQueue.java:981)
> at
> net.openhft.chronicle.queue.impl.WireStorePool.acquire(WireStorePool.java:53)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.cleanupStoreFilesWithNoData(SingleChronicleQueue.java:821)
> at
> net.openhft.chronicle.queue.impl.single.StoreAppender.(StoreAppender.java:75)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.newAppender(SingleChronicleQueue.java:422)
> at
> net.openhft.chronicle.core.threads.CleaningThreadLocal.initialValue(CleaningThreadLocal.java:54)
> at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:180)
> at java.lang.ThreadLocal.get(ThreadLocal.java:170)
> at
> net.openhft.chronicle.core.threads.CleaningThreadLocal.get(CleaningThreadLocal.java:59)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.acquireAppender(SingleChronicleQueue.java:441)
> at org.apache.cassandra.utils.binlog.BinLog.(BinLog.java:133)
> at org.apache.cassandra.utils.binlog.BinLog.(BinLog.java:65)
> at
> org.apache.cassandra.utils.binlog.BinLog$Builder.build(BinLog.java:453)
> at
> org.apache.cassandra.audit.BinAuditLogger.(BinAuditLogger.java:55)
> ...
[jira] [Deleted] (CASSANDRA-17953) gjyfgty
[ https://issues.apache.org/jira/browse/CASSANDRA-17953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams deleted CASSANDRA-17953: - > gjyfgty > --- > > Key: CASSANDRA-17953 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17953 > Project: Cassandra > Issue Type: Bug >Reporter: akian uba >Priority: Normal > > gffgtyt > > [https://wiki.opendaylight.org/plugins/viewsource/viewpagesrc.action?pageId=27067614] > [https://wiki.onap.org/plugins/viewsource/viewpagesrc.action?pageId=149030248] > [https://wiki.tungsten.io/plugins/viewsource/viewpagesrc.action?pageId=62718070] > [https://wiki.lfnetworking.org/plugins/viewsource/viewpagesrc.action?pageId=74648195] > [https://goframe.org/plugins/viewsource/viewpagesrc.action?pageId=62097892] > [https://wiki.openidl.org/plugins/viewsource/viewpagesrc.action?pageId=24053539] > [https://wiki.odim.io/plugins/viewsource/viewpagesrc.action?pageId=25165943] > [https://wiki.aswf.io/plugins/viewsource/viewpagesrc.action?pageId=43408079] > [https://wiki.trustoverip.org/plugins/viewsource/viewpagesrc.action?pageId=27723245] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17953) gjyfgty
akian uba created CASSANDRA-17953: - Summary: gjyfgty Key: CASSANDRA-17953 URL: https://issues.apache.org/jira/browse/CASSANDRA-17953 Project: Cassandra Issue Type: Bug Reporter: akian uba gffgtyt [https://wiki.opendaylight.org/plugins/viewsource/viewpagesrc.action?pageId=27067614] [https://wiki.onap.org/plugins/viewsource/viewpagesrc.action?pageId=149030248] [https://wiki.tungsten.io/plugins/viewsource/viewpagesrc.action?pageId=62718070] [https://wiki.lfnetworking.org/plugins/viewsource/viewpagesrc.action?pageId=74648195] [https://goframe.org/plugins/viewsource/viewpagesrc.action?pageId=62097892] [https://wiki.openidl.org/plugins/viewsource/viewpagesrc.action?pageId=24053539] [https://wiki.odim.io/plugins/viewsource/viewpagesrc.action?pageId=25165943] [https://wiki.aswf.io/plugins/viewsource/viewpagesrc.action?pageId=43408079] [https://wiki.trustoverip.org/plugins/viewsource/viewpagesrc.action?pageId=27723245] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17931) Augment our disk space checks for compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-17931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17931: Status: Ready to Commit (was: Review In Progress) +1 > Augment our disk space checks for compaction > > > Key: CASSANDRA-17931 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17931 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.x > > > There are a few things we can augment in how we handle compactions locally to > improve upon the very simple "keep X Mebibytes free on disk" we currently > have: > # Allow specification of free space available in percent rather than raw size > # Do this on a per-disk basis based on what's going on with compactions > # Include an estimate of the disk space of active compactions in flight when > we do the above calculation check so we don't blow past our limits due to > concurrent runs > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17915) Confusing error message when using ? with functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614028#comment-17614028
]
Brandon Williams commented on CASSANDRA-17915:
--
I'm happy to review if we know which branches we're targeting and have CI ready.
> Confusing error message when using ? with functions
> ---
>
> Key: CASSANDRA-17915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17915
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: David Capwell
>Assignee: Natnael Adere
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> INSERT INTO %S (a, b, c) VALUES (? + 1, ?, ?)
> {code}
> Errors saying
> {code}
> Ambiguous '+' operation with args ? and 1: use type casts to disambiguate
> {code}
> Now, if you google “type casts CQL” you get
> https://docs.datastax.com/en/dse/5.1/cql/cql/cql_reference/refCqlFunction.html
> which says to do
> {code}
> CAST( selector AS to_type )
> {code}
> But this also fails!
> {code}
> InvalidRequestException: Ambiguous call to function system.castAsFloat (can
> be matched by following signatures: system."castAsFloat" : (bigint) -> float,
> system."castAsFloat" : (counter) -> float, system."castAsFloat" : (double) ->
> float, system."castAsFloat" : (int) -> float, system."castAsFloat" :
> (tinyint) -> float, system."castAsFloat" : (varint) -> float,
> system."castAsFloat" : (decimal) -> float, system."castAsFloat" : (smallint)
> -> float): use type casts to disambiguate
> {code}
> What we have to do is
> {code}
> INSERT INTO %S (a, b, c) VALUES ((int) ? + 1, ?, ?)
> {code}
> We should improve the error message to show the expected syntax (or fix CAST
> to work in this case).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17915) Confusing error message when using ? with functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17915:
---
Reviewers: Benjamin Lerer
Status: Review In Progress (was: Patch Available)
> Confusing error message when using ? with functions
> ---
>
> Key: CASSANDRA-17915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17915
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: David Capwell
>Assignee: Natnael Adere
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> INSERT INTO %S (a, b, c) VALUES (? + 1, ?, ?)
> {code}
> Errors saying
> {code}
> Ambiguous '+' operation with args ? and 1: use type casts to disambiguate
> {code}
> Now, if you google “type casts CQL” you get
> https://docs.datastax.com/en/dse/5.1/cql/cql/cql_reference/refCqlFunction.html
> which says to do
> {code}
> CAST( selector AS to_type )
> {code}
> But this also fails!
> {code}
> InvalidRequestException: Ambiguous call to function system.castAsFloat (can
> be matched by following signatures: system."castAsFloat" : (bigint) -> float,
> system."castAsFloat" : (counter) -> float, system."castAsFloat" : (double) ->
> float, system."castAsFloat" : (int) -> float, system."castAsFloat" :
> (tinyint) -> float, system."castAsFloat" : (varint) -> float,
> system."castAsFloat" : (decimal) -> float, system."castAsFloat" : (smallint)
> -> float): use type casts to disambiguate
> {code}
> What we have to do is
> {code}
> INSERT INTO %S (a, b, c) VALUES ((int) ? + 1, ?, ?)
> {code}
> We should improve the error message to show the expected syntax (or fix CAST
> to work in this case).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17915) Confusing error message when using ? with functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17915:
---
Test and Documentation Plan: The patch update existing tests
Status: Patch Available (was: In Progress)
> Confusing error message when using ? with functions
> ---
>
> Key: CASSANDRA-17915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17915
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: David Capwell
>Assignee: Natnael Adere
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> INSERT INTO %S (a, b, c) VALUES (? + 1, ?, ?)
> {code}
> Errors saying
> {code}
> Ambiguous '+' operation with args ? and 1: use type casts to disambiguate
> {code}
> Now, if you google “type casts CQL” you get
> https://docs.datastax.com/en/dse/5.1/cql/cql/cql_reference/refCqlFunction.html
> which says to do
> {code}
> CAST( selector AS to_type )
> {code}
> But this also fails!
> {code}
> InvalidRequestException: Ambiguous call to function system.castAsFloat (can
> be matched by following signatures: system."castAsFloat" : (bigint) -> float,
> system."castAsFloat" : (counter) -> float, system."castAsFloat" : (double) ->
> float, system."castAsFloat" : (int) -> float, system."castAsFloat" :
> (tinyint) -> float, system."castAsFloat" : (varint) -> float,
> system."castAsFloat" : (decimal) -> float, system."castAsFloat" : (smallint)
> -> float): use type casts to disambiguate
> {code}
> What we have to do is
> {code}
> INSERT INTO %S (a, b, c) VALUES ((int) ? + 1, ?, ?)
> {code}
> We should improve the error message to show the expected syntax (or fix CAST
> to work in this case).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17915) Confusing error message when using ? with functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17915:
---
Status: Needs Committer (was: Review In Progress)
> Confusing error message when using ? with functions
> ---
>
> Key: CASSANDRA-17915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17915
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: David Capwell
>Assignee: Natnael Adere
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> INSERT INTO %S (a, b, c) VALUES (? + 1, ?, ?)
> {code}
> Errors saying
> {code}
> Ambiguous '+' operation with args ? and 1: use type casts to disambiguate
> {code}
> Now, if you google “type casts CQL” you get
> https://docs.datastax.com/en/dse/5.1/cql/cql/cql_reference/refCqlFunction.html
> which says to do
> {code}
> CAST( selector AS to_type )
> {code}
> But this also fails!
> {code}
> InvalidRequestException: Ambiguous call to function system.castAsFloat (can
> be matched by following signatures: system."castAsFloat" : (bigint) -> float,
> system."castAsFloat" : (counter) -> float, system."castAsFloat" : (double) ->
> float, system."castAsFloat" : (int) -> float, system."castAsFloat" :
> (tinyint) -> float, system."castAsFloat" : (varint) -> float,
> system."castAsFloat" : (decimal) -> float, system."castAsFloat" : (smallint)
> -> float): use type casts to disambiguate
> {code}
> What we have to do is
> {code}
> INSERT INTO %S (a, b, c) VALUES ((int) ? + 1, ?, ?)
> {code}
> We should improve the error message to show the expected syntax (or fix CAST
> to work in this case).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17915) Confusing error message when using ? with functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614023#comment-17614023
]
Benjamin Lerer commented on CASSANDRA-17915:
[~NateAdere] When your patch is ready do not forget to change the status to
PATCH AVAILABLE otherwise people might miss it :)
> Confusing error message when using ? with functions
> ---
>
> Key: CASSANDRA-17915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17915
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: David Capwell
>Assignee: Natnael Adere
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> INSERT INTO %S (a, b, c) VALUES (? + 1, ?, ?)
> {code}
> Errors saying
> {code}
> Ambiguous '+' operation with args ? and 1: use type casts to disambiguate
> {code}
> Now, if you google “type casts CQL” you get
> https://docs.datastax.com/en/dse/5.1/cql/cql/cql_reference/refCqlFunction.html
> which says to do
> {code}
> CAST( selector AS to_type )
> {code}
> But this also fails!
> {code}
> InvalidRequestException: Ambiguous call to function system.castAsFloat (can
> be matched by following signatures: system."castAsFloat" : (bigint) -> float,
> system."castAsFloat" : (counter) -> float, system."castAsFloat" : (double) ->
> float, system."castAsFloat" : (int) -> float, system."castAsFloat" :
> (tinyint) -> float, system."castAsFloat" : (varint) -> float,
> system."castAsFloat" : (decimal) -> float, system."castAsFloat" : (smallint)
> -> float): use type casts to disambiguate
> {code}
> What we have to do is
> {code}
> INSERT INTO %S (a, b, c) VALUES ((int) ? + 1, ?, ?)
> {code}
> We should improve the error message to show the expected syntax (or fix CAST
> to work in this case).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17915) Confusing error message when using ? with functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614022#comment-17614022
]
Benjamin Lerer commented on CASSANDRA-17915:
[~NateAdere] the patch looks good to me. Were you able to run CircleCI ?
[~brandon.williams] we would need another reviewer.
> Confusing error message when using ? with functions
> ---
>
> Key: CASSANDRA-17915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17915
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: David Capwell
>Assignee: Natnael Adere
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> INSERT INTO %S (a, b, c) VALUES (? + 1, ?, ?)
> {code}
> Errors saying
> {code}
> Ambiguous '+' operation with args ? and 1: use type casts to disambiguate
> {code}
> Now, if you google “type casts CQL” you get
> https://docs.datastax.com/en/dse/5.1/cql/cql/cql_reference/refCqlFunction.html
> which says to do
> {code}
> CAST( selector AS to_type )
> {code}
> But this also fails!
> {code}
> InvalidRequestException: Ambiguous call to function system.castAsFloat (can
> be matched by following signatures: system."castAsFloat" : (bigint) -> float,
> system."castAsFloat" : (counter) -> float, system."castAsFloat" : (double) ->
> float, system."castAsFloat" : (int) -> float, system."castAsFloat" :
> (tinyint) -> float, system."castAsFloat" : (varint) -> float,
> system."castAsFloat" : (decimal) -> float, system."castAsFloat" : (smallint)
> -> float): use type casts to disambiguate
> {code}
> What we have to do is
> {code}
> INSERT INTO %S (a, b, c) VALUES ((int) ? + 1, ?, ?)
> {code}
> We should improve the error message to show the expected syntax (or fix CAST
> to work in this case).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614005#comment-17614005 ] Aleksey Yeschenko commented on CASSANDRA-16681: --- Yep. That's why I've actually delayed that a bit and only committed the test fix so far. Not placing the recycled chunk in the optimal queue is a minor performance issue, but failing to recycle altogether is more serious than that. > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Piotr Kolaczkowski >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > Time Spent: 20m > Remaining Estimate: 0h > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17933) Zero length file in Audit log folder, prevents a node from starting
[
https://issues.apache.org/jira/browse/CASSANDRA-17933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17933:
--
Status: Changes Suggested (was: Review In Progress)
> Zero length file in Audit log folder, prevents a node from starting
> ---
>
> Key: CASSANDRA-17933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17933
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Andrew Hogg
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> We have encountered a 4.0.3 cluster where the audit log folder had a zero
> byte length file within it after the node had stopped. It is not clear how
> Cassandra got to the point of this file existing. On restarting the node, the
> node will not start and throws the following stack trace.
> {code:java}
> ERROR [main] 2022-09-26 14:01:27,892 CassandraDaemon.java:911 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:468)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
> Caused by: org.apache.cassandra.exceptions.ConfigurationException: Unable to
> create instance of IAuditLogger.
> at
> org.apache.cassandra.utils.FBUtilities.newAuditLogger(FBUtilities.java:686)
> at
> org.apache.cassandra.audit.AuditLogManager.getAuditLogger(AuditLogManager.java:95)
> at
> org.apache.cassandra.audit.AuditLogManager.(AuditLogManager.java:74)
> at
> org.apache.cassandra.audit.AuditLogManager.(AuditLogManager.java:60)
> ... 3 common frames omitted
> Caused by: java.lang.reflect.InvocationTargetException: null
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.cassandra.utils.FBUtilities.newAuditLogger(FBUtilities.java:682)
> ... 6 common frames omitted
> Caused by: java.nio.channels.OverlappingFileLockException: null
> at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255)
> at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152)
> at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1068)
> at java.nio.channels.FileChannel.lock(FileChannel.java:1053)
> at
> net.openhft.chronicle.bytes.MappedFile.resizeRafIfTooSmall(MappedFile.java:369)
> at
> net.openhft.chronicle.bytes.MappedFile.acquireByteStore(MappedFile.java:307)
> at
> net.openhft.chronicle.bytes.MappedFile.acquireByteStore(MappedFile.java:269)
> at
> net.openhft.chronicle.bytes.MappedBytes.acquireNextByteStore0(MappedBytes.java:434)
> at
> net.openhft.chronicle.bytes.MappedBytes.readVolatileInt(MappedBytes.java:792)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue$StoreSupplier.headerRecovery(SingleChronicleQueue.java:1027)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue$StoreSupplier.acquire(SingleChronicleQueue.java:981)
> at
> net.openhft.chronicle.queue.impl.WireStorePool.acquire(WireStorePool.java:53)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.cleanupStoreFilesWithNoData(SingleChronicleQueue.java:821)
> at
> net.openhft.chronicle.queue.impl.single.StoreAppender.(StoreAppender.java:75)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.newAppender(SingleChronicleQueue.java:422)
> at
> net.openhft.chronicle.core.threads.CleaningThreadLocal.initialValue(CleaningThreadLocal.java:54)
> at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:180)
> at java.lang.ThreadLocal.get(ThreadLocal.java:170)
> at
> net.openhft.chronicle.core.threads.CleaningThreadLocal.get(CleaningThreadLocal.java:59)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.acquireAppender(SingleChronicleQueue.java:441)
> at org.apache.cassandra.utils.binlog.BinLog.(BinLog.java:133)
> at org.apache.cassandra.utils.binlog.BinLog.(BinLog.java:65)
> at
> org.apache.cassandra.utils.binlog.BinLog$Builder.build(BinLog.java:453)
> at
> org.apache.cassandra.audit.BinAuditLogger.(BinAuditLogger.java:55)
> ... 11 common fra
[jira] [Updated] (CASSANDRA-17933) Zero length file in Audit log folder, prevents a node from starting
[
https://issues.apache.org/jira/browse/CASSANDRA-17933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17933:
--
Status: In Progress (was: Changes Suggested)
> Zero length file in Audit log folder, prevents a node from starting
> ---
>
> Key: CASSANDRA-17933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17933
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Andrew Hogg
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> We have encountered a 4.0.3 cluster where the audit log folder had a zero
> byte length file within it after the node had stopped. It is not clear how
> Cassandra got to the point of this file existing. On restarting the node, the
> node will not start and throws the following stack trace.
> {code:java}
> ERROR [main] 2022-09-26 14:01:27,892 CassandraDaemon.java:911 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:468)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
> Caused by: org.apache.cassandra.exceptions.ConfigurationException: Unable to
> create instance of IAuditLogger.
> at
> org.apache.cassandra.utils.FBUtilities.newAuditLogger(FBUtilities.java:686)
> at
> org.apache.cassandra.audit.AuditLogManager.getAuditLogger(AuditLogManager.java:95)
> at
> org.apache.cassandra.audit.AuditLogManager.(AuditLogManager.java:74)
> at
> org.apache.cassandra.audit.AuditLogManager.(AuditLogManager.java:60)
> ... 3 common frames omitted
> Caused by: java.lang.reflect.InvocationTargetException: null
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.cassandra.utils.FBUtilities.newAuditLogger(FBUtilities.java:682)
> ... 6 common frames omitted
> Caused by: java.nio.channels.OverlappingFileLockException: null
> at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255)
> at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152)
> at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1068)
> at java.nio.channels.FileChannel.lock(FileChannel.java:1053)
> at
> net.openhft.chronicle.bytes.MappedFile.resizeRafIfTooSmall(MappedFile.java:369)
> at
> net.openhft.chronicle.bytes.MappedFile.acquireByteStore(MappedFile.java:307)
> at
> net.openhft.chronicle.bytes.MappedFile.acquireByteStore(MappedFile.java:269)
> at
> net.openhft.chronicle.bytes.MappedBytes.acquireNextByteStore0(MappedBytes.java:434)
> at
> net.openhft.chronicle.bytes.MappedBytes.readVolatileInt(MappedBytes.java:792)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue$StoreSupplier.headerRecovery(SingleChronicleQueue.java:1027)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue$StoreSupplier.acquire(SingleChronicleQueue.java:981)
> at
> net.openhft.chronicle.queue.impl.WireStorePool.acquire(WireStorePool.java:53)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.cleanupStoreFilesWithNoData(SingleChronicleQueue.java:821)
> at
> net.openhft.chronicle.queue.impl.single.StoreAppender.(StoreAppender.java:75)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.newAppender(SingleChronicleQueue.java:422)
> at
> net.openhft.chronicle.core.threads.CleaningThreadLocal.initialValue(CleaningThreadLocal.java:54)
> at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:180)
> at java.lang.ThreadLocal.get(ThreadLocal.java:170)
> at
> net.openhft.chronicle.core.threads.CleaningThreadLocal.get(CleaningThreadLocal.java:59)
> at
> net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.acquireAppender(SingleChronicleQueue.java:441)
> at org.apache.cassandra.utils.binlog.BinLog.(BinLog.java:133)
> at org.apache.cassandra.utils.binlog.BinLog.(BinLog.java:65)
> at
> org.apache.cassandra.utils.binlog.BinLog$Builder.build(BinLog.java:453)
> at
> org.apache.cassandra.audit.BinAuditLogger.(BinAuditLogger.java:55)
> ... 11 common frames omi
[jira] [Comment Edited] (CASSANDRA-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17613928#comment-17613928
]
Piotr Kolaczkowski edited comment on CASSANDRA-16681 at 10/7/22 7:41 AM:
-
The `testPoolAllocateWithRecyclePartially` fails quite reliably if I exclude
the last patch:
{noformat}
INFO [main] 2022-10-07 09:31:39,811 LongBufferPoolTest.java:329 - 2022/10/07
09:31:39 - testing 16 threads for 2m
INFO [main] 2022-10-07 09:31:39,811 LongBufferPoolTest.java:330 - Testing
BufferPool with memoryUsageThreshold=16777216 and enabling BufferPool.DEBUG
INFO [test:5] 2022-10-07 09:31:39,829 NoSpamLogger.java:92 - Maximum memory
usage reached (16,000MiB), cannot allocate chunk of 8,000MiB
java.lang.AssertionError: Last recycled 5 < last acquired 6
at
org.apache.cassandra.utils.memory.LongBufferPoolTest$Debug.check(LongBufferPoolTest.java:122)
at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testAllocate(LongBufferPoolTest.java:353)
at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testPoolAllocate(LongBufferPoolTest.java:159)
at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testPoolAllocateWithRecyclePartially(LongBufferPoolTest.java:147)
{noformat}
The other test `testPoolAllocateWithoutRecyclePartially` works fine with only 6
patches.
So the 7-th patch fixes partial recycling. Not sure how serious this is - looks
like some chunks would simply be not recycled, so that could cause a memory
leak worst case?
was (Author: pkolaczk):
The {noformat}testPoolAllocateWithRecyclePartially{noformat} fails quite
reliably if I exclude the last patch:
{noformat}
INFO [main] 2022-10-07 09:31:39,811 LongBufferPoolTest.java:329 - 2022/10/07
09:31:39 - testing 16 threads for 2m
INFO [main] 2022-10-07 09:31:39,811 LongBufferPoolTest.java:330 - Testing
BufferPool with memoryUsageThreshold=16777216 and enabling BufferPool.DEBUG
INFO [test:5] 2022-10-07 09:31:39,829 NoSpamLogger.java:92 - Maximum memory
usage reached (16,000MiB), cannot allocate chunk of 8,000MiB
java.lang.AssertionError: Last recycled 5 < last acquired 6
at
org.apache.cassandra.utils.memory.LongBufferPoolTest$Debug.check(LongBufferPoolTest.java:122)
at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testAllocate(LongBufferPoolTest.java:353)
at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testPoolAllocate(LongBufferPoolTest.java:159)
at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testPoolAllocateWithRecyclePartially(LongBufferPoolTest.java:147)
{noformat}
The other test ({noformat}testPoolAllocateWithoutRecyclePartially{noformat})
works fine with only 6 patches.
So the 7-th patch fixes partial recycling. Not sure how serious this is - looks
like some chunks would simply be not recycled, so that could cause a memory
leak worst case?
> org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
> --
>
> Key: CASSANDRA-16681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16681
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Piotr Kolaczkowski
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Jenkins history:
> [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/]
> Fails being run in a loop in CircleCI:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17613928#comment-17613928
]
Piotr Kolaczkowski commented on CASSANDRA-16681:
The {noformat}testPoolAllocateWithRecyclePartially{noformat} fails quite
reliably if I exclude the last patch:
{noformat}
INFO [main] 2022-10-07 09:31:39,811 LongBufferPoolTest.java:329 - 2022/10/07
09:31:39 - testing 16 threads for 2m
INFO [main] 2022-10-07 09:31:39,811 LongBufferPoolTest.java:330 - Testing
BufferPool with memoryUsageThreshold=16777216 and enabling BufferPool.DEBUG
INFO [test:5] 2022-10-07 09:31:39,829 NoSpamLogger.java:92 - Maximum memory
usage reached (16,000MiB), cannot allocate chunk of 8,000MiB
java.lang.AssertionError: Last recycled 5 < last acquired 6
at
org.apache.cassandra.utils.memory.LongBufferPoolTest$Debug.check(LongBufferPoolTest.java:122)
at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testAllocate(LongBufferPoolTest.java:353)
at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testPoolAllocate(LongBufferPoolTest.java:159)
at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testPoolAllocateWithRecyclePartially(LongBufferPoolTest.java:147)
{noformat}
The other test ({noformat}testPoolAllocateWithoutRecyclePartially{noformat})
works fine with only 6 patches.
So the 7-th patch fixes partial recycling. Not sure how serious this is - looks
like some chunks would simply be not recycled, so that could cause a memory
leak worst case?
> org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
> --
>
> Key: CASSANDRA-16681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16681
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Piotr Kolaczkowski
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Jenkins history:
> [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/]
> Fails being run in a loop in CircleCI:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17613911#comment-17613911
]
Piotr Kolaczkowski edited comment on CASSANDRA-16681 at 10/7/22 7:22 AM:
-
[~aleksey] I'm not sure if the the last patch didn't fix something actually.
Let me try to rerun the test with only 6 changes and see if it works and I get
back to you. There was simply many back-and-forth already on this and I don't
remember exactly at the moment, but the fact that the original control flow
didn't go through the same CAS could be a correctness issue, not just code
style issue.
// edit:
Looking at the description, there was a race fixed there, not just code style:
{quote}
2. When a chunk was evicted, it was first released and later marked as
EVICTED. The actual order of operations with partial recycling
enabled was as follows:
a) release: clear owner -> tryRecycle -> try change status
EVICTED to IN_USE (fail)
b) change status to EVICTED
This not only didn't really recycle the chunk, but could also race
with an other thread trying to recycle the very same chunk and
accidentally mark an already recycled chunk as EVICTED.
The order has been fixed and now chunk is marked as evicted before
attempting to recycle it.
{quote}
was (Author: pkolaczk):
[~aleksey] I'm not sure if the the last patch didn't fix something actually.
Let me try to rerun the test with only 6 changes and see if it works and I get
back to you. There was simply many back-and-forth already on this and I don't
remember exactly at the moment, but the fact that the original control flow
didn't go through the same CAS could be a correctness issue, not just code
style issue.
> org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
> --
>
> Key: CASSANDRA-16681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16681
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Piotr Kolaczkowski
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Jenkins history:
> [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/]
> Fails being run in a loop in CircleCI:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17613911#comment-17613911 ] Piotr Kolaczkowski commented on CASSANDRA-16681: [~aleksey] I'm not sure if the the last patch didn't fix something actually. Let me try to rerun the test with only 6 changes and see if it works and I get back to you. There was simply many back-and-forth already on this and I don't remember exactly at the moment, but the fact that the original control flow didn't go through the same CAS could be a correctness issue, not just code style issue. > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Piotr Kolaczkowski >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > Time Spent: 20m > Remaining Estimate: 0h > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
