[jira] [Updated] (CASSANDRA-16661) Fix typo: Alterting -> Altering
[ https://issues.apache.org/jira/browse/CASSANDRA-16661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated CASSANDRA-16661: --- Description: Fix a typo in the response message when trying to alter a type of an UDT field. (was: Fix a typo in the response message when trying to alter a type of UDT column) > Fix typo: Alterting -> Altering > --- > > Key: CASSANDRA-16661 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16661 > Project: Cassandra > Issue Type: Bug > Components: CQL/Syntax >Reporter: Edward Ribeiro >Assignee: Edward Ribeiro >Priority: Normal > Fix For: 4.0-rc1 > > Time Spent: 10m > Remaining Estimate: 0h > > Fix a typo in the response message when trying to alter a type of an UDT > field. -- 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-16661) Fix typo: Alterting -> Altering
[ https://issues.apache.org/jira/browse/CASSANDRA-16661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated CASSANDRA-16661: --- Impacts: (was: None) > Fix typo: Alterting -> Altering > --- > > Key: CASSANDRA-16661 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16661 > Project: Cassandra > Issue Type: Bug > Components: CQL/Syntax >Reporter: Edward Ribeiro >Assignee: Edward Ribeiro >Priority: Normal > > Fix a typo in the response message when trying to alter a type of UDT column -- 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-16661) Fix typo: Alterting -> Altering
[ https://issues.apache.org/jira/browse/CASSANDRA-16661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated CASSANDRA-16661: --- Fix Version/s: 4.0-rc1 > Fix typo: Alterting -> Altering > --- > > Key: CASSANDRA-16661 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16661 > Project: Cassandra > Issue Type: Bug > Components: CQL/Syntax >Reporter: Edward Ribeiro >Assignee: Edward Ribeiro >Priority: Normal > Fix For: 4.0-rc1 > > > Fix a typo in the response message when trying to alter a type of UDT column -- 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-16661) Fix typo: Alterting -> Altering
Edward Ribeiro created CASSANDRA-16661: -- Summary: Fix typo: Alterting -> Altering Key: CASSANDRA-16661 URL: https://issues.apache.org/jira/browse/CASSANDRA-16661 Project: Cassandra Issue Type: Bug Components: CQL/Syntax Reporter: Edward Ribeiro Assignee: Edward Ribeiro Fix a typo in the response message when trying to alter a type of UDT column -- 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-16482) CQL schema generated by DESCRIBE KEYSPACE fails to import with custom indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-16482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17315672#comment-17315672
]
Edward Ribeiro commented on CASSANDRA-16482:
No problem. Thanks again for the awesome work. The C* community really stands
out. :)
> CQL schema generated by DESCRIBE KEYSPACE fails to import with custom indexes
> -
>
> Key: CASSANDRA-16482
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16482
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Mike Adamson
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc1, 4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The CQL schema generated by a DESCRIBE KEYSPACE on a keyspace with a table
> that contains a custom index cannot be reimported.
> The reimport of the schema fails with:
> {noformat}
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> specify class_name as a CUSTOM option"
> {noformat}
> The reason for this is that the custom index definition is created with
> {{class_name}} and {{target}} options added to it in it's {{WITH OPTIONS}}
> section. This is then picked up by the {{IndexAttributes.validate}} method
> that specifically rejects them.
> Note: This only seems to happen if the custom index was created with options
> in the first place. So if the {{CREATE CUSTOM INDEX}} statement didn't
> originally have a {{WITH OPTIONS}} section then it won't have the
> {{class_name}} and {{target}} options added to it.
> h3. Steps to reproduce
> {noformat}
> CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> CREATE TABLE test.test (id int PRIMARY KEY, value text);
> CREATE CUSTOM INDEX ON test.test(value) USING
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'is_literal':
> 'false'};
> DESCRIBE KEYSPACE test;
> {noformat}
> Trying to import the resultant schema will fail.
--
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-16303) ClassNotFoundException: com.googlecode.concurrenttrees.radix.node.NodeFactory
[ https://issues.apache.org/jira/browse/CASSANDRA-16303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314994#comment-17314994 ] Edward Ribeiro commented on CASSANDRA-16303: Awesome! Thanks for the quick reply. :) > ClassNotFoundException: com.googlecode.concurrenttrees.radix.node.NodeFactory > - > > Key: CASSANDRA-16303 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16303 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Adrian Cole >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.0-rc1, 4.0 > > Attachments: cassandra-all-4.0-beta5-SNAPSHOT.pom, > cassandra-parent-4.0-beta5-SNAPSHOT.pom > > > If you look at the pom for cassandra-all 4.0.0-beta-3, you'll notice > that concurrent-trees is in dependencyManagement, but not dependencies. This > might be going unnoticed as sasi is disabled by default now, but it can lead > to a ClassNotFoundException. I presume this was accidental -- 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-16303) ClassNotFoundException: com.googlecode.concurrenttrees.radix.node.NodeFactory
[ https://issues.apache.org/jira/browse/CASSANDRA-16303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314908#comment-17314908 ] Edward Ribeiro commented on CASSANDRA-16303: [~mck] Thanks for catching this and fixing it. Please, do you know when 4.0-rc1 will be available on Maven's central repo? > ClassNotFoundException: com.googlecode.concurrenttrees.radix.node.NodeFactory > - > > Key: CASSANDRA-16303 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16303 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Adrian Cole >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.0-rc1, 4.0 > > Attachments: cassandra-all-4.0-beta5-SNAPSHOT.pom, > cassandra-parent-4.0-beta5-SNAPSHOT.pom > > > If you look at the pom for cassandra-all 4.0.0-beta-3, you'll notice > that concurrent-trees is in dependencyManagement, but not dependencies. This > might be going unnoticed as sasi is disabled by default now, but it can lead > to a ClassNotFoundException. I presume this was accidental -- 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-16482) CQL schema generated by DESCRIBE KEYSPACE fails to import with custom indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-16482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314512#comment-17314512
]
Edward Ribeiro commented on CASSANDRA-16482:
[~blerer] Thanks for catch and fix this! Please, do you have any idea when
4.0-rc1 will be available at https://repo.maven.apache.org/maven2 ?
> CQL schema generated by DESCRIBE KEYSPACE fails to import with custom indexes
> -
>
> Key: CASSANDRA-16482
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16482
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Mike Adamson
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc1, 4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The CQL schema generated by a DESCRIBE KEYSPACE on a keyspace with a table
> that contains a custom index cannot be reimported.
> The reimport of the schema fails with:
> {noformat}
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> specify class_name as a CUSTOM option"
> {noformat}
> The reason for this is that the custom index definition is created with
> {{class_name}} and {{target}} options added to it in it's {{WITH OPTIONS}}
> section. This is then picked up by the {{IndexAttributes.validate}} method
> that specifically rejects them.
> Note: This only seems to happen if the custom index was created with options
> in the first place. So if the {{CREATE CUSTOM INDEX}} statement didn't
> originally have a {{WITH OPTIONS}} section then it won't have the
> {{class_name}} and {{target}} options added to it.
> h3. Steps to reproduce
> {noformat}
> CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> CREATE TABLE test.test (id int PRIMARY KEY, value text);
> CREATE CUSTOM INDEX ON test.test(value) USING
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'is_literal':
> 'false'};
> DESCRIBE KEYSPACE test;
> {noformat}
> Trying to import the resultant schema will fail.
--
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-12271) NonSystemKeyspaces jmx attribute needs to return jre list
[
https://issues.apache.org/jira/browse/CASSANDRA-12271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16467606#comment-16467606
]
Edward Ribeiro commented on CASSANDRA-12271:
Hi [~michaelsembwever], thanks for taking a look at this little contribution.
:) I read the CHANGES.txt and it looks good and the patch is correct. So, it's
ready to commit, imho.
> NonSystemKeyspaces jmx attribute needs to return jre list
> -
>
> Key: CASSANDRA-12271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12271
> Project: Cassandra
> Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Edward Ribeiro
>Priority: Major
> Labels: lhf
> Fix For: 4.0, 3.11.3
>
> Attachments: CASSANDRA-12271.patch, screenshot-1.png, screenshot-2.png
>
>
> If you dont have right guava in classpath you cant query the
> NonSystemKeyspaces attribute. i.e. jconsole. can reproduce using Swiss java
> knife:
> {code}
> # java -jar sjk.jar mx -s localhost:7199 -mg -b
> "org.apache.cassandra.db:type=StorageService" -f NonSystemKeyspaces
> org.apache.cassandra.db:type=StorageService
> java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
> java.lang.ClassNotFoundException:
> com.google.common.collect.ImmutableList$SerializedForm (no security manager:
> RMI class loader disabled)
> {code}
> If return a ArrayList or LinkedList or anything in JRE this will be fixed
--
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] [Comment Edited] (CASSANDRA-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425891#comment-16425891
]
Edward Ribeiro edited comment on CASSANDRA-13891 at 4/4/18 5:25 PM:
[~jasobrown], the second test I created below fails with
NullPointerException, but everything passes after the little fix. FYI,
the test that fails on 2.2 and 3.0 is below:
{code:java}
execute("INSERT INTO %s (k, frozenmapval) VALUES (?, fromJson(?))", 0, null);
assertRows(execute("SELECT k, frozenmapval FROM %s WHERE k = ?", 0), row(0,
null));{code}
I have open the following PRs targeting 2.2 and 3.0, respectively. I don't have
access to a CI so it would be nice if you could run those tests. :)
[https://github.com/apache/cassandra/pull/215]
[https://github.com/apache/cassandra/pull/216]
Oh, and let me know if I missed something, please.
Thanks!
was (Author: eribeiro):
[~jasobrown], the second test I created below fails with
\{{NullPointerException}}, but everything passes after the little fix. I have
open the following PRs targeting 2.2 and 3.0, respectively. I don't have access
to a CI so it would be nice if you could run those tests. :)
[https://github.com/apache/cassandra/pull/215]
[https://github.com/apache/cassandra/pull/216]
Oh, and let me know if I missed something, please.
Thanks!
> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Assignee: Edward Ribeiro
>Priority: Minor
> Fix For: 4.0, 3.11.3
>
> Attachments: CASSANDRA-13891.patch
>
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL
> is passed, instead of just returning a NULL itself. Say I create a UDT and a
> table as follows:
> {code:java}
> create type type1
> (
> id int,
> name text
> );
> create table table1
> (
> id int,
> t FROZEN,
> primary key (id)
> );{code}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me
> expecting {{fromJson}} to just return NULL.
--
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-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425891#comment-16425891
]
Edward Ribeiro commented on CASSANDRA-13891:
[~jasobrown], the second test I created below fails with
\{{NullPointerException}}, but everything passes after the little fix. I have
open the following PRs targeting 2.2 and 3.0, respectively. I don't have access
to a CI so it would be nice if you could run those tests. :)
[https://github.com/apache/cassandra/pull/215]
[https://github.com/apache/cassandra/pull/216]
Oh, and let me know if I missed something, please.
Thanks!
> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Assignee: Edward Ribeiro
>Priority: Minor
> Fix For: 4.0, 3.11.3
>
> Attachments: CASSANDRA-13891.patch
>
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL
> is passed, instead of just returning a NULL itself. Say I create a UDT and a
> table as follows:
> {code:java}
> create type type1
> (
> id int,
> name text
> );
> create table table1
> (
> id int,
> t FROZEN,
> primary key (id)
> );{code}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me
> expecting {{fromJson}} to just return NULL.
--
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-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425546#comment-16425546
]
Edward Ribeiro commented on CASSANDRA-13891:
Sure! Gonna try to repro on 2.2 and 3.0 for double check, no problem. Thanks
again, Jason!
> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Assignee: Edward Ribeiro
>Priority: Minor
> Fix For: 4.0, 3.11.3
>
> Attachments: CASSANDRA-13891.patch
>
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL
> is passed, instead of just returning a NULL itself. Say I create a UDT and a
> table as follows:
> {code:java}
> create type type1
> (
> id int,
> name text
> );
> create table table1
> (
> id int,
> t FROZEN,
> primary key (id)
> );{code}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me
> expecting {{fromJson}} to just return NULL.
--
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] [Comment Edited] (CASSANDRA-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16424283#comment-16424283
]
Edward Ribeiro edited comment on CASSANDRA-13891 at 4/3/18 4:59 PM:
Hey, [~jasobrown], thank you very much. I was going to do this today, but you
beat me to it. :) Thanks again and sorry for taking too long to look again at
this issue.
PS: fyi, the first incarnation of this patch was adressed to trunk, but I was
asked to port it to 2.2 first.
Cheers!
was (Author: eribeiro):
Hey, [~jasobrown], thank you very much. I was going to do this today, but you
beat me. :) Thanks again.
PS: fyi, the first incarnation of this patch was adressed to trunk, but I was
asked to port it to 2.2 first.
Cheers!
> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Assignee: Edward Ribeiro
>Priority: Minor
> Fix For: 4.0, 3.11.3
>
> Attachments: CASSANDRA-13891.patch
>
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL
> is passed, instead of just returning a NULL itself. Say I create a UDT and a
> table as follows:
> {code:java}
> create type type1
> (
> id int,
> name text
> );
> create table table1
> (
> id int,
> t FROZEN,
> primary key (id)
> );{code}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me
> expecting {{fromJson}} to just return NULL.
--
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-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16424283#comment-16424283
]
Edward Ribeiro commented on CASSANDRA-13891:
Hey, [~jasobrown], thank you very much. I was going to do this today, but you
beat me. :) Thanks again.
PS: fyi, the first incarnation of this patch was adressed to trunk, but I was
asked to port it to 2.2 first.
Cheers!
> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Assignee: Edward Ribeiro
>Priority: Minor
> Fix For: 4.0, 3.11.3
>
> Attachments: CASSANDRA-13891.patch
>
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL
> is passed, instead of just returning a NULL itself. Say I create a UDT and a
> table as follows:
> {code:java}
> create type type1
> (
> id int,
> name text
> );
> create table table1
> (
> id int,
> t FROZEN,
> primary key (id)
> );{code}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me
> expecting {{fromJson}} to just return NULL.
--
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] [Resolved] (CASSANDRA-13991) NullPointerException when querying a table with a previous state
[ https://issues.apache.org/jira/browse/CASSANDRA-13991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro resolved CASSANDRA-13991. Resolution: Won't Fix Reproduced In: 3.11.1, 3.0.15 (was: 3.0.15, 3.11.1) > NullPointerException when querying a table with a previous state > > > Key: CASSANDRA-13991 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13991 > Project: Cassandra > Issue Type: Bug > Components: CQL >Reporter: Chris mildebrandt >Priority: Major > Labels: lhf > Attachments: CASSANDRA-13991.log > > > Performing the following steps (using the gocql library) results in an NPE: > * With a table of 12 entries, read all rows. > * Set the page size to 1 and read the first row. Save the query state. > * Read all the row again. > * Set the page size to 5 and the page state to the previous state. (This is > where the NPE occurs). > This can be reproduced with the following project: > https://github.com/eyeofthefrog/CASSANDRA-13991 -- 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] [Comment Edited] (CASSANDRA-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341664#comment-16341664
]
Edward Ribeiro edited comment on CASSANDRA-13891 at 1/26/18 10:06 PM:
--
Hi [~blerer],
Thanks for taking your time to look at this patch.
I have setup a 2.2 patched branch:
[https://github.com/eribeiro/cassandra/tree/13891-2.2]
I have never used CircleCI before (the project is using this to build and test
C* right?), so I am lost about how to build and run the CI on my 2.2 patched
branch.
I have created a CircleCI account via Github authentication, but it looks like
it tries to build a only master and even so it spews an error message. Could
you point me at links where I can find how to solve those issues?
PS: Running {{JsonTest}} on both cassandra-2.2 and 13891-2.2 branches: it threw
some errors I didn't see when the patch was 3.9+
Thanks again!
was (Author: eribeiro):
Hi [~blerer],
Thanks for taking your time to look at this patch.
I have setup a 2.2 patched branch:
[https://github.com/eribeiro/cassandra/tree/13891-2.2]
I have never used CircleCI before (the project is using this to build and test
C* right?), so I am lost about how to build and run the CI on my 2.2 patched
branch.
I have created a CircleCI account via Github authentication, but it looks like
it tries to build a only master and even so it spews an error message. Could
you point me at links where I can find how to solve those issues?
PS: Running \{{JsonTest}} on both cassandra-2.2 and 13891-2.2 branches threw
some errors I didn't see when the patch was 3.9+
Thanks again!
> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Assignee: Edward Ribeiro
>Priority: Minor
> Attachments: CASSANDRA-13891.patch
>
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL
> is passed, instead of just returning a NULL itself. Say I create a UDT and a
> table as follows:
> {code:java}
> create type type1
> (
> id int,
> name text
> );
> create table table1
> (
> id int,
> t FROZEN,
> primary key (id)
> );{code}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me
> expecting {{fromJson}} to just return NULL.
--
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-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341664#comment-16341664
]
Edward Ribeiro commented on CASSANDRA-13891:
Hi [~blerer],
Thanks for taking your time to look at this patch.
I have setup a 2.2 patched branch:
[https://github.com/eribeiro/cassandra/tree/13891-2.2]
I have never used CircleCI before (the project is using this to build and test
C* right?), so I am lost about how to build and run the CI on my 2.2 patched
branch.
I have created a CircleCI account via Github authentication, but it looks like
it tries to build a only master and even so it spews an error message. Could
you point me at links where I can find how to solve those issues?
PS: Running \{{JsonTest}} on both cassandra-2.2 and 13891-2.2 branches threw
some errors I didn't see when the patch was 3.9+
Thanks again!
> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Assignee: Edward Ribeiro
>Priority: Minor
> Attachments: CASSANDRA-13891.patch
>
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL
> is passed, instead of just returning a NULL itself. Say I create a UDT and a
> table as follows:
> {code:java}
> create type type1
> (
> id int,
> name text
> );
> create table table1
> (
> id int,
> t FROZEN,
> primary key (id)
> );{code}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me
> expecting {{fromJson}} to just return NULL.
--
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-14173) JDK 8u161 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341453#comment-16341453
]
Edward Ribeiro commented on CASSANDRA-14173:
Woot! Great job, [~beobal]! :) I have removed my hacky-patches from upload area
not to pollute this issue.
> JDK 8u161 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Updated] (CASSANDRA-14173) JDK 8u161 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Attachment: (was: cassandra-14173.39-trunk.patch)
> JDK 8u161 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Updated] (CASSANDRA-14173) JDK 8u161 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Attachment: (was: cassandra-14173.38.patch)
> JDK 8u161 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Updated] (CASSANDRA-14173) JDK 8u161 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Attachment: (was: cassandra-14173.patch)
> JDK 8u161 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Updated] (CASSANDRA-14173) JDK 8u161 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Attachment: (was: cassandra-14173.36-37.patch)
> JDK 8u161 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Updated] (CASSANDRA-14005) CqlBulkRecordWriter swallows exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-14005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14005:
---
Attachment: CASSANDRA-14005.patch
> CqlBulkRecordWriter swallows exceptions
> ---
>
> Key: CASSANDRA-14005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14005
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Vincent Dumont
>Priority: Major
> Attachments: CASSANDRA-14005.patch
>
>
> The {{close()}} method in {{CqlBulkRecordWriter}} has the following:
> {code:java}
> try
> {
> future.get(1000, TimeUnit.MILLISECONDS);
> break;
> }
> catch (ExecutionException | TimeoutException te)
> {
> if (null != progress)
> progress.progress();
> if (null != context)
> HadoopCompat.progress(context);
> }
> catch (InterruptedException e)
> {
> throw new IOException(e);
> }
> {code}
> And so any exception that happens when uploading SSTables silently gets
> swallowed and not surfaced.
--
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] [Updated] (CASSANDRA-14005) CqlBulkRecordWriter swallows exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-14005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14005:
---
Attachment: (was: CASSANDRA-14005.patch)
> CqlBulkRecordWriter swallows exceptions
> ---
>
> Key: CASSANDRA-14005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14005
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Vincent Dumont
>Priority: Major
>
> The {{close()}} method in {{CqlBulkRecordWriter}} has the following:
> {code:java}
> try
> {
> future.get(1000, TimeUnit.MILLISECONDS);
> break;
> }
> catch (ExecutionException | TimeoutException te)
> {
> if (null != progress)
> progress.progress();
> if (null != context)
> HadoopCompat.progress(context);
> }
> catch (InterruptedException e)
> {
> throw new IOException(e);
> }
> {code}
> And so any exception that happens when uploading SSTables silently gets
> swallowed and not surfaced.
--
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-14005) CqlBulkRecordWriter swallows exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-14005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336589#comment-16336589
]
Edward Ribeiro commented on CASSANDRA-14005:
Hi [~vdumont],
I have attached trivial proposal to this issue. Instead of swallowing the
exception it logs the exception at the WARN level. As TimeOutExceptions are
expected (and it will retry until it succeeds or fail) then I tried to log only
ExecutionExceptions. I have based off this patch on cassandra-3.9 because you
didn't provide a starting branch to apply the patch. Please, let me know what
you think.
Cheers!
Ed
> CqlBulkRecordWriter swallows exceptions
> ---
>
> Key: CASSANDRA-14005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14005
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Vincent Dumont
>Priority: Major
> Attachments: CASSANDRA-14005.patch
>
>
> The {{close()}} method in {{CqlBulkRecordWriter}} has the following:
> {code:java}
> try
> {
> future.get(1000, TimeUnit.MILLISECONDS);
> break;
> }
> catch (ExecutionException | TimeoutException te)
> {
> if (null != progress)
> progress.progress();
> if (null != context)
> HadoopCompat.progress(context);
> }
> catch (InterruptedException e)
> {
> throw new IOException(e);
> }
> {code}
> And so any exception that happens when uploading SSTables silently gets
> swallowed and not surfaced.
--
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] [Updated] (CASSANDRA-14005) CqlBulkRecordWriter swallows exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-14005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14005:
---
Attachment: CASSANDRA-14005.patch
> CqlBulkRecordWriter swallows exceptions
> ---
>
> Key: CASSANDRA-14005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14005
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Vincent Dumont
>Priority: Major
> Attachments: CASSANDRA-14005.patch
>
>
> The {{close()}} method in {{CqlBulkRecordWriter}} has the following:
> {code:java}
> try
> {
> future.get(1000, TimeUnit.MILLISECONDS);
> break;
> }
> catch (ExecutionException | TimeoutException te)
> {
> if (null != progress)
> progress.progress();
> if (null != context)
> HadoopCompat.progress(context);
> }
> catch (InterruptedException e)
> {
> throw new IOException(e);
> }
> {code}
> And so any exception that happens when uploading SSTables silently gets
> swallowed and not surfaced.
--
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-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336566#comment-16336566
]
Edward Ribeiro commented on CASSANDRA-13891:
Thanks! :)
> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Assignee: Edward Ribeiro
>Priority: Minor
> Attachments: CASSANDRA-13891.patch
>
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL
> is passed, instead of just returning a NULL itself. Say I create a UDT and a
> table as follows:
> {code:java}
> create type type1
> (
> id int,
> name text
> );
> create table table1
> (
> id int,
> t FROZEN,
> primary key (id)
> );{code}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me
> expecting {{fromJson}} to just return NULL.
--
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-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16334909#comment-16334909
]
Edward Ribeiro commented on CASSANDRA-13891:
Hi [~mar...@lisemarie.com], and [~jdarcy], I am still finding my way again
after a long period of absence from Cassandra dev, so I would like to see if I
am missing something here. Thanks!
> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Priority: Minor
> Attachments: CASSANDRA-13891.patch
>
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL
> is passed, instead of just returning a NULL itself. Say I create a UDT and a
> table as follows:
> {code:java}
> create type type1
> (
> id int,
> name text
> );
> create table table1
> (
> id int,
> t FROZEN,
> primary key (id)
> );{code}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me
> expecting {{fromJson}} to just return NULL.
--
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] [Updated] (CASSANDRA-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-13891:
---
Attachment: CASSANDRA-13891.patch
> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Priority: Minor
> Attachments: CASSANDRA-13891.patch
>
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL
> is passed, instead of just returning a NULL itself. Say I create a UDT and a
> table as follows:
> {code:java}
> create type type1
> (
> id int,
> name text
> );
> create table table1
> (
> id int,
> t FROZEN,
> primary key (id)
> );{code}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me
> expecting {{fromJson}} to just return NULL.
--
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] [Comment Edited] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1683#comment-1683
]
Edward Ribeiro edited comment on CASSANDRA-14173 at 1/22/18 7:25 PM:
-
Yes [~mshuler], the first cut of this patch *required* >= 1.8u161 :(
OTOH, I have put together another version (see further attachments above) that
compiles on both 152 and 161. *_But_* *_I still need to verify if it doesn't
break Cassandra_ _at runtime, though!_*
(heh, changing jdk back and forth messed up my IDE so it dragged me down)
AFAIK, 161 build has both the legacy and the new constructor (the one with
_ObjectInputFilter_), so it should work as intended, but I am not sure about
152 yet. _Please_, let me know what you think, thanks.
*update:* I have uploaded a couple of patches following the pattern
cassandra-14173..patch that apply to a single branch or a range of
branches.
was (Author: eribeiro):
Yes [~mshuler], the first cut of this patch *required* >= 1.8u161 :(
OTOH, I have put together another version (see attachment) that compiles on
both 152 and 161. *_But_* *_I still need to verify if it doesn't break
Cassandra_ _at runtime, though!_*
(heh, changing jdk back and forth messed up my IDE so it dragged me down)
AFAIK, 161 build has both the legacy and the new constructor (the one with
_ObjectInputFilter_), so it should work as intended, but I am not sure about
152 yet. _Please_, let me know what you think, thanks.
*update:* I have uploaded a couple of patches following the pattern
cassandra-14173..patch that apply to a single branch or a range of
branches.
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.36-37.patch, cassandra-14173.38.patch,
> cassandra-14173.39-trunk.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Comment Edited] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1683#comment-1683
]
Edward Ribeiro edited comment on CASSANDRA-14173 at 1/22/18 7:25 PM:
-
Yes [~mshuler], the first cut of this patch *required* >= 1.8u161 :(
OTOH, I have put together another version (see attachment) that compiles on
both 152 and 161. *_But_* *_I still need to verify if it doesn't break
Cassandra_ _at runtime, though!_*
(heh, changing jdk back and forth messed up my IDE so it dragged me down)
AFAIK, 161 build has both the legacy and the new constructor (the one with
_ObjectInputFilter_), so it should work as intended, but I am not sure about
152 yet. _Please_, let me know what you think, thanks.
*update:* I have uploaded a couple of patches following the pattern
cassandra-14173..patch that apply to a single branch or a range of
branches.
was (Author: eribeiro):
Yes [~mshuler], the first cut of this patch *requires* >= 1.8u161 :(
OTOH, I have put together another version (see attachment) that compiles on
both 152 and 161. *_But_* *_I still need to verify if it doesn't break
Cassandra_ _at runtime, though!_*
(heh, changing jdk back and forth messed up my IDE so it dragged me down)
AFAIK, 161 build has both the legacy and the new constructor (the one with
_ObjectInputFilter_), so it should work as intended, but I am not sure about
152 yet. _Please_, let me know what you think, thanks.
*update:* I have uploaded a couple of patches following the pattern
cassandra-14173..patch that apply to a single branch or a range of
branches.
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.36-37.patch, cassandra-14173.38.patch,
> cassandra-14173.39-trunk.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Comment Edited] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1683#comment-1683
]
Edward Ribeiro edited comment on CASSANDRA-14173 at 1/22/18 7:37 AM:
-
Yes [~mshuler], the first cut of this patch *requires* >= 1.8u161 :(
OTOH, I have put together another version (see attachment) that compiles on
both 152 and 161. *_But_* *_I still need to verify if it doesn't break
Cassandra_ _at runtime, though!_*
(heh, changing jdk back and forth messed up my IDE so it dragged me down)
AFAIK, 161 build has both the legacy and the new constructor (the one with
_ObjectInputFilter_), so it should work as intended, but I am not sure about
152 yet. _Please_, let me know what you think, thanks.
*update:* I have uploaded a couple of patches following the pattern
cassandra-14173..patch that apply to a single branch or a range of
branches.
was (Author: eribeiro):
Yes [~mshuler], the first cut of this patch *requires* >= 1.8u161 :(
OTOH, I have put together another version (see attachment) that compiles on
both 152 and 161. *_But_* *_I still need to verify if it doesn't break
Cassandra_ _at runtime, though!_*
(heh, changing jdk back and forth messed up my IDE so it dragged me down)
AFAIK, 161 build has both the legacy and the new constructor (the one with
_ObjectInputFilter_), so it should work as intended, but I am not sure about
152 yet. _Please_, let me know what you think, thanks.
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.36-37.patch, cassandra-14173.38.patch,
> cassandra-14173.39-trunk.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Updated] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Attachment: cassandra-14173.38.patch
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.36-37.patch, cassandra-14173.38.patch,
> cassandra-14173.39-trunk.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Updated] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Attachment: cassandra-14173.36-37.patch
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.36-37.patch,
> cassandra-14173.39-trunk.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Updated] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Attachment: cassandra-14173.39-trunk.patch
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.39-trunk.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Updated] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Attachment: (was: cassandra-14173.2.patch)
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Updated] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Attachment: cassandra-14173.2.patch
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.2.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Updated] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Attachment: (was: cassandra-14173.2.patch)
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.2.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Comment Edited] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1683#comment-1683
]
Edward Ribeiro edited comment on CASSANDRA-14173 at 1/21/18 3:18 AM:
-
Yes [~mshuler], the first cut of this patch *requires* >= 1.8u161 :(
OTOH, I have put together another version (see attachment) that compiles on
both 152 and 161. *_But_* *_I still need to verify if it doesn't break
Cassandra_ _at runtime, though!_*
(heh, changing jdk back and forth messed up my IDE so it dragged me down)
AFAIK, 161 build has both the legacy and the new constructor (the one with
_ObjectInputFilter_), so it should work as intended, but I am not sure about
152 yet. _Please_, let me know what you think, thanks.
was (Author: eribeiro):
Yes [~mshuler], the first cut of this patch *requires* >= 1.8u161 :(
OTOH, I have put together another version (see attachment) that compiles on
both 152 and 161. *_But_* *_I still need to verify if it doesn't break C_ _at
runtime, though!_*
(heh, changing jdk back and forth messed up my IDE so it dragged me down)
AFAIK, 161 build has both the legacy and the new constructor (the one with
_ObjectInputFilter_), so it should work as intended, but I am not sure about
152 yet. _Please_, let me know what you think, thanks.
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.2.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Comment Edited] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1683#comment-1683
]
Edward Ribeiro edited comment on CASSANDRA-14173 at 1/21/18 3:18 AM:
-
Yes [~mshuler], the first cut of this patch *requires* >= 1.8u161 :(
OTOH, I have put together another version (see attachment) that compiles on
both 152 and 161. *_But_* *_I still need to verify if it doesn't break C_ _at
runtime, though!_*
(heh, changing jdk back and forth messed up my IDE so it dragged me down)
AFAIK, 161 build has both the legacy and the new constructor (the one with
_ObjectInputFilter_), so it should work as intended, but I am not sure about
152 yet. _Please_, let me know what you think, thanks.
was (Author: eribeiro):
Yes [~mshuler], the first cut of this patch *requires* >= 1.8u161 :(
OTOH, I have put together another version (see attachment) that compiles on
both 152 and 161. *_But_* *_I still need to verify if it doesn't break C* at
runtime, though!_* (heh, changing jdk back and forth messed up my IDE so it
dragged me down)
AFAIK, 161 build has both the legacy and the new constructor (the one with
_ObjectInputFilter_), so it should work as intended, but I am not sure about
152 yet. _Please_, let me know what you think, thanks.
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.2.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1683#comment-1683
]
Edward Ribeiro commented on CASSANDRA-14173:
Yes [~mshuler], the first cut of this patch *requires* >= 1.8u161 :(
OTOH, I have put together another version (see attachment) that compiles on
both 152 and 161. *_But_* *_I still need to verify if it doesn't break C* at
runtime, though!_* (heh, changing jdk back and forth messed up my IDE so it
dragged me down)
AFAIK, 161 build has both the legacy and the new constructor (the one with
_ObjectInputFilter_), so it should work as intended, but I am not sure about
152 yet. _Please_, let me know what you think, thanks.
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.2.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Updated] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Attachment: cassandra-14173.2.patch
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.2.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Updated] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Reproduced In: 3.11.1, 3.11.0, 3.10, 3.9, 3.8, 3.7, 3.6 (was: 3.6, 3.7,
3.8, 3.9, 3.10, 3.11.0, 3.11.1)
Status: Open (was: Patch Available)
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Updated] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Reproduced In: 3.11.1, 3.11.0, 3.10, 3.9, 3.8, 3.7, 3.6 (was: 3.6, 3.7,
3.8, 3.9, 3.10, 3.11.0, 3.11.1)
Status: Patch Available (was: Open)
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333279#comment-16333279
]
Edward Ribeiro commented on CASSANDRA-14173:
Hi guys,
I have uploaded a patch file based on cassandra-3.x branch. Please, see if it
helps to solve the issue.
Best regards,
Ed
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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] [Updated] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Attachment: cassandra-14173.patch
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
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-12978) mx4j -> HTTP 500 -> ConcurrentModificationException
[ https://issues.apache.org/jira/browse/CASSANDRA-12978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16287737#comment-16287737 ] Edward Ribeiro commented on CASSANDRA-12978: Yes, sounds good to close it. Thanks > mx4j -> HTTP 500 -> ConcurrentModificationException > --- > > Key: CASSANDRA-12978 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12978 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Debian, Single cluster, 2 data centres, E5-2620 v3, > 16GB, RAID1 SSD Commit log, RAID10 15k HDD data >Reporter: Rob Emery >Priority: Critical > Labels: proposed-wontfix > Fix For: 2.1.6 > > > We run some checks from our Monitoring software that rely on mx4j. > The checks typically grab some xml via HTTP request and parse it. For > example, CF Stats on 'MyKeySpace' and 'MyColumnFamily' are retrieved > using: > http://cassandra001:8081/mbean?template=identity=org.apache.cassandra.db%3Atype%3DColumnFamilies%2Ckeyspace%3DMyKeySpace%2Ccolumnfamily%3DMyColumnFamily > The checks run each minute. Periodically they result in a "HTTP 500 internal > server error". The HTML body returned is empty. > Experimentally we ran Cassandra in the foreground on one node and reproduced > the problem. this elicited the following stack trace: > javax.management.RuntimeMBeanException: > java.util.ConcurrentModificationException > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrow(DefaultMBeanServerInterceptor.java:839) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrowMaybeMBeanException(DefaultMBeanServerInterceptor.java:852) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:651) > at > com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) > at > mx4j.tools.adaptor.http.MBeanCommandProcessor.createMBeanElement(MBeanCommandProcessor.java:119) > at > mx4j.tools.adaptor.http.MBeanCommandProcessor.executeRequest(MBeanCommandProcessor.java:56) > at > mx4j.tools.adaptor.http.HttpAdaptor$HttpClient.run(HttpAdaptor.java:980) > Caused by: java.util.ConcurrentModificationException > at > java.util.TreeMap$NavigableSubMap$SubMapIterator.nextEntry(TreeMap.java:1594) > at > java.util.TreeMap$NavigableSubMap$SubMapEntryIterator.next(TreeMap.java:1642) > at > java.util.TreeMap$NavigableSubMap$SubMapEntryIterator.next(TreeMap.java:1636) > at java.util.AbstractMap$2$1.next(AbstractMap.java:385) > at > org.apache.cassandra.utils.StreamingHistogram.sum(StreamingHistogram.java:160) > at > org.apache.cassandra.io.sstable.metadata.StatsMetadata.getDroppableTombstonesBefore(StatsMetadata.java:113) > at > org.apache.cassandra.io.sstable.SSTableReader.getDroppableTombstonesBefore(SSTableReader.java:2004) > at > org.apache.cassandra.db.DataTracker.getDroppableTombstoneRatio(DataTracker.java:507) > at > org.apache.cassandra.db.ColumnFamilyStore.getDroppableTombstoneRatio(ColumnFamilyStore.java:3089) > at sun.reflect.GeneratedMethodAccessor64.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279) > at > com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112) > at > com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46) > at > com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) > at > com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83) > at > com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647) > ... 4 more -- 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-12978) mx4j -> HTTP 500 -> ConcurrentModificationException
[
https://issues.apache.org/jira/browse/CASSANDRA-12978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830166#comment-15830166
]
Edward Ribeiro commented on CASSANDRA-12978:
Hi [~Reweavers],
It looks like the problem is because
{{org.apache.cassandra.utils.StreamingHistogram}} is not *thread-safe*. So, if
{{sum}} method, for example, is called concurrently with an {{update}} then the
{{TreeMap}} underneath {{StreamingHistogram}} will get changed and throws the
{{ConcurrentModificationException}}. One possible 'straightforward' solution
would be to make the methods {{synchronized}} but this could have a net impact
on performance, maybe. This problem didn't pop up before because the usually it
is used by a single thread, as far as I can quickly see looking at C* code base.
I will /cc [~tjake] 'cause he worked on this class about 1 year ago, so better
than me to say if it makes sense.
> mx4j -> HTTP 500 -> ConcurrentModificationException
> ---
>
> Key: CASSANDRA-12978
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12978
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Debian, Single cluster, 2 data centres, E5-2620 v3,
> 16GB, RAID1 SSD Commit log, RAID10 15k HDD data
>Reporter: Rob Emery
>Priority: Critical
> Fix For: 2.1.6
>
>
> We run some checks from our Monitoring software that rely on mx4j.
> The checks typically grab some xml via HTTP request and parse it. For
> example, CF Stats on 'MyKeySpace' and 'MyColumnFamily' are retrieved
> using:
> http://cassandra001:8081/mbean?template=identity=org.apache.cassandra.db%3Atype%3DColumnFamilies%2Ckeyspace%3DMyKeySpace%2Ccolumnfamily%3DMyColumnFamily
> The checks run each minute. Periodically they result in a "HTTP 500 internal
> server error". The HTML body returned is empty.
> Experimentally we ran Cassandra in the foreground on one node and reproduced
> the problem. this elicited the following stack trace:
> javax.management.RuntimeMBeanException:
> java.util.ConcurrentModificationException
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrow(DefaultMBeanServerInterceptor.java:839)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrowMaybeMBeanException(DefaultMBeanServerInterceptor.java:852)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:651)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
> at
> mx4j.tools.adaptor.http.MBeanCommandProcessor.createMBeanElement(MBeanCommandProcessor.java:119)
> at
> mx4j.tools.adaptor.http.MBeanCommandProcessor.executeRequest(MBeanCommandProcessor.java:56)
> at
> mx4j.tools.adaptor.http.HttpAdaptor$HttpClient.run(HttpAdaptor.java:980)
> Caused by: java.util.ConcurrentModificationException
> at
> java.util.TreeMap$NavigableSubMap$SubMapIterator.nextEntry(TreeMap.java:1594)
> at
> java.util.TreeMap$NavigableSubMap$SubMapEntryIterator.next(TreeMap.java:1642)
> at
> java.util.TreeMap$NavigableSubMap$SubMapEntryIterator.next(TreeMap.java:1636)
> at java.util.AbstractMap$2$1.next(AbstractMap.java:385)
> at
> org.apache.cassandra.utils.StreamingHistogram.sum(StreamingHistogram.java:160)
> at
> org.apache.cassandra.io.sstable.metadata.StatsMetadata.getDroppableTombstonesBefore(StatsMetadata.java:113)
> at
> org.apache.cassandra.io.sstable.SSTableReader.getDroppableTombstonesBefore(SSTableReader.java:2004)
> at
> org.apache.cassandra.db.DataTracker.getDroppableTombstoneRatio(DataTracker.java:507)
> at
> org.apache.cassandra.db.ColumnFamilyStore.getDroppableTombstoneRatio(ColumnFamilyStore.java:3089)
> at sun.reflect.GeneratedMethodAccessor64.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at
>
[jira] [Commented] (CASSANDRA-12274) mx4j not work in 3.0.8
[
https://issues.apache.org/jira/browse/CASSANDRA-12274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566605#comment-15566605
]
Edward Ribeiro commented on CASSANDRA-12274:
Sorry for taking so long to look at this. :( It's +1 from me, but, more
importantly, Jake has given his blessing already. ;)
> mx4j not work in 3.0.8
> --
>
> Key: CASSANDRA-12274
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12274
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: suse 12
> java 1.8.0_60
> mx4j 3.0.2
>Reporter: Ilya
>Assignee: Robert Stupp
> Fix For: 3.0.x
>
> Attachments: mx4j-error-log.txt
>
>
> After update from 2.1 to 3.x version mx4j page begin empty
> {code}
> $ curl -i cassandra1:8081
> HTTP/1.0 200 OK
> expires: now
> Server: MX4J-HTTPD/1.0
> Cache-Control: no-cache
> pragma: no-cache
> Content-Type: text/html
> {code}
> There are no errors in the log.
> logs:
> {code}
> ~ $ grep -i mx4j /local/apache-cassandra/logs/system.log | tail -2
> INFO [main] 2016-07-22 13:48:00,352 CassandraDaemon.java:432 - JVM
> Arguments: [-Xloggc:/local/apache-cassandra//logs/gc.log,
> -XX:+UseThreadPriorities, -XX:ThreadPriorityPolicy=42,
> -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=/local/tmp, -Xss256k,
> -XX:StringTableSize=103, -XX:+AlwaysPreTouch, -XX:+UseTLAB,
> -XX:+ResizeTLAB, -XX:+UseNUMA, -Djava.net.preferIPv4Stack=true, -Xms512M,
> -Xmx1G, -XX:+UseG1GC, -XX:G1RSetUpdatingPauseTimePercent=5,
> -XX:MaxGCPauseMillis=500, -XX:InitiatingHeapOccupancyPercent=25,
> -XX:G1HeapRegionSize=32m, -XX:ParallelGCThreads=16, -XX:+PrintGCDetails,
> -XX:+PrintGCDateStamps, -XX:+PrintHeapAtGC, -XX:+PrintTenuringDistribution,
> -XX:+PrintGCApplicationStoppedTime, -XX:+PrintPromotionFailure,
> -XX:+UseGCLogFileRotation, -XX:NumberOfGCLogFiles=10, -XX:GCLogFileSize=10M,
> -XX:CompileCommandFile=/local/apache-cassandra//conf/hotspot_compiler,
> -javaagent:/local/apache-cassandra//lib/jamm-0.3.0.jar,
> -Djava.rmi.server.hostname=cassandra1.d3,
> -Dcom.sun.management.jmxremote.port=7199,
> -Dcom.sun.management.jmxremote.rmi.port=7199,
> -Dcom.sun.management.jmxremote.ssl=false,
> -Dcom.sun.management.jmxremote.authenticate=false,
> -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password,
> -Djava.library.path=/local/apache-cassandra//lib/sigar-bin, -Dmx4jport=8081,
> -Dlogback.configurationFile=logback.xml,
> -Dcassandra.logdir=/local/apache-cassandra//logs,
> -Dcassandra.storagedir=/local/apache-cassandra//data,
> -Dcassandra-pidfile=/local/apache-cassandra/run/cassandra.pid]
> INFO [main] 2016-07-22 13:48:04,045 Mx4jTool.java:63 - mx4j successfuly
> loaded
> {code}
> {code}
> ~ $ sudo lsof -i:8081
> COMMAND PID USER FD TYPEDEVICE SIZE/OFF NODE NAME
> java14489 cassandra 86u IPv4 381043582 0t0 TCP
> cassandra1.d3:sunproxyadmin (LISTEN)
> {code}
> I checked versions 3.0.8 and 3.5, result the same - not work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12271) NonSystemKeyspaces jmx attribute needs to return jre list
[
https://issues.apache.org/jira/browse/CASSANDRA-12271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-12271:
---
Fix Version/s: 3.x
> NonSystemKeyspaces jmx attribute needs to return jre list
> -
>
> Key: CASSANDRA-12271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12271
> Project: Cassandra
> Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Edward Ribeiro
> Labels: lhf
> Fix For: 3.x
>
> Attachments: CASSANDRA-12271.patch, screenshot-1.png, screenshot-2.png
>
>
> If you dont have right guava in classpath you cant query the
> NonSystemKeyspaces attribute. i.e. jconsole. can reproduce using Swiss java
> knife:
> {code}
> # java -jar sjk.jar mx -s localhost:7199 -mg -b
> "org.apache.cassandra.db:type=StorageService" -f NonSystemKeyspaces
> org.apache.cassandra.db:type=StorageService
> java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
> java.lang.ClassNotFoundException:
> com.google.common.collect.ImmutableList$SerializedForm (no security manager:
> RMI class loader disabled)
> {code}
> If return a ArrayList or LinkedList or anything in JRE this will be fixed
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12271) NonSystemKeyspaces jmx attribute needs to return jre list
[
https://issues.apache.org/jira/browse/CASSANDRA-12271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15423668#comment-15423668
]
Edward Ribeiro commented on CASSANDRA-12271:
Thanks [~cnlwsu],
I am getting in touch to know if there are any major impediment to have this
patch merged? :)
Cheers!
> NonSystemKeyspaces jmx attribute needs to return jre list
> -
>
> Key: CASSANDRA-12271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12271
> Project: Cassandra
> Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Edward Ribeiro
> Labels: lhf
> Attachments: CASSANDRA-12271.patch, screenshot-1.png, screenshot-2.png
>
>
> If you dont have right guava in classpath you cant query the
> NonSystemKeyspaces attribute. i.e. jconsole. can reproduce using Swiss java
> knife:
> {code}
> # java -jar sjk.jar mx -s localhost:7199 -mg -b
> "org.apache.cassandra.db:type=StorageService" -f NonSystemKeyspaces
> org.apache.cassandra.db:type=StorageService
> java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
> java.lang.ClassNotFoundException:
> com.google.common.collect.ImmutableList$SerializedForm (no security manager:
> RMI class loader disabled)
> {code}
> If return a ArrayList or LinkedList or anything in JRE this will be fixed
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12274) mx4j not work in 3.0.8
[
https://issues.apache.org/jira/browse/CASSANDRA-12274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-12274:
---
Attachment: mx4j-error-log.txt
Hi [~snazy],
I've discovered by accident that this regression was indirectly caused by
CASSANDRA-9402. I am testing on C* 3.9 branch.
I could check that by putting the mx4j-tools.jar in the lib directory then
commenting/uncommenting this line:
https://github.com/apache/cassandra/blob/143d16961a67cc9d5608605ee2561253de629d2c/src/java/org/apache/cassandra/service/CassandraDaemon.java#L189
Looks like, the addition of a {{SecurityManager}} makes {{mx4j}} throws an
exception and show a blank page. I have attached the Runtime error exception.
{{Mx4jTool}} is the class in charge of loading mx4j if it is in the classpath.
Last but not least, I found a small typo ("panalty") here:
https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java#L36
I am sorry for not being able to provide a ready solution, but this
SecurityManager + ClassLoader + XSLT stuff is beyond me now. :(
> mx4j not work in 3.0.8
> --
>
> Key: CASSANDRA-12274
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12274
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: suse 12
> java 1.8.0_60
> mx4j 3.0.2
>Reporter: Ilya
> Attachments: mx4j-error-log.txt
>
>
> After update from 2.1 to 3.x version mx4j page begin empty
> {code}
> $ curl -i cassandra1:8081
> HTTP/1.0 200 OK
> expires: now
> Server: MX4J-HTTPD/1.0
> Cache-Control: no-cache
> pragma: no-cache
> Content-Type: text/html
> {code}
> There are no errors in the log.
> logs:
> {code}
> ~ $ grep -i mx4j /local/apache-cassandra/logs/system.log | tail -2
> INFO [main] 2016-07-22 13:48:00,352 CassandraDaemon.java:432 - JVM
> Arguments: [-Xloggc:/local/apache-cassandra//logs/gc.log,
> -XX:+UseThreadPriorities, -XX:ThreadPriorityPolicy=42,
> -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=/local/tmp, -Xss256k,
> -XX:StringTableSize=103, -XX:+AlwaysPreTouch, -XX:+UseTLAB,
> -XX:+ResizeTLAB, -XX:+UseNUMA, -Djava.net.preferIPv4Stack=true, -Xms512M,
> -Xmx1G, -XX:+UseG1GC, -XX:G1RSetUpdatingPauseTimePercent=5,
> -XX:MaxGCPauseMillis=500, -XX:InitiatingHeapOccupancyPercent=25,
> -XX:G1HeapRegionSize=32m, -XX:ParallelGCThreads=16, -XX:+PrintGCDetails,
> -XX:+PrintGCDateStamps, -XX:+PrintHeapAtGC, -XX:+PrintTenuringDistribution,
> -XX:+PrintGCApplicationStoppedTime, -XX:+PrintPromotionFailure,
> -XX:+UseGCLogFileRotation, -XX:NumberOfGCLogFiles=10, -XX:GCLogFileSize=10M,
> -XX:CompileCommandFile=/local/apache-cassandra//conf/hotspot_compiler,
> -javaagent:/local/apache-cassandra//lib/jamm-0.3.0.jar,
> -Djava.rmi.server.hostname=cassandra1.d3,
> -Dcom.sun.management.jmxremote.port=7199,
> -Dcom.sun.management.jmxremote.rmi.port=7199,
> -Dcom.sun.management.jmxremote.ssl=false,
> -Dcom.sun.management.jmxremote.authenticate=false,
> -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password,
> -Djava.library.path=/local/apache-cassandra//lib/sigar-bin, -Dmx4jport=8081,
> -Dlogback.configurationFile=logback.xml,
> -Dcassandra.logdir=/local/apache-cassandra//logs,
> -Dcassandra.storagedir=/local/apache-cassandra//data,
> -Dcassandra-pidfile=/local/apache-cassandra/run/cassandra.pid]
> INFO [main] 2016-07-22 13:48:04,045 Mx4jTool.java:63 - mx4j successfuly
> loaded
> {code}
> {code}
> ~ $ sudo lsof -i:8081
> COMMAND PID USER FD TYPEDEVICE SIZE/OFF NODE NAME
> java14489 cassandra 86u IPv4 381043582 0t0 TCP
> cassandra1.d3:sunproxyadmin (LISTEN)
> {code}
> I checked versions 3.0.8 and 3.5, result the same - not work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12205) nodetool tablestats sstable count missing.
[ https://issues.apache.org/jira/browse/CASSANDRA-12205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409542#comment-15409542 ] Edward Ribeiro commented on CASSANDRA-12205: No problem, Cameron. This patch has been committed on Cassandra 3.9 and the issue marked as fixed. Thanks for reporting! :) > nodetool tablestats sstable count missing. > -- > > Key: CASSANDRA-12205 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12205 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Cassandra 3.7 >Reporter: Cameron MacMinn >Assignee: Edward Ribeiro > Fix For: 3.9 > > Attachments: CASSANDRA-12205.patch, bad.txt, good.txt > > > As a user, I have used nodetool cfstats since v2.1. The most useful line is > the 1 like 'SSTable count: 12'. > As a user, I want v3.7 nodetool tablestats to continue showing SStable > count. At the moment, SStable count is missing from the output. > Examples attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12205) nodetool tablestats sstable count missing.
[
https://issues.apache.org/jira/browse/CASSANDRA-12205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15408665#comment-15408665
]
Edward Ribeiro commented on CASSANDRA-12205:
Um... this issue is now marked as a duplication of CASSANDRA-11880, but it
looks like that issue is adding the number of tables (column families) to the
stats collections while this one is restoring the SSTable counting that was
removed at C* 3.7, right? I mean, this is is {{related}} to CASSANDRA-11880
instead of duplication, afaik. wdyt?
> nodetool tablestats sstable count missing.
> --
>
> Key: CASSANDRA-12205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12205
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Cassandra 3.7
>Reporter: Cameron MacMinn
>Assignee: Edward Ribeiro
> Fix For: 3.x
>
> Attachments: CASSANDRA-12205.patch, bad.txt, good.txt
>
>
> As a user, I have used nodetool cfstats since v2.1. The most useful line is
> the 1 like 'SSTable count: 12'.
> As a user, I want v3.7 nodetool tablestats to continue showing SStable
> count. At the moment, SStable count is missing from the output.
> Examples attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12205) nodetool tablestats sstable count missing.
[ https://issues.apache.org/jira/browse/CASSANDRA-12205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated CASSANDRA-12205: --- Attachment: CASSANDRA-12205.patch Hi [~cam888eron], [~JoshuaMcKenzie], [~weideng], I am submitting a patch for cassandra-3.8 branch that restores the printing of this statistics. I have also checked to see if any other table level stats were missing, but this was the only one I've found on a quick check. Best regards > nodetool tablestats sstable count missing. > -- > > Key: CASSANDRA-12205 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12205 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Cassandra 3.7 >Reporter: Cameron MacMinn > Attachments: CASSANDRA-12205.patch, bad.txt, good.txt > > > As a user, I have used nodetool cfstats since v2.1. The most useful line is > the 1 like 'SSTable count: 12'. > As a user, I want v3.7 nodetool tablestats to continue showing SStable > count. At the moment, SStable count is missing from the output. > Examples attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11823) Creating a table leads to a race with GraphiteReporter
[
https://issues.apache.org/jira/browse/CASSANDRA-11823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406925#comment-15406925
]
Edward Ribeiro commented on CASSANDRA-11823:
Cool! Really glad to help. Thanks for the opportunity. :)
> Creating a table leads to a race with GraphiteReporter
> --
>
> Key: CASSANDRA-11823
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11823
> Project: Cassandra
> Issue Type: Bug
> Components: Observability
>Reporter: Stefano Ortolani
>Assignee: Edward Ribeiro
>Priority: Minor
> Labels: lhf
> Fix For: 3.0.9, 3.9
>
> Attachments: CASSANDRA-11823.patch
>
>
> Happened only on 3/4 nodes out of 13.
> {code:xml}
> INFO [MigrationStage:1] 2016-05-18 00:34:11,566 ColumnFamilyStore.java:381 -
> Initializing schema.table
> ERROR [metrics-graphite-reporter-1-thread-1] 2016-05-18 00:34:11,569
> ScheduledReporter.java:119 - RuntimeException thrown from
> GraphiteReporter#report. Exception was suppressed.
> java.util.ConcurrentModificationException: null
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
> ~[na:1.8.0_91]
> at java.util.HashMap$KeyIterator.next(HashMap.java:1453) ~[na:1.8.0_91]
> at
> org.apache.cassandra.metrics.TableMetrics$33.getValue(TableMetrics.java:690)
> ~[apache-cassandra-3.0.6.jar:3.0.6]
> at
> org.apache.cassandra.metrics.TableMetrics$33.getValue(TableMetrics.java:686)
> ~[apache-cassandra-3.0.6.jar:3.0.6]
> at
> com.codahale.metrics.graphite.GraphiteReporter.reportGauge(GraphiteReporter.java:281)
> ~[metrics-graphite-3.1.0.jar:3.1.0]
> at
> com.codahale.metrics.graphite.GraphiteReporter.report(GraphiteReporter.java:158)
> ~[metrics-graphite-3.1.0.jar:3.1.0]
> at
> com.codahale.metrics.ScheduledReporter.report(ScheduledReporter.java:162)
> ~[metrics-core-3.1.0.jar:3.1.0]
> at
> com.codahale.metrics.ScheduledReporter$1.run(ScheduledReporter.java:117)
> ~[metrics-core-3.1.0.jar:3.1.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_91]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_91]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_91]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_91]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_91]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_91]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11823) Creating a table leads to a race with GraphiteReporter
[
https://issues.apache.org/jira/browse/CASSANDRA-11823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-11823:
---
Attachment: CASSANDRA-11823.patch
Hi [~ostefano] and [~Stefania],
I took a stab at this issue, and I guess I've found the root cause of the
problem. I am providing a patch for cassandra-3.0 branch.
*IMHO*, it looks like when a table is created, the metrics Set for a specific
key entry at {{TableMetrics.allTableMetrics}} is updated while the metrics
{{Set}} is being iterated to get a summarized value to be passed to
{{GraphiteReporter}}, as below, for example:
{code}
public Long getValue()
{
long total = 0;
for (Metric cfGauge : allTableMetrics.get(name))
{
total = total + ((Gauge)
cfGauge).getValue().longValue();
}
return total;
}
{code}
Even tough {{allTableMetrics}} is a thread-safe {{ConcurrentMap}}, *the {{Set}}
iterated in the for-loop above is not!* Oddly enough, the
{{ConcurrentModificationException}} reports the {{Map}} as the offending one
instead of the {{Set}} inside the {{Map}} that's effectively being iterated (I
guess that is is due to the nature of the for-each loop).
*If this is the case*, the solution is to create a thread-safe {{Set}}.
{{Collections#synchronizedSet}} will not work, but fortunately, we can also
create a thread-safe {{Set}} backed by a {{ConcurrentHashMap}}.
Until Java 8, we could do this as shown here:
http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#newSetFromMap%28java.util.Map%29
But as C* uses Java 8 this can be done as here:
http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html#newKeySet--
Of course, I can be chasing my own tail (would not the first time, lol) and the
problem has *nothing* to do with I exposed above, so, please, let me know what
you think. :)
> Creating a table leads to a race with GraphiteReporter
> --
>
> Key: CASSANDRA-11823
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11823
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefano Ortolani
>Priority: Minor
> Labels: lhf
> Attachments: CASSANDRA-11823.patch
>
>
> Happened only on 3/4 nodes out of 13.
> {code:xml}
> INFO [MigrationStage:1] 2016-05-18 00:34:11,566 ColumnFamilyStore.java:381 -
> Initializing schema.table
> ERROR [metrics-graphite-reporter-1-thread-1] 2016-05-18 00:34:11,569
> ScheduledReporter.java:119 - RuntimeException thrown from
> GraphiteReporter#report. Exception was suppressed.
> java.util.ConcurrentModificationException: null
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
> ~[na:1.8.0_91]
> at java.util.HashMap$KeyIterator.next(HashMap.java:1453) ~[na:1.8.0_91]
> at
> org.apache.cassandra.metrics.TableMetrics$33.getValue(TableMetrics.java:690)
> ~[apache-cassandra-3.0.6.jar:3.0.6]
> at
> org.apache.cassandra.metrics.TableMetrics$33.getValue(TableMetrics.java:686)
> ~[apache-cassandra-3.0.6.jar:3.0.6]
> at
> com.codahale.metrics.graphite.GraphiteReporter.reportGauge(GraphiteReporter.java:281)
> ~[metrics-graphite-3.1.0.jar:3.1.0]
> at
> com.codahale.metrics.graphite.GraphiteReporter.report(GraphiteReporter.java:158)
> ~[metrics-graphite-3.1.0.jar:3.1.0]
> at
> com.codahale.metrics.ScheduledReporter.report(ScheduledReporter.java:162)
> ~[metrics-core-3.1.0.jar:3.1.0]
> at
> com.codahale.metrics.ScheduledReporter$1.run(ScheduledReporter.java:117)
> ~[metrics-core-3.1.0.jar:3.1.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_91]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_91]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_91]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_91]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_91]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_91]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12271) NonSystemKeyspaces jmx attribute needs to return jre list
[
https://issues.apache.org/jira/browse/CASSANDRA-12271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-12271:
---
Attachment: screenshot-2.png
CASSANDRA-12271.patch
Hey [~cnlwsu], I am submitting a small patch to address this.
Some considerations:
1. I could have just written
{code}
return
Collections.unmodifiableList(ArrayList<>(Schema.instance.getNonSystemKeyspaces()));
{code}
But I chose to maintain the "look" of the above method ({{getKeyspaces()}}).
wdyt?
2. The main problem with mine approach to this patch is that it copies the
content from a ImmutableList that has been itself copied from other collection
(inside {{Schema.instance.getNonSystemKeyspaces}}). :(
*But* I would prefer to do this than alter
{{Schema.instance.getNonSystemKeyspaces}}. Also, I suppose the keyspace list is
not that large, and this method changed is basically called by the nodeProbe
(JMX). wdyt?
3. As you can see from the screenshot I have attached (and the code),
{{NonSystemKeyspaces}} is equals to {{NonLocalStrategyKeyspaces}}. Is that
right?
> NonSystemKeyspaces jmx attribute needs to return jre list
> -
>
> Key: CASSANDRA-12271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12271
> Project: Cassandra
> Issue Type: Bug
>Reporter: Chris Lohfink
> Labels: lhf
> Attachments: CASSANDRA-12271.patch, screenshot-1.png, screenshot-2.png
>
>
> If you dont have right guava in classpath you cant query the
> NonSystemKeyspaces attribute. i.e. jconsole. can reproduce using Swiss java
> knife:
> {code}
> # java -jar sjk.jar mx -s localhost:7199 -mg -b
> "org.apache.cassandra.db:type=StorageService" -f NonSystemKeyspaces
> org.apache.cassandra.db:type=StorageService
> java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
> java.lang.ClassNotFoundException:
> com.google.common.collect.ImmutableList$SerializedForm (no security manager:
> RMI class loader disabled)
> {code}
> If return a ArrayList or LinkedList or anything in JRE this will be fixed
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8693) QueryProcessor never removes internal statements from its cache
[
https://issues.apache.org/jira/browse/CASSANDRA-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14298740#comment-14298740
]
Edward Ribeiro edited comment on CASSANDRA-8693 at 1/30/15 3:20 PM:
Hi Tyler, thanks! :)
+1 for leaving the tests out. Agree.
was (Author: eribeiro):
Hi Tyler, thanks! :)
QueryProcessor never removes internal statements from its cache
---
Key: CASSANDRA-8693
URL: https://issues.apache.org/jira/browse/CASSANDRA-8693
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro
Labels: cql3
Fix For: 2.1.3
Attachments: qp-internal.patch
QueryProcessor holds a reference to {{internalStatements}}, a map for
prepared statements used internally.
Those commands don't mix with the ones created by the user, but the problem
is that if a KS/CF is dropped and then recreated {{internalStatements}}
entries will point to invalid PreparedStatements (old cf_id) so any operation
on those statements will fail thereafter. In fact, as of today, this map is
never actually cleaned, no matter what.
This problem is similar to the ones addressed by
https://issues.apache.org/jira/browse/CASSANDRA-8652 and
https://issues.apache.org/jira/browse/CASSANDRA-7566, so those issues provide
any further context.
I am attaching a patch to this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8693) QueryProcessor never removes internal statements from its cache
[
https://issues.apache.org/jira/browse/CASSANDRA-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14298740#comment-14298740
]
Edward Ribeiro commented on CASSANDRA-8693:
---
Hi Tyler, thanks! :)
QueryProcessor never removes internal statements from its cache
---
Key: CASSANDRA-8693
URL: https://issues.apache.org/jira/browse/CASSANDRA-8693
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro
Labels: cql3
Fix For: 2.1.3
Attachments: qp-internal.patch
QueryProcessor holds a reference to {{internalStatements}}, a map for
prepared statements used internally.
Those commands don't mix with the ones created by the user, but the problem
is that if a KS/CF is dropped and then recreated {{internalStatements}}
entries will point to invalid PreparedStatements (old cf_id) so any operation
on those statements will fail thereafter. In fact, as of today, this map is
never actually cleaned, no matter what.
This problem is similar to the ones addressed by
https://issues.apache.org/jira/browse/CASSANDRA-8652 and
https://issues.apache.org/jira/browse/CASSANDRA-7566, so those issues provide
any further context.
I am attaching a patch to this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8693) QueryProcessor never removes internal statements from its cache
[
https://issues.apache.org/jira/browse/CASSANDRA-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-8693:
--
Summary: QueryProcessor never removes internal statements from its cache
(was: QueryProcessor.executeInternal(statement) never evictes statements from
internal cache)
QueryProcessor never removes internal statements from its cache
---
Key: CASSANDRA-8693
URL: https://issues.apache.org/jira/browse/CASSANDRA-8693
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Edward Ribeiro
Labels: cql3
Fix For: 2.1.2
Attachments: qp-internal.patch
QueryProcessor holds a reference to {{internalStatements}}, a map for
prepared statements used internally.
Those commands don't mix with the ones created by the user, but the problem
is that if a KS/CF is dropped and then recreated {{internalStatements}}
entries will point to invalid PreparedStatements (old cf_id) so any operation
on those statements will fail therefore. In fact, as of today, this map is
never actually cleaned no matter what.
This problem is similar to the ones addressed by
https://issues.apache.org/jira/browse/CASSANDRA-8652 and
https://issues.apache.org/jira/browse/CASSANDRA-7566, so those issues provide
any further context.
I am attaching a patch to this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8693) QueryProcessor never removes internal statements from its cache
[
https://issues.apache.org/jira/browse/CASSANDRA-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-8693:
--
Description:
QueryProcessor holds a reference to {{internalStatements}}, a map for prepared
statements used internally.
Those commands don't mix with the ones created by the user, but the problem is
that if a KS/CF is dropped and then recreated {{internalStatements}} entries
will point to invalid PreparedStatements (old cf_id) so any operation on those
statements will fail thereafter. In fact, as of today, this map is never
actually cleaned, no matter what.
This problem is similar to the ones addressed by
https://issues.apache.org/jira/browse/CASSANDRA-8652 and
https://issues.apache.org/jira/browse/CASSANDRA-7566, so those issues provide
any further context.
I am attaching a patch to this issue.
was:
QueryProcessor holds a reference to {{internalStatements}}, a map for prepared
statements used internally.
Those commands don't mix with the ones created by the user, but the problem is
that if a KS/CF is dropped and then recreated {{internalStatements}} entries
will point to invalid PreparedStatements (old cf_id) so any operation on those
statements will fail therefore. In fact, as of today, this map is never
actually cleaned no matter what.
This problem is similar to the ones addressed by
https://issues.apache.org/jira/browse/CASSANDRA-8652 and
https://issues.apache.org/jira/browse/CASSANDRA-7566, so those issues provide
any further context.
I am attaching a patch to this issue.
QueryProcessor never removes internal statements from its cache
---
Key: CASSANDRA-8693
URL: https://issues.apache.org/jira/browse/CASSANDRA-8693
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro
Labels: cql3
Fix For: 2.1.2
Attachments: qp-internal.patch
QueryProcessor holds a reference to {{internalStatements}}, a map for
prepared statements used internally.
Those commands don't mix with the ones created by the user, but the problem
is that if a KS/CF is dropped and then recreated {{internalStatements}}
entries will point to invalid PreparedStatements (old cf_id) so any operation
on those statements will fail thereafter. In fact, as of today, this map is
never actually cleaned, no matter what.
This problem is similar to the ones addressed by
https://issues.apache.org/jira/browse/CASSANDRA-8652 and
https://issues.apache.org/jira/browse/CASSANDRA-7566, so those issues provide
any further context.
I am attaching a patch to this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-8693) QueryProcessor never removes internal statements from its cache
[
https://issues.apache.org/jira/browse/CASSANDRA-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro reassigned CASSANDRA-8693:
-
Assignee: Edward Ribeiro
QueryProcessor never removes internal statements from its cache
---
Key: CASSANDRA-8693
URL: https://issues.apache.org/jira/browse/CASSANDRA-8693
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro
Labels: cql3
Fix For: 2.1.2
Attachments: qp-internal.patch
QueryProcessor holds a reference to {{internalStatements}}, a map for
prepared statements used internally.
Those commands don't mix with the ones created by the user, but the problem
is that if a KS/CF is dropped and then recreated {{internalStatements}}
entries will point to invalid PreparedStatements (old cf_id) so any operation
on those statements will fail therefore. In fact, as of today, this map is
never actually cleaned no matter what.
This problem is similar to the ones addressed by
https://issues.apache.org/jira/browse/CASSANDRA-8652 and
https://issues.apache.org/jira/browse/CASSANDRA-7566, so those issues provide
any further context.
I am attaching a patch to this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8693) QueryProcessor.executeInternal(statement) never evictes statements from internal cache
[
https://issues.apache.org/jira/browse/CASSANDRA-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-8693:
--
Summary: QueryProcessor.executeInternal(statement) never evictes statements
from internal cache (was: QueryProcessor.executeInternal(statement) are never
evicted from internal cache)
QueryProcessor.executeInternal(statement) never evictes statements from
internal cache
--
Key: CASSANDRA-8693
URL: https://issues.apache.org/jira/browse/CASSANDRA-8693
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Edward Ribeiro
Labels: cql3
Fix For: 2.1.2
Attachments: qp-internal.patch
QueryProcessor holds a reference to {{internalStatements}}, a map for
prepared statements used internally.
Those commands don't mix with the ones created by the user, but the problem
is that if a KS/CF is dropped and then recreated {{internalStatements}}
entries will point to invalid PreparedStatements (old cf_id) so any operation
on those statements will fail therefore. In fact, as of today, this map is
never actually cleaned no matter what.
This problem is similar to the ones addressed by
https://issues.apache.org/jira/browse/CASSANDRA-8652 and
https://issues.apache.org/jira/browse/CASSANDRA-7566, so those issues provide
any further context.
I am attaching a patch to this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8693) QueryProcessor.executeInternal(statement) are never evicted from internal cache
Edward Ribeiro created CASSANDRA-8693:
-
Summary: QueryProcessor.executeInternal(statement) are never
evicted from internal cache
Key: CASSANDRA-8693
URL: https://issues.apache.org/jira/browse/CASSANDRA-8693
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Edward Ribeiro
Fix For: 2.1.2
Attachments: qp-internal.patch
QueryProcessor holds a reference to {{internalStatements}}, a map for prepared
statements used internally.
Those commands don't mix with the ones created by the user, but the problem is
that if a KS/CF is dropped and then recreated {{internalStatements}} entries
will point to invalid PreparedStatements (old cf_id) so any operation on those
statements will fail therefore. In fact, as of today, this map is never
actually cleaned no matter what.
This problem is similar to the ones addressed by
https://issues.apache.org/jira/browse/CASSANDRA-8652 and
https://issues.apache.org/jira/browse/CASSANDRA-7566, so those issues provide
any further context.
I am attaching a patch to this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8652) DROP TABLE should also drop BATCH prepared statements associated to it
[
https://issues.apache.org/jira/browse/CASSANDRA-8652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14285717#comment-14285717
]
Edward Ribeiro commented on CASSANDRA-8652:
---
Thank you [~thobbs] and [~deckerego]! :)
DROP TABLE should also drop BATCH prepared statements associated to it
--
Key: CASSANDRA-8652
URL: https://issues.apache.org/jira/browse/CASSANDRA-8652
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro
Labels: cql3
Fix For: 2.1.3
Attachments: batch-exception.patch
When a Keyspace or Column Family is dropped, Cassandra should evict the
cached prepared statements that reference that keyspace and/or table as
partially solved by the issue
https://issues.apache.org/jira/browse/CASSANDRA-7566.
Unfortunately, when it's a BATCH prepared statement it is not being evicted
from the cache. Executing the BATCH statement after a drop of KS/CF, and
subsequent recreation of KS/CF with same name, should NOT retrieve them from
cache, or else the batch prepared statements will throw an error like
{{java.lang.IllegalArgumentException: Unknown CF
fd47fd00-a0d1-11e4-8be2-75ac7e9e28a5}} because the statements inside the
batch statement still hold a reference to the old (pre-dropping) cf_id.
The attached patch solves this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8652) DROP TABLE should also drop BATCH prepared statements associated to
[
https://issues.apache.org/jira/browse/CASSANDRA-8652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-8652:
--
Reproduced In: 2.1.2
Since Version: 2.1.1
Description:
When a Keyspace or Column Family is dropped, Cassandra should evict the cached
prepared statements that reference that keyspace and/or table as partially
solved by the issue https://issues.apache.org/jira/browse/CASSANDRA-7566.
Unfortunately, when it's a BATCH prepared statement it is not being evicted
from the cache. Executing the BATCH statement after a drop of KS/CF, and
subsequent recreation of KS/CF with same name, should NOT retrieve them from
cache, or else the batch prepared statements will throw an error like
{{java.lang.IllegalArgumentException: Unknown CF
fd47fd00-a0d1-11e4-8be2-75ac7e9e28a5}} because the statements inside the batch
statement still hold a reference to the old (pre-dropping) cf_id.
The attached patch solves this issue.
was:
When a Keyspace or Column Family is dropped, Cassandra should evict the cached
prepared statements that reference that keyspace and/or table as partially
solved by the issue https://issues.apache.org/jira/browse/CASSANDRA-7566.
Unfortunately, when it's a BATCH prepared statement it is not being evicted
from the cache. Executing the BATCH statement after a drop of KS/CF, and
subsequent recreation of KS/CF with same name, should NOT retrieve them from
cache, or else the batch prepared statements will throw an error like
{{java.lang.IllegalArgumentException: Unknown CF
fd47fd00-a0d1-11e4-8be2-75ac7e9e28a5}} because the statements inside the batch
statement still hold a reference to the old (pre-dropping) cf_id.
The attached patch solves this issue.
DROP TABLE should also drop BATCH prepared statements associated to
---
Key: CASSANDRA-8652
URL: https://issues.apache.org/jira/browse/CASSANDRA-8652
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro
Fix For: 2.1.2
Attachments: batch-exception.patch
When a Keyspace or Column Family is dropped, Cassandra should evict the
cached prepared statements that reference that keyspace and/or table as
partially solved by the issue
https://issues.apache.org/jira/browse/CASSANDRA-7566.
Unfortunately, when it's a BATCH prepared statement it is not being evicted
from the cache. Executing the BATCH statement after a drop of KS/CF, and
subsequent recreation of KS/CF with same name, should NOT retrieve them from
cache, or else the batch prepared statements will throw an error like
{{java.lang.IllegalArgumentException: Unknown CF
fd47fd00-a0d1-11e4-8be2-75ac7e9e28a5}} because the statements inside the
batch statement still hold a reference to the old (pre-dropping) cf_id.
The attached patch solves this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8652) DROP TABLE should also drop BATCH prepared statements associated to
Edward Ribeiro created CASSANDRA-8652:
-
Summary: DROP TABLE should also drop BATCH prepared statements
associated to
Key: CASSANDRA-8652
URL: https://issues.apache.org/jira/browse/CASSANDRA-8652
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro
Fix For: 2.1.2
Attachments: batch-exception.patch
When a Keyspace or Column Family is dropped, Cassandra should evict the cached
prepared statements that reference that keyspace and/or table as partially
solved by the issue https://issues.apache.org/jira/browse/CASSANDRA-7566.
Unfortunately, when it's a BATCH prepared statement it is not being evicted
from the cache. Executing the BATCH statement after a drop of KS/CF, and
subsequent recreation of KS/CF with same name, should NOT retrieve them from
cache, or else the batch prepared statements will throw an error like
{{java.lang.IllegalArgumentException: Unknown CF
fd47fd00-a0d1-11e4-8be2-75ac7e9e28a5}} because the statements inside the batch
statement still hold a reference to the old (pre-dropping) cf_id.
The attached patch solves this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8652) DROP TABLE should also drop BATCH prepared statements associated to
[
https://issues.apache.org/jira/browse/CASSANDRA-8652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-8652:
--
Labels: cql3 (was: )
DROP TABLE should also drop BATCH prepared statements associated to
---
Key: CASSANDRA-8652
URL: https://issues.apache.org/jira/browse/CASSANDRA-8652
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro
Labels: cql3
Fix For: 2.1.2
Attachments: batch-exception.patch
When a Keyspace or Column Family is dropped, Cassandra should evict the
cached prepared statements that reference that keyspace and/or table as
partially solved by the issue
https://issues.apache.org/jira/browse/CASSANDRA-7566.
Unfortunately, when it's a BATCH prepared statement it is not being evicted
from the cache. Executing the BATCH statement after a drop of KS/CF, and
subsequent recreation of KS/CF with same name, should NOT retrieve them from
cache, or else the batch prepared statements will throw an error like
{{java.lang.IllegalArgumentException: Unknown CF
fd47fd00-a0d1-11e4-8be2-75ac7e9e28a5}} because the statements inside the
batch statement still hold a reference to the old (pre-dropping) cf_id.
The attached patch solves this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8652) DROP TABLE should also drop BATCH prepared statements associated to it
[
https://issues.apache.org/jira/browse/CASSANDRA-8652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-8652:
--
Summary: DROP TABLE should also drop BATCH prepared statements associated
to it (was: DROP TABLE should also drop BATCH prepared statements associated
to)
DROP TABLE should also drop BATCH prepared statements associated to it
--
Key: CASSANDRA-8652
URL: https://issues.apache.org/jira/browse/CASSANDRA-8652
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro
Labels: cql3
Fix For: 2.1.2
Attachments: batch-exception.patch
When a Keyspace or Column Family is dropped, Cassandra should evict the
cached prepared statements that reference that keyspace and/or table as
partially solved by the issue
https://issues.apache.org/jira/browse/CASSANDRA-7566.
Unfortunately, when it's a BATCH prepared statement it is not being evicted
from the cache. Executing the BATCH statement after a drop of KS/CF, and
subsequent recreation of KS/CF with same name, should NOT retrieve them from
cache, or else the batch prepared statements will throw an error like
{{java.lang.IllegalArgumentException: Unknown CF
fd47fd00-a0d1-11e4-8be2-75ac7e9e28a5}} because the statements inside the
batch statement still hold a reference to the old (pre-dropping) cf_id.
The attached patch solves this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] Commented: (CASSANDRA-1684) Entity groups
[ https://issues.apache.org/jira/browse/CASSANDRA-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12982203#action_12982203 ] Edward Ribeiro commented on CASSANDRA-1684: --- CIDR 2011 Megastore paper: http://www.cidrdb.org/cidr2011/Papers/CIDR11_Paper32.pdf Any development already started on this issue? Entity groups - Key: CASSANDRA-1684 URL: https://issues.apache.org/jira/browse/CASSANDRA-1684 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Fix For: 0.8 Original Estimate: 80h Remaining Estimate: 80h Supporting entity groups similar to App Engine's (that is, allow rows to be part of a parent entity group, whose key is used for routing instead of the row itself) allows several improvements: - batches within an EG can be atomic across multiple rows - order-by-value queries within an EG only have to touch a single replica even with RandomPartitioner -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1016) Plugins
[ https://issues.apache.org/jira/browse/CASSANDRA-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12884327#action_12884327 ] Edward Ribeiro commented on CASSANDRA-1016: --- Jeff, What about using a CopyOnWriteArrayListWriteCallback instead of using a ArrayList? If the writeCallbacks list is read heavy then CopyOnWriteArrayList is better because 1) you can an concurrent list cheaply and 2) you avoid ConcurrentModificationException being ever thrown. Regards, Ed Plugins --- Key: CASSANDRA-1016 URL: https://issues.apache.org/jira/browse/CASSANDRA-1016 Project: Cassandra Issue Type: New Feature Affects Versions: 0.6.1 Reporter: Ryan King Assignee: Jeff Hodges Attachments: CASSANDRA-1016-2.patch, CASSANDRA-1016.patch As discussed at the Digg-hosted hackathon. First off, this needs a better name, the idea isn't exactly like coprocessors from BigTable and this entry should be considered a stub for now (Stu and Marius should be able to provide more details). The idea is that for mutation operations, we should all the user to run a routine that has access to the old version of the data and the new version, and can take action. At a bare minimum, this should be capable of implementing distributed secondary indexes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
