[jira] [Commented] (CASSANDRA-15494) Support additional Jar url scheme
[
https://issues.apache.org/jira/browse/CASSANDRA-15494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17035637#comment-17035637
]
Gus Heck commented on CASSANDRA-15494:
--
Pull request created.
> Support additional Jar url scheme
> -
>
> Key: CASSANDRA-15494
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15494
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Normal
> Labels: pull-request-available
> Attachments: CASSANDRA-15494.patch, CASSANDRA-15494.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This code in ThreadAwareSecurityManager causes issues for embedded cassandra
> launched from a one-jar or uno-jar.
> {code:java}
> switch (codesource.getLocation().getProtocol())
> {
> case "file":
> // All JARs and class files reside on the file system
> - we can safely
> // assume that these classes are "good".
> return true;
> }
> {code}
> Attaching patch to support protocol of 'jar' as well. AFAICT this won't
> introduce any added risk for UDF's discussed in CASSANDRA-9402 since a jar
> (or one/uno jar) must also be on the filesystem.
> New code would be (in 2 places):
> {code:java}
> switch (codesource.getLocation().getProtocol())
> {
> case "jar":
> case "file":
> // All JARs and class files reside on the file system
> - we can safely
> // assume that these classes are "good".
> return true;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-12995) update hppc dependency to 0.7
[
https://issues.apache.org/jira/browse/CASSANDRA-12995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17034090#comment-17034090
]
Gus Heck edited comment on CASSANDRA-12995 at 2/11/20 2:29 AM:
---
Yeah saw this comment earlier today. Looked at your test and it looks like
failures are a function of the
{code:java}
new LongHashSet() {{ add() }} {code}
syntax, which is cute for readability, but the creation of a subclass there is
entirely unnecessary. Since it's not a bug and no change is needed I expect
this was vetted for solr when the library was upgraded there (by Dawid in
SOLR-7790 )
was (Author: gus_heck):
Yeah saw this comment earlier today. Looked at your test and it looks like
failures of a function of the
{code:java}
new LongHashSet() {{ add() }} {code}
syntax, which is cute for readability, but the creation of a subclass there is
entirely unnecessary. Since it's not a bug and no change is needed I expect
this was vetted for solr when the library was upgraded there (by Dawid in
SOLR-7790 )
> update hppc dependency to 0.7
> -
>
> Key: CASSANDRA-12995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12995
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies, Packaging
>Reporter: Tomas Repik
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: easyfix
> Fix For: 4.0
>
> Attachments: Screen Shot 2020-01-29 at 11.14.30 AM.png, Screen Shot
> 2020-01-29 at 11.20.39 AM.png, Screen Shot 2020-01-29 at 11.20.47 AM.png,
> cassandra-3.11.0-hppc.patch
>
>
> Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to
> the sources we need to do in order to successfully build it. Cassandra
> depends on hppc 0.5.4, but In Fedora we have the newer version 0.7.1 Upstream
> released even newer version 0.7.2. I attached a patch updating cassandra
> sources to depend on the 0.7.1 hppc sources. It should be also compatible
> with the newest upstream version. The only actual changes are the removal of
> Open infix in class names. The issue was discussed in here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1340876 Please consider updating.
--
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-12995) update hppc dependency to 0.7
[
https://issues.apache.org/jira/browse/CASSANDRA-12995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17034090#comment-17034090
]
Gus Heck commented on CASSANDRA-12995:
--
Yeah saw this comment earlier today. Looked at your test and it looks like
failures of a function of the
{code:java}
new LongHashSet() {{ add() }} {code}
syntax, which is cute for readability, but the creation of a subclass there is
entirely unnecessary. Since it's not a bug and no change is needed I expect
this was vetted for solr when the library was upgraded there (by Dawid in
SOLR-7790 )
> update hppc dependency to 0.7
> -
>
> Key: CASSANDRA-12995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12995
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies, Packaging
>Reporter: Tomas Repik
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: easyfix
> Fix For: 4.0
>
> Attachments: Screen Shot 2020-01-29 at 11.14.30 AM.png, Screen Shot
> 2020-01-29 at 11.20.39 AM.png, Screen Shot 2020-01-29 at 11.20.47 AM.png,
> cassandra-3.11.0-hppc.patch
>
>
> Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to
> the sources we need to do in order to successfully build it. Cassandra
> depends on hppc 0.5.4, but In Fedora we have the newer version 0.7.1 Upstream
> released even newer version 0.7.2. I attached a patch updating cassandra
> sources to depend on the 0.7.1 hppc sources. It should be also compatible
> with the newest upstream version. The only actual changes are the removal of
> Open infix in class names. The issue was discussed in here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1340876 Please consider updating.
--
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-15494) Support additional Jar url scheme
[
https://issues.apache.org/jira/browse/CASSANDRA-15494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17031742#comment-17031742
]
Gus Heck commented on CASSANDRA-15494:
--
Sorry just noticed I uploaded the wrong patch last time, now switched it out.
> Support additional Jar url scheme
> -
>
> Key: CASSANDRA-15494
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15494
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Normal
> Attachments: CASSANDRA-15494.patch, CASSANDRA-15494.patch
>
>
> This code in ThreadAwareSecurityManager causes issues for embedded cassandra
> launched from a one-jar or uno-jar.
> {code:java}
> switch (codesource.getLocation().getProtocol())
> {
> case "file":
> // All JARs and class files reside on the file system
> - we can safely
> // assume that these classes are "good".
> return true;
> }
> {code}
> Attaching patch to support protocol of 'jar' as well. AFAICT this won't
> introduce any added risk for UDF's discussed in CASSANDRA-9402 since a jar
> (or one/uno jar) must also be on the filesystem.
> New code would be (in 2 places):
> {code:java}
> switch (codesource.getLocation().getProtocol())
> {
> case "jar":
> case "file":
> // All JARs and class files reside on the file system
> - we can safely
> // assume that these classes are "good".
> return true;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15494) Support additional Jar url scheme
[
https://issues.apache.org/jira/browse/CASSANDRA-15494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gus Heck updated CASSANDRA-15494:
-
Attachment: CASSANDRA-15494.patch
> Support additional Jar url scheme
> -
>
> Key: CASSANDRA-15494
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15494
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Normal
> Attachments: CASSANDRA-15494.patch, CASSANDRA-15494.patch
>
>
> This code in ThreadAwareSecurityManager causes issues for embedded cassandra
> launched from a one-jar or uno-jar.
> {code:java}
> switch (codesource.getLocation().getProtocol())
> {
> case "file":
> // All JARs and class files reside on the file system
> - we can safely
> // assume that these classes are "good".
> return true;
> }
> {code}
> Attaching patch to support protocol of 'jar' as well. AFAICT this won't
> introduce any added risk for UDF's discussed in CASSANDRA-9402 since a jar
> (or one/uno jar) must also be on the filesystem.
> New code would be (in 2 places):
> {code:java}
> switch (codesource.getLocation().getProtocol())
> {
> case "jar":
> case "file":
> // All JARs and class files reside on the file system
> - we can safely
> // assume that these classes are "good".
> return true;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15494) Support additional Jar url scheme
[
https://issues.apache.org/jira/browse/CASSANDRA-15494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gus Heck updated CASSANDRA-15494:
-
Attachment: (was: CASSANDRA-15494.patch)
> Support additional Jar url scheme
> -
>
> Key: CASSANDRA-15494
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15494
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Normal
> Attachments: CASSANDRA-15494.patch
>
>
> This code in ThreadAwareSecurityManager causes issues for embedded cassandra
> launched from a one-jar or uno-jar.
> {code:java}
> switch (codesource.getLocation().getProtocol())
> {
> case "file":
> // All JARs and class files reside on the file system
> - we can safely
> // assume that these classes are "good".
> return true;
> }
> {code}
> Attaching patch to support protocol of 'jar' as well. AFAICT this won't
> introduce any added risk for UDF's discussed in CASSANDRA-9402 since a jar
> (or one/uno jar) must also be on the filesystem.
> New code would be (in 2 places):
> {code:java}
> switch (codesource.getLocation().getProtocol())
> {
> case "jar":
> case "file":
> // All JARs and class files reside on the file system
> - we can safely
> // assume that these classes are "good".
> return true;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15494) Support additional Jar url scheme
[
https://issues.apache.org/jira/browse/CASSANDRA-15494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17031741#comment-17031741
]
Gus Heck commented on CASSANDRA-15494:
--
[~brandon.williams] ok will open PR shortly, which version is preferable?
> Support additional Jar url scheme
> -
>
> Key: CASSANDRA-15494
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15494
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Normal
> Attachments: CASSANDRA-15494.patch, CASSANDRA-15494.patch
>
>
> This code in ThreadAwareSecurityManager causes issues for embedded cassandra
> launched from a one-jar or uno-jar.
> {code:java}
> switch (codesource.getLocation().getProtocol())
> {
> case "file":
> // All JARs and class files reside on the file system
> - we can safely
> // assume that these classes are "good".
> return true;
> }
> {code}
> Attaching patch to support protocol of 'jar' as well. AFAICT this won't
> introduce any added risk for UDF's discussed in CASSANDRA-9402 since a jar
> (or one/uno jar) must also be on the filesystem.
> New code would be (in 2 places):
> {code:java}
> switch (codesource.getLocation().getProtocol())
> {
> case "jar":
> case "file":
> // All JARs and class files reside on the file system
> - we can safely
> // assume that these classes are "good".
> return true;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15494) Support additional Jar url scheme
[
https://issues.apache.org/jira/browse/CASSANDRA-15494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17031738#comment-17031738
]
Gus Heck commented on CASSANDRA-15494:
--
Added a slightly more conservative patch in case that helps. Either one works.
> Support additional Jar url scheme
> -
>
> Key: CASSANDRA-15494
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15494
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Normal
> Attachments: CASSANDRA-15494.patch, CASSANDRA-15494.patch
>
>
> This code in ThreadAwareSecurityManager causes issues for embedded cassandra
> launched from a one-jar or uno-jar.
> {code:java}
> switch (codesource.getLocation().getProtocol())
> {
> case "file":
> // All JARs and class files reside on the file system
> - we can safely
> // assume that these classes are "good".
> return true;
> }
> {code}
> Attaching patch to support protocol of 'jar' as well. AFAICT this won't
> introduce any added risk for UDF's discussed in CASSANDRA-9402 since a jar
> (or one/uno jar) must also be on the filesystem.
> New code would be (in 2 places):
> {code:java}
> switch (codesource.getLocation().getProtocol())
> {
> case "jar":
> case "file":
> // All JARs and class files reside on the file system
> - we can safely
> // assume that these classes are "good".
> return true;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15494) Support additional Jar url scheme
[
https://issues.apache.org/jira/browse/CASSANDRA-15494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gus Heck updated CASSANDRA-15494:
-
Attachment: CASSANDRA-15494.patch
> Support additional Jar url scheme
> -
>
> Key: CASSANDRA-15494
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15494
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Normal
> Attachments: CASSANDRA-15494.patch, CASSANDRA-15494.patch
>
>
> This code in ThreadAwareSecurityManager causes issues for embedded cassandra
> launched from a one-jar or uno-jar.
> {code:java}
> switch (codesource.getLocation().getProtocol())
> {
> case "file":
> // All JARs and class files reside on the file system
> - we can safely
> // assume that these classes are "good".
> return true;
> }
> {code}
> Attaching patch to support protocol of 'jar' as well. AFAICT this won't
> introduce any added risk for UDF's discussed in CASSANDRA-9402 since a jar
> (or one/uno jar) must also be on the filesystem.
> New code would be (in 2 places):
> {code:java}
> switch (codesource.getLocation().getProtocol())
> {
> case "jar":
> case "file":
> // All JARs and class files reside on the file system
> - we can safely
> // assume that these classes are "good".
> return true;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15494) Support additional Jar url scheme
[
https://issues.apache.org/jira/browse/CASSANDRA-15494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17031635#comment-17031635
]
Gus Heck commented on CASSANDRA-15494:
--
This is a really simple change. Would be nice if this could get into 4.0 do
you want a github PR instead?
> Support additional Jar url scheme
> -
>
> Key: CASSANDRA-15494
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15494
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Gus Heck
>Priority: Normal
> Attachments: CASSANDRA-15494.patch
>
>
> This code in ThreadAwareSecurityManager causes issues for embedded cassandra
> launched from a one-jar or uno-jar.
> {code:java}
> switch (codesource.getLocation().getProtocol())
> {
> case "file":
> // All JARs and class files reside on the file system
> - we can safely
> // assume that these classes are "good".
> return true;
> }
> {code}
> Attaching patch to support protocol of 'jar' as well. AFAICT this won't
> introduce any added risk for UDF's discussed in CASSANDRA-9402 since a jar
> (or one/uno jar) must also be on the filesystem.
> New code would be (in 2 places):
> {code:java}
> switch (codesource.getLocation().getProtocol())
> {
> case "jar":
> case "file":
> // All JARs and class files reside on the file system
> - we can safely
> // assume that these classes are "good".
> return true;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12995) update hppc dependency to 0.7
[ https://issues.apache.org/jira/browse/CASSANDRA-12995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028470#comment-17028470 ] Gus Heck commented on CASSANDRA-12995: -- [https://issues.carrot2.org/projects/HPPC/issues/HPPC-173?filter=allopenissues] seems to be the place to file bugs. If there is a flaw in LongHashSet, this is potentially important to the Lucene/Solr project too since we definitely use that class in both the Lucene and Solr layers (though I haven't investigated if there's a case where we rely on .equals yet). > update hppc dependency to 0.7 > - > > Key: CASSANDRA-12995 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12995 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Packaging >Reporter: Tomas Repik >Assignee: Ekaterina Dimitrova >Priority: Normal > Labels: easyfix > Fix For: 4.0 > > Attachments: Screen Shot 2020-01-29 at 11.14.30 AM.png, Screen Shot > 2020-01-29 at 11.20.39 AM.png, Screen Shot 2020-01-29 at 11.20.47 AM.png, > cassandra-3.11.0-hppc.patch > > > Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to > the sources we need to do in order to successfully build it. Cassandra > depends on hppc 0.5.4, but In Fedora we have the newer version 0.7.1 Upstream > released even newer version 0.7.2. I attached a patch updating cassandra > sources to depend on the 0.7.1 hppc sources. It should be also compatible > with the newest upstream version. The only actual changes are the removal of > Open infix in class names. The issue was discussed in here: > https://bugzilla.redhat.com/show_bug.cgi?id=1340876 Please consider updating. -- 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-12995) update hppc dependency to 0.7
[ https://issues.apache.org/jira/browse/CASSANDRA-12995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024390#comment-17024390 ] Gus Heck commented on CASSANDRA-12995: -- If this makes it into 4 that would be great. This ticket requests 0.7.2, but I encourage you to bring the version of hppc as far forward as makes sense since 0.7.2 is already a point release behind. > update hppc dependency to 0.7 > - > > Key: CASSANDRA-12995 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12995 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Packaging >Reporter: Tomas Repik >Assignee: Ekaterina Dimitrova >Priority: Normal > Labels: easyfix > Fix For: 4.0 > > Attachments: cassandra-3.11.0-hppc.patch > > > Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to > the sources we need to do in order to successfully build it. Cassandra > depends on hppc 0.5.4, but In Fedora we have the newer version 0.7.1 Upstream > released even newer version 0.7.2. I attached a patch updating cassandra > sources to depend on the 0.7.1 hppc sources. It should be also compatible > with the newest upstream version. The only actual changes are the removal of > Open infix in class names. The issue was discussed in here: > https://bugzilla.redhat.com/show_bug.cgi?id=1340876 Please consider updating. -- 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-12995) update hppc dependency to 0.7
[ https://issues.apache.org/jira/browse/CASSANDRA-12995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17012269#comment-17012269 ] Gus Heck commented on CASSANDRA-12995: -- CASSANDRA-15455 notes that Beam has issues with this, and I'm also having difficulty in JesterJ due to Solr libraries on the path requiring hppc 0.8.1 > update hppc dependency to 0.7 > - > > Key: CASSANDRA-12995 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12995 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Packaging >Reporter: Tomas Repik >Priority: Normal > Labels: easyfix > Fix For: 4.0 > > Attachments: cassandra-3.11.0-hppc.patch > > > Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to > the sources we need to do in order to successfully build it. Cassandra > depends on hppc 0.5.4, but In Fedora we have the newer version 0.7.1 Upstream > released even newer version 0.7.2. I attached a patch updating cassandra > sources to depend on the 0.7.1 hppc sources. It should be also compatible > with the newest upstream version. The only actual changes are the removal of > Open infix in class names. The issue was discussed in here: > https://bugzilla.redhat.com/show_bug.cgi?id=1340876 Please consider updating. -- 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-15455) Upgrade com.carrotsearch:hppc dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-15455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17012267#comment-17012267 ] Gus Heck commented on CASSANDRA-15455: -- Possible duplicate of CASSANDRA-12995 > Upgrade com.carrotsearch:hppc dependency > > > Key: CASSANDRA-15455 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15455 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tomo Suzuki >Priority: Normal > > Upgrade com.carrotsearch:hppc dependency. > Current version 0.5 causes diamond dependency conflict with other dependency > (via Elasticsearch) in Apache Beam. > https://gist.github.com/suztomo/6fe16f6bda526aab97e879feac70309d -- 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-15468) Unable to start embedded cassandra on JDK 11
[
https://issues.apache.org/jira/browse/CASSANDRA-15468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17011085#comment-17011085
]
Gus Heck commented on CASSANDRA-15468:
--
Worth noting that I've realized that "Add-Opens" does not exist in the world of
jar Manifests AFAICT... I assumed it would if "Add-Export" did, but it didn't
work and I find no references to it on the web. It might be possible for me to
use that info in Uno-Jar anyway since I hope to add support for module layers
such that dependencies on different versions can co-exist, and java.lang.Module
has an addOpens() method, so while I'm there playing with modules anyway... :).
> Unable to start embedded cassandra on JDK 11
>
>
> Key: CASSANDRA-15468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15468
> Project: Cassandra
> Issue Type: Bug
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Normal
> Attachments: CASSANDRA-15468.patch
>
>
> Cassandra fails to start without the following jvm options from
> jvm-11-server.options:
> {code:java}
> -Djdk.attach.allowAttachSelf=true
> --add-exports java.base/jdk.internal.misc=ALL-UNNAMED
> --add-exports java.base/jdk.internal.ref=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports java.management.rmi/com.sun.jmx.remote.internal.rmi=ALL-UNNAMED
> --add-exports java.rmi/sun.rmi.registry=ALL-UNNAMED
> --add-exports java.rmi/sun.rmi.server=ALL-UNNAMED
> --add-exports java.sql/java.sql=ALL-UNNAMED
> --add-opens java.base/java.lang.module=ALL-UNNAMED
> --add-opens java.base/jdk.internal.loader=ALL-UNNAMED
> --add-opens java.base/jdk.internal.ref=ALL-UNNAMED
> --add-opens java.base/jdk.internal.reflect=ALL-UNNAMED
> --add-opens java.base/jdk.internal.math=ALL-UNNAMED
> --add-opens java.base/jdk.internal.module=ALL-UNNAMED
> --add-opens java.base/jdk.internal.util.jar=ALL-UNNAMED
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
> {code}
> Without these options the following stack trace appears and prevents startup
> {code:java}
> 2020-01-05T17:42:15,009 ERROR main
> org.apache.cassandra.service.CassandraDaemon Exception encountered during
> startup java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.config.DatabaseDescriptor.guessFileStore(DatabaseDescriptor.java:1127)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:541)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:340)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:168)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:152)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:665)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:609)
> at org.jesterj.ingest.persistence.Cassandra.start(Cassandra.java:135)
> at
> org.jesterj.ingest.scanners.SimpleFileScannerImplFTITest.testScanWithMemory(SimpleFileScannerImplFTITest.java:63)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
[jira] [Updated] (CASSANDRA-15494) Support additional Jar url scheme
[
https://issues.apache.org/jira/browse/CASSANDRA-15494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gus Heck updated CASSANDRA-15494:
-
Attachment: CASSANDRA-15494.patch
> Support additional Jar url scheme
> -
>
> Key: CASSANDRA-15494
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15494
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Gus Heck
>Priority: Normal
> Attachments: CASSANDRA-15494.patch
>
>
> This code in ThreadAwareSecurityManager causes issues for embedded cassandra
> launched from a one-jar or uno-jar.
> {code:java}
> switch (codesource.getLocation().getProtocol())
> {
> case "file":
> // All JARs and class files reside on the file system
> - we can safely
> // assume that these classes are "good".
> return true;
> }
> {code}
> Attaching patch to support protocol of 'jar' as well. AFAICT this won't
> introduce any added risk for UDF's discussed in CASSANDRA-9402 since a jar
> (or one/uno jar) must also be on the filesystem.
> New code would be (in 2 places):
> {code:java}
> switch (codesource.getLocation().getProtocol())
> {
> case "jar":
> case "file":
> // All JARs and class files reside on the file system
> - we can safely
> // assume that these classes are "good".
> return true;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15494) Support additional Jar url scheme
Gus Heck created CASSANDRA-15494:
Summary: Support additional Jar url scheme
Key: CASSANDRA-15494
URL: https://issues.apache.org/jira/browse/CASSANDRA-15494
Project: Cassandra
Issue Type: Improvement
Reporter: Gus Heck
This code in ThreadAwareSecurityManager causes issues for embedded cassandra
launched from a one-jar or uno-jar.
{code:java}
switch (codesource.getLocation().getProtocol())
{
case "file":
// All JARs and class files reside on the file system -
we can safely
// assume that these classes are "good".
return true;
}
{code}
Attaching patch to support protocol of 'jar' as well. AFAICT this won't
introduce any added risk for UDF's discussed in CASSANDRA-9402 since a jar (or
one/uno jar) must also be on the filesystem.
New code would be (in 2 places):
{code:java}
switch (codesource.getLocation().getProtocol())
{
case "jar":
case "file":
// All JARs and class files reside on the file system -
we can safely
// assume that these classes are "good".
return true;
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15468) Unable to start embedded cassandra on JDK 11
[
https://issues.apache.org/jira/browse/CASSANDRA-15468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010070#comment-17010070
]
Gus Heck edited comment on CASSANDRA-15468 at 1/7/20 8:35 PM:
--
I'd like to respectfully ask that this not be resolved yet. I don't agree that
there are no problems here. What is the point of the latter half of the
message?
{quote}Some data, both in-memory and on-disk, may live longer due to garbage
collection.{quote}
I would say that's quite incorrect since Cassandra won't even be starting up,
and even if it did attempts to use FileUtils.clean() are going to throw NPE's
which will probably do a bit worse than cause data to live longer.
Additionally the message give here is cryptic and leaves the user unable to
discern (without searching through your jira, and taking the time to fully
debug cassandra's code, and read your startups scripts as I did) what the
problem is or how to correct it. So before we close this I'd like to suggest
one thing that I hope is non-controversial, and another that might require some
consideration:
1. Revise the error message here for the case of an IllegalAccessException to
advise the user how to move forward. Particularly tell them that they should
either use the standard cassandra start up scripts, or (expert) supply the
following --add-export and --add-open jvm args
2. Perhaps document the exports and opens requirements in a machine readable
way by adding Add-Exports: and Add-Opens: attributes to the manifest for the
jar file.
Suggestion #2 will not change the need for the .options files unless a bigger
change to invoke via java -jar happens (which I'm not suggesting here, but it
could eliminate that portion of the options file)
At some point I'll likely add support to Uno-Jar to dig through manifests of
dependency jars looking for any jars with exports to collect them for the uber
jar... obviously that can only be a best effort thing, since no spec requires
such attributes but certainly it makes sense for jars to politely declare what
exports they require. (except of course proprietary stuff that might seek to
obfuscate and inhibit any usage not licensed...)
was (Author: gus_heck):
I'd like to respectfully ask that this not be resolved yet. I don't agree that
there are no problems here. What is the point of the latter half of the
message?
{quote}Some data, both in-memory and on-disk, may live longer due to garbage
collection.{quote}
I would say that's quite incorrect since Cassandra won't even be starting up,
and even if it did attempts to use FileUtils.clean() are going to throw NPE's
which will probably do a bit worse than cause data to live longer.
Additionally the message give here is cryptic and leaves the user unable to
discern (without searching through your jira, and taking the time to fully
debug cassandra's code, and read your startups scripts as I did) what the
problem is or how to correct it. So before we close this I'd like to suggest
one thing that I hope is non-controversial, and another that might require some
consideration:
1. Revise the error message here for the case of an IllegalAccessException to
advise the user how to move forward. Particularly tell them that they should
either use the standard cassandra start up scripts, or (expert) supply the
following --add-export and --add-open jvm args
2. Perhaps document the exports and opens requirements in a machine readable
way by adding Add-Exports: and Add-Opens: attributes to the manifest for the
jar file.
Suggestion #2 will not change the need for the .options files unless a bigger
change to invoke via java -jar happens (which I'm not suggesting here, but it
could eliminate that portion of the options file)
At some point I'll likely add support to Uno-Jar I'll to dig through manifests
of dependency jars looking for any jars with exports to collect them for the
uber jar... obviously that can only be a best effort thing, since no spec
requires such attributes but certainly it makes sense for jars to politely
declare what exports they require. (except of course proprietary stuff that
might seek to obfuscate and inhibit any usage not licensed...)
> Unable to start embedded cassandra on JDK 11
>
>
> Key: CASSANDRA-15468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15468
> Project: Cassandra
> Issue Type: Bug
>Reporter: Gus Heck
>Priority: Normal
> Attachments: CASSANDRA-15468.patch
>
>
> Cassandra fails to start without the following jvm options from
> jvm-11-server.options:
> {code:java}
> -Djdk.attach.allowAttachSelf=true
> --add-exports java.base/jdk.internal.misc=ALL-UNNAMED
> --add-exports java.base/jdk.internal.ref=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED
>
[jira] [Commented] (CASSANDRA-15468) Unable to start embedded cassandra on JDK 11
[
https://issues.apache.org/jira/browse/CASSANDRA-15468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010072#comment-17010072
]
Gus Heck commented on CASSANDRA-15468:
--
Patch suggesting a possible improved error message (item 1) attached.
> Unable to start embedded cassandra on JDK 11
>
>
> Key: CASSANDRA-15468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15468
> Project: Cassandra
> Issue Type: Bug
>Reporter: Gus Heck
>Priority: Normal
> Attachments: CASSANDRA-15468.patch
>
>
> Cassandra fails to start without the following jvm options from
> jvm-11-server.options:
> {code:java}
> -Djdk.attach.allowAttachSelf=true
> --add-exports java.base/jdk.internal.misc=ALL-UNNAMED
> --add-exports java.base/jdk.internal.ref=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports java.management.rmi/com.sun.jmx.remote.internal.rmi=ALL-UNNAMED
> --add-exports java.rmi/sun.rmi.registry=ALL-UNNAMED
> --add-exports java.rmi/sun.rmi.server=ALL-UNNAMED
> --add-exports java.sql/java.sql=ALL-UNNAMED
> --add-opens java.base/java.lang.module=ALL-UNNAMED
> --add-opens java.base/jdk.internal.loader=ALL-UNNAMED
> --add-opens java.base/jdk.internal.ref=ALL-UNNAMED
> --add-opens java.base/jdk.internal.reflect=ALL-UNNAMED
> --add-opens java.base/jdk.internal.math=ALL-UNNAMED
> --add-opens java.base/jdk.internal.module=ALL-UNNAMED
> --add-opens java.base/jdk.internal.util.jar=ALL-UNNAMED
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
> {code}
> Without these options the following stack trace appears and prevents startup
> {code:java}
> 2020-01-05T17:42:15,009 ERROR main
> org.apache.cassandra.service.CassandraDaemon Exception encountered during
> startup java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.config.DatabaseDescriptor.guessFileStore(DatabaseDescriptor.java:1127)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:541)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:340)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:168)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:152)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:665)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:609)
> at org.jesterj.ingest.persistence.Cassandra.start(Cassandra.java:135)
> at
> org.jesterj.ingest.scanners.SimpleFileScannerImplFTITest.testScanWithMemory(SimpleFileScannerImplFTITest.java:63)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
>
[jira] [Commented] (CASSANDRA-15468) Unable to start embedded cassandra on JDK 11
[
https://issues.apache.org/jira/browse/CASSANDRA-15468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010070#comment-17010070
]
Gus Heck commented on CASSANDRA-15468:
--
I'd like to respectfully ask that this not be resolved yet. I don't agree that
there are no problems here. What is the point of the latter half of the
message?
{quote}Some data, both in-memory and on-disk, may live longer due to garbage
collection.{quote}
I would say that's quite incorrect since Cassandra won't even be starting up,
and even if it did attempts to use FileUtils.clean() are going to throw NPE's
which will probably do a bit worse than cause data to live longer.
Additionally the message give here is cryptic and leaves the user unable to
discern (without searching through your jira, and taking the time to fully
debug cassandra's code, and read your startups scripts as I did) what the
problem is or how to correct it. So before we close this I'd like to suggest
one thing that I hope is non-controversial, and another that might require some
consideration:
1. Revise the error message here for the case of an IllegalAccessException to
advise the user how to move forward. Particularly tell them that they should
either use the standard cassandra start up scripts, or (expert) supply the
following --add-export and --add-open jvm args
2. Perhaps document the exports and opens requirements in a machine readable
way by adding Add-Exports: and Add-Opens: attributes to the manifest for the
jar file.
Suggestion #2 will not change the need for the .options files unless a bigger
change to invoke via java -jar happens (which I'm not suggesting here, but it
could eliminate that portion of the options file)
At some point I'll likely add support to Uno-Jar I'll to dig through manifests
of dependency jars looking for any jars with exports to collect them for the
uber jar... obviously that can only be a best effort thing, since no spec
requires such attributes but certainly it makes sense for jars to politely
declare what exports they require. (except of course proprietary stuff that
might seek to obfuscate and inhibit any usage not licensed...)
> Unable to start embedded cassandra on JDK 11
>
>
> Key: CASSANDRA-15468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15468
> Project: Cassandra
> Issue Type: Bug
>Reporter: Gus Heck
>Priority: Normal
> Attachments: CASSANDRA-15468.patch
>
>
> Cassandra fails to start without the following jvm options from
> jvm-11-server.options:
> {code:java}
> -Djdk.attach.allowAttachSelf=true
> --add-exports java.base/jdk.internal.misc=ALL-UNNAMED
> --add-exports java.base/jdk.internal.ref=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports java.management.rmi/com.sun.jmx.remote.internal.rmi=ALL-UNNAMED
> --add-exports java.rmi/sun.rmi.registry=ALL-UNNAMED
> --add-exports java.rmi/sun.rmi.server=ALL-UNNAMED
> --add-exports java.sql/java.sql=ALL-UNNAMED
> --add-opens java.base/java.lang.module=ALL-UNNAMED
> --add-opens java.base/jdk.internal.loader=ALL-UNNAMED
> --add-opens java.base/jdk.internal.ref=ALL-UNNAMED
> --add-opens java.base/jdk.internal.reflect=ALL-UNNAMED
> --add-opens java.base/jdk.internal.math=ALL-UNNAMED
> --add-opens java.base/jdk.internal.module=ALL-UNNAMED
> --add-opens java.base/jdk.internal.util.jar=ALL-UNNAMED
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
> {code}
> Without these options the following stack trace appears and prevents startup
> {code:java}
> 2020-01-05T17:42:15,009 ERROR main
> org.apache.cassandra.service.CassandraDaemon Exception encountered during
> startup java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.config.DatabaseDescriptor.guessFileStore(DatabaseDescriptor.java:1127)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:541)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:340)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:168)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:152)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:665)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:609)
> at org.jesterj.ingest.persistence.Cassandra.start(Cassandra.java:135)
> at
> org.jesterj.ingest.scanners.SimpleFileScannerImplFTITest.testScanWithMemory(SimpleFileScannerImplFTITest.java:63)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Updated] (CASSANDRA-15468) Unable to start embedded cassandra on JDK 11
[
https://issues.apache.org/jira/browse/CASSANDRA-15468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gus Heck updated CASSANDRA-15468:
-
Attachment: CASSANDRA-15468.patch
> Unable to start embedded cassandra on JDK 11
>
>
> Key: CASSANDRA-15468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15468
> Project: Cassandra
> Issue Type: Bug
>Reporter: Gus Heck
>Priority: Normal
> Attachments: CASSANDRA-15468.patch
>
>
> Cassandra fails to start without the following jvm options from
> jvm-11-server.options:
> {code:java}
> -Djdk.attach.allowAttachSelf=true
> --add-exports java.base/jdk.internal.misc=ALL-UNNAMED
> --add-exports java.base/jdk.internal.ref=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports java.management.rmi/com.sun.jmx.remote.internal.rmi=ALL-UNNAMED
> --add-exports java.rmi/sun.rmi.registry=ALL-UNNAMED
> --add-exports java.rmi/sun.rmi.server=ALL-UNNAMED
> --add-exports java.sql/java.sql=ALL-UNNAMED
> --add-opens java.base/java.lang.module=ALL-UNNAMED
> --add-opens java.base/jdk.internal.loader=ALL-UNNAMED
> --add-opens java.base/jdk.internal.ref=ALL-UNNAMED
> --add-opens java.base/jdk.internal.reflect=ALL-UNNAMED
> --add-opens java.base/jdk.internal.math=ALL-UNNAMED
> --add-opens java.base/jdk.internal.module=ALL-UNNAMED
> --add-opens java.base/jdk.internal.util.jar=ALL-UNNAMED
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
> {code}
> Without these options the following stack trace appears and prevents startup
> {code:java}
> 2020-01-05T17:42:15,009 ERROR main
> org.apache.cassandra.service.CassandraDaemon Exception encountered during
> startup java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.config.DatabaseDescriptor.guessFileStore(DatabaseDescriptor.java:1127)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:541)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:340)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:168)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:152)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:665)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:609)
> at org.jesterj.ingest.persistence.Cassandra.start(Cassandra.java:135)
> at
> org.jesterj.ingest.scanners.SimpleFileScannerImplFTITest.testScanWithMemory(SimpleFileScannerImplFTITest.java:63)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.lang.RuntimeException:
[jira] [Updated] (CASSANDRA-15258) Cassandra Windows JDK11 not working
[ https://issues.apache.org/jira/browse/CASSANDRA-15258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gus Heck updated CASSANDRA-15258: - Platform: Java11,OpenJDK,Windows (was: Java11,OpenJDK,Linux,Windows) > Cassandra Windows JDK11 not working > > > Key: CASSANDRA-15258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15258 > Project: Cassandra > Issue Type: Bug > Components: Build, Local/Startup and Shutdown >Reporter: RamyaK >Priority: Urgent > Labels: windows > > I'm trying to setup Cassandra 4.0 trunk with OpenJDK11, but getting below > error on start up. > > + $content = Get-Content "$env:CASSANDRA_CONF\jvm.options" > + ~ > + CategoryInfo : ObjectNotFound: > (D:\Stuff\save\C...onf\jvm.options:String) [Get-Content], > ItemNotFoundException > + FullyQualifiedErrorId : > PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand > Also JVM_VERSION is 11, still its showing as > Cassandra 4.0 requires either Java 8 (update 151 or newer) or Java 11 (or > newer). Java 11 is not supported. > > Please suggest. > -- 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-15468) Unable to start embedded cassandra on JDK 11
Gus Heck created CASSANDRA-15468:
Summary: Unable to start embedded cassandra on JDK 11
Key: CASSANDRA-15468
URL: https://issues.apache.org/jira/browse/CASSANDRA-15468
Project: Cassandra
Issue Type: Bug
Reporter: Gus Heck
Cassandra fails to start without the following jvm options from
jvm-11-server.options:
{code:java}
-Djdk.attach.allowAttachSelf=true
--add-exports java.base/jdk.internal.misc=ALL-UNNAMED
--add-exports java.base/jdk.internal.ref=ALL-UNNAMED
--add-exports java.base/sun.nio.ch=ALL-UNNAMED
--add-exports java.management.rmi/com.sun.jmx.remote.internal.rmi=ALL-UNNAMED
--add-exports java.rmi/sun.rmi.registry=ALL-UNNAMED
--add-exports java.rmi/sun.rmi.server=ALL-UNNAMED
--add-exports java.sql/java.sql=ALL-UNNAMED
--add-opens java.base/java.lang.module=ALL-UNNAMED
--add-opens java.base/jdk.internal.loader=ALL-UNNAMED
--add-opens java.base/jdk.internal.ref=ALL-UNNAMED
--add-opens java.base/jdk.internal.reflect=ALL-UNNAMED
--add-opens java.base/jdk.internal.math=ALL-UNNAMED
--add-opens java.base/jdk.internal.module=ALL-UNNAMED
--add-opens java.base/jdk.internal.util.jar=ALL-UNNAMED
--add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
{code}
Without these options the following stack trace appears and prevents startup
{code:java}
2020-01-05T17:42:15,009 ERROR main org.apache.cassandra.service.CassandraDaemon
Exception encountered during startup java.lang.ExceptionInInitializerError
at
org.apache.cassandra.config.DatabaseDescriptor.guessFileStore(DatabaseDescriptor.java:1127)
at
org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:541)
at
org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:340)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:168)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:152)
at
org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:665)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:609)
at org.jesterj.ingest.persistence.Cassandra.start(Cassandra.java:135)
at
org.jesterj.ingest.scanners.SimpleFileScannerImplFTITest.testScanWithMemory(SimpleFileScannerImplFTITest.java:63)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException: access
to public member failed:
jdk.internal.ref.Cleaner.clean[Ljava.lang.Object;@779dfe55/invokeVirtual, from
org.apache.cassandra.io.util.FileUtils (unnamed module @2eda0940)
at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:95)
... 33 more
Caused by: java.lang.IllegalAccessException: access to public member
[jira] [Commented] (CASSANDRA-15258) Cassandra Windows JDK11 not working
[ https://issues.apache.org/jira/browse/CASSANDRA-15258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008436#comment-17008436 ] Gus Heck commented on CASSANDRA-15258: -- Given that adding those options gets me past the particular exception (but is not an good solution in the long term), I suspect that this bug as originally written really is only windows, and the exception encountered in the first comment indicates that the windows startup does not add the above vm options. I'm going to file a separate issue for further contemplation of the merits of these options. > Cassandra Windows JDK11 not working > > > Key: CASSANDRA-15258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15258 > Project: Cassandra > Issue Type: Bug > Components: Build, Local/Startup and Shutdown >Reporter: RamyaK >Priority: Urgent > Labels: windows > > I'm trying to setup Cassandra 4.0 trunk with OpenJDK11, but getting below > error on start up. > > + $content = Get-Content "$env:CASSANDRA_CONF\jvm.options" > + ~ > + CategoryInfo : ObjectNotFound: > (D:\Stuff\save\C...onf\jvm.options:String) [Get-Content], > ItemNotFoundException > + FullyQualifiedErrorId : > PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand > Also JVM_VERSION is 11, still its showing as > Cassandra 4.0 requires either Java 8 (update 151 or newer) or Java 11 (or > newer). Java 11 is not supported. > > Please suggest. > -- 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-15258) Cassandra Windows JDK11 not working
[ https://issues.apache.org/jira/browse/CASSANDRA-15258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gus Heck updated CASSANDRA-15258: - Summary: Cassandra Windows JDK11 not working (was: Cassandra JDK11 not working) > Cassandra Windows JDK11 not working > > > Key: CASSANDRA-15258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15258 > Project: Cassandra > Issue Type: Bug > Components: Build, Local/Startup and Shutdown >Reporter: RamyaK >Priority: Urgent > Labels: windows > > I'm trying to setup Cassandra 4.0 trunk with OpenJDK11, but getting below > error on start up. > > + $content = Get-Content "$env:CASSANDRA_CONF\jvm.options" > + ~ > + CategoryInfo : ObjectNotFound: > (D:\Stuff\save\C...onf\jvm.options:String) [Get-Content], > ItemNotFoundException > + FullyQualifiedErrorId : > PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand > Also JVM_VERSION is 11, still its showing as > Cassandra 4.0 requires either Java 8 (update 151 or newer) or Java 11 (or > newer). Java 11 is not supported. > > Please suggest. > -- 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-15258) Cassandra JDK11 not working
[
https://issues.apache.org/jira/browse/CASSANDRA-15258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008431#comment-17008431
]
Gus Heck commented on CASSANDRA-15258:
--
However, I checked out the rev from the 9608 commit, build a jar (verified that
it had mrjar directories and manifest by opening it up) and installed it to the
maven local repo, and that did not fix the above stack trace. Reading the
commit further on a hunch, I found what is likely the culprit: The code
presumes that the following jvm args are present:
{code}
### JPMS
-Djdk.attach.allowAttachSelf=true
--add-exports java.base/jdk.internal.misc=ALL-UNNAMED
--add-opens java.base/jdk.internal.module=ALL-UNNAMED
--add-exports java.base/jdk.internal.ref=ALL-UNNAMED
--add-exports java.base/sun.nio.ch=ALL-UNNAMED
--add-exports java.management.rmi/com.sun.jmx.remote.internal.rmi=ALL-UNNAMED
--add-exports java.rmi/sun.rmi.registry=ALL-UNNAMED
--add-exports java.rmi/sun.rmi.server=ALL-UNNAMED
--add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
{code}
That's very bad for any embeded or test use cases that are not started via the
cassandra startup scripts
> Cassandra JDK11 not working
>
>
> Key: CASSANDRA-15258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15258
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Local/Startup and Shutdown
>Reporter: RamyaK
>Priority: Urgent
> Labels: windows
>
> I'm trying to setup Cassandra 4.0 trunk with OpenJDK11, but getting below
> error on start up.
>
> + $content = Get-Content "$env:CASSANDRA_CONF\jvm.options"
> + ~
> + CategoryInfo : ObjectNotFound:
> (D:\Stuff\save\C...onf\jvm.options:String) [Get-Content],
> ItemNotFoundException
> + FullyQualifiedErrorId :
> PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand
> Also JVM_VERSION is 11, still its showing as
> Cassandra 4.0 requires either Java 8 (update 151 or newer) or Java 11 (or
> newer). Java 11 is not supported.
>
> Please suggest.
>
--
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-15108) Support building Cassandra with JDK 11
[ https://issues.apache.org/jira/browse/CASSANDRA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008413#comment-17008413 ] Gus Heck commented on CASSANDRA-15108: -- This might be causing CASSANDRA-15258 > Support building Cassandra with JDK 11 > -- > > Key: CASSANDRA-15108 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15108 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.0 > > > With the changes in java 8 support and licensing, we should be able to build > and run Cassandra with java 11. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15258) Cassandra JDK11 not working
[
https://issues.apache.org/jira/browse/CASSANDRA-15258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008412#comment-17008412
]
Gus Heck commented on CASSANDRA-15258:
--
Opening the jar file found in my gradle cache for 4.0-alpha2, I find this
manifest:
{code:java}
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.10.5
Created-By: 1.8.0_222-8u222-b10-1-b10 (Debian)
{code}
Based on [http://openjdk.java.net/jeps/238] and the discussion of multi-release
jars in CASSANDRA-9608 I expected to find {{Multi-Release:true}} and
sub-directories of META-INF for an mrjar... but neither is present.
nor is this line from the commit in trunk:
[https://github.com/apache/cassandra/commit/6ba2fb9395226491872b41312d978a169f36fcdb#diff-2cccd7bf48b7a9cc113ff564acd802a8R232]
Digging further It seems that this was removed in CASSANDRA-15108 - which seems
to contradict the finding in bullet 2 of
https://issues.apache.org/jira/browse/CASSANDRA-9608?focusedCommentId=16510196=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16510196
the exceptions in this ticket suggest that the java 8 only build is not
working in java 11 as originally asserted in 9608.
> Cassandra JDK11 not working
>
>
> Key: CASSANDRA-15258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15258
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Local/Startup and Shutdown
>Reporter: RamyaK
>Priority: Urgent
> Labels: windows
>
> I'm trying to setup Cassandra 4.0 trunk with OpenJDK11, but getting below
> error on start up.
>
> + $content = Get-Content "$env:CASSANDRA_CONF\jvm.options"
> + ~
> + CategoryInfo : ObjectNotFound:
> (D:\Stuff\save\C...onf\jvm.options:String) [Get-Content],
> ItemNotFoundException
> + FullyQualifiedErrorId :
> PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand
> Also JVM_VERSION is 11, still its showing as
> Cassandra 4.0 requires either Java 8 (update 151 or newer) or Java 11 (or
> newer). Java 11 is not supported.
>
> Please suggest.
>
--
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-15258) Cassandra JDK11 not working
[ https://issues.apache.org/jira/browse/CASSANDRA-15258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008398#comment-17008398 ] Gus Heck commented on CASSANDRA-15258: -- much discussion at https://issues.apache.org/jira/browse/CASSANDRA-9608 for future readers... > Cassandra JDK11 not working > > > Key: CASSANDRA-15258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15258 > Project: Cassandra > Issue Type: Bug > Components: Build, Local/Startup and Shutdown >Reporter: RamyaK >Priority: Urgent > Labels: windows > > I'm trying to setup Cassandra 4.0 trunk with OpenJDK11, but getting below > error on start up. > > + $content = Get-Content "$env:CASSANDRA_CONF\jvm.options" > + ~ > + CategoryInfo : ObjectNotFound: > (D:\Stuff\save\C...onf\jvm.options:String) [Get-Content], > ItemNotFoundException > + FullyQualifiedErrorId : > PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand > Also JVM_VERSION is 11, still its showing as > Cassandra 4.0 requires either Java 8 (update 151 or newer) or Java 11 (or > newer). Java 11 is not supported. > > Please suggest. > -- 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-15258) Cassandra JDK11 not working
[ https://issues.apache.org/jira/browse/CASSANDRA-15258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008392#comment-17008392 ] Gus Heck commented on CASSANDRA-15258: -- Some further googling points out it's the inaccessibility of internal packages in java 9 (see also [https://github.com/rrd4j/rrd4j/issues/72)] It looks like Java 11 is not fooled by method handles based reflection. > Cassandra JDK11 not working > > > Key: CASSANDRA-15258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15258 > Project: Cassandra > Issue Type: Bug > Components: Build, Local/Startup and Shutdown >Reporter: RamyaK >Priority: Urgent > Labels: windows > > I'm trying to setup Cassandra 4.0 trunk with OpenJDK11, but getting below > error on start up. > > + $content = Get-Content "$env:CASSANDRA_CONF\jvm.options" > + ~ > + CategoryInfo : ObjectNotFound: > (D:\Stuff\save\C...onf\jvm.options:String) [Get-Content], > ItemNotFoundException > + FullyQualifiedErrorId : > PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand > Also JVM_VERSION is 11, still its showing as > Cassandra 4.0 requires either Java 8 (update 151 or newer) or Java 11 (or > newer). Java 11 is not supported. > > Please suggest. > -- 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-15258) Cassandra JDK11 not working
[ https://issues.apache.org/jira/browse/CASSANDRA-15258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008266#comment-17008266 ] Gus Heck edited comment on CASSANDRA-15258 at 1/5/20 8:04 AM: -- Took a look at the code in FileUtils and I'm not quite understanding why the methodhandles and reflection are necessary. I did find that I can also repro the same stacktrace by running ConnectionTest vs the above JDK (or an oracle java 9 jdk, or the current ubuntu open jdk 11) in intellij. I tried simply casting whih *looks* like it shoudl work since the method is public on the interface... yet it fails in a very odd way where testTimeout spins forever and a lot of "javax.net.ssl.SSLException: SSLEngine closed already" messages. was (Author: gus_heck): Took a look at the code in FileUtils and I'm not quite understanding why the methodhandles and reflection are necessary. I did find that I can also repro the same stacktrace by running ConnectionTest vs the above JDK in intellij. I tried simply casting whih *looks* like it shoudl work since the method is public on the interface... yet it fails in a very odd way where testTimeout spins forever and a lot of "javax.net.ssl.SSLException: SSLEngine closed already" messages. > Cassandra JDK11 not working > > > Key: CASSANDRA-15258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15258 > Project: Cassandra > Issue Type: Bug > Components: Build, Local/Startup and Shutdown >Reporter: RamyaK >Priority: Urgent > Labels: windows > > I'm trying to setup Cassandra 4.0 trunk with OpenJDK11, but getting below > error on start up. > > + $content = Get-Content "$env:CASSANDRA_CONF\jvm.options" > + ~ > + CategoryInfo : ObjectNotFound: > (D:\Stuff\save\C...onf\jvm.options:String) [Get-Content], > ItemNotFoundException > + FullyQualifiedErrorId : > PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand > Also JVM_VERSION is 11, still its showing as > Cassandra 4.0 requires either Java 8 (update 151 or newer) or Java 11 (or > newer). Java 11 is not supported. > > Please suggest. > -- 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-15258) Cassandra JDK11 not working
[ https://issues.apache.org/jira/browse/CASSANDRA-15258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008266#comment-17008266 ] Gus Heck commented on CASSANDRA-15258: -- Took a look at the code in FileUtils and I'm not quite understanding why the methodhandles and reflection are necessary. I did find that I can also repro the same stacktrace by running ConnectionTest vs the above JDK in intellij. I tried simply casting whih *looks* like it shoudl work since the method is public on the interface... yet it fails in a very odd way where testTimeout spins forever and a lot of "javax.net.ssl.SSLException: SSLEngine closed already" messages. > Cassandra JDK11 not working > > > Key: CASSANDRA-15258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15258 > Project: Cassandra > Issue Type: Bug > Components: Build, Local/Startup and Shutdown >Reporter: RamyaK >Priority: Urgent > Labels: windows > > I'm trying to setup Cassandra 4.0 trunk with OpenJDK11, but getting below > error on start up. > > + $content = Get-Content "$env:CASSANDRA_CONF\jvm.options" > + ~ > + CategoryInfo : ObjectNotFound: > (D:\Stuff\save\C...onf\jvm.options:String) [Get-Content], > ItemNotFoundException > + FullyQualifiedErrorId : > PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand > Also JVM_VERSION is 11, still its showing as > Cassandra 4.0 requires either Java 8 (update 151 or newer) or Java 11 (or > newer). Java 11 is not supported. > > Please suggest. > -- 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-15258) Cassandra JDK11 not working
[ https://issues.apache.org/jira/browse/CASSANDRA-15258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gus Heck updated CASSANDRA-15258: - Platform: Java11,OpenJDK,Linux,Windows (was: Java11,OpenJDK,Windows) > Cassandra JDK11 not working > > > Key: CASSANDRA-15258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15258 > Project: Cassandra > Issue Type: Bug > Components: Build, Local/Startup and Shutdown >Reporter: RamyaK >Priority: Urgent > Labels: windows > > I'm trying to setup Cassandra 4.0 trunk with OpenJDK11, but getting below > error on start up. > > + $content = Get-Content "$env:CASSANDRA_CONF\jvm.options" > + ~ > + CategoryInfo : ObjectNotFound: > (D:\Stuff\save\C...onf\jvm.options:String) [Get-Content], > ItemNotFoundException > + FullyQualifiedErrorId : > PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand > Also JVM_VERSION is 11, still its showing as > Cassandra 4.0 requires either Java 8 (update 151 or newer) or Java 11 (or > newer). Java 11 is not supported. > > Please suggest. > -- 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-15258) Cassandra JDK11 Windows not working
[
https://issues.apache.org/jira/browse/CASSANDRA-15258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008177#comment-17008177
]
Gus Heck edited comment on CASSANDRA-15258 at 1/4/20 11:57 PM:
---
I am seeing this on 4.0-alpha2 Running on Ubuntu 18.0.4...
{code:java}
openjdk version "11.0.5" 2019-10-15 LTS
OpenJDK Runtime Environment Zulu11.35+15-CA (build 11.0.5+10-LTS)
OpenJDK 64-Bit Server VM Zulu11.35+15-CA (build 11.0.5+10-LTS, mixed mode){code}
Full stack trace:
{code:java}
2020-01-04T17:22:52,885 ERROR main org.apache.cassandra.service.CassandraDaemon
Exception encountered during startup java.lang.ExceptionInInitializerError
at
org.apache.cassandra.config.DatabaseDescriptor.guessFileStore(DatabaseDescriptor.java:1127)
at
org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:541)
at
org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:340)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:168)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:152)
at
org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:665)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:609)
at org.jesterj.ingest.persistence.Cassandra.start(Cassandra.java:135)
at
org.jesterj.ingest.scanners.SimpleFileScannerImplFTITest.testScanWithMemory(SimpleFileScannerImplFTITest.java:63)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException: access
to public member failed:
jdk.internal.ref.Cleaner.clean[Ljava.lang.Object;@794b435f/invokeVirtual, from
org.apache.cassandra.io.util.FileUtils (unnamed module @43a0cee9)
at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:95)
... 33 more
Caused by: java.lang.IllegalAccessException: access to public member failed:
jdk.internal.ref.Cleaner.clean[Ljava.lang.Object;@794b435f/invokeVirtual, from
org.apache.cassandra.io.util.FileUtils (unnamed module @43a0cee9)
at
java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:942)
at
java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:2206)
at
java.base/java.lang.invoke.MethodHandles$Lookup.checkMethod(MethodHandles.java:2146)
at
java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:2290)
at
java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:2283)
at
java.base/java.lang.invoke.MethodHandles$Lookup.unreflect(MethodHandles.java:1747)
at
[jira] [Updated] (CASSANDRA-15258) Cassandra JDK11 not working
[ https://issues.apache.org/jira/browse/CASSANDRA-15258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gus Heck updated CASSANDRA-15258: - Summary: Cassandra JDK11 not working (was: Cassandra JDK11 Windows not working) > Cassandra JDK11 not working > > > Key: CASSANDRA-15258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15258 > Project: Cassandra > Issue Type: Bug > Components: Build, Local/Startup and Shutdown >Reporter: RamyaK >Priority: Urgent > Labels: windows > > I'm trying to setup Cassandra 4.0 trunk with OpenJDK11, but getting below > error on start up. > > + $content = Get-Content "$env:CASSANDRA_CONF\jvm.options" > + ~ > + CategoryInfo : ObjectNotFound: > (D:\Stuff\save\C...onf\jvm.options:String) [Get-Content], > ItemNotFoundException > + FullyQualifiedErrorId : > PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand > Also JVM_VERSION is 11, still its showing as > Cassandra 4.0 requires either Java 8 (update 151 or newer) or Java 11 (or > newer). Java 11 is not supported. > > Please suggest. > -- 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-15258) Cassandra JDK11 Windows not working
[
https://issues.apache.org/jira/browse/CASSANDRA-15258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008177#comment-17008177
]
Gus Heck commented on CASSANDRA-15258:
--
I am seeing this on 4.0-alpha2 Running on
{code:java}
openjdk version "11.0.5" 2019-10-15 LTS
OpenJDK Runtime Environment Zulu11.35+15-CA (build 11.0.5+10-LTS)
OpenJDK 64-Bit Server VM Zulu11.35+15-CA (build 11.0.5+10-LTS, mixed mode){code}
Full stack trace:
{code:java}
2020-01-04T17:22:52,885 ERROR main org.apache.cassandra.service.CassandraDaemon
Exception encountered during startup java.lang.ExceptionInInitializerError
at
org.apache.cassandra.config.DatabaseDescriptor.guessFileStore(DatabaseDescriptor.java:1127)
at
org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:541)
at
org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:340)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:168)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:152)
at
org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:665)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:609)
at org.jesterj.ingest.persistence.Cassandra.start(Cassandra.java:135)
at
org.jesterj.ingest.scanners.SimpleFileScannerImplFTITest.testScanWithMemory(SimpleFileScannerImplFTITest.java:63)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException: access
to public member failed:
jdk.internal.ref.Cleaner.clean[Ljava.lang.Object;@794b435f/invokeVirtual, from
org.apache.cassandra.io.util.FileUtils (unnamed module @43a0cee9)
at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:95)
... 33 more
Caused by: java.lang.IllegalAccessException: access to public member failed:
jdk.internal.ref.Cleaner.clean[Ljava.lang.Object;@794b435f/invokeVirtual, from
org.apache.cassandra.io.util.FileUtils (unnamed module @43a0cee9)
at
java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:942)
at
java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:2206)
at
java.base/java.lang.invoke.MethodHandles$Lookup.checkMethod(MethodHandles.java:2146)
at
java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:2290)
at
java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:2283)
at
java.base/java.lang.invoke.MethodHandles$Lookup.unreflect(MethodHandles.java:1747)
at org.apache.cassandra.io.util.FileUtils.(FileUtils.java:86)
... 33 more
{code}
> Cassandra JDK11 Windows
[jira] [Commented] (CASSANDRA-15248) Upgrade Guava to latest on master branch
[ https://issues.apache.org/jira/browse/CASSANDRA-15248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008137#comment-17008137 ] Gus Heck commented on CASSANDRA-15248: -- This is also causing issues in my project (JesterJ) that uses embedded Cassandra. I'm trying to upgrade to a recent Tika and it pulls in Guava 28.1-jre ... It looks like the current guava is now 28.2 > Upgrade Guava to latest on master branch > > > Key: CASSANDRA-15248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15248 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies, Packaging >Reporter: Abhijit Sarkar >Priority: Normal > > Upgrade Guava to latest on master branch. See > https://issues.apache.org/jira/browse/CASSANDRA-15245. -- 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-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369594#comment-16369594 ] Gus Heck commented on CASSANDRA-13396: -- Though my embedded usage is not only for unit test, my choice of Cassandra relates more to the fact that you are Apache licensed, pure java and clustered rather than performance concerns. When there's a viable alternative I'll worry about whether or not you're faster... in the mean time, I'm very happy to be responsible for (or take credit for) any performance variation from plugging in my preferred logging framework (log4j2). Please don't use performance worries as an excuse to not fix this. Generally +1 on Eric's summary also. I don't mind doing something extra to enable pluggable logging so that you can default to your supported config, so long as it doesn't impact the command line invocation of my project (i.e. requiring -D or -agentlib, etc). > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Bug >Reporter: Edward Capriolo >Assignee: Eugene Fedotov >Priority: Minor > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16147845#comment-16147845 ] Gus Heck commented on CASSANDRA-13396: -- Any one have a chance to look at my patch yet? > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Bug >Reporter: Edward Capriolo >Assignee: Eugene Fedotov >Priority: Minor > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16075022#comment-16075022 ] Gus Heck commented on CASSANDRA-13396: -- FYI, Circle CI did pass. Any commentary or review would be appreciated. I won't be able to release without knowing what direction this issue is going. > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Bug >Reporter: Edward Capriolo >Assignee: Eugene Fedotov >Priority: Minor > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069393#comment-16069393 ] Gus Heck edited comment on CASSANDRA-13396 at 6/30/17 3:01 AM: --- After some IRC discussion, I've been encouraged to submit a patch. Here's an implementation of my #3 suggestion above: https://github.com/nsoft/cassandra/commit/382a44c238b6d4bd7e3d8cc7bbd6710b0a7c5274 Though Github's diff has done a fabulous job of obfuscating it, the patch is very simple all I did was add a constant, and two conditions that read the system property represented by the constant and prevent this security manager and its policies from getting installed via the install() method if the system property has been set. Circle CI here: https://circleci.com/gh/nsoft/cassandra/2 (still running as of this comment, but I expect it to pass) Ran tests locally and Installed a version with this patch in JesterJ and everything seems happy there. was (Author: gus_heck): After some IRC discussion, I've been encouraged to submit a patch. Here's an implementation of my #3 suggestion above: https://github.com/nsoft/cassandra/commit/382a44c238b6d4bd7e3d8cc7bbd6710b0a7c5274 Though Github's diff has done a fabulous job of obfuscating it, the patch is very simple all I did was add a constant, and two conditions that read the system property represented by the constant and prevent this security manager and its policies from getting installed via the install() method if the system property has been set. Circle CI here: https://circleci.com/gh/nsoft/cassandra/2 (still running as of this comment, but I expect it to pass) Installed a version with this patch in JesterJ and everything seems happy there. > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Bug >Reporter: Edward Capriolo >Assignee: Eugene Fedotov >Priority: Minor > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069393#comment-16069393 ] Gus Heck commented on CASSANDRA-13396: -- After some IRC discussion, I've been encouraged to submit a patch. Here's an implementation of my #3 suggestion above: https://github.com/nsoft/cassandra/commit/382a44c238b6d4bd7e3d8cc7bbd6710b0a7c5274 Though Github's diff has done a fabulous job of obfuscating it, the patch is very simple all I did was add a constant, and two conditions that read the system property represented by the constant and prevent this security manager and its policies from getting installed via the install() method if the system property has been set. Circle CI here: https://circleci.com/gh/nsoft/cassandra/2 (still running as of this comment, but I expect it to pass) Installed a version with this patch in JesterJ and everything seems happy there. > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Bug >Reporter: Edward Capriolo >Assignee: Eugene Fedotov >Priority: Minor > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069141#comment-16069141 ] Gus Heck commented on CASSANDRA-13396: -- And yes I might be interested in providing a patch for 3 if folks seem in favor... 1 is probably beyond my knowledge of Cassandra, but a version of 3 dependent on a system property seems tractable. > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Bug >Reporter: Edward Capriolo >Assignee: Eugene Fedotov >Priority: Minor > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069133#comment-16069133 ] Gus Heck commented on CASSANDRA-13396: -- Looking forward to the resolution of this issue in any of the following ways: 1) Don't load this security manager and policies if UDF's are configured to be disabled 2) Handle other possible loggers conditionally (log4j2 being my case) 3) Provide an option to run with insecure UDF's ( by not installing this security manager). Not everyone is exposing UDF's to folks they don't trust. In some use cases it might be a feature to be able to read system properties etc. Glancing at the discussion it sounds like this is heading towards a "break UDF's but continue" strategy, which will also work for me since I don't need UDF's but seems likely to trip folks. My exact itch is documented here: https://github.com/nsoft/jesterj/issues/89 If option 1 or 3 were available, that would greatly simplify my life, because this security manager installs policies in a class initializer and these policies assume a codePath with a url scheme of "file" but in my case the scheme is "onejar"... which forced me into lots of gyrations to force an early load and then un-set your policies so that the rest of my code could have permissions. > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Bug >Reporter: Edward Capriolo >Assignee: Eugene Fedotov >Priority: Minor > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
