[jira] [Commented] (CASSANDRA-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823074#comment-17823074
]
Angelo Polo commented on CASSANDRA-19453:
-
I'm getting the exact same error with 5.0-beta1. This is a fresh install on a
fresh Amazon Linux 2023 on arm64 instance. JAVA_HOME seems to be correct.
{code:java}
$ java -version
openjdk version "17.0.2" 2022-01-18
OpenJDK Runtime Environment (build 17.0.2+8-86)
OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing)
$ which java
/usr/local/bin/jdk-17.0.2/bin/java
$ echo $JAVA_HOME
/usr/local/bin/jdk-17.0.2
$ echo $CASSANDRA_CONF
/home/cassandra/c_conf/5.0-beta1_01
$ echo $CASSANDRA_HOME
/usr/local/bin/apache-cassandra-5.0-beta1
{code}
("XXX"s indicate redaction.)
{code:java}
$ cd $CASSANDRA_CONF
$ diff cassandra.yaml.bak cassandra.yaml
11c11
< cluster_name: 'Test Cluster'
---
> cluster_name: 'XX'
154c154
< class_name : org.apache.cassandra.auth.AllowAllAuthenticator
---
> class_name : org.apache.cassandra.auth.PasswordAuthenticator
169c169
< authorizer: AllowAllAuthorizer
---
> authorizer: CassandraAuthorizer
974c974
< rpc_address: localhost
---
> rpc_address: XXX-XXX-XXX-XXX
$ diff cassandra-env.sh.bak cassandra-env.sh
206c206
< # JVM_OPTS="$JVM_OPTS -Djava.rmi.server.hostname="
---
> JVM_OPTS="$JVM_OPTS
> -Djava.rmi.server.hostname=ec2-XXX-XXX-XXX-XXX.compute-1.amazonaws.com"
216a217
> LOCAL_JMX=no
224c225
< JMX_PORT="7199"
---
> JMX_PORT="7488"
{code}
Get the same error whether or not I set "java.rmi.server.hostname".
If I do not set "LOCAL_JMX=no" in cassandra-env.sh, it runs fine.
Any ideas what could be wrong?
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
> ... 7 more
> ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
>
[jira] [Commented] (CASSANDRA-14325) Java executable check succeeds despite no java on PATH
[ https://issues.apache.org/jira/browse/CASSANDRA-14325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17381960#comment-17381960 ] Angelo Polo commented on CASSANDRA-14325: - Patches for trunk/4.0 and 3.11/3.0 attached. > Java executable check succeeds despite no java on PATH > -- > > Key: CASSANDRA-14325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14325 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Low > Fix For: 3.0.x, 3.11.x, 4.0.x > > Attachments: 3.x.patch, trunk.patch > > > The check -z $JAVA on line 102 of bin/cassandra currently always succeeds if > JAVA_HOME is not set since in this case JAVA gets set directly to 'java'. The > error message "_Unable to find java executable. Check JAVA_HOME and PATH > environment variables._" will never be echoed on a PATH misconfiguration. If > java isn't on the PATH the failure will instead occur on line 95 of > cassandra-env.sh at the java version check. > It would be better to check consistently for the java executable in one place > in bin/cassandra. Also we don't want users to mistakenly think they have a > java version problem when they in fact have a PATH problem. > See proposed patch. -- 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-14325) Java executable check succeeds despite no java on PATH
[ https://issues.apache.org/jira/browse/CASSANDRA-14325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo Polo updated CASSANDRA-14325: Attachment: (was: redhat_cassandra.in.sh.patch) > Java executable check succeeds despite no java on PATH > -- > > Key: CASSANDRA-14325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14325 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Low > Fix For: 3.0.x, 3.11.x, 4.0.x > > Attachments: 3.x.patch, trunk.patch > > > The check -z $JAVA on line 102 of bin/cassandra currently always succeeds if > JAVA_HOME is not set since in this case JAVA gets set directly to 'java'. The > error message "_Unable to find java executable. Check JAVA_HOME and PATH > environment variables._" will never be echoed on a PATH misconfiguration. If > java isn't on the PATH the failure will instead occur on line 95 of > cassandra-env.sh at the java version check. > It would be better to check consistently for the java executable in one place > in bin/cassandra. Also we don't want users to mistakenly think they have a > java version problem when they in fact have a PATH problem. > See proposed patch. -- 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-14325) Java executable check succeeds despite no java on PATH
[ https://issues.apache.org/jira/browse/CASSANDRA-14325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo Polo updated CASSANDRA-14325: Attachment: (was: bin_cassandra.in.sh.patch) > Java executable check succeeds despite no java on PATH > -- > > Key: CASSANDRA-14325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14325 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Low > Fix For: 3.0.x, 3.11.x, 4.0.x > > Attachments: 3.x.patch, trunk.patch > > > The check -z $JAVA on line 102 of bin/cassandra currently always succeeds if > JAVA_HOME is not set since in this case JAVA gets set directly to 'java'. The > error message "_Unable to find java executable. Check JAVA_HOME and PATH > environment variables._" will never be echoed on a PATH misconfiguration. If > java isn't on the PATH the failure will instead occur on line 95 of > cassandra-env.sh at the java version check. > It would be better to check consistently for the java executable in one place > in bin/cassandra. Also we don't want users to mistakenly think they have a > java version problem when they in fact have a PATH problem. > See proposed patch. -- 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-14325) Java executable check succeeds despite no java on PATH
[ https://issues.apache.org/jira/browse/CASSANDRA-14325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo Polo updated CASSANDRA-14325: Attachment: (was: tools_bin_cassandra.in.sh.patch) > Java executable check succeeds despite no java on PATH > -- > > Key: CASSANDRA-14325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14325 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Low > Fix For: 3.0.x, 3.11.x, 4.0.x > > Attachments: 3.x.patch, trunk.patch > > > The check -z $JAVA on line 102 of bin/cassandra currently always succeeds if > JAVA_HOME is not set since in this case JAVA gets set directly to 'java'. The > error message "_Unable to find java executable. Check JAVA_HOME and PATH > environment variables._" will never be echoed on a PATH misconfiguration. If > java isn't on the PATH the failure will instead occur on line 95 of > cassandra-env.sh at the java version check. > It would be better to check consistently for the java executable in one place > in bin/cassandra. Also we don't want users to mistakenly think they have a > java version problem when they in fact have a PATH problem. > See proposed patch. -- 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-14325) Java executable check succeeds despite no java on PATH
[ https://issues.apache.org/jira/browse/CASSANDRA-14325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo Polo updated CASSANDRA-14325: Attachment: trunk.patch 3.x.patch > Java executable check succeeds despite no java on PATH > -- > > Key: CASSANDRA-14325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14325 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Low > Fix For: 3.0.x, 3.11.x, 4.0.x > > Attachments: 3.x.patch, trunk.patch > > > The check -z $JAVA on line 102 of bin/cassandra currently always succeeds if > JAVA_HOME is not set since in this case JAVA gets set directly to 'java'. The > error message "_Unable to find java executable. Check JAVA_HOME and PATH > environment variables._" will never be echoed on a PATH misconfiguration. If > java isn't on the PATH the failure will instead occur on line 95 of > cassandra-env.sh at the java version check. > It would be better to check consistently for the java executable in one place > in bin/cassandra. Also we don't want users to mistakenly think they have a > java version problem when they in fact have a PATH problem. > See proposed patch. -- 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-14325) Java executable check succeeds despite no java on PATH
[ https://issues.apache.org/jira/browse/CASSANDRA-14325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17381407#comment-17381407 ] Angelo Polo commented on CASSANDRA-14325: - That's a nice simplification. I've attached patches for all three files. > Java executable check succeeds despite no java on PATH > -- > > Key: CASSANDRA-14325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14325 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Low > Fix For: 3.0.x, 3.11.x, 4.0.x > > Attachments: bin_cassandra.in.sh.patch, redhat_cassandra.in.sh.patch, > tools_bin_cassandra.in.sh.patch > > > The check -z $JAVA on line 102 of bin/cassandra currently always succeeds if > JAVA_HOME is not set since in this case JAVA gets set directly to 'java'. The > error message "_Unable to find java executable. Check JAVA_HOME and PATH > environment variables._" will never be echoed on a PATH misconfiguration. If > java isn't on the PATH the failure will instead occur on line 95 of > cassandra-env.sh at the java version check. > It would be better to check consistently for the java executable in one place > in bin/cassandra. Also we don't want users to mistakenly think they have a > java version problem when they in fact have a PATH problem. > See proposed patch. -- 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-14325) Java executable check succeeds despite no java on PATH
[ https://issues.apache.org/jira/browse/CASSANDRA-14325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo Polo updated CASSANDRA-14325: Attachment: bin_cassandra.in.sh.patch tools_bin_cassandra.in.sh.patch redhat_cassandra.in.sh.patch > Java executable check succeeds despite no java on PATH > -- > > Key: CASSANDRA-14325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14325 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Low > Fix For: 3.0.x, 3.11.x, 4.0.x > > Attachments: bin_cassandra.in.sh.patch, redhat_cassandra.in.sh.patch, > tools_bin_cassandra.in.sh.patch > > > The check -z $JAVA on line 102 of bin/cassandra currently always succeeds if > JAVA_HOME is not set since in this case JAVA gets set directly to 'java'. The > error message "_Unable to find java executable. Check JAVA_HOME and PATH > environment variables._" will never be echoed on a PATH misconfiguration. If > java isn't on the PATH the failure will instead occur on line 95 of > cassandra-env.sh at the java version check. > It would be better to check consistently for the java executable in one place > in bin/cassandra. Also we don't want users to mistakenly think they have a > java version problem when they in fact have a PATH problem. > See proposed patch. -- 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-14325) Java executable check succeeds despite no java on PATH
[ https://issues.apache.org/jira/browse/CASSANDRA-14325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo Polo updated CASSANDRA-14325: Attachment: (was: bin_cassandra.patch) > Java executable check succeeds despite no java on PATH > -- > > Key: CASSANDRA-14325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14325 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Low > Fix For: 3.0.x, 3.11.x, 4.0.x > > Attachments: bin_cassandra.in.sh.patch, redhat_cassandra.in.sh.patch, > tools_bin_cassandra.in.sh.patch > > > The check -z $JAVA on line 102 of bin/cassandra currently always succeeds if > JAVA_HOME is not set since in this case JAVA gets set directly to 'java'. The > error message "_Unable to find java executable. Check JAVA_HOME and PATH > environment variables._" will never be echoed on a PATH misconfiguration. If > java isn't on the PATH the failure will instead occur on line 95 of > cassandra-env.sh at the java version check. > It would be better to check consistently for the java executable in one place > in bin/cassandra. Also we don't want users to mistakenly think they have a > java version problem when they in fact have a PATH problem. > See proposed patch. -- 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-16704) Fix imports; run tests with packaged dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-16704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17360242#comment-17360242 ] Angelo Polo commented on CASSANDRA-16704: - The patch 'cleanup-imports.patch' is simply the old patch with the change to build.xml removed. The patch 'dedup-deps.patch' contains the following changes, exclusively modifying build.xml, from my understanding of our discussion above: * Removed duplicates of test scope that are already in provided scope. * Removed duplicated scope attributes. All scope attributes are now uniformly provided in parent-pom. * Added to parent-pom. Was previously only declared in build-deps-pom. > Fix imports; run tests with packaged dependencies > - > > Key: CASSANDRA-16704 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16704 > Project: Cassandra > Issue Type: Bug > Components: Build, Test/burn, Test/unit >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Normal > Fix For: 4.0.x, 4.x > > Attachments: cleanup-imports.patch, dedup-deps.patch > > > Tests are currently run with a classpath containing _all_ downloaded jars. > The tests would be more reflective of the behavior of a runtime environment > if the test classpath only contained jars that are bundled with the binary > release, together with explicit test dependencies. Ideally we'd use the > build/lib/ jars for the classpath since that's what gets packaged, but since > these aren't available at test compile time and should be identical to lib/ > anyway, I've used the later. > Doing so exposed a couple of references in src/java to > "org.apache.commons.lang", which is not available at runtime (should be > "org.apache.commons.lang*3*"). > Attached patch modifies the test classpath, fixes various imports in both > test/ and src/ classes, and makes some simple substitutions in the tests such > as using AbstractMap.SimpleEntry in place of > org.apache.commons.collections.keyvalue.AbstractMapEntry. -- 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-16704) Fix imports; run tests with packaged dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-16704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo Polo updated CASSANDRA-16704: Attachment: (was: test-with-runtime-deps.patch) > Fix imports; run tests with packaged dependencies > - > > Key: CASSANDRA-16704 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16704 > Project: Cassandra > Issue Type: Bug > Components: Build, Test/burn, Test/unit >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Normal > Fix For: 4.0.x, 4.x > > Attachments: cleanup-imports.patch, dedup-deps.patch > > > Tests are currently run with a classpath containing _all_ downloaded jars. > The tests would be more reflective of the behavior of a runtime environment > if the test classpath only contained jars that are bundled with the binary > release, together with explicit test dependencies. Ideally we'd use the > build/lib/ jars for the classpath since that's what gets packaged, but since > these aren't available at test compile time and should be identical to lib/ > anyway, I've used the later. > Doing so exposed a couple of references in src/java to > "org.apache.commons.lang", which is not available at runtime (should be > "org.apache.commons.lang*3*"). > Attached patch modifies the test classpath, fixes various imports in both > test/ and src/ classes, and makes some simple substitutions in the tests such > as using AbstractMap.SimpleEntry in place of > org.apache.commons.collections.keyvalue.AbstractMapEntry. -- 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-16704) Fix imports; run tests with packaged dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-16704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo Polo updated CASSANDRA-16704: Attachment: cleanup-imports.patch dedup-deps.patch > Fix imports; run tests with packaged dependencies > - > > Key: CASSANDRA-16704 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16704 > Project: Cassandra > Issue Type: Bug > Components: Build, Test/burn, Test/unit >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Normal > Fix For: 4.0.x, 4.x > > Attachments: cleanup-imports.patch, dedup-deps.patch, > test-with-runtime-deps.patch > > > Tests are currently run with a classpath containing _all_ downloaded jars. > The tests would be more reflective of the behavior of a runtime environment > if the test classpath only contained jars that are bundled with the binary > release, together with explicit test dependencies. Ideally we'd use the > build/lib/ jars for the classpath since that's what gets packaged, but since > these aren't available at test compile time and should be identical to lib/ > anyway, I've used the later. > Doing so exposed a couple of references in src/java to > "org.apache.commons.lang", which is not available at runtime (should be > "org.apache.commons.lang*3*"). > Attached patch modifies the test classpath, fixes various imports in both > test/ and src/ classes, and makes some simple substitutions in the tests such > as using AbstractMap.SimpleEntry in place of > org.apache.commons.collections.keyvalue.AbstractMapEntry. -- 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-16704) Fix imports; run tests with packaged dependencies
[
https://issues.apache.org/jira/browse/CASSANDRA-16704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17359125#comment-17359125
]
Angelo Polo commented on CASSANDRA-16704:
-
{quote}They are in places, see all those marked as "provided" or "optional"
[here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/build.xml#L491-L657]
and
[here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/build.xml#L749-L833].
{quote}
Is it intentional that the scope for some entries is repeated across the two
pom definitions, while missing for others? Below is for 'provided' scope,
similar situation for 'test' scope. Those shown in blue are declared with scope
in only one place, those in green are given a scope in both places:
parent-pom:
{color:#4c9aff}{color}
{color:#57d9a3}{color}
{color:#57d9a3}{color}
{color:#4c9aff}{color}
{color:#57d9a3}{color}
{color:#57d9a3}{color}
all-pom:
{color:#4c9aff}{color}
{color:#57d9a3}{color}
{color:#57d9a3}{color}
{color:#57d9a3}{color}
{color:#57d9a3}{color}
{color:#4c9aff}{color}
{color:#4c9aff}{color}
{color:#4c9aff}{color}
{color:#4c9aff}{color}
{color:#4c9aff}{color}
> Fix imports; run tests with packaged dependencies
> -
>
> Key: CASSANDRA-16704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16704
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/burn, Test/unit
>Reporter: Angelo Polo
>Assignee: Angelo Polo
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: test-with-runtime-deps.patch
>
>
> Tests are currently run with a classpath containing _all_ downloaded jars.
> The tests would be more reflective of the behavior of a runtime environment
> if the test classpath only contained jars that are bundled with the binary
> release, together with explicit test dependencies. Ideally we'd use the
> build/lib/ jars for the classpath since that's what gets packaged, but since
> these aren't available at test compile time and should be identical to lib/
> anyway, I've used the later.
> Doing so exposed a couple of references in src/java to
> "org.apache.commons.lang", which is not available at runtime (should be
> "org.apache.commons.lang*3*").
> Attached patch modifies the test classpath, fixes various imports in both
> test/ and src/ classes, and makes some simple substitutions in the tests such
> as using AbstractMap.SimpleEntry in place of
> org.apache.commons.collections.keyvalue.AbstractMapEntry.
--
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-16704) Fix imports; run tests with packaged dependencies
[
https://issues.apache.org/jira/browse/CASSANDRA-16704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17356637#comment-17356637
]
Angelo Polo commented on CASSANDRA-16704:
-
I would think so. I can check and create a second patch for those.
A side comment:
{quote}Maybe there are jar files here that should be removed, i.e. should not
even be part the provided scope?
{quote}
Byteman in particular seems to be in 'provided' because of the single class
src/java/org/apache/cassandra/utils/TestRateLimiter.java, which appears to be
only used for testing. Without knowing the details of how byteman works, since
this class doesn't seem to make any reference to other Cassandra classes, the
package name would be the only relevant thing here (if even that) and it could
be moved to test/. The byteman deps could then all be 'test' scoped only. Or is
this class in src/ simply because it could be used by test/unit/,
test/distributed/, etc., whose trees shouldn't depend on each other? (That
would seem a weak reason to include a class with ordinarily unresolvable
imports in the end product, but so long as no one uses it no harm done, and I'm
not up to speed on the organization of tests categories anyhow.)
> Fix imports; run tests with packaged dependencies
> -
>
> Key: CASSANDRA-16704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16704
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/burn, Test/unit
>Reporter: Angelo Polo
>Assignee: Angelo Polo
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: test-with-runtime-deps.patch
>
>
> Tests are currently run with a classpath containing _all_ downloaded jars.
> The tests would be more reflective of the behavior of a runtime environment
> if the test classpath only contained jars that are bundled with the binary
> release, together with explicit test dependencies. Ideally we'd use the
> build/lib/ jars for the classpath since that's what gets packaged, but since
> these aren't available at test compile time and should be identical to lib/
> anyway, I've used the later.
> Doing so exposed a couple of references in src/java to
> "org.apache.commons.lang", which is not available at runtime (should be
> "org.apache.commons.lang*3*").
> Attached patch modifies the test classpath, fixes various imports in both
> test/ and src/ classes, and makes some simple substitutions in the tests such
> as using AbstractMap.SimpleEntry in place of
> org.apache.commons.collections.keyvalue.AbstractMapEntry.
--
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-16704) Fix imports; run tests with packaged dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-16704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17356571#comment-17356571 ] Angelo Polo edited comment on CASSANDRA-16704 at 6/3/21, 4:43 PM: -- If the 'provided' scope is intentionally part of the test dependencies (and not just the 'test' scope), then does it make sense to remove the exclusion of 'provided' from [test jars resolution|https://github.com/apache/cassandra/blob/3282f5ecf187ecbb56b8d73ab9a9110c010898b0/.build/build-resolver.xml#L178]? Unless there's some other detail with the transitive dependencies, looks like this is what provided is for: "A dependency with this scope is added to the classpath used for compilation and test, but not the runtime classpath." (http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope). Then as a bonus, there's no need to duplicate dependencies across provided and test. For example: ./build.xml:733: ./build.xml:734: ./build.xml:735: ./build.xml:736: ./build.xml:830: ./build.xml:831: ./build.xml:832: ./build.xml:833: Though in terms of classpath, we're effectively back where we started since instead of joining the compile and provided scopes from build/lib/ with the test scope in build/test/lib/ we'd be joining the compile scope in lib/ with the test and provided scopes in build/test/lib/. So let me know if you me to remove the modification to build.xml from the patch. At a minimum, I think the two changes to src/ are required for runtime correctness. was (Author: polo-language): If the 'provided' scope is intentionally part of the test dependencies (and not just the 'test' scope), then does it make sense to remove the exclusion of 'provided' from [test jars resolution|https://github.com/apache/cassandra/blob/3282f5ecf187ecbb56b8d73ab9a9110c010898b0/.build/build-resolver.xml#L178]? Unless there's some other detail with the transitive dependencies, looks like this is what provided is for: "A dependency with this scope is added to the classpath used for compilation and test, but not the runtime classpath." ([http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope).] Then as a bonus, there's no need to duplicate dependencies across provided and test. For example: ./build.xml:733: ./build.xml:734: ./build.xml:735: ./build.xml:736: ./build.xml:830: ./build.xml:831: ./build.xml:832: ./build.xml:833: Though in terms of classpath, we're effectively back where we started since instead of joining the compile and provided scopes from build/lib/ with the test scope in build/test/lib/ we'd be joining the compile scope in lib/ with the test and provided scopes in build/test/lib/. So let me know if you me to remove the modification to build.xml from the patch. At a minimum, I think the two changes to src/ are required for runtime correctness. > Fix imports; run tests with packaged dependencies > - > > Key: CASSANDRA-16704 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16704 > Project: Cassandra > Issue Type: Bug > Components: Build, Test/burn, Test/unit >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Normal > Fix For: 4.0.x, 4.x > > Attachments: test-with-runtime-deps.patch > > > Tests are currently run with a classpath containing _all_ downloaded jars. > The tests would be more reflective of the behavior of a runtime environment > if the test classpath only contained jars that are bundled with the binary > release, together with explicit test dependencies. Ideally we'd use the > build/lib/ jars for the classpath since that's what gets packaged, but since > these aren't available at test compile time and should be identical to lib/ > anyway, I've used the later. > Doing so exposed a couple of references in src/java to > "org.apache.commons.lang", which is not available at runtime (should be > "org.apache.commons.lang*3*"). > Attached patch modifies the test classpath, fixes various imports in both > test/ and src/ classes, and makes some simple substitutions in the tests such > as using AbstractMap.SimpleEntry in place of > org.apache.commons.collections.keyvalue.AbstractMapEntry. -- 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-16704) Fix imports; run tests with packaged dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-16704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17356571#comment-17356571 ] Angelo Polo commented on CASSANDRA-16704: - If the 'provided' scope is intentionally part of the test dependencies (and not just the 'test' scope), then does it make sense to remove the exclusion of 'provided' from [test jars resolution|https://github.com/apache/cassandra/blob/3282f5ecf187ecbb56b8d73ab9a9110c010898b0/.build/build-resolver.xml#L178]? Unless there's some other detail with the transitive dependencies, looks like this is what provided is for: "A dependency with this scope is added to the classpath used for compilation and test, but not the runtime classpath." ([http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope).] Then as a bonus, there's no need to duplicate dependencies across provided and test. For example: ./build.xml:733: ./build.xml:734: ./build.xml:735: ./build.xml:736: ./build.xml:830: ./build.xml:831: ./build.xml:832: ./build.xml:833: Though in terms of classpath, we're effectively back where we started since instead of joining the compile and provided scopes from build/lib/ with the test scope in build/test/lib/ we'd be joining the compile scope in lib/ with the test and provided scopes in build/test/lib/. So let me know if you me to remove the modification to build.xml from the patch. At a minimum, I think the two changes to src/ are required for runtime correctness. > Fix imports; run tests with packaged dependencies > - > > Key: CASSANDRA-16704 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16704 > Project: Cassandra > Issue Type: Bug > Components: Build, Test/burn, Test/unit >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Normal > Fix For: 4.0.x, 4.x > > Attachments: test-with-runtime-deps.patch > > > Tests are currently run with a classpath containing _all_ downloaded jars. > The tests would be more reflective of the behavior of a runtime environment > if the test classpath only contained jars that are bundled with the binary > release, together with explicit test dependencies. Ideally we'd use the > build/lib/ jars for the classpath since that's what gets packaged, but since > these aren't available at test compile time and should be identical to lib/ > anyway, I've used the later. > Doing so exposed a couple of references in src/java to > "org.apache.commons.lang", which is not available at runtime (should be > "org.apache.commons.lang*3*"). > Attached patch modifies the test classpath, fixes various imports in both > test/ and src/ classes, and makes some simple substitutions in the tests such > as using AbstractMap.SimpleEntry in place of > org.apache.commons.collections.keyvalue.AbstractMapEntry. -- 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-16704) Fix imports; run tests with packaged dependencies
[
https://issues.apache.org/jira/browse/CASSANDRA-16704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17356350#comment-17356350
]
Angelo Polo commented on CASSANDRA-16704:
-
{quote}Tests can run against those optional dependencies that we don't bundle.
I don't think that is currently the case for any tests, but it can be.
{quote}
My thinking is that such dependencies should then become explicit test
dependencies, rather than allowing transitive dependencies (which may disappear
or change version when any other dependency is updated) to creep into the
tests. Though I don't know what 'provided' means here so hopefully I haven't
misunderstood something.
{quote}I'm not quite understanding this statement, if build/lib/jars/ doesn't
exist then neither does lib/.
{quote}
Oops, this was supposed to be build/dist/lib/.
My patch doesn't touch the IDE classpaths. Should just be a matter of removing
this
[fileset|https://github.com/apache/cassandra/blob/3282f5ecf187ecbb56b8d73ab9a9110c010898b0/build.xml#L2005].
> Fix imports; run tests with packaged dependencies
> -
>
> Key: CASSANDRA-16704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16704
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/burn, Test/unit
>Reporter: Angelo Polo
>Assignee: Angelo Polo
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: test-with-runtime-deps.patch
>
>
> Tests are currently run with a classpath containing _all_ downloaded jars.
> The tests would be more reflective of the behavior of a runtime environment
> if the test classpath only contained jars that are bundled with the binary
> release, together with explicit test dependencies. Ideally we'd use the
> build/lib/ jars for the classpath since that's what gets packaged, but since
> these aren't available at test compile time and should be identical to lib/
> anyway, I've used the later.
> Doing so exposed a couple of references in src/java to
> "org.apache.commons.lang", which is not available at runtime (should be
> "org.apache.commons.lang*3*").
> Attached patch modifies the test classpath, fixes various imports in both
> test/ and src/ classes, and makes some simple substitutions in the tests such
> as using AbstractMap.SimpleEntry in place of
> org.apache.commons.collections.keyvalue.AbstractMapEntry.
--
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-16704) Fix imports; run tests with packaged dependencies
Angelo Polo created CASSANDRA-16704: --- Summary: Fix imports; run tests with packaged dependencies Key: CASSANDRA-16704 URL: https://issues.apache.org/jira/browse/CASSANDRA-16704 Project: Cassandra Issue Type: Bug Components: Build, Test/burn, Test/unit Reporter: Angelo Polo Assignee: Angelo Polo Attachments: test-with-runtime-deps.patch Tests are currently run with a classpath containing _all_ downloaded jars. The tests would be more reflective of the behavior of a runtime environment if the test classpath only contained jars that are bundled with the binary release, together with explicit test dependencies. Ideally we'd use the build/lib/ jars for the classpath since that's what gets packaged, but since these aren't available at test compile time and should be identical to lib/ anyway, I've used the later. Doing so exposed a couple of references in src/java to "org.apache.commons.lang", which is not available at runtime (should be "org.apache.commons.lang*3*"). Attached patch modifies the test classpath, fixes various imports in both test/ and src/ classes, and makes some simple substitutions in the tests such as using AbstractMap.SimpleEntry in place of org.apache.commons.collections.keyvalue.AbstractMapEntry. -- 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-16700) Python driver dependency missing
Angelo Polo created CASSANDRA-16700:
---
Summary: Python driver dependency missing
Key: CASSANDRA-16700
URL: https://issues.apache.org/jira/browse/CASSANDRA-16700
Project: Cassandra
Issue Type: Bug
Components: Dependencies
Reporter: Angelo Polo
Cqlsh depends on the python driver, which is not included in the downloaded
dependencies.
{noformat}
$ bin/cqlsh
Python Cassandra driver not installed, or not on PYTHONPATH.
You might try "pip install cassandra-driver".
Python: /usr/local/bin/python3
Module load path:
['/usr/local/share/java/cassandra/bin/../lib/geomet-0.1.0.zip',
'/usr/local/share/java/cassandra/bin/../lib/six-1.12.0-py2.py3-none-any.zip',
'/usr/local/share/java/cassandra/bin/../lib/futures-2.1.6-py2.py3-none-any.zip',
'/usr/local/share/java/cassandra/bin', '/usr/local/lib/python37.zip',
'/usr/local/lib/python3.7', '/usr/local/lib/python3.7/lib-dynload',
'/usr/local/lib/python3.7/site-packages']
Error: No module named 'cassandra'
{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] [Assigned] (CASSANDRA-16403) Python 3 compatibility for Cassandra 3
[ https://issues.apache.org/jira/browse/CASSANDRA-16403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo Polo reassigned CASSANDRA-16403: --- Assignee: Angelo Polo > Python 3 compatibility for Cassandra 3 > -- > > Key: CASSANDRA-16403 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16403 > Project: Cassandra > Issue Type: Improvement >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Normal > Fix For: 3.11.x > > > Back-port python3 compatibility from 4.0 to 3.11. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15987) Failure in ViewTest#testNullInClusteringColumns on FreeBSD
[
https://issues.apache.org/jira/browse/CASSANDRA-15987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angelo Polo reassigned CASSANDRA-15987:
---
Assignee: Angelo Polo
> Failure in ViewTest#testNullInClusteringColumns on FreeBSD
> --
>
> Key: CASSANDRA-15987
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15987
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Angelo Polo
>Assignee: Angelo Polo
>Priority: Normal
>
>
> Failure occurs on FreeBSD 12.1-RELEASE-p5 amd64, OpenJDK 64-Bit Server VM
> (build 11.0.8+10-1, mixed mode), 4.0-beta1.
> {noformat}
> [junit-timeout] Testsuite: org.apache.cassandra.cql3.ViewTest Tests run: 41,
> Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 110.152 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testNullInClusteringColumns(org.apache.cassandra.cql3.ViewTest): FAILED
> [junit-timeout] Invalid value for row 0 column 2 (v1 of type varchar),
> expected (-1 bytes) but got <'foo'> (3 bytes) (using protocol version
> 4/v4)
> [junit-timeout] junit.framework.AssertionFailedError: Invalid value for row 0
> column 2 (v1 of type varchar), expected (-1 bytes) but got <'foo'> (3
> bytes) (using protocol version 4/v4)
> [junit-timeout] at
> org.apache.cassandra.cql3.CQLTester.assertRowsNet(CQLTester.java:1034)
> [junit-timeout] at
> org.apache.cassandra.cql3.ViewTest.testNullInClusteringColumns(ViewTest.java:1262)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.cql3.ViewTest FAILED{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] [Assigned] (CASSANDRA-15760) Javadoc fails on java 11: unexported package
[
https://issues.apache.org/jira/browse/CASSANDRA-15760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angelo Polo reassigned CASSANDRA-15760:
---
Assignee: Angelo Polo
> Javadoc fails on java 11: unexported package
>
>
> Key: CASSANDRA-15760
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15760
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Documentation/Javadoc
>Reporter: Angelo Polo
>Assignee: Angelo Polo
>Priority: Normal
> Labels: patch
> Attachments: 0001-Javadoc-requires-module-exports-too-on-java-11.patch
>
>
> Javadoc generation fails on java 11 due to an unexported package:
> {noformat}
> [javadoc] Constructing Javadoc information...
> [javadoc]
> /my/local/cassandra/src/java/org/apache/cassandra/utils/JMXServerUtils.java:311:
> error: package sun.rmi.registry is not visible
> [javadoc] private static class JmxRegistry extends
> sun.rmi.registry.RegistryImpl {
> [javadoc] ^
> [javadoc] (package sun.rmi.registry is declared in module java.rmi, which
> does not export it to the unnamed module)
> [javadoc] 1 error{noformat}
> The attached patch adds the existing "jdk11-javac-exports" property as an
> embedded argument to the called in the create-javadoc macro.
--
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-14306) Single config variable to specify logs path
[ https://issues.apache.org/jira/browse/CASSANDRA-14306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo Polo reassigned CASSANDRA-14306: --- Assignee: Angelo Polo > Single config variable to specify logs path > --- > > Key: CASSANDRA-14306 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14306 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Low > Fix For: 3.0.20, 3.11.6, 4.0, 4.0-alpha3 > > Attachments: unified_logs_dir.patch, unified_logs_dir_v2_3.11.patch, > unified_logs_dir_v2_trunk.patch > > > Motivation: All configuration should take place in bin/cassandra.in.sh (for > non-Windows) and the various conf/ files. In particular, bin/cassandra should > not need to be modified upon installation. In many installs, $CASSANDRA_HOME > is not a writable location, the yaml setting 'data_file_directories' is being > set to a non-default location, etc. It would be good to have a single > variable in an explicit conf file to specify where logs should be written. > For non-Windows installs, there are currently two places where the log > directory is set: in conf/cassandra-env.sh and in bin/cassandra. The defaults > for these are both $CASSANDRA_HOME/logs. These can be unified to a single > variable CASSANDRA_LOGS that is set in conf/cassandra-env.sh, with the > intention that it would be modified once there (if not set in the > environment) by a user running a custom installation. Then include a check in > bin/cassandra that CASSANDRA_LOGS is set in case conf/cassandra-env.sh > doesn't get sourced on startup, and provide a default value if not. For the > scenario that a user would prefer different paths for the logback logs and > the GC logs, they can still go into bin/cassandra to set the second path, > just as they would do currently. See "unified_logs_dir.patch" for a proposed > patch. > No change seems necessary for the Windows scripts. The two uses of > $CASSANDRA_HOME/logs are in the same script conf/cassandra-env.ps1 within > scrolling distance of each other (lines 278-301). They haven't been combined > I suppose because of the different path separators in the two usages. -- 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-16403) Python 3 compatibility for Cassandra 3
Angelo Polo created CASSANDRA-16403: --- Summary: Python 3 compatibility for Cassandra 3 Key: CASSANDRA-16403 URL: https://issues.apache.org/jira/browse/CASSANDRA-16403 Project: Cassandra Issue Type: Improvement Reporter: Angelo Polo Back-port python3 compatibility from 4.0 to 3.11. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16151) Package tools/bin scripts as executable
[
https://issues.apache.org/jira/browse/CASSANDRA-16151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218214#comment-17218214
]
Angelo Polo commented on CASSANDRA-16151:
-
Patches for 2.2 and 3.0 attached!
> Package tools/bin scripts as executable
> ---
>
> Key: CASSANDRA-16151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16151
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Angelo Polo
>Assignee: Angelo Polo
>Priority: Normal
> Labels: patch
> Fix For: 4.0-beta, 3.11.9
>
> Attachments: 2.2-Package-tools-bin-scripts-as-executable.patch,
> 3.0-Package-tools-bin-scripts-as-executable.patch,
> 3.11-Package-tools-bin-scripts-as-executable.patch,
> trunk-Package-tools-bin-scripts-as-executable.patch
>
>
> The tools/bin scripts aren't packaged as executable in the source
> distributions, though in the repository the scripts have the right bits.
> This causes, on 3.11.8 for example, the tests in
> org.apache.cassandra.cql3.EmptyValuesTest to fail:
> {{java.io.IOException: Cannot run program "tools/bin/sstabledump": error=13,
> Permission denied}}
> {{[junit-timeout] junit.framework.AssertionFailedError: java.io.IOException}}
> {{[junit-timeout] at
> org.apache.cassandra.cql3.EmptyValuesTest.verify(EmptyValuesTest.java:85)}}
> {{[junit-timeout] at
> org.apache.cassandra.cql3.EmptyValuesTest.verifyJsonInsert(EmptyValuesTest.java:112)}}
> See attached patch of build.xml for the trunk and cassandra-3.11 branches.
--
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-16151) Package tools/bin scripts as executable
[
https://issues.apache.org/jira/browse/CASSANDRA-16151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angelo Polo updated CASSANDRA-16151:
Attachment: 3.0-Package-tools-bin-scripts-as-executable.patch
2.2-Package-tools-bin-scripts-as-executable.patch
> Package tools/bin scripts as executable
> ---
>
> Key: CASSANDRA-16151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16151
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Angelo Polo
>Assignee: Angelo Polo
>Priority: Normal
> Labels: patch
> Fix For: 4.0-beta, 3.11.9
>
> Attachments: 2.2-Package-tools-bin-scripts-as-executable.patch,
> 3.0-Package-tools-bin-scripts-as-executable.patch,
> 3.11-Package-tools-bin-scripts-as-executable.patch,
> trunk-Package-tools-bin-scripts-as-executable.patch
>
>
> The tools/bin scripts aren't packaged as executable in the source
> distributions, though in the repository the scripts have the right bits.
> This causes, on 3.11.8 for example, the tests in
> org.apache.cassandra.cql3.EmptyValuesTest to fail:
> {{java.io.IOException: Cannot run program "tools/bin/sstabledump": error=13,
> Permission denied}}
> {{[junit-timeout] junit.framework.AssertionFailedError: java.io.IOException}}
> {{[junit-timeout] at
> org.apache.cassandra.cql3.EmptyValuesTest.verify(EmptyValuesTest.java:85)}}
> {{[junit-timeout] at
> org.apache.cassandra.cql3.EmptyValuesTest.verifyJsonInsert(EmptyValuesTest.java:112)}}
> See attached patch of build.xml for the trunk and cassandra-3.11 branches.
--
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-16206) Eliminate gen-doc template warning and unused (problematic) import
[
https://issues.apache.org/jira/browse/CASSANDRA-16206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angelo Polo reassigned CASSANDRA-16206:
---
Assignee: Angelo Polo
> Eliminate gen-doc template warning and unused (problematic) import
> --
>
> Key: CASSANDRA-16206
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16206
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Documentation/Website
>Reporter: Angelo Polo
>Assignee: Angelo Polo
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 1)
> When running 'sphinx-build -b html -d build/doctrees source build/html'
> on Linux we get the following warning:
> {noformat}
> [exec] generating indices... genindex
> [exec] WARNING: Now base template defindex.html is deprecated.
> [exec] writing additional pages... index search{noformat}
> On FreeBSD this causes gen-doc to fail:
> {noformat}
> [exec] writing additional pages... indexfailed
> [exec]
> [exec] Theme error:
> [exec] An error happened in rendering the page index.
> [exec] Reason: UndefinedError("'warn' is undefined")
> [exec] *** Error code 2{noformat}
> 2)
> The patch to doc/source/_util/cql.py removes the unused iteritems import,
> preventing errors on versions of pygments 2.6.0+:
> {noformat}
> [exec] Running Sphinx v3.2.1
> [exec]
> [exec] Exception occurred:
> [exec] File
> "/path/to/apache-cassandra-4.0-beta2-src/doc/source/_util/cql.py", line 29,
> in
> [exec] from pygments.util import iteritems
> [exec] ImportError: cannot import name 'iteritems' from 'pygments.util'
> (/usr/local/lib/python3.7/site-packages/pygments/util.py){noformat}
> The patch has been tested in the following environments:
> * FreeBSD 12.1-RELEASE-p7
> Python 3.7.9
> Sphinx 3.2.1
> pygments 2.7.1
> * Ubuntu 18.04.1
> Python 3.7.5
> Sphinx 1.6.7
> pygments 2.2.0
> * Ubuntu 18.04.1
> Python 2.7.17
> Sphinx 1.6.7
> pygments 2.5.2
--
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-16206) Eliminate gen-doc template warning and unused (problematic) import
Angelo Polo created CASSANDRA-16206:
---
Summary: Eliminate gen-doc template warning and unused
(problematic) import
Key: CASSANDRA-16206
URL: https://issues.apache.org/jira/browse/CASSANDRA-16206
Project: Cassandra
Issue Type: Bug
Components: Build, Documentation/Website
Reporter: Angelo Polo
1)
When running 'sphinx-build -b html -d build/doctrees source build/html'
on Linux we get the following warning:
{noformat}
[exec] generating indices... genindex
[exec] WARNING: Now base template defindex.html is deprecated.
[exec] writing additional pages... index search{noformat}
On FreeBSD this causes gen-doc to fail:
{noformat}
[exec] writing additional pages... indexfailed
[exec]
[exec] Theme error:
[exec] An error happened in rendering the page index.
[exec] Reason: UndefinedError("'warn' is undefined")
[exec] *** Error code 2{noformat}
2)
The patch to doc/source/_util/cql.py removes the unused iteritems import,
preventing errors on versions of pygments 2.6.0+:
{noformat}
[exec] Running Sphinx v3.2.1
[exec]
[exec] Exception occurred:
[exec] File
"/path/to/apache-cassandra-4.0-beta2-src/doc/source/_util/cql.py", line 29, in
[exec] from pygments.util import iteritems
[exec] ImportError: cannot import name 'iteritems' from 'pygments.util'
(/usr/local/lib/python3.7/site-packages/pygments/util.py){noformat}
The patch has been tested in the following environments:
* FreeBSD 12.1-RELEASE-p7
Python 3.7.9
Sphinx 3.2.1
pygments 2.7.1
* Ubuntu 18.04.1
Python 3.7.5
Sphinx 1.6.7
pygments 2.2.0
* Ubuntu 18.04.1
Python 2.7.17
Sphinx 1.6.7
pygments 2.5.2
--
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-16179) gen-doc depends on jar
[
https://issues.apache.org/jira/browse/CASSANDRA-16179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angelo Polo updated CASSANDRA-16179:
Labels: pat (was: )
> gen-doc depends on jar
> --
>
> Key: CASSANDRA-16179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16179
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Documentation/Website
>Reporter: Angelo Polo
>Assignee: Angelo Polo
>Priority: Normal
> Labels: pat
> Attachments: 3.11-gen-doc-depends-on-jar.patch,
> trunk-gen-doc-depends-on-jar.patch
>
>
> The target 'gen-doc' depends on 'jar' so let's add it the depends attribute.
> Patches for trunk and 3.11 are attached.
> {noformat}
> # ant gen-doc
> gen-doc:
> [exec] python convert_yaml_to_rst.py ../conf/cassandra.yaml
> source/configuration/cassandra_config_file.rst
> [exec] python gen-nodetool-docs.py
> [exec] ls: cannot access '../bin/../build/apache-cassandra*.jar': No
> such file or directory
> [exec] ERROR: Nodetool failed to run, you likely need to build cassandra
> using ant jar from the top level directory
> [exec] Error: Could not find or load main class
> org.apache.cassandra.tools.NodeTool
> [exec] Makefile:64: recipe for target 'html' failed
> [exec] Traceback (most recent call last):
> [exec] File "gen-nodetool-docs.py", line 68, in
> [exec] create_help_file()
> [exec] File "gen-nodetool-docs.py", line 52, in create_help_file
> [exec] raise cpe
> [exec] File "gen-nodetool-docs.py", line 46, in create_help_file
> [exec] subprocess.check_call([nodetool, "help"], stdout=output_file)
> [exec] File "/usr/lib/python3.6/subprocess.py", line 311, in check_call
> [exec] raise CalledProcessError(retcode, cmd)
> [exec] subprocess.CalledProcessError: Command '['../bin/nodetool',
> 'help']' returned non-zero exit status 1.
> [exec] make: *** [html] Error 1
> [exec] Result: 2{noformat}
> {{The then redundant 'jar' dependency on the 'artifacts' target could be
> removed too, though the attached patches don't include this modification.}}
--
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-16179) gen-doc depends on jar
[
https://issues.apache.org/jira/browse/CASSANDRA-16179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angelo Polo updated CASSANDRA-16179:
Labels: patch (was: pat)
> gen-doc depends on jar
> --
>
> Key: CASSANDRA-16179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16179
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Documentation/Website
>Reporter: Angelo Polo
>Assignee: Angelo Polo
>Priority: Normal
> Labels: patch
> Attachments: 3.11-gen-doc-depends-on-jar.patch,
> trunk-gen-doc-depends-on-jar.patch
>
>
> The target 'gen-doc' depends on 'jar' so let's add it the depends attribute.
> Patches for trunk and 3.11 are attached.
> {noformat}
> # ant gen-doc
> gen-doc:
> [exec] python convert_yaml_to_rst.py ../conf/cassandra.yaml
> source/configuration/cassandra_config_file.rst
> [exec] python gen-nodetool-docs.py
> [exec] ls: cannot access '../bin/../build/apache-cassandra*.jar': No
> such file or directory
> [exec] ERROR: Nodetool failed to run, you likely need to build cassandra
> using ant jar from the top level directory
> [exec] Error: Could not find or load main class
> org.apache.cassandra.tools.NodeTool
> [exec] Makefile:64: recipe for target 'html' failed
> [exec] Traceback (most recent call last):
> [exec] File "gen-nodetool-docs.py", line 68, in
> [exec] create_help_file()
> [exec] File "gen-nodetool-docs.py", line 52, in create_help_file
> [exec] raise cpe
> [exec] File "gen-nodetool-docs.py", line 46, in create_help_file
> [exec] subprocess.check_call([nodetool, "help"], stdout=output_file)
> [exec] File "/usr/lib/python3.6/subprocess.py", line 311, in check_call
> [exec] raise CalledProcessError(retcode, cmd)
> [exec] subprocess.CalledProcessError: Command '['../bin/nodetool',
> 'help']' returned non-zero exit status 1.
> [exec] make: *** [html] Error 1
> [exec] Result: 2{noformat}
> {{The then redundant 'jar' dependency on the 'artifacts' target could be
> removed too, though the attached patches don't include this modification.}}
--
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-16179) gen-doc depends on jar
Angelo Polo created CASSANDRA-16179:
---
Summary: gen-doc depends on jar
Key: CASSANDRA-16179
URL: https://issues.apache.org/jira/browse/CASSANDRA-16179
Project: Cassandra
Issue Type: Bug
Components: Build, Documentation/Website
Reporter: Angelo Polo
Assignee: Angelo Polo
Attachments: 3.11-gen-doc-depends-on-jar.patch,
trunk-gen-doc-depends-on-jar.patch
The target 'gen-doc' depends on 'jar' so let's add it the depends attribute.
Patches for trunk and 3.11 are attached.
{noformat}
# ant gen-doc
gen-doc:
[exec] python convert_yaml_to_rst.py ../conf/cassandra.yaml
source/configuration/cassandra_config_file.rst
[exec] python gen-nodetool-docs.py
[exec] ls: cannot access '../bin/../build/apache-cassandra*.jar': No such
file or directory
[exec] ERROR: Nodetool failed to run, you likely need to build cassandra
using ant jar from the top level directory
[exec] Error: Could not find or load main class
org.apache.cassandra.tools.NodeTool
[exec] Makefile:64: recipe for target 'html' failed
[exec] Traceback (most recent call last):
[exec] File "gen-nodetool-docs.py", line 68, in
[exec] create_help_file()
[exec] File "gen-nodetool-docs.py", line 52, in create_help_file
[exec] raise cpe
[exec] File "gen-nodetool-docs.py", line 46, in create_help_file
[exec] subprocess.check_call([nodetool, "help"], stdout=output_file)
[exec] File "/usr/lib/python3.6/subprocess.py", line 311, in check_call
[exec] raise CalledProcessError(retcode, cmd)
[exec] subprocess.CalledProcessError: Command '['../bin/nodetool',
'help']' returned non-zero exit status 1.
[exec] make: *** [html] Error 1
[exec] Result: 2{noformat}
{{The then redundant 'jar' dependency on the 'artifacts' target could be
removed too, though the attached patches don't include this modification.}}
--
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-16151) Package tools/bin scripts as executable
[
https://issues.apache.org/jira/browse/CASSANDRA-16151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angelo Polo updated CASSANDRA-16151:
Labels: patch (was: )
> Package tools/bin scripts as executable
> ---
>
> Key: CASSANDRA-16151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16151
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Angelo Polo
>Priority: Normal
> Labels: patch
> Attachments: 3.11-Package-tools-bin-scripts-as-executable.patch,
> trunk-Package-tools-bin-scripts-as-executable.patch
>
>
> The tools/bin scripts aren't packaged as executable in the source
> distributions, though in the repository the scripts have the right bits.
> This causes, on 3.11.8 for example, the tests in
> org.apache.cassandra.cql3.EmptyValuesTest to fail:
> {{java.io.IOException: Cannot run program "tools/bin/sstabledump": error=13,
> Permission denied}}
> {{[junit-timeout] junit.framework.AssertionFailedError: java.io.IOException}}
> {{[junit-timeout] at
> org.apache.cassandra.cql3.EmptyValuesTest.verify(EmptyValuesTest.java:85)}}
> {{[junit-timeout] at
> org.apache.cassandra.cql3.EmptyValuesTest.verifyJsonInsert(EmptyValuesTest.java:112)}}
> See attached patch of build.xml for the trunk and cassandra-3.11 branches.
--
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-16151) Package tools/bin scripts as executable
Angelo Polo created CASSANDRA-16151:
---
Summary: Package tools/bin scripts as executable
Key: CASSANDRA-16151
URL: https://issues.apache.org/jira/browse/CASSANDRA-16151
Project: Cassandra
Issue Type: Bug
Components: Packaging
Reporter: Angelo Polo
Attachments: 3.11-Package-tools-bin-scripts-as-executable.patch,
trunk-Package-tools-bin-scripts-as-executable.patch
The tools/bin scripts aren't packaged as executable in the source
distributions, though in the repository the scripts have the right bits.
This causes, on 3.11.8 for example, the tests in
org.apache.cassandra.cql3.EmptyValuesTest to fail:
{{java.io.IOException: Cannot run program "tools/bin/sstabledump": error=13,
Permission denied}}
{{[junit-timeout] junit.framework.AssertionFailedError: java.io.IOException}}
{{[junit-timeout] at
org.apache.cassandra.cql3.EmptyValuesTest.verify(EmptyValuesTest.java:85)}}
{{[junit-timeout] at
org.apache.cassandra.cql3.EmptyValuesTest.verifyJsonInsert(EmptyValuesTest.java:112)}}
See attached patch of build.xml for the trunk and cassandra-3.11 branches.
--
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-15987) Failure in ViewTest#testNullInClusteringColumns on FreeBSD
Angelo Polo created CASSANDRA-15987:
---
Summary: Failure in ViewTest#testNullInClusteringColumns on FreeBSD
Key: CASSANDRA-15987
URL: https://issues.apache.org/jira/browse/CASSANDRA-15987
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Angelo Polo
Failure occurs on FreeBSD 12.1-RELEASE-p5 amd64, OpenJDK 64-Bit Server VM
(build 11.0.8+10-1, mixed mode), 4.0-beta1.
{noformat}
[junit-timeout] Testsuite: org.apache.cassandra.cql3.ViewTest Tests run: 41,
Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 110.152 sec
[junit-timeout]
[junit-timeout] Testcase:
testNullInClusteringColumns(org.apache.cassandra.cql3.ViewTest): FAILED
[junit-timeout] Invalid value for row 0 column 2 (v1 of type varchar), expected
(-1 bytes) but got <'foo'> (3 bytes) (using protocol version 4/v4)
[junit-timeout] junit.framework.AssertionFailedError: Invalid value for row 0
column 2 (v1 of type varchar), expected (-1 bytes) but got <'foo'> (3
bytes) (using protocol version 4/v4)
[junit-timeout] at
org.apache.cassandra.cql3.CQLTester.assertRowsNet(CQLTester.java:1034)
[junit-timeout] at
org.apache.cassandra.cql3.ViewTest.testNullInClusteringColumns(ViewTest.java:1262)
[junit-timeout] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit-timeout] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit-timeout] at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit-timeout]
[junit-timeout]
[junit-timeout] Test org.apache.cassandra.cql3.ViewTest FAILED{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-15693) Generating nodetool docs fails with python 3
[
https://issues.apache.org/jira/browse/CASSANDRA-15693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158500#comment-17158500
]
Angelo Polo commented on CASSANDRA-15693:
-
I've already submitted a patch. What else can I do for this one?
> Generating nodetool docs fails with python 3
>
>
> Key: CASSANDRA-15693
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15693
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Angelo Polo
>Assignee: Angelo Polo
>Priority: Normal
> Labels: patch
> Attachments: 0001-Fix-file-open-modes-for-python-3.patch
>
>
> Building nodetool docs with the ant target 'gen-doc' fails for python 3.
> Python 3 doesn't allow the file open mode "rw+".
> {noformat}
> gen-doc:
> [exec] python convert_yaml_to_rst.py ../conf/cassandra.yaml
> source/configuration/cassandra_config_file.rst
> [exec] python gen-nodetool-docs.py
> [exec] Makefile:64: recipe for target 'html' failed
> [exec] Traceback (most recent call last):
> [exec] File "gen-nodetool-docs.py", line 75, in
> [exec] with open(helpfilename, "rw+") as helpfile:
> [exec] ValueError: must have exactly one of create/read/write/append mode
> [exec] make: *** [html] Error 1
> [exec] Result: 2
> {noformat}
> Fails on and patch [^0001-Fix-file-open-modes-for-python-3.patch] tested on
> the following platforms: Ubuntu 18.04.4 LTS with Python 3.6.9 and FreeBSD
> 12.1-RELEASE-p1 with Python 3.7.7.
--
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-13859) SASIIndexTest.testTableRebuild crashing on Ubuntu16.04 with OpenJDK 'zero' variant
[ https://issues.apache.org/jira/browse/CASSANDRA-13859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107979#comment-17107979 ] Angelo Polo commented on CASSANDRA-13859: - Encountering exactly the same failure on FreeBSD 12.1-RELEASE-p1 amd64 with OpenJDK 64 1.8.0_242-b07. See attached fatal error log[^hs_err_pid7828.log] > SASIIndexTest.testTableRebuild crashing on Ubuntu16.04 with OpenJDK 'zero' > variant > -- > > Key: CASSANDRA-13859 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13859 > Project: Cassandra > Issue Type: Bug > Components: Feature/SASI > Environment: Architecture: x86_64 > OS: Ubuntu 16.04 > JAVA: openjdk version "1.8.0_131" > OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2ubuntu1.16.04.3-b11) > OpenJDK 64-Bit Zero VM (build 25.131-b11, interpreted mode) > Cpu cores: 2 > RAM: 8GB >Reporter: Faiz Akhtar >Priority: Normal > Attachments: cassandra_SASIIndextestlog_x86_64_ubuntu16.04, > hs_err_pid7828.log > > > The following command causes a jvm crash with OpenJDK 8 zero vm > ant testsome -Dtest.name=org.apache.cassandra.index.sasi.SASIIndexTest > -Dtest.methods=testTableRebuild > The test passes with OpenJDK 8 server vm > Attached the error log. -- 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-13859) SASIIndexTest.testTableRebuild crashing on Ubuntu16.04 with OpenJDK 'zero' variant
[ https://issues.apache.org/jira/browse/CASSANDRA-13859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo Polo updated CASSANDRA-13859: Attachment: hs_err_pid7828.log > SASIIndexTest.testTableRebuild crashing on Ubuntu16.04 with OpenJDK 'zero' > variant > -- > > Key: CASSANDRA-13859 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13859 > Project: Cassandra > Issue Type: Bug > Components: Feature/SASI > Environment: Architecture: x86_64 > OS: Ubuntu 16.04 > JAVA: openjdk version "1.8.0_131" > OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2ubuntu1.16.04.3-b11) > OpenJDK 64-Bit Zero VM (build 25.131-b11, interpreted mode) > Cpu cores: 2 > RAM: 8GB >Reporter: Faiz Akhtar >Priority: Normal > Attachments: cassandra_SASIIndextestlog_x86_64_ubuntu16.04, > hs_err_pid7828.log > > > The following command causes a jvm crash with OpenJDK 8 zero vm > ant testsome -Dtest.name=org.apache.cassandra.index.sasi.SASIIndexTest > -Dtest.methods=testTableRebuild > The test passes with OpenJDK 8 server vm > Attached the error log. -- 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-15323) MessagingServiceTest failed with method listenRequiredSecureConnectionWithBroadcastAddr ON MAC OS
[ https://issues.apache.org/jira/browse/CASSANDRA-15323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17104208#comment-17104208 ] Angelo Polo commented on CASSANDRA-15323: - Adding here for reference: the problem and fix provided in the description apply to FreeBSD as well. > MessagingServiceTest failed with method > listenRequiredSecureConnectionWithBroadcastAddrON MAC OS > -- > > Key: CASSANDRA-15323 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15323 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Fix For: 4.0 > > Attachments: exception.png > > > when I do unit test on mac os for cassandra4.0 tag version , I found that the > unit test failed when doing MessagingServiceTest on method > listenRequiredSecureConnectionWithBroadcastAddr. > I found out that it is because that the mac os can not get connect to ip > address 127.0.0.2 on default. > so when you doing : ant test -Dtest.name=MessagingServiceTest > -Dtest.methods=listenRequiredSecureConnectionWithBroadcastAddr > you can get a bind exception : can not assign request address. > !exception.png! > what to do with it ,you can just set the 127.0.0.2 by : > sudo ifconfig lo0 alias 127.0.0.2 netmask 0x > then the unit can run successfully . -- 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-15693) Generating nodetool docs fails with python 3
[
https://issues.apache.org/jira/browse/CASSANDRA-15693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angelo Polo updated CASSANDRA-15693:
Platform: All (was: Java11)
> Generating nodetool docs fails with python 3
>
>
> Key: CASSANDRA-15693
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15693
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Angelo Polo
>Priority: Normal
> Labels: patch
> Attachments: 0001-Fix-file-open-modes-for-python-3.patch
>
>
> Building nodetool docs with the ant target 'gen-doc' fails for python 3.
> Python 3 doesn't allow the file open mode "rw+".
> {noformat}
> gen-doc:
> [exec] python convert_yaml_to_rst.py ../conf/cassandra.yaml
> source/configuration/cassandra_config_file.rst
> [exec] python gen-nodetool-docs.py
> [exec] Makefile:64: recipe for target 'html' failed
> [exec] Traceback (most recent call last):
> [exec] File "gen-nodetool-docs.py", line 75, in
> [exec] with open(helpfilename, "rw+") as helpfile:
> [exec] ValueError: must have exactly one of create/read/write/append mode
> [exec] make: *** [html] Error 1
> [exec] Result: 2
> {noformat}
> Fails on and patch [^0001-Fix-file-open-modes-for-python-3.patch] tested on
> the following platforms: Ubuntu 18.04.4 LTS with Python 3.6.9 and FreeBSD
> 12.1-RELEASE-p1 with Python 3.7.7.
--
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-15760) Javadoc fails on java 11: unexported package
[
https://issues.apache.org/jira/browse/CASSANDRA-15760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angelo Polo updated CASSANDRA-15760:
Platform: Java11 (was: All)
> Javadoc fails on java 11: unexported package
>
>
> Key: CASSANDRA-15760
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15760
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Documentation/Javadoc
>Reporter: Angelo Polo
>Priority: Normal
> Labels: patch
> Attachments: 0001-Javadoc-requires-module-exports-too-on-java-11.patch
>
>
> Javadoc generation fails on java 11 due to an unexported package:
> {noformat}
> [javadoc] Constructing Javadoc information...
> [javadoc]
> /my/local/cassandra/src/java/org/apache/cassandra/utils/JMXServerUtils.java:311:
> error: package sun.rmi.registry is not visible
> [javadoc] private static class JmxRegistry extends
> sun.rmi.registry.RegistryImpl {
> [javadoc] ^
> [javadoc] (package sun.rmi.registry is declared in module java.rmi, which
> does not export it to the unnamed module)
> [javadoc] 1 error{noformat}
> The attached patch adds the existing "jdk11-javac-exports" property as an
> embedded argument to the called in the create-javadoc macro.
--
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-15693) Generating nodetool docs fails with python 3
[
https://issues.apache.org/jira/browse/CASSANDRA-15693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angelo Polo updated CASSANDRA-15693:
Labels: patch (was: )
> Generating nodetool docs fails with python 3
>
>
> Key: CASSANDRA-15693
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15693
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Angelo Polo
>Priority: Normal
> Labels: patch
> Attachments: 0001-Fix-file-open-modes-for-python-3.patch
>
>
> Building nodetool docs with the ant target 'gen-doc' fails for python 3.
> Python 3 doesn't allow the file open mode "rw+".
> {noformat}
> gen-doc:
> [exec] python convert_yaml_to_rst.py ../conf/cassandra.yaml
> source/configuration/cassandra_config_file.rst
> [exec] python gen-nodetool-docs.py
> [exec] Makefile:64: recipe for target 'html' failed
> [exec] Traceback (most recent call last):
> [exec] File "gen-nodetool-docs.py", line 75, in
> [exec] with open(helpfilename, "rw+") as helpfile:
> [exec] ValueError: must have exactly one of create/read/write/append mode
> [exec] make: *** [html] Error 1
> [exec] Result: 2
> {noformat}
> Fails on and patch [^0001-Fix-file-open-modes-for-python-3.patch] tested on
> the following platforms: Ubuntu 18.04.4 LTS with Python 3.6.9 and FreeBSD
> 12.1-RELEASE-p1 with Python 3.7.7.
--
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-15693) Generating nodetool docs fails with python 3
[
https://issues.apache.org/jira/browse/CASSANDRA-15693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angelo Polo updated CASSANDRA-15693:
Platform: Java11 (was: All)
> Generating nodetool docs fails with python 3
>
>
> Key: CASSANDRA-15693
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15693
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Angelo Polo
>Priority: Normal
> Attachments: 0001-Fix-file-open-modes-for-python-3.patch
>
>
> Building nodetool docs with the ant target 'gen-doc' fails for python 3.
> Python 3 doesn't allow the file open mode "rw+".
> {noformat}
> gen-doc:
> [exec] python convert_yaml_to_rst.py ../conf/cassandra.yaml
> source/configuration/cassandra_config_file.rst
> [exec] python gen-nodetool-docs.py
> [exec] Makefile:64: recipe for target 'html' failed
> [exec] Traceback (most recent call last):
> [exec] File "gen-nodetool-docs.py", line 75, in
> [exec] with open(helpfilename, "rw+") as helpfile:
> [exec] ValueError: must have exactly one of create/read/write/append mode
> [exec] make: *** [html] Error 1
> [exec] Result: 2
> {noformat}
> Fails on and patch [^0001-Fix-file-open-modes-for-python-3.patch] tested on
> the following platforms: Ubuntu 18.04.4 LTS with Python 3.6.9 and FreeBSD
> 12.1-RELEASE-p1 with Python 3.7.7.
--
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-15760) Javadoc fails on java 11: unexported package
[
https://issues.apache.org/jira/browse/CASSANDRA-15760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angelo Polo updated CASSANDRA-15760:
Labels: patch (was: )
> Javadoc fails on java 11: unexported package
>
>
> Key: CASSANDRA-15760
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15760
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Documentation/Javadoc
>Reporter: Angelo Polo
>Priority: Normal
> Labels: patch
> Attachments: 0001-Javadoc-requires-module-exports-too-on-java-11.patch
>
>
> Javadoc generation fails on java 11 due to an unexported package:
> {noformat}
> [javadoc] Constructing Javadoc information...
> [javadoc]
> /my/local/cassandra/src/java/org/apache/cassandra/utils/JMXServerUtils.java:311:
> error: package sun.rmi.registry is not visible
> [javadoc] private static class JmxRegistry extends
> sun.rmi.registry.RegistryImpl {
> [javadoc] ^
> [javadoc] (package sun.rmi.registry is declared in module java.rmi, which
> does not export it to the unnamed module)
> [javadoc] 1 error{noformat}
> The attached patch adds the existing "jdk11-javac-exports" property as an
> embedded argument to the called in the create-javadoc macro.
--
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-15760) Javadoc fails on java 11: unexported package
Angelo Polo created CASSANDRA-15760:
---
Summary: Javadoc fails on java 11: unexported package
Key: CASSANDRA-15760
URL: https://issues.apache.org/jira/browse/CASSANDRA-15760
Project: Cassandra
Issue Type: Bug
Components: Build, Documentation/Javadoc
Reporter: Angelo Polo
Attachments: 0001-Javadoc-requires-module-exports-too-on-java-11.patch
Javadoc generation fails on java 11 due to an unexported package:
{noformat}
[javadoc] Constructing Javadoc information...
[javadoc]
/my/local/cassandra/src/java/org/apache/cassandra/utils/JMXServerUtils.java:311:
error: package sun.rmi.registry is not visible
[javadoc] private static class JmxRegistry extends
sun.rmi.registry.RegistryImpl {
[javadoc] ^
[javadoc] (package sun.rmi.registry is declared in module java.rmi, which
does not export it to the unnamed module)
[javadoc] 1 error{noformat}
The attached patch adds the existing "jdk11-javac-exports" property as an
embedded argument to the called in the create-javadoc macro.
--
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-15586) 4.0 quality testing: Cluster Setup and Maintenance
[ https://issues.apache.org/jira/browse/CASSANDRA-15586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076210#comment-17076210 ] Angelo Polo commented on CASSANDRA-15586: - Glad to see FreeBSD is back on the map for the broader Cassandra community :). [~e.dimitrova] I will let you know as I investigate bugs or need any insight. Some things can get patched in the FreeBSD build and don't need immediate (i.e. prior to 4.0 release) support from a core project commiter, such as CASSANDRA-15693, which I opened recently, and can be upstreamed sometime later. > 4.0 quality testing: Cluster Setup and Maintenance > -- > > Key: CASSANDRA-15586 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15586 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Josh McKenzie >Assignee: Ekaterina Dimitrova >Priority: Normal > Labels: 4.0-QA > Fix For: 4.0-rc > > > We want 4.0 to be easy for users to setup out of the box and just work. This > means having low friction when users download the Cassandra package and start > running it. For example, users should be able to easily configure and start > new 4.0 clusters and have tokens distributed evenly. Another example is > packaging, it should be easy to install Cassandra on all supported platforms > (e.g. packaging) and have Cassandra use standard platform integrations. -- 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-15693) Generating nodetool docs fails with python 3
[
https://issues.apache.org/jira/browse/CASSANDRA-15693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angelo Polo updated CASSANDRA-15693:
Description:
Building nodetool docs with the ant target 'gen-doc' fails for python 3. Python
3 doesn't allow the file open mode "rw+".
{noformat}
gen-doc:
[exec] python convert_yaml_to_rst.py ../conf/cassandra.yaml
source/configuration/cassandra_config_file.rst
[exec] python gen-nodetool-docs.py
[exec] Makefile:64: recipe for target 'html' failed
[exec] Traceback (most recent call last):
[exec] File "gen-nodetool-docs.py", line 75, in
[exec] with open(helpfilename, "rw+") as helpfile:
[exec] ValueError: must have exactly one of create/read/write/append mode
[exec] make: *** [html] Error 1
[exec] Result: 2
{noformat}
Fails on and patch [^0001-Fix-file-open-modes-for-python-3.patch] tested on the
following platforms: Ubuntu 18.04.4 LTS with Python 3.6.9 and FreeBSD
12.1-RELEASE-p1 with Python 3.7.7.
was:
Building nodetool docs with the ant target 'gen-docs' fails for python 3.
Python 3 doesn't allow the file open mode "rw+".
{noformat}
gen-doc:
[exec] python convert_yaml_to_rst.py ../conf/cassandra.yaml
source/configuration/cassandra_config_file.rst
[exec] python gen-nodetool-docs.py
[exec] Makefile:64: recipe for target 'html' failed
[exec] Traceback (most recent call last):
[exec] File "gen-nodetool-docs.py", line 75, in
[exec] with open(helpfilename, "rw+") as helpfile:
[exec] ValueError: must have exactly one of create/read/write/append mode
[exec] make: *** [html] Error 1
[exec] Result: 2
{noformat}
Fails on and patch [^0001-Fix-file-open-modes-for-python-3.patch] tested on the
following platforms: Ubuntu 18.04.4 LTS with Python 3.6.9 and FreeBSD
12.1-RELEASE-p1 with Python 3.7.7.
> Generating nodetool docs fails with python 3
>
>
> Key: CASSANDRA-15693
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15693
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Angelo Polo
>Priority: Normal
> Attachments: 0001-Fix-file-open-modes-for-python-3.patch
>
>
> Building nodetool docs with the ant target 'gen-doc' fails for python 3.
> Python 3 doesn't allow the file open mode "rw+".
> {noformat}
> gen-doc:
> [exec] python convert_yaml_to_rst.py ../conf/cassandra.yaml
> source/configuration/cassandra_config_file.rst
> [exec] python gen-nodetool-docs.py
> [exec] Makefile:64: recipe for target 'html' failed
> [exec] Traceback (most recent call last):
> [exec] File "gen-nodetool-docs.py", line 75, in
> [exec] with open(helpfilename, "rw+") as helpfile:
> [exec] ValueError: must have exactly one of create/read/write/append mode
> [exec] make: *** [html] Error 1
> [exec] Result: 2
> {noformat}
> Fails on and patch [^0001-Fix-file-open-modes-for-python-3.patch] tested on
> the following platforms: Ubuntu 18.04.4 LTS with Python 3.6.9 and FreeBSD
> 12.1-RELEASE-p1 with Python 3.7.7.
--
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-15693) Generating nodetool docs fails with python 3
[
https://issues.apache.org/jira/browse/CASSANDRA-15693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angelo Polo updated CASSANDRA-15693:
Description:
Building nodetool docs with the ant target 'gen-docs' fails for python 3.
Python 3 doesn't allow the file open mode "rw+".
{noformat}
gen-doc:
[exec] python convert_yaml_to_rst.py ../conf/cassandra.yaml
source/configuration/cassandra_config_file.rst
[exec] python gen-nodetool-docs.py
[exec] Makefile:64: recipe for target 'html' failed
[exec] Traceback (most recent call last):
[exec] File "gen-nodetool-docs.py", line 75, in
[exec] with open(helpfilename, "rw+") as helpfile:
[exec] ValueError: must have exactly one of create/read/write/append mode
[exec] make: *** [html] Error 1
[exec] Result: 2
{noformat}
Fails on and patch [^0001-Fix-file-open-modes-for-python-3.patch] tested on the
following platforms: Ubuntu 18.04.4 LTS with Python 3.6.9 and FreeBSD
12.1-RELEASE-p1 with Python 3.7.7.
was:
Building nodetool docs with the ant target 'gen-docs' fails for python 3.
Python 3 doesn't allow the file open mode "rw+".
Fails on and patch [^0001-Fix-file-open-modes-for-python-3.patch] tested on the
following platforms: Ubuntu 18.04.4 LTS with Python 3.6.9 and FreeBSD
12.1-RELEASE-p1 with Python 3.7.7.
> Generating nodetool docs fails with python 3
>
>
> Key: CASSANDRA-15693
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15693
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Angelo Polo
>Priority: Normal
> Attachments: 0001-Fix-file-open-modes-for-python-3.patch
>
>
> Building nodetool docs with the ant target 'gen-docs' fails for python 3.
> Python 3 doesn't allow the file open mode "rw+".
> {noformat}
> gen-doc:
> [exec] python convert_yaml_to_rst.py ../conf/cassandra.yaml
> source/configuration/cassandra_config_file.rst
> [exec] python gen-nodetool-docs.py
> [exec] Makefile:64: recipe for target 'html' failed
> [exec] Traceback (most recent call last):
> [exec] File "gen-nodetool-docs.py", line 75, in
> [exec] with open(helpfilename, "rw+") as helpfile:
> [exec] ValueError: must have exactly one of create/read/write/append mode
> [exec] make: *** [html] Error 1
> [exec] Result: 2
> {noformat}
> Fails on and patch [^0001-Fix-file-open-modes-for-python-3.patch] tested on
> the following platforms: Ubuntu 18.04.4 LTS with Python 3.6.9 and FreeBSD
> 12.1-RELEASE-p1 with Python 3.7.7.
--
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-15693) Generating nodetool docs fails with python 3
Angelo Polo created CASSANDRA-15693: --- Summary: Generating nodetool docs fails with python 3 Key: CASSANDRA-15693 URL: https://issues.apache.org/jira/browse/CASSANDRA-15693 Project: Cassandra Issue Type: Bug Components: Build Reporter: Angelo Polo Attachments: 0001-Fix-file-open-modes-for-python-3.patch Building nodetool docs with the ant target 'gen-docs' fails for python 3. Python 3 doesn't allow the file open mode "rw+". Fails on and patch [^0001-Fix-file-open-modes-for-python-3.patch] tested on the following platforms: Ubuntu 18.04.4 LTS with Python 3.6.9 and FreeBSD 12.1-RELEASE-p1 with Python 3.7.7. -- 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-14306) Single config variable to specify logs path
[ https://issues.apache.org/jira/browse/CASSANDRA-14306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004830#comment-17004830 ] Angelo Polo commented on CASSANDRA-14306: - This issue predates 15090, so it was just a different choice of name for the same concept. I've attached two updated patches (of conf/cassandra-env.sh only) for the GC logs. These use the now-committed variable name CASSANDRA_LOG_DIR. * [^unified_logs_dir_v2_trunk.patch] * [^unified_logs_dir_v2_3.11.patch] > Single config variable to specify logs path > --- > > Key: CASSANDRA-14306 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14306 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Angelo Polo >Priority: Low > Attachments: unified_logs_dir.patch, unified_logs_dir_v2_3.11.patch, > unified_logs_dir_v2_trunk.patch > > > Motivation: All configuration should take place in bin/cassandra.in.sh (for > non-Windows) and the various conf/ files. In particular, bin/cassandra should > not need to be modified upon installation. In many installs, $CASSANDRA_HOME > is not a writable location, the yaml setting 'data_file_directories' is being > set to a non-default location, etc. It would be good to have a single > variable in an explicit conf file to specify where logs should be written. > For non-Windows installs, there are currently two places where the log > directory is set: in conf/cassandra-env.sh and in bin/cassandra. The defaults > for these are both $CASSANDRA_HOME/logs. These can be unified to a single > variable CASSANDRA_LOGS that is set in conf/cassandra-env.sh, with the > intention that it would be modified once there (if not set in the > environment) by a user running a custom installation. Then include a check in > bin/cassandra that CASSANDRA_LOGS is set in case conf/cassandra-env.sh > doesn't get sourced on startup, and provide a default value if not. For the > scenario that a user would prefer different paths for the logback logs and > the GC logs, they can still go into bin/cassandra to set the second path, > just as they would do currently. See "unified_logs_dir.patch" for a proposed > patch. > No change seems necessary for the Windows scripts. The two uses of > $CASSANDRA_HOME/logs are in the same script conf/cassandra-env.ps1 within > scrolling distance of each other (lines 278-301). They haven't been combined > I suppose because of the different path separators in the two usages. -- 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-14306) Single config variable to specify logs path
[ https://issues.apache.org/jira/browse/CASSANDRA-14306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo Polo updated CASSANDRA-14306: Attachment: unified_logs_dir_v2_trunk.patch unified_logs_dir_v2_3.11.patch > Single config variable to specify logs path > --- > > Key: CASSANDRA-14306 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14306 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Angelo Polo >Priority: Low > Attachments: unified_logs_dir.patch, unified_logs_dir_v2_3.11.patch, > unified_logs_dir_v2_trunk.patch > > > Motivation: All configuration should take place in bin/cassandra.in.sh (for > non-Windows) and the various conf/ files. In particular, bin/cassandra should > not need to be modified upon installation. In many installs, $CASSANDRA_HOME > is not a writable location, the yaml setting 'data_file_directories' is being > set to a non-default location, etc. It would be good to have a single > variable in an explicit conf file to specify where logs should be written. > For non-Windows installs, there are currently two places where the log > directory is set: in conf/cassandra-env.sh and in bin/cassandra. The defaults > for these are both $CASSANDRA_HOME/logs. These can be unified to a single > variable CASSANDRA_LOGS that is set in conf/cassandra-env.sh, with the > intention that it would be modified once there (if not set in the > environment) by a user running a custom installation. Then include a check in > bin/cassandra that CASSANDRA_LOGS is set in case conf/cassandra-env.sh > doesn't get sourced on startup, and provide a default value if not. For the > scenario that a user would prefer different paths for the logback logs and > the GC logs, they can still go into bin/cassandra to set the second path, > just as they would do currently. See "unified_logs_dir.patch" for a proposed > patch. > No change seems necessary for the Windows scripts. The two uses of > $CASSANDRA_HOME/logs are in the same script conf/cassandra-env.ps1 within > scrolling distance of each other (lines 278-301). They haven't been combined > I suppose because of the different path separators in the two usages. -- 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-15090) Customize cassandra log directory
[ https://issues.apache.org/jira/browse/CASSANDRA-15090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16995572#comment-16995572 ] Angelo Polo commented on CASSANDRA-15090: - The JVM GC log path is still configured separately in conf/cassandra-env.sh. It would be great to see these unified. See the description and patch I wrote for CASSANDRA-14306. > Customize cassandra log directory > - > > Key: CASSANDRA-15090 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15090 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Zephyr Guo >Assignee: Zephyr Guo >Priority: Normal > Fix For: 3.0.19, 3.11.5, 4.0 > > Attachments: CASSANDRA-15090-v1.patch > > > Add a new variable CASSANDRA_LOG_DIR (default: $CASSANDRA_HOME/logs) so that > we could customize log directory such as ‘/var/log/cassandra’ . > > -- 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-14325) Java executable check succeeds despite no java on PATH
Angelo Polo created CASSANDRA-14325: --- Summary: Java executable check succeeds despite no java on PATH Key: CASSANDRA-14325 URL: https://issues.apache.org/jira/browse/CASSANDRA-14325 Project: Cassandra Issue Type: Bug Components: Lifecycle Reporter: Angelo Polo Attachments: bin_cassandra.patch The check -z $JAVA on line 102 of bin/cassandra currently always succeeds if JAVA_HOME is not set since in this case JAVA gets set directly to 'java'. The error message "_Unable to find java executable. Check JAVA_HOME and PATH environment variables._" will never be echoed on a PATH misconfiguration. If java isn't on the PATH the failure will instead occur on line 95 of cassandra-env.sh at the java version check. It would be better to check consistently for the java executable in one place in bin/cassandra. Also we don't want users to mistakenly think they have a java version problem when they in fact have a PATH problem. See proposed patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14306) Single config variable to specify logs path
Angelo Polo created CASSANDRA-14306: --- Summary: Single config variable to specify logs path Key: CASSANDRA-14306 URL: https://issues.apache.org/jira/browse/CASSANDRA-14306 Project: Cassandra Issue Type: Improvement Components: Configuration Reporter: Angelo Polo Attachments: unified_logs_dir.patch Motivation: All configuration should take place in bin/cassandra.in.sh (for non-Windows) and the various conf/ files. In particular, bin/cassandra should not need to be modified upon installation. In many installs, $CASSANDRA_HOME is not a writable location, the yaml setting 'data_file_directories' is being set to a non-default location, etc. It would be good to have a single variable in an explicit conf file to specify where logs should be written. For non-Windows installs, there are currently two places where the log directory is set: in conf/cassandra-env.sh and in bin/cassandra. The defaults for these are both $CASSANDRA_HOME/logs. These can be unified to a single variable CASSANDRA_LOGS that is set in conf/cassandra-env.sh, with the intention that it would be modified once there (if not set in the environment) by a user running a custom installation. Then include a check in bin/cassandra that CASSANDRA_LOGS is set in case conf/cassandra-env.sh doesn't get sourced on startup, and provide a default value if not. For the scenario that a user would prefer different paths for the logback logs and the GC logs, they can still go into bin/cassandra to set the second path, just as they would do currently. See "unified_logs_dir.patch" for a proposed patch. No change seems necessary for the Windows scripts. The two uses of $CASSANDRA_HOME/logs are in the same script conf/cassandra-env.ps1 within scrolling distance of each other (lines 278-301). They haven't been combined I suppose because of the different path separators in the two usages. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14305) Use $CASSANDRA_CONF not $CASSANDRA_HOME/conf in cassandra-env.sh
Angelo Polo created CASSANDRA-14305: --- Summary: Use $CASSANDRA_CONF not $CASSANDRA_HOME/conf in cassandra-env.sh Key: CASSANDRA-14305 URL: https://issues.apache.org/jira/browse/CASSANDRA-14305 Project: Cassandra Issue Type: Improvement Components: Configuration Reporter: Angelo Polo Attachments: conf_cassandra-env.sh.patch CASSANDRA_CONF should be used uniformly in conf/cassandra-env.sh to reference the configuration path. Currently, jaas users will have to modify the default path provided for cassandra-jaas.config if their $CASSANDRA_CONF differs from $CASSANDRA_HOME/conf. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
