[jira] [Commented] (CASSANDRA-12179) Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop
[
https://issues.apache.org/jira/browse/CASSANDRA-12179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15401148#comment-15401148
]
Robert Stupp commented on CASSANDRA-12179:
--
Forgot to mention: Generally this would have to go into trunk since it
introduces a new feature. But on the other side this would fix {{updateSnitch}}
- not sure on this one. Comments from others appreciated.
> Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop
> ---
>
> Key: CASSANDRA-12179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12179
> Project: Cassandra
> Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Trivial
> Fix For: 3.0.x
>
> Attachments: CASSANDRA-12179-3.0_v2.txt, CASSANDRA-12179_3.0.txt,
> CASSANDRA-12179_3.0_v3.txt
>
>
> Need to expose dynamic_snitch_update_interval_in_ms so that it does not
> require a bounce. This is useful for large clusters where we can change this
> value and see the impact.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12179) Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop
[
https://issues.apache.org/jira/browse/CASSANDRA-12179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15401141#comment-15401141
]
Robert Stupp commented on CASSANDRA-12179:
--
Some more comments:
* The {{if}} condition
[here|https://github.com/apache/cassandra/commit/251c8d7499453452604fad1f577450fc979217e3#diff-b76a607445d53f18a98c9df14323c7ddR4245]
is always wrong.
* The logic in {{StorageService.updateSnitch}} would effectively remove the
{{DynamicEndpointSnitch}} mbean since it first instantiates a new dynamic
snitch instance and then unregisters the mbean from the old one (not sure if
that wouldn't cause an exception anyway).
* In c.yaml it is possible to pass in the "abbreviated"/short snitch class
name, but {{updateSnitch}} always expects the full class name. (Not introduced
by this patch)
* The methods {{changeDynamicResetIntervalInMs}} + {{changeBadnessThreshold}} +
{{changeDynamicUpdateIntervalInMs}} can be merged into a single method.
* The logic to restart the tasks in {{DynamicEndpointSnicht}} is fine.
I took the freedom to update the patch in [this
commit|https://github.com/apache/cassandra/commit/feb38d92d5e4bf0176d68c409478c7a21e1f9bf7]
to address the above points and also:
* update the javadoc on the {{updateSnitch}} method
* reuse the {{DatabaseDescriptor.createEndpointSnitch}} method (and change it a
bit) to allow short snitch class names
* merge the change* methods into a single {{applyConfigChanges}} method
* merge {{close}} and {{unregisterMBean}} methods
* fix the {{updateSnitch}} unregister-bbean logic and also refactor it to just
cover the two cases when the snitch is changed and when it is not changed.
WDYT?
(Triggered new CI runs)
> Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop
> ---
>
> Key: CASSANDRA-12179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12179
> Project: Cassandra
> Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Trivial
> Fix For: 3.0.x
>
> Attachments: CASSANDRA-12179-3.0_v2.txt, CASSANDRA-12179_3.0.txt,
> CASSANDRA-12179_3.0_v3.txt
>
>
> Need to expose dynamic_snitch_update_interval_in_ms so that it does not
> require a bounce. This is useful for large clusters where we can change this
> value and see the impact.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12181) Include table name in "Cannot get comparator" exception
[ https://issues.apache.org/jira/browse/CASSANDRA-12181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-12181: - Resolution: Fixed Status: Resolved (was: Patch Available) +1 Committed as [1823c84b827ff5f38862757db58001105f1d753f|https://github.com/apache/cassandra/commit/1823c84b827ff5f38862757db58001105f1d753f] to [cassandra-3.0|https://github.com/apache/cassandra/tree/cassandra-3.0] and merged to 3.9 and trunk. > Include table name in "Cannot get comparator" exception > --- > > Key: CASSANDRA-12181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12181 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: sankalp kohli >Priority: Trivial > Attachments: CASSANDRA-12181-3.0_v2.txt, CASSANDRA-12181_3.0-v3.txt, > CASSANDRA-12181_3.0.txt > > > Having table name will help in debugging the following exception. > ERROR [MutationStage:xx] CassandraDaemon.java (line 199) Exception in thread > Thread[MutationStage:3788,5,main] > clusterName=itms8shared20 > java.lang.RuntimeException: Cannot get comparator 2 in > org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type). > > This might be due to a mismatch between the schema and the data read -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12343) Make 'static final boolean' easier to optimize for Hotspot
[
https://issues.apache.org/jira/browse/CASSANDRA-12343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-12343:
-
Status: Patch Available (was: Open)
> Make 'static final boolean' easier to optimize for Hotspot
> --
>
> Key: CASSANDRA-12343
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12343
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Trivial
> Fix For: 3.x
>
>
> Hotspot is able to optimize condition checks on `static final` fields. But
> the compiler can only optimize if the referenced "constant" is the first
> condition to check. (If I understood the optimization in Hotspot correctly.)
> I.e. the first {{if}} block can be "eliminated" whereas the second cannot:
> {code}
> class Foo {
> static final boolean CONST = /* some fragment evaluating to false */;
>
> public void doSomeStuff(boolean param) {
> if (!CONST) {
> // this code block can be eliminated
> }
> if (!CONST && param) {
> // this code block can be eliminated
> }
> if (param && !CONST) {
> // this code block cannot be eliminated due to some compiler logic
> }
>
> }
> }
> {code}
> Linked patch changes the order in some {{if}} statements and migrates a few
> methods to static final fields.
> ||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:boolean-hotspot]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-boolean-hotspot-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-boolean-hotspot-dtest/lastSuccessfulBuild/]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12342) CLibrary improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-12342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-12342:
-
Status: Patch Available (was: Open)
> CLibrary improvements
> -
>
> Key: CASSANDRA-12342
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12342
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> {{CLibrary}} uses {{FBUtilities.getProtectedField}} for each invocation of
> {{getfd}} - i.e. {{Class.getDeclaredField}} + {{Field.setAccessible}}. Linked
> patch migrates these {{Field}} references to static class fields + adds
> constants for the OS. Also adds a tiny optimization for non-linux OSs in
> {{trySync}}.
> ||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:CLibrary-opts]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-CLibrary-opts-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-CLibrary-opts-dtest/lastSuccessfulBuild/]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9054) Break DatabaseDescriptor up into multiple classes.
[ https://issues.apache.org/jira/browse/CASSANDRA-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15399828#comment-15399828 ] Robert Stupp commented on CASSANDRA-9054: - Alright - pushed a couple of commits to the branch to address the review comments and also fix some things. utests + dtests look good now. Latest dtest run has 0 errors an utest a couple of timeouts (triggered another run). Worked in all the review comments. Just removed the weird comments in Config + DD. The intention of these comments was to hint contributors to be careful to not introduce new "magic" class dependencies that startup "everything" by accessing DD. > Break DatabaseDescriptor up into multiple classes. > -- > > Key: CASSANDRA-9054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9054 > Project: Cassandra > Issue Type: Improvement >Reporter: Jeremiah Jordan >Assignee: Robert Stupp > Fix For: 3.x > > > Right now to get at Config stuff you go through DatabaseDescriptor. But when > you instantiate DatabaseDescriptor it actually opens system tables and such, > which triggers commit log replays, and other things if the right flags aren't > set ahead of time. This makes getting at config stuff from tools annoying, > as you have to be very careful about instantiation orders. > It would be nice if we could break DatabaseDescriptor up into multiple > classes, so that getting at config stuff from tools wasn't such a pain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12343) Make 'static final boolean' easier to optimize for Hotspot
Robert Stupp created CASSANDRA-12343:
Summary: Make 'static final boolean' easier to optimize for Hotspot
Key: CASSANDRA-12343
URL: https://issues.apache.org/jira/browse/CASSANDRA-12343
Project: Cassandra
Issue Type: Improvement
Reporter: Robert Stupp
Assignee: Robert Stupp
Priority: Trivial
Fix For: 3.x
Hotspot is able to optimize condition checks on `static final` fields. But the
compiler can only optimize if the referenced "constant" is the first condition
to check. (If I understood the optimization in Hotspot correctly.)
I.e. the first {{if}} block can be "eliminated" whereas the second cannot:
{code}
class Foo {
static final boolean CONST = /* some fragment evaluating to false */;
public void doSomeStuff(boolean param) {
if (!CONST) {
// this code block can be eliminated
}
if (!CONST && param) {
// this code block can be eliminated
}
if (param && !CONST) {
// this code block cannot be eliminated due to some compiler logic
}
}
}
{code}
Linked patch changes the order in some {{if}} statements and migrates a few
methods to static final fields.
||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:boolean-hotspot]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-boolean-hotspot-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-boolean-hotspot-dtest/lastSuccessfulBuild/]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12342) CLibrary improvements
Robert Stupp created CASSANDRA-12342:
Summary: CLibrary improvements
Key: CASSANDRA-12342
URL: https://issues.apache.org/jira/browse/CASSANDRA-12342
Project: Cassandra
Issue Type: Improvement
Reporter: Robert Stupp
Assignee: Robert Stupp
Priority: Minor
Fix For: 3.x
{{CLibrary}} uses {{FBUtilities.getProtectedField}} for each invocation of
{{getfd}} - i.e. {{Class.getDeclaredField}} + {{Field.setAccessible}}. Linked
patch migrates these {{Field}} references to static class fields + adds
constants for the OS. Also adds a tiny optimization for non-linux OSs in
{{trySync}}.
||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:CLibrary-opts]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-CLibrary-opts-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-CLibrary-opts-dtest/lastSuccessfulBuild/]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7021) With tracing enabled, queries should still be recorded when using prepared and batch statements
[ https://issues.apache.org/jira/browse/CASSANDRA-7021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15395987#comment-15395987 ] Robert Stupp commented on CASSANDRA-7021: - Yes, CASSANDRA-11425 added the CQL text and CASSANDRA-11719 added the bind variables to trace. This works at least for prepared statements. Need to check whether it works for prepared batch statements, too. (It should, but did not test it yet.) > With tracing enabled, queries should still be recorded when using prepared > and batch statements > --- > > Key: CASSANDRA-7021 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7021 > Project: Cassandra > Issue Type: Improvement > Environment: C* 2.0.6 running on Ubuntu 12.04 >Reporter: Bill Joyce >Priority: Minor > Fix For: 2.1.x > > > I've enabled tracing on my cluster and am analyzing data in the > system_traces.sessions table. Single statement, non-prepared queries show up > with data in the 'parameters' field like 'query=select * from tablename where > x=1' and the request field is execute_cql3_query. But batches have null in > the parameters field and prepared statements just have 'page size=5000' in > the parameters field (the request field values are 'Execute batch of CQL3 > queries' and 'Execute CQL3 prepared query'). Please include the actual query > text with prepared and batch statements. This will make performance analysis > much easier so I can do things like sort by duration and find my most > expensive queries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12133) Failed to load Java8 implementation ohc-core-j8
[
https://issues.apache.org/jira/browse/CASSANDRA-12133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15390686#comment-15390686
]
Robert Stupp commented on CASSANDRA-12133:
--
Yup, rebased + scheduled CI again. Looks fine now.
> Failed to load Java8 implementation ohc-core-j8
> ---
>
> Key: CASSANDRA-12133
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12133
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04, Java 1.8.0_91
>Reporter: Mike
>Assignee: Robert Stupp
>Priority: Trivial
> Fix For: 3.0.x
>
>
> After enabling row cache in cassandra.yaml by setting row_cache_size_in_mb, I
> receive this warning in system.log during startup:
> {noformat}
> WARN [main] 2016-07-05 13:36:14,671 Uns.java:169 - Failed to load Java8
> implementation ohc-core-j8 : java.lang.NoSuchMethodException:
> org.caffinitas.ohc.linked.UnsExt8.(java.lang.Class)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12179) Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop
[ https://issues.apache.org/jira/browse/CASSANDRA-12179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387196#comment-15387196 ] Robert Stupp edited comment on CASSANDRA-12179 at 7/21/16 5:30 AM: --- CI results: ||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:12179-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12179-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12179-trunk-dtest/lastSuccessfulBuild/] ||cassandra-3.0|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...snazy:12179-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12179-3.0-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12179-3.0-dtest/lastSuccessfulBuild/] was (Author: snazy): CI results: ||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:12179-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12179-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12179-trunk-dtest/lastSuccessfulBuild/] ||cassandra-3.0|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...snazy:cassandra-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-cassandra-3.0-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-cassandra-3.0-dtest/lastSuccessfulBuild/] > Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop > --- > > Key: CASSANDRA-12179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12179 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: sankalp kohli >Priority: Trivial > Fix For: 3.0.x > > Attachments: CASSANDRA-12179-3.0_v2.txt, CASSANDRA-12179_3.0.txt, > CASSANDRA-12179_3.0_v3.txt > > > Need to expose dynamic_snitch_update_interval_in_ms so that it does not > require a bounce. This is useful for large clusters where we can change this > value and see the impact. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12179) Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop
[ https://issues.apache.org/jira/browse/CASSANDRA-12179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387196#comment-15387196 ] Robert Stupp edited comment on CASSANDRA-12179 at 7/21/16 5:30 AM: --- CI results: ||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:12179-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12179-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12179-trunk-dtest/lastSuccessfulBuild/] ||cassandra-3.0|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...snazy:cassandra-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-cassandra-3.0-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-cassandra-3.0-dtest/lastSuccessfulBuild/] was (Author: snazy): CI results: ||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:9054-split-dd-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-9054-split-dd-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-9054-split-dd-trunk-dtest/lastSuccessfulBuild/] ||cassandra-3.0|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...snazy:cassandra-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-cassandra-3.0-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-cassandra-3.0-dtest/lastSuccessfulBuild/] > Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop > --- > > Key: CASSANDRA-12179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12179 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: sankalp kohli >Priority: Trivial > Fix For: 3.0.x > > Attachments: CASSANDRA-12179-3.0_v2.txt, CASSANDRA-12179_3.0.txt, > CASSANDRA-12179_3.0_v3.txt > > > Need to expose dynamic_snitch_update_interval_in_ms so that it does not > require a bounce. This is useful for large clusters where we can change this > value and see the impact. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12179) Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop
[ https://issues.apache.org/jira/browse/CASSANDRA-12179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387196#comment-15387196 ] Robert Stupp commented on CASSANDRA-12179: -- CI results: ||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:9054-split-dd-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-9054-split-dd-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-9054-split-dd-trunk-dtest/lastSuccessfulBuild/] ||cassandra-3.0|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...snazy:cassandra-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-cassandra-3.0-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-cassandra-3.0-dtest/lastSuccessfulBuild/] > Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop > --- > > Key: CASSANDRA-12179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12179 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: sankalp kohli >Priority: Trivial > Fix For: 3.0.x > > Attachments: CASSANDRA-12179-3.0_v2.txt, CASSANDRA-12179_3.0.txt, > CASSANDRA-12179_3.0_v3.txt > > > Need to expose dynamic_snitch_update_interval_in_ms so that it does not > require a bounce. This is useful for large clusters where we can change this > value and see the impact. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12179) Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop
[ https://issues.apache.org/jira/browse/CASSANDRA-12179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15385183#comment-15385183 ] Robert Stupp commented on CASSANDRA-12179: -- Looks good so far. Let me play with that a bit. > Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop > --- > > Key: CASSANDRA-12179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12179 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: sankalp kohli >Priority: Trivial > Fix For: 3.0.x > > Attachments: CASSANDRA-12179-3.0_v2.txt, CASSANDRA-12179_3.0.txt, > CASSANDRA-12179_3.0_v3.txt > > > Need to expose dynamic_snitch_update_interval_in_ms so that it does not > require a bounce. This is useful for large clusters where we can change this > value and see the impact. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9054) Break DatabaseDescriptor up into multiple classes.
[
https://issues.apache.org/jira/browse/CASSANDRA-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15383365#comment-15383365
]
Robert Stupp commented on CASSANDRA-9054:
-
After I've made DD a "non active initializer", it felt too heavy to also break
DD into multiple classes. On the one hand, there's DD but on the other there's
{{Config}} - and both are highly related. I think a better approach would be to
move stuff from DD into the appropriate services - but that's an even more
intrusive patch. And I don't know whether it's worth to do that. What we want
to tackle is that accessing DD doesn't "magically" initialize everything in a
more or less "unexpected" order (CASSANDRA-8616, CASSANDRA-9555).
Beside that, I guess, the patch needs a proper rebase.
> Break DatabaseDescriptor up into multiple classes.
> --
>
> Key: CASSANDRA-9054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9054
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Jeremiah Jordan
>Assignee: Robert Stupp
> Fix For: 3.x
>
>
> Right now to get at Config stuff you go through DatabaseDescriptor. But when
> you instantiate DatabaseDescriptor it actually opens system tables and such,
> which triggers commit log replays, and other things if the right flags aren't
> set ahead of time. This makes getting at config stuff from tools annoying,
> as you have to be very careful about instantiation orders.
> It would be nice if we could break DatabaseDescriptor up into multiple
> classes, so that getting at config stuff from tools wasn't such a pain.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12179) Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop
[
https://issues.apache.org/jira/browse/CASSANDRA-12179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15382033#comment-15382033
]
Robert Stupp commented on CASSANDRA-12179:
--
I think the instanceof check is fine - just realised that
{{StorageService.updateSnitch}} exists and does it in a similar but broken way.
* {{updateSnitch}} instantiates a new instance of the snitch but it doesn't
cleanup the old instance properly - i.e. the scheduled tasks for update + reset
of the {{DynamicEndpointSnitch}} keep running forever. Probably worth to rename
{{DynamicEndpointSnitch.unregisterMBean}} to {{tearDown()}} and have it stop
the scheduled tasks.
* The implementation of {{updateSnitch}} wouldn't apply changes to the
parameters for {{DynamicEndpointSnitch}}, because it first instantiates the
snitch and then updates the configs via {{DatabaseDescriptor.set...}}} - but
{{DynamicEndpointSnitch}} reads these values during initialization (so before
the changes are applied).
* There are also a couple of {{null}} checks missing in {{updateSnitch}}.
* Beside that, {{StorageService.updateSnitch()}} also updates the {{snitch}}
field in all instances of {{AbstractReplicationStrategy}} - this might lead to
a race condition in case a keyspace's concurrently created. Unrelated to this
ticket, but I do not see the maybe obvious reason why
{{AbstractReplicationStrategy}} has a field {{snitch}} and does not use the
global setting.
* {{changeDynamicUpdateIntervalInMs}} changes the interval of the update task
but it doesn't change {{UPDATE_INTERVAL_IN_MS}} - this should become a
modifiable instance variable called {{updateIntervalInMs}}.
Sorry for coming up with that this late, but {{updateSnitch}} feels very
related to {{setDynamicUpdateInterval}}. I'd also be fine to let
{{setDynamicUpdateInterval(int dynamicUpdateInterval}} call
{{updateSnitch(null, null, dynamicUpdateInterval, null, null)}} and let
{{updateSnitch}} handle the actual changes.
WDYT?
> Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop
> ---
>
> Key: CASSANDRA-12179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12179
> Project: Cassandra
> Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Trivial
> Fix For: 3.0.x
>
> Attachments: CASSANDRA-12179-3.0_v2.txt, CASSANDRA-12179_3.0.txt
>
>
> Need to expose dynamic_snitch_update_interval_in_ms so that it does not
> require a bounce. This is useful for large clusters where we can change this
> value and see the impact.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12220) utest RowIndexEntryTest.testC11206AgainstPreviousArray/Shallow failure
Robert Stupp created CASSANDRA-12220:
Summary: utest
RowIndexEntryTest.testC11206AgainstPreviousArray/Shallow failure
Key: CASSANDRA-12220
URL: https://issues.apache.org/jira/browse/CASSANDRA-12220
Project: Cassandra
Issue Type: Bug
Reporter: Robert Stupp
The unit tests {{RowIndexEntryTest.testC11206AgainstPreviousArray}} and
{{RowIndexEntryTest.testC11206AgainstPreviousShallow}} fail after [this single
line
change|https://github.com/apache/cassandra/commit/70fd80ae43f3902e651c956b6d4d07cbc203d30a#diff-75146ba408a51071a0b19ffdfbb2bb3cL307]
as shown in [this
build|http://cassci.datastax.com/view/trunk/job/trunk_testall/1044/].
Reverting that line to {{new HashMap<>()}} fixes the unit test issues - but
_does not_ explain why it fails, since initializing a collection with the
expected size should not change the overall behaviour. There seems to be
something else being wrong.
/cc [~dbrosius]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12181) Include table name in "Cannot get comparator" exception
[ https://issues.apache.org/jira/browse/CASSANDRA-12181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15381593#comment-15381593 ] Robert Stupp commented on CASSANDRA-12181: -- Alright - kicked off CI for 3.0 + trunk: ||cassandra-3.0|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...snazy:12181-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12181-3.0-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12181-3.0-dtest/lastSuccessfulBuild/] ||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:12181-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12181-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12181-trunk-dtest/lastSuccessfulBuild/] > Include table name in "Cannot get comparator" exception > --- > > Key: CASSANDRA-12181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12181 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: sankalp kohli >Priority: Trivial > Attachments: CASSANDRA-12181-3.0_v2.txt, CASSANDRA-12181_3.0.txt > > > Having table name will help in debugging the following exception. > ERROR [MutationStage:xx] CassandraDaemon.java (line 199) Exception in thread > Thread[MutationStage:3788,5,main] > clusterName=itms8shared20 > java.lang.RuntimeException: Cannot get comparator 2 in > org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type). > > This might be due to a mismatch between the schema and the data read -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9608) Support Java 9
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15380816#comment-15380816
]
Robert Stupp commented on CASSANDRA-9608:
-
Updated the branch so far with patched versions of jamm and ohc. Seems many
more utests work now.
The [commit for
jamm|https://github.com/snazy/jamm/commit/c81473ebf3cf41bcc5e7ebfeb3559bc88249a486]
feels quite hacky - so I think that needs some refurbishing.
The [commit for
ohc|https://github.com/snazy/ohc/commit/33889bba38cdc8089be37a007d30646c9771ad6c]
just adds support to parse Java 9 EA version numbers.
UDFs (both Java + JavaScript) don't work yet - all unit tests using UDFs fail
(did not investigate yet).
Some cipher tests and an mmap test fail, too. Some utests still fail with
abnormal JVM exit (probably a missing jigsaw module).
> Support Java 9
> --
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Priority: Minor
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12181) Include table name in "Cannot get comparator" exception
[ https://issues.apache.org/jira/browse/CASSANDRA-12181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15380625#comment-15380625 ] Robert Stupp commented on CASSANDRA-12181: -- Yes, would be great. > Include table name in "Cannot get comparator" exception > --- > > Key: CASSANDRA-12181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12181 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: sankalp kohli >Priority: Trivial > Attachments: CASSANDRA-12181_3.0.txt > > > Having table name will help in debugging the following exception. > ERROR [MutationStage:xx] CassandraDaemon.java (line 199) Exception in thread > Thread[MutationStage:3788,5,main] > clusterName=itms8shared20 > java.lang.RuntimeException: Cannot get comparator 2 in > org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type). > > This might be due to a mismatch between the schema and the data read -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9608) Support Java 9
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15380564#comment-15380564
]
Robert Stupp commented on CASSANDRA-9608:
-
Sure, go ahead - looking forward for pull request for the branch.
> Support Java 9
> --
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Priority: Minor
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12209) Make Level compaction default
[ https://issues.apache.org/jira/browse/CASSANDRA-12209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15380561#comment-15380561 ] Robert Stupp commented on CASSANDRA-12209: -- >From my experience, many people do not know about the implications (or >requirements) of LCS. Many users initially do _not_ know about how their data >model will look like, what amount of data is ingested and how it is ingested. >As [~brandon.williams] said, STCS is a not super-clever but it works - an it's >used in other compaction strategies as well. I mean, it's not a big deal to >configure the CS in a CREATE TABLE statement. TL;DR I'd prefer to stick with >STCS as the default. > Make Level compaction default > - > > Key: CASSANDRA-12209 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12209 > Project: Cassandra > Issue Type: Wish >Reporter: sankalp kohli >Priority: Minor > > Level Compaction has come a long way since it was added. I think it is time > to make it default. We can debate which version we can do this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12181) Include table name in "Cannot get comparator" exception
[ https://issues.apache.org/jira/browse/CASSANDRA-12181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15380530#comment-15380530 ] Robert Stupp commented on CASSANDRA-12181: -- Well, you don't. But it would add ks+cf name to every exception - not just for the special case of composite types. WDYT? > Include table name in "Cannot get comparator" exception > --- > > Key: CASSANDRA-12181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12181 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: sankalp kohli >Priority: Trivial > Attachments: CASSANDRA-12181_3.0.txt > > > Having table name will help in debugging the following exception. > ERROR [MutationStage:xx] CassandraDaemon.java (line 199) Exception in thread > Thread[MutationStage:3788,5,main] > clusterName=itms8shared20 > java.lang.RuntimeException: Cannot get comparator 2 in > org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type). > > This might be due to a mismatch between the schema and the data read -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9954) Improve Java-UDF timeout detection
[
https://issues.apache.org/jira/browse/CASSANDRA-9954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-9954:
Status: Open (was: Patch Available)
Cancelling patch for the moment - needs a thorough rebase.
> Improve Java-UDF timeout detection
> --
>
> Key: CASSANDRA-9954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9954
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Fix For: 3.x
>
>
> CASSANDRA-9402 introduced a sandbox using a thread-pool to enforce security
> constraints and to detect "amok UDFs" - i.e. UDFs that essentially never
> return (e.g. {{while (true)}}.
> Currently the safest way to react on such an "amok UDF" is to _fail-fast_ -
> to stop the C* daemon since stopping a thread (in Java) is just no solution.
> CASSANDRA-9890 introduced further protection by inspecting the byte-code. The
> same mechanism can also be used to manipulate the Java-UDF byte-code.
> By manipulating the byte-code I mean to add regular "is-amok-UDF" checks in
> the compiled code.
> EDIT: These "is-amok-UDF" checks would also work for _UNFENCED_ Java-UDFs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7384) Collect metrics on queries by consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1537#comment-1537 ] Robert Stupp commented on CASSANDRA-7384: - Also kicked off CI tests: ||cassandra-3.0|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...snazy:7384-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-7384-3.0-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-7384-3.0-dtest/lastSuccessfulBuild/] ||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:7384-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-7384-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-7384-trunk-dtest/lastSuccessfulBuild/] > Collect metrics on queries by consistency level > --- > > Key: CASSANDRA-7384 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7384 > Project: Cassandra > Issue Type: Improvement >Reporter: Vishy Kasar >Assignee: sankalp kohli >Priority: Minor > Fix For: 3.x > > Attachments: CASSANDRA-7384_3.0_v2.txt > > > We had cases where cassandra client users thought that they were doing > queries at one consistency level but turned out to be not correct. It will be > good to collect metrics on number of queries done at various consistency > level on the server. See the equivalent JIRA on java driver: > https://datastax-oss.atlassian.net/browse/JAVA-354 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-7384) Collect metrics on queries by consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15378877#comment-15378877
]
Robert Stupp edited comment on CASSANDRA-7384 at 7/15/16 5:19 AM:
--
Generally LGTM - just a one comment:
* we use {{.}} as a separator throughout the metrics. Would be nicer to use a
{{.}} instead of {{\-}} for the metric names (in the constructor initializing
the metric maps - e.g. {{new ClientRequestMetrics("Read-" + level.name())}})
If you're fine, I can fix that on commit.
was (Author: snazy):
Generally LGTM - just a one comment:
* we use {{.}} as a separator throughout the metrics. Would be nicer to use a
{{.}} instead of {{-}} for the metric names (in the constructor initializing
the metric maps - e.g. {{new ClientRequestMetrics("Read-" + level.name())}})
If you're fine, I can fix that on commit.
> Collect metrics on queries by consistency level
> ---
>
> Key: CASSANDRA-7384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7384
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Vishy Kasar
>Assignee: sankalp kohli
>Priority: Minor
> Fix For: 3.x
>
> Attachments: CASSANDRA-7384_3.0_v2.txt
>
>
> We had cases where cassandra client users thought that they were doing
> queries at one consistency level but turned out to be not correct. It will be
> good to collect metrics on number of queries done at various consistency
> level on the server. See the equivalent JIRA on java driver:
> https://datastax-oss.atlassian.net/browse/JAVA-354
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7384) Collect metrics on queries by consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7384:
Status: Open (was: Patch Available)
Generally LGTM - just a one comment:
* we use {{.}} as a separator throughout the metrics. Would be nicer to use a
{{.}} instead of {{-}} for the metric names (in the constructor initializing
the metric maps - e.g. {{new ClientRequestMetrics("Read-" + level.name())}})
If you're fine, I can fix that on commit.
> Collect metrics on queries by consistency level
> ---
>
> Key: CASSANDRA-7384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7384
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Vishy Kasar
>Assignee: sankalp kohli
>Priority: Minor
> Fix For: 3.x
>
> Attachments: CASSANDRA-7384_3.0_v2.txt
>
>
> We had cases where cassandra client users thought that they were doing
> queries at one consistency level but turned out to be not correct. It will be
> good to collect metrics on number of queries done at various consistency
> level on the server. See the equivalent JIRA on java driver:
> https://datastax-oss.atlassian.net/browse/JAVA-354
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12211) Avoid giving every command the same latency number
Robert Stupp created CASSANDRA-12211: Summary: Avoid giving every command the same latency number Key: CASSANDRA-12211 URL: https://issues.apache.org/jira/browse/CASSANDRA-12211 Project: Cassandra Issue Type: Improvement Reporter: Robert Stupp Priority: Minor While reviewing CASSANDRA-7384, I found a _TODO avoid giving every command the same latency number. Can fix this in CASSANDRA-5329_ [here|https://github.com/apache/cassandra/blob/70059726f08a98ea21af91ce3855bf62f6f4b652/src/java/org/apache/cassandra/service/StorageProxy.java#L1631] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10520) Compressed writer and reader should support non-compressed data.
[
https://issues.apache.org/jira/browse/CASSANDRA-10520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-10520:
-
Status: Open (was: Patch Available)
Just set status to "open" as we're still a few days away from 4.0. Feel free to
set to PA as soon as 4.0 is in sight.
> Compressed writer and reader should support non-compressed data.
>
>
> Key: CASSANDRA-10520
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10520
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
> Labels: messaging-service-bump-required
> Fix For: 4.x
>
>
> Compressing uncompressible data, as done, for instance, to write SSTables
> during stress-tests, results in chunks larger than 64k which are a problem
> for the buffer pooling mechanisms employed by the
> {{CompressedRandomAccessReader}}. This results in non-negligible performance
> issues due to excessive memory allocation.
> To solve this problem and avoid decompression delays in the cases where it
> does not provide benefits, I think we should allow compressed files to store
> uncompressed chunks as alternative to compressed data. Such a chunk could be
> written after compression returns a buffer larger than, for example, 90% of
> the input, and would not result in additional delays in writing. On reads it
> could be recognized by size (using a single global threshold constant in the
> compression metadata) and data could be directly transferred into the
> decompressed buffer, skipping the decompression step and ensuring a 64k
> buffer for compressed data always suffices.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12181) Include table name in "Cannot get comparator" exception
[
https://issues.apache.org/jira/browse/CASSANDRA-12181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15378818#comment-15378818
]
Robert Stupp commented on CASSANDRA-12181:
--
Would it be ok to just catch {{RuntimeException}} and wrap that one instead of
a new {{InvalidCustomTypeException}}?
So like this:
{code}
catch (RuntimeException e)
{
throw new RuntimeException(e.getMessage()
+ " This might due to a
mismatch between the schema and the data read for ksName: "
+ keyspace.getName() + ",
cfName: " + name, e);
}
{code}
> Include table name in "Cannot get comparator" exception
> ---
>
> Key: CASSANDRA-12181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12181
> Project: Cassandra
> Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Trivial
> Attachments: CASSANDRA-12181_3.0.txt
>
>
> Having table name will help in debugging the following exception.
> ERROR [MutationStage:xx] CassandraDaemon.java (line 199) Exception in thread
> Thread[MutationStage:3788,5,main]
> clusterName=itms8shared20
> java.lang.RuntimeException: Cannot get comparator 2 in
> org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type).
>
> This might be due to a mismatch between the schema and the data read
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12181) Include table name in "Cannot get comparator" exception
[ https://issues.apache.org/jira/browse/CASSANDRA-12181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-12181: - Status: Open (was: Patch Available) > Include table name in "Cannot get comparator" exception > --- > > Key: CASSANDRA-12181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12181 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: sankalp kohli >Priority: Trivial > Attachments: CASSANDRA-12181_3.0.txt > > > Having table name will help in debugging the following exception. > ERROR [MutationStage:xx] CassandraDaemon.java (line 199) Exception in thread > Thread[MutationStage:3788,5,main] > clusterName=itms8shared20 > java.lang.RuntimeException: Cannot get comparator 2 in > org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type). > > This might be due to a mismatch between the schema and the data read -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12210) Add metrics to track size of reads and writes by customer requests
[ https://issues.apache.org/jira/browse/CASSANDRA-12210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp resolved CASSANDRA-12210. -- Resolution: Duplicate > Add metrics to track size of reads and writes by customer requests > -- > > Key: CASSANDRA-12210 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12210 > Project: Cassandra > Issue Type: Improvement >Reporter: Nachiket Patil >Priority: Minor > > We have metrics to track number of customer requests but not the size of > them. These metrics help monitoring and recognizing usage patterns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12179) Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop
[ https://issues.apache.org/jira/browse/CASSANDRA-12179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-12179: - Status: Open (was: Patch Available) > Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop > --- > > Key: CASSANDRA-12179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12179 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: sankalp kohli >Priority: Trivial > Attachments: CASSANDRA-12179_3.0.txt > > > Need to expose dynamic_snitch_update_interval_in_ms so that it does not > require a bounce. This is useful for large clusters where we can change this > value and see the impact. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12179) Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop
[ https://issues.apache.org/jira/browse/CASSANDRA-12179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-12179: - Fix Version/s: 3.0.x > Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop > --- > > Key: CASSANDRA-12179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12179 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: sankalp kohli >Priority: Trivial > Fix For: 3.0.x > > Attachments: CASSANDRA-12179_3.0.txt > > > Need to expose dynamic_snitch_update_interval_in_ms so that it does not > require a bounce. This is useful for large clusters where we can change this > value and see the impact. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12179) Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop
[
https://issues.apache.org/jira/browse/CASSANDRA-12179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15376038#comment-15376038
]
Robert Stupp commented on CASSANDRA-12179:
--
Can you expose the setting via the the mbean using a getter, too?
I think it's necessary to restart the task setup in the
{{DynamicEndpointSnitch}} c'tor as it's [initialized
here|https://github.com/apache/cassandra/blob/04e7723e552459d4b96cea4b5bfbbc5773b0cd68/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java#L91].
> Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop
> ---
>
> Key: CASSANDRA-12179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12179
> Project: Cassandra
> Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Trivial
> Attachments: CASSANDRA-12179_3.0.txt
>
>
> Need to expose dynamic_snitch_update_interval_in_ms so that it does not
> require a bounce. This is useful for large clusters where we can change this
> value and see the impact.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12199) Config class uses boxed types but DD exposes primitive types
Robert Stupp created CASSANDRA-12199:
Summary: Config class uses boxed types but DD exposes primitive
types
Key: CASSANDRA-12199
URL: https://issues.apache.org/jira/browse/CASSANDRA-12199
Project: Cassandra
Issue Type: Improvement
Components: Configuration
Reporter: Robert Stupp
Priority: Minor
Fix For: 3.x
{{Config}} class contains a lot of properties that are defined using boxed
types - ({{Config.dynamic_snitch_update_interval_in_ms}}) but the corresponding
get-methods in {{DatabaseDescriptor}} require them to be not null. Means,
setting such properties to {{null}} will lead to NPEs anyway.
Proposal:
* Identify all properties that use boxed values and have a default value (e.g.
{{public Integer rpc_port = 9160;}})
* Refactor those to use primitive types
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12133) Failed to load Java8 implementation ohc-core-j8
[
https://issues.apache.org/jira/browse/CASSANDRA-12133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-12133:
-
Fix Version/s: (was: 3.x)
3.0.x
> Failed to load Java8 implementation ohc-core-j8
> ---
>
> Key: CASSANDRA-12133
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12133
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04, Java 1.8.0_91
>Reporter: Mike
>Assignee: Robert Stupp
>Priority: Trivial
> Fix For: 3.0.x
>
>
> After enabling row cache in cassandra.yaml by setting row_cache_size_in_mb, I
> receive this warning in system.log during startup:
> {noformat}
> WARN [main] 2016-07-05 13:36:14,671 Uns.java:169 - Failed to load Java8
> implementation ohc-core-j8 : java.lang.NoSuchMethodException:
> org.caffinitas.ohc.linked.UnsExt8.(java.lang.Class)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9613) Omit (de)serialization of state variable in UDAs
[ https://issues.apache.org/jira/browse/CASSANDRA-9613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-9613: Resolution: Fixed Fix Version/s: (was: 3.x) 3.10 Status: Resolved (was: Ready to Commit) Thank you! Committed as [adffb3602033273efdbb8b5303c62dbf33c36903|https://github.com/apache/cassandra/commit/adffb3602033273efdbb8b5303c62dbf33c36903] to [trunk|https://github.com/apache/cassandra/tree/trunk] > Omit (de)serialization of state variable in UDAs > > > Key: CASSANDRA-9613 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9613 > Project: Cassandra > Issue Type: Improvement >Reporter: Robert Stupp >Assignee: Robert Stupp >Priority: Minor > Fix For: 3.10 > > > Currently the result of each UDA's state function call is serialized and then > deserialized for the next state-function invocation and optionally final > function invocation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7384) Collect metrics on queries by consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373960#comment-15373960
]
Robert Stupp commented on CASSANDRA-7384:
-
Just looked briefly at the patch: can you make the two maps of type {{EnumMap}}
instead of CHM?
> Collect metrics on queries by consistency level
> ---
>
> Key: CASSANDRA-7384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7384
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Vishy Kasar
>Assignee: sankalp kohli
>Priority: Minor
> Fix For: 3.x
>
> Attachments: CASSANDRA-7384_3.0.txt
>
>
> We had cases where cassandra client users thought that they were doing
> queries at one consistency level but turned out to be not correct. It will be
> good to collect metrics on number of queries done at various consistency
> level on the server. See the equivalent JIRA on java driver:
> https://datastax-oss.atlassian.net/browse/JAVA-354
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9608) Support Java 9
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15372821#comment-15372821
]
Robert Stupp commented on CASSANDRA-9608:
-
[~carlosabad], thanks for your effort! I've already created [a
branch|https://github.com/snazy/cassandra/tree/9608-java9-trunk] and thought I
left a comment about it in this ticket - apologies for that. I basically found
the same issues. But I'm a bit opposed to the use of {{ReentrantLock}} since
there are usually a huge amount of {{AtomicBTreePartition}} instances and each
{{ReentrantLock}} can potentially create lot of dependent objects - tl;dr it
potentially introduces a lot of GC pressure. So, what we would need here is an
exclusive lock, which doesn't need to be fair, that is just good enough - not
sure whether [my
approach|https://github.com/snazy/cassandra/commit/c67c532fec9b2b073ecdf70b50b80440fb972f31#diff-7246e27576858f45f3f2678b9be03bfeR105]
is good enough, though.
Would be glad to have you on board and tackle this ticket!
Many of the tests fail because we evaluate the system property
{{java.vm.version}} in out agent library [jamm at this
line|https://github.com/jbellis/jamm/blob/17fe5661d3706ac8bdcc2cc1a1d747efa00157fa/src/org/github/jamm/MemoryLayoutSpecification.java#L190].
The meaning of the version has changed completely. Before Java 9, it looked
like {{25.92-b14}} but with Java 9 is looks like {{9-ea+121}} - i.e. the
agent's code throws a {{StringIndexOutOfBoundsException}}. A viable solution
(viable workaround is probably a better term, though) could be to let jamm
produce Java 8 byte code and remove the {{java.vm.version}} check and/or change
the code in jamm. We use jamm to calculate on-heap usage of objects.
We might have to support both Java 8 and Java 9 (as soon as Java 9 is GA) for
some period of time - similar to the transition from Java 7 to Java 8, where we
built C* on Java 7 but kind-of supported Java 8 before actually just C* 3.0
required Java 8. I think a major version (maybe 5.x?) would be required for
such a switch. Just want to say, that both the code and the build.xml file need
to work against Java 8 _and_ 9. (Requiring ant 1.9.7 is not an issue imo.)
> Support Java 9
> --
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Priority: Minor
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8831) Create a system table to expose prepared statements
[
https://issues.apache.org/jira/browse/CASSANDRA-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-8831:
Resolution: Fixed
Fix Version/s: (was: 3.x)
3.10
Status: Resolved (was: Patch Available)
Thanks!
Committed with addition to NEWS.txt as
[997cb663e8c8f164873515f81bb779e435aead6d|https://github.com/apache/cassandra/commit/997cb663e8c8f164873515f81bb779e435aead6d]
to [trunk|https://github.com/apache/cassandra/tree/trunk]
> Create a system table to expose prepared statements
> ---
>
> Key: CASSANDRA-8831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8831
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Robert Stupp
> Labels: client-impacting, docs-impacting
> Fix For: 3.10
>
>
> Because drivers abstract from users the handling of up/down nodes, they have
> to deal with the fact that when a node is restarted (or join), it won't know
> any prepared statement. Drivers could somewhat ignore that problem and wait
> for a query to return an error (that the statement is unknown by the node) to
> re-prepare the query on that node, but it's relatively inefficient because
> every time a node comes back up, you'll get bad latency spikes due to some
> queries first failing, then being re-prepared and then only being executed.
> So instead, drivers (at least the java driver but I believe others do as
> well) pro-actively re-prepare statements when a node comes up. It solves the
> latency problem, but currently every driver instance blindly re-prepare all
> statements, meaning that in a large cluster with many clients there is a lot
> of duplication of work (it would be enough for a single client to prepare the
> statements) and a bigger than necessary load on the node that started.
> An idea to solve this it to have a (cheap) way for clients to check if some
> statements are prepared on the node. There is different options to provide
> that but what I'd suggest is to add a system table to expose the (cached)
> prepared statements because:
> # it's reasonably straightforward to implement: we just add a line to the
> table when a statement is prepared and remove it when it's evicted (we
> already have eviction listeners). We'd also truncate the table on startup but
> that's easy enough). We can even switch it to a "virtual table" if/when
> CASSANDRA-7622 lands but it's trivial to do with a normal table in the
> meantime.
> # it doesn't require a change to the protocol or something like that. It
> could even be done in 2.1 if we wish to.
> # exposing prepared statements feels like a genuinely useful information to
> have (outside of the problem exposed here that is), if only for
> debugging/educational purposes.
> The exposed table could look something like:
> {noformat}
> CREATE TABLE system.prepared_statements (
>keyspace_name text,
>table_name text,
>prepared_id blob,
>query_string text,
>PRIMARY KEY (keyspace_name, table_name, prepared_id)
> )
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9613) Omit (de)serialization of state variable in UDAs
[ https://issues.apache.org/jira/browse/CASSANDRA-9613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-9613: Status: Patch Available (was: Awaiting Feedback) (set to PA - but there's still Tyler's first comment that might need discussion) > Omit (de)serialization of state variable in UDAs > > > Key: CASSANDRA-9613 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9613 > Project: Cassandra > Issue Type: Improvement >Reporter: Robert Stupp >Assignee: Robert Stupp >Priority: Minor > Fix For: 3.x > > > Currently the result of each UDA's state function call is serialized and then > deserialized for the next state-function invocation and optionally final > function invocation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8831) Create a system table to expose prepared statements
[
https://issues.apache.org/jira/browse/CASSANDRA-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-8831:
Status: Patch Available (was: Open)
> Create a system table to expose prepared statements
> ---
>
> Key: CASSANDRA-8831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8831
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Robert Stupp
> Labels: client-impacting, docs-impacting
> Fix For: 3.x
>
>
> Because drivers abstract from users the handling of up/down nodes, they have
> to deal with the fact that when a node is restarted (or join), it won't know
> any prepared statement. Drivers could somewhat ignore that problem and wait
> for a query to return an error (that the statement is unknown by the node) to
> re-prepare the query on that node, but it's relatively inefficient because
> every time a node comes back up, you'll get bad latency spikes due to some
> queries first failing, then being re-prepared and then only being executed.
> So instead, drivers (at least the java driver but I believe others do as
> well) pro-actively re-prepare statements when a node comes up. It solves the
> latency problem, but currently every driver instance blindly re-prepare all
> statements, meaning that in a large cluster with many clients there is a lot
> of duplication of work (it would be enough for a single client to prepare the
> statements) and a bigger than necessary load on the node that started.
> An idea to solve this it to have a (cheap) way for clients to check if some
> statements are prepared on the node. There is different options to provide
> that but what I'd suggest is to add a system table to expose the (cached)
> prepared statements because:
> # it's reasonably straightforward to implement: we just add a line to the
> table when a statement is prepared and remove it when it's evicted (we
> already have eviction listeners). We'd also truncate the table on startup but
> that's easy enough). We can even switch it to a "virtual table" if/when
> CASSANDRA-7622 lands but it's trivial to do with a normal table in the
> meantime.
> # it doesn't require a change to the protocol or something like that. It
> could even be done in 2.1 if we wish to.
> # exposing prepared statements feels like a genuinely useful information to
> have (outside of the problem exposed here that is), if only for
> debugging/educational purposes.
> The exposed table could look something like:
> {noformat}
> CREATE TABLE system.prepared_statements (
>keyspace_name text,
>table_name text,
>prepared_id blob,
>query_string text,
>PRIMARY KEY (keyspace_name, table_name, prepared_id)
> )
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9613) Omit (de)serialization of state variable in UDAs
[
https://issues.apache.org/jira/browse/CASSANDRA-9613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15369341#comment-15369341
]
Robert Stupp commented on CASSANDRA-9613:
-
Yes, there's no built-in function that is actually usable as a state or final
function.
The contract for all functions (built-ins and UDFs) is still to pass serialized
arguments (deserialization is part of the code in {{JavaSourceUDF.txt}} and the
respective scripted UDF impl). This patch is only an optimization for the state
variable since that is probably of a type that has a higher serialisation cost
(e.g. map, tuple, udt). But it would be a generally affordable optimization to
let built-in and especially UDFs take the non-serialized representation -
thinking of "constant" arguments to UDFs. But at the moment we don't have the
case where we pass "constant" arguments to UDFs (state functions especially).
Added comments to {{generateArguments}} and the new utest and triggered CI.
> Omit (de)serialization of state variable in UDAs
>
>
> Key: CASSANDRA-9613
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9613
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> Currently the result of each UDA's state function call is serialized and then
> deserialized for the next state-function invocation and optionally final
> function invocation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8831) Create a system table to expose prepared statements
[
https://issues.apache.org/jira/browse/CASSANDRA-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15369330#comment-15369330
]
Robert Stupp commented on CASSANDRA-8831:
-
Was an oversight. It didn't invalidate on
{{QueryProcessor.internalStatements}}. Fixed that and triggered a new CI run
(above links work).
> Create a system table to expose prepared statements
> ---
>
> Key: CASSANDRA-8831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8831
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Robert Stupp
> Labels: client-impacting, docs-impacting
> Fix For: 3.x
>
>
> Because drivers abstract from users the handling of up/down nodes, they have
> to deal with the fact that when a node is restarted (or join), it won't know
> any prepared statement. Drivers could somewhat ignore that problem and wait
> for a query to return an error (that the statement is unknown by the node) to
> re-prepare the query on that node, but it's relatively inefficient because
> every time a node comes back up, you'll get bad latency spikes due to some
> queries first failing, then being re-prepared and then only being executed.
> So instead, drivers (at least the java driver but I believe others do as
> well) pro-actively re-prepare statements when a node comes up. It solves the
> latency problem, but currently every driver instance blindly re-prepare all
> statements, meaning that in a large cluster with many clients there is a lot
> of duplication of work (it would be enough for a single client to prepare the
> statements) and a bigger than necessary load on the node that started.
> An idea to solve this it to have a (cheap) way for clients to check if some
> statements are prepared on the node. There is different options to provide
> that but what I'd suggest is to add a system table to expose the (cached)
> prepared statements because:
> # it's reasonably straightforward to implement: we just add a line to the
> table when a statement is prepared and remove it when it's evicted (we
> already have eviction listeners). We'd also truncate the table on startup but
> that's easy enough). We can even switch it to a "virtual table" if/when
> CASSANDRA-7622 lands but it's trivial to do with a normal table in the
> meantime.
> # it doesn't require a change to the protocol or something like that. It
> could even be done in 2.1 if we wish to.
> # exposing prepared statements feels like a genuinely useful information to
> have (outside of the problem exposed here that is), if only for
> debugging/educational purposes.
> The exposed table could look something like:
> {noformat}
> CREATE TABLE system.prepared_statements (
>keyspace_name text,
>table_name text,
>prepared_id blob,
>query_string text,
>PRIMARY KEY (keyspace_name, table_name, prepared_id)
> )
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12154) "SELECT * FROM foo LIMIT ;" does not error out
Robert Stupp created CASSANDRA-12154:
Summary: "SELECT * FROM foo LIMIT ;" does not error out
Key: CASSANDRA-12154
URL: https://issues.apache.org/jira/browse/CASSANDRA-12154
Project: Cassandra
Issue Type: Bug
Components: CQL
Reporter: Robert Stupp
Priority: Minor
We found out that {{SELECT * FROM foo LIMIT ;}} is unanimously accepted and
executed but it should not.
Have not dug deeper why that is possible (it's not a big issue IMO) but it is
strange. Seems it doesn't parse {{LIMIT}} as {{K_LIMIT}} because otherwise it
would require an int argument.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11970) Reuse DataOutputBuffer from ColumnIndex
[
https://issues.apache.org/jira/browse/CASSANDRA-11970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-11970:
-
Resolution: Fixed
Fix Version/s: (was: 3.x)
3.10
Status: Resolved (was: Ready to Commit)
Thanks!
Committed as
[ae4d705db38b713400292fc46ae0858fb0545fe3|https://github.com/apache/cassandra/commit/ae4d705db38b713400292fc46ae0858fb0545fe3]
to [trunk|https://github.com/apache/cassandra/tree/trunk]
> Reuse DataOutputBuffer from ColumnIndex
> ---
>
> Key: CASSANDRA-11970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11970
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.10
>
>
> With a simple change, the {{DataOutputBuffer}} used in {{ColumnIndex}} can be
> reused. This saves a couple of (larger) object allocations.
> (Will provide a patch soon)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8831) Create a system table to expose prepared statements
[
https://issues.apache.org/jira/browse/CASSANDRA-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368070#comment-15368070
]
Robert Stupp commented on CASSANDRA-8831:
-
Huh! That's strange - let me check.
> Create a system table to expose prepared statements
> ---
>
> Key: CASSANDRA-8831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8831
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Robert Stupp
> Labels: client-impacting, docs-impacting
> Fix For: 3.x
>
>
> Because drivers abstract from users the handling of up/down nodes, they have
> to deal with the fact that when a node is restarted (or join), it won't know
> any prepared statement. Drivers could somewhat ignore that problem and wait
> for a query to return an error (that the statement is unknown by the node) to
> re-prepare the query on that node, but it's relatively inefficient because
> every time a node comes back up, you'll get bad latency spikes due to some
> queries first failing, then being re-prepared and then only being executed.
> So instead, drivers (at least the java driver but I believe others do as
> well) pro-actively re-prepare statements when a node comes up. It solves the
> latency problem, but currently every driver instance blindly re-prepare all
> statements, meaning that in a large cluster with many clients there is a lot
> of duplication of work (it would be enough for a single client to prepare the
> statements) and a bigger than necessary load on the node that started.
> An idea to solve this it to have a (cheap) way for clients to check if some
> statements are prepared on the node. There is different options to provide
> that but what I'd suggest is to add a system table to expose the (cached)
> prepared statements because:
> # it's reasonably straightforward to implement: we just add a line to the
> table when a statement is prepared and remove it when it's evicted (we
> already have eviction listeners). We'd also truncate the table on startup but
> that's easy enough). We can even switch it to a "virtual table" if/when
> CASSANDRA-7622 lands but it's trivial to do with a normal table in the
> meantime.
> # it doesn't require a change to the protocol or something like that. It
> could even be done in 2.1 if we wish to.
> # exposing prepared statements feels like a genuinely useful information to
> have (outside of the problem exposed here that is), if only for
> debugging/educational purposes.
> The exposed table could look something like:
> {noformat}
> CREATE TABLE system.prepared_statements (
>keyspace_name text,
>table_name text,
>prepared_id blob,
>query_string text,
>PRIMARY KEY (keyspace_name, table_name, prepared_id)
> )
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12133) Failed to load Java8 implementation ohc-core-j8
[
https://issues.apache.org/jira/browse/CASSANDRA-12133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-12133:
-
Status: Patch Available (was: Open)
> Failed to load Java8 implementation ohc-core-j8
> ---
>
> Key: CASSANDRA-12133
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12133
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04, Java 1.8.0_91
>Reporter: Mike
>Assignee: Robert Stupp
>Priority: Trivial
> Fix For: 3.x
>
>
> After enabling row cache in cassandra.yaml by setting row_cache_size_in_mb, I
> receive this warning in system.log during startup:
> {noformat}
> WARN [main] 2016-07-05 13:36:14,671 Uns.java:169 - Failed to load Java8
> implementation ohc-core-j8 : java.lang.NoSuchMethodException:
> org.caffinitas.ohc.linked.UnsExt8.(java.lang.Class)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12062) Prevent key invalidation if there's no key to invalidate
[
https://issues.apache.org/jira/browse/CASSANDRA-12062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-12062:
-
Resolution: Fixed
Fix Version/s: (was: 3.x)
3.10
Status: Resolved (was: Ready to Commit)
Thanks!
Committed as
[c57d0d4fabb8b1c8b9b312010a706245a203be57|https://github.com/apache/cassandra/commit/c57d0d4fabb8b1c8b9b312010a706245a203be57]
to [trunk|https://github.com/apache/cassandra/tree/trunk]
> Prevent key invalidation if there's no key to invalidate
>
>
> Key: CASSANDRA-12062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12062
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.10
>
>
> In {{SSTableRewriter}} we currently assume that there are keys to be
> invalidated in the key cache. That's not always true - especially if a bunch
> of tiny sstables have been generated.
> Patch saves one {{synchronized}} and a few objects if that's the case.
> Just a small optimisation, but maybe worth to include.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8831) Create a system table to expose prepared statements
[
https://issues.apache.org/jira/browse/CASSANDRA-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-8831:
Status: Patch Available (was: Open)
Rebased the branch and addressed the review comments in a separate commit. Also
triggered new CI runs.
||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:8831-pstmts]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-8831-pstmts-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-8831-pstmts-dtest/lastSuccessfulBuild/]
> Create a system table to expose prepared statements
> ---
>
> Key: CASSANDRA-8831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8831
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Robert Stupp
> Labels: client-impacting, docs-impacting
> Fix For: 3.x
>
>
> Because drivers abstract from users the handling of up/down nodes, they have
> to deal with the fact that when a node is restarted (or join), it won't know
> any prepared statement. Drivers could somewhat ignore that problem and wait
> for a query to return an error (that the statement is unknown by the node) to
> re-prepare the query on that node, but it's relatively inefficient because
> every time a node comes back up, you'll get bad latency spikes due to some
> queries first failing, then being re-prepared and then only being executed.
> So instead, drivers (at least the java driver but I believe others do as
> well) pro-actively re-prepare statements when a node comes up. It solves the
> latency problem, but currently every driver instance blindly re-prepare all
> statements, meaning that in a large cluster with many clients there is a lot
> of duplication of work (it would be enough for a single client to prepare the
> statements) and a bigger than necessary load on the node that started.
> An idea to solve this it to have a (cheap) way for clients to check if some
> statements are prepared on the node. There is different options to provide
> that but what I'd suggest is to add a system table to expose the (cached)
> prepared statements because:
> # it's reasonably straightforward to implement: we just add a line to the
> table when a statement is prepared and remove it when it's evicted (we
> already have eviction listeners). We'd also truncate the table on startup but
> that's easy enough). We can even switch it to a "virtual table" if/when
> CASSANDRA-7622 lands but it's trivial to do with a normal table in the
> meantime.
> # it doesn't require a change to the protocol or something like that. It
> could even be done in 2.1 if we wish to.
> # exposing prepared statements feels like a genuinely useful information to
> have (outside of the problem exposed here that is), if only for
> debugging/educational purposes.
> The exposed table could look something like:
> {noformat}
> CREATE TABLE system.prepared_statements (
>keyspace_name text,
>table_name text,
>prepared_id blob,
>query_string text,
>PRIMARY KEY (keyspace_name, table_name, prepared_id)
> )
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-12133) Failed to load Java8 implementation ohc-core-j8
[
https://issues.apache.org/jira/browse/CASSANDRA-12133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp reassigned CASSANDRA-12133:
Assignee: Robert Stupp
> Failed to load Java8 implementation ohc-core-j8
> ---
>
> Key: CASSANDRA-12133
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12133
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04, Java 1.8.0_91
>Reporter: Mike
>Assignee: Robert Stupp
>Priority: Trivial
> Fix For: 3.x
>
>
> After enabling row cache in cassandra.yaml by setting row_cache_size_in_mb, I
> receive this warning in system.log during startup:
> {noformat}
> WARN [main] 2016-07-05 13:36:14,671 Uns.java:169 - Failed to load Java8
> implementation ohc-core-j8 : java.lang.NoSuchMethodException:
> org.caffinitas.ohc.linked.UnsExt8.(java.lang.Class)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12133) Failed to load Java8 implementation ohc-core-j8
[
https://issues.apache.org/jira/browse/CASSANDRA-12133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-12133:
-
Fix Version/s: 3.x
> Failed to load Java8 implementation ohc-core-j8
> ---
>
> Key: CASSANDRA-12133
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12133
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04, Java 1.8.0_91
>Reporter: Mike
>Assignee: Robert Stupp
>Priority: Trivial
> Fix For: 3.x
>
>
> After enabling row cache in cassandra.yaml by setting row_cache_size_in_mb, I
> receive this warning in system.log during startup:
> {noformat}
> WARN [main] 2016-07-05 13:36:14,671 Uns.java:169 - Failed to load Java8
> implementation ohc-core-j8 : java.lang.NoSuchMethodException:
> org.caffinitas.ohc.linked.UnsExt8.(java.lang.Class)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12133) Failed to load Java8 implementation ohc-core-j8
[
https://issues.apache.org/jira/browse/CASSANDRA-12133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15362471#comment-15362471
]
Robert Stupp commented on CASSANDRA-12133:
--
[~limonad], you can safely ignore this message (see [OHC
issue|https://github.com/snazy/ohc/issues/17]).
It's fixed in OHC 0.4.4 (not sure why I forgot to submit a patch for that until
now)..
Using this ticket to upgrade OHC - but not in 3.0.x as it's just an "annoying"
message.
||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:12133-update-ohc-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12133-update-ohc-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12133-update-ohc-trunk-dtest/lastSuccessfulBuild/]
> Failed to load Java8 implementation ohc-core-j8
> ---
>
> Key: CASSANDRA-12133
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12133
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04, Java 1.8.0_91
>Reporter: Mike
>Priority: Trivial
> Fix For: 3.x
>
>
> After enabling row cache in cassandra.yaml by setting row_cache_size_in_mb, I
> receive this warning in system.log during startup:
> {noformat}
> WARN [main] 2016-07-05 13:36:14,671 Uns.java:169 - Failed to load Java8
> implementation ohc-core-j8 : java.lang.NoSuchMethodException:
> org.caffinitas.ohc.linked.UnsExt8.(java.lang.Class)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12133) Failed to load Java8 implementation ohc-core-j8
[
https://issues.apache.org/jira/browse/CASSANDRA-12133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-12133:
-
Priority: Trivial (was: Major)
> Failed to load Java8 implementation ohc-core-j8
> ---
>
> Key: CASSANDRA-12133
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12133
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04, Java 1.8.0_91
>Reporter: Mike
>Priority: Trivial
>
> After enabling row cache in cassandra.yaml by setting row_cache_size_in_mb, I
> receive this warning in system.log during startup:
> {noformat}
> WARN [main] 2016-07-05 13:36:14,671 Uns.java:169 - Failed to load Java8
> implementation ohc-core-j8 : java.lang.NoSuchMethodException:
> org.caffinitas.ohc.linked.UnsExt8.(java.lang.Class)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12133) Failed to load Java8 implementation ohc-core-j8
[
https://issues.apache.org/jira/browse/CASSANDRA-12133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-12133:
-
Fix Version/s: (was: 3.0.7)
> Failed to load Java8 implementation ohc-core-j8
> ---
>
> Key: CASSANDRA-12133
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12133
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04, Java 1.8.0_91
>Reporter: Mike
>
> After enabling row cache in cassandra.yaml by setting row_cache_size_in_mb, I
> receive this warning in system.log during startup:
> {noformat}
> WARN [main] 2016-07-05 13:36:14,671 Uns.java:169 - Failed to load Java8
> implementation ohc-core-j8 : java.lang.NoSuchMethodException:
> org.caffinitas.ohc.linked.UnsExt8.(java.lang.Class)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12072) dtest failure in auth_test.TestAuthRoles.udf_permissions_in_selection_test
[
https://issues.apache.org/jira/browse/CASSANDRA-12072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360061#comment-15360061
]
Robert Stupp edited comment on CASSANDRA-12072 at 7/2/16 8:17 AM:
--
Based on [~tjake] and [~jjordan] findings, I *think* I found a way to repro
this in a utest.
[Branch on
github|https://github.com/apache/cassandra/compare/trunk...snazy:12072-utest-trunk?expand=1]
I tried it a couple of times against trunk and it constantly fails w/ netty
4.0.37 but succeeds w/ 4.0.36.
EDIT
[previously|https://github.com/netty/netty/commit/f984870ccca133d6056e8b0df0b2352f8f90b0fe#diff-6b8633f415085302023f47004357891aL210]
there was a call to {{waitOnFuture}} which is no longer there in 4.0.37.
Also changed {{CQLTester}} so that it actually runs into [this
line|https://github.com/apache/cassandra/blob/88229a47a847532d04041047d2db40411d04f49b/src/java/org/apache/cassandra/transport/Server.java#L331].
was (Author: snazy):
Based on [~tjake] and [~jjordan] findings, I *think* I found a way to repro
this in a utest.
[Branch on
github|https://github.com/apache/cassandra/compare/trunk...snazy:12072-utest-trunk?expand=1]
I tried it a couple of times against trunk and it constantly fails w/ netty
4.0.37 but succeeds w/ 4.0.36.
> dtest failure in auth_test.TestAuthRoles.udf_permissions_in_selection_test
> --
>
> Key: CASSANDRA-12072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12072
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Joel Knighton
> Labels: dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log
>
>
> Multiple failures:
> http://cassci.datastax.com/job/trunk_offheap_dtest/265/testReport/auth_test/TestAuthRoles/udf_permissions_in_selection_test
> http://cassci.datastax.com/job/trunk_offheap_dtest/265/testReport/auth_test/TestAuthRoles/create_and_grant_roles_with_superuser_status_test/
> http://cassci.datastax.com/job/trunk_offheap_dtest/265/testReport/auth_test/TestAuthRoles/drop_keyspace_cleans_up_function_level_permissions_test/
> http://cassci.datastax.com/job/trunk_offheap_dtest/265/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_reading_max_parse_errors/
> http://cassci.datastax.com/job/trunk_offheap_dtest/265/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_read_wrong_column_names/
> http://cassci.datastax.com/job/trunk_offheap_dtest/264/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_boolstyle_round_trip/
> http://cassci.datastax.com/job/trunk_offheap_dtest/264/testReport/compaction_test/TestCompaction_with_SizeTieredCompactionStrategy/disable_autocompaction_alter_test/
> http://cassci.datastax.com/job/trunk_offheap_dtest/264/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_describe/
> http://cassci.datastax.com/job/trunk_offheap_dtest/264/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_describe_mv/
> Logs are from
> http://cassci.datastax.com/job/trunk_offheap_dtest/265/testReport/auth_test/TestAuthRoles/udf_permissions_in_selection_test/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12072) dtest failure in auth_test.TestAuthRoles.udf_permissions_in_selection_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360061#comment-15360061 ] Robert Stupp commented on CASSANDRA-12072: -- Based on [~tjake] and [~jjordan] findings, I *think* I found a way to repro this in a utest. [Branch on github|https://github.com/apache/cassandra/compare/trunk...snazy:12072-utest-trunk?expand=1] I tried it a couple of times against trunk and it constantly fails w/ netty 4.0.37 but succeeds w/ 4.0.36. > dtest failure in auth_test.TestAuthRoles.udf_permissions_in_selection_test > -- > > Key: CASSANDRA-12072 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12072 > Project: Cassandra > Issue Type: Bug >Reporter: Sean McCarthy >Assignee: Joel Knighton > Labels: dtest > Attachments: node1.log, node1_debug.log, node1_gc.log > > > Multiple failures: > http://cassci.datastax.com/job/trunk_offheap_dtest/265/testReport/auth_test/TestAuthRoles/udf_permissions_in_selection_test > http://cassci.datastax.com/job/trunk_offheap_dtest/265/testReport/auth_test/TestAuthRoles/create_and_grant_roles_with_superuser_status_test/ > http://cassci.datastax.com/job/trunk_offheap_dtest/265/testReport/auth_test/TestAuthRoles/drop_keyspace_cleans_up_function_level_permissions_test/ > http://cassci.datastax.com/job/trunk_offheap_dtest/265/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_reading_max_parse_errors/ > http://cassci.datastax.com/job/trunk_offheap_dtest/265/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_read_wrong_column_names/ > http://cassci.datastax.com/job/trunk_offheap_dtest/264/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_boolstyle_round_trip/ > http://cassci.datastax.com/job/trunk_offheap_dtest/264/testReport/compaction_test/TestCompaction_with_SizeTieredCompactionStrategy/disable_autocompaction_alter_test/ > http://cassci.datastax.com/job/trunk_offheap_dtest/264/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_describe/ > http://cassci.datastax.com/job/trunk_offheap_dtest/264/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_describe_mv/ > Logs are from > http://cassci.datastax.com/job/trunk_offheap_dtest/265/testReport/auth_test/TestAuthRoles/udf_permissions_in_selection_test/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12034) Special handling for Netty's direct memory allocation failure
[
https://issues.apache.org/jira/browse/CASSANDRA-12034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15353176#comment-15353176
]
Robert Stupp commented on CASSANDRA-12034:
--
ok to commit this to 3.8? or at least the changes to the {{NEWS.txt}},
{{cassandra-env.*}} and {{jvm.options}} files?
> Special handling for Netty's direct memory allocation failure
> -
>
> Key: CASSANDRA-12034
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12034
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Labels: doc-impacting
> Fix For: 3.x
>
>
> With CASSANDRA-12032, Netty throws a
> {{io.netty.util.internal.OutOfDirectMemoryError}} if there's not enough
> off-heap memory for the response buffer. We can easily handle this situation
> and return an error. This is not a condition that destabilizes the system and
> should therefore not passed to {{JVMStabilityInspector}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12089) Update metrics-reporter dependencies
Robert Stupp created CASSANDRA-12089: Summary: Update metrics-reporter dependencies Key: CASSANDRA-12089 URL: https://issues.apache.org/jira/browse/CASSANDRA-12089 Project: Cassandra Issue Type: Improvement Reporter: Robert Stupp Assignee: Robert Stupp Priority: Minor Fix For: 2.1.x Proposal to update the metrics-reporter jars. Upcoming versions (>=3.0.2) of [metrics-reporter-config|https://github.com/addthis/metrics-reporter-config] should support prometheus and maybe also riemann (in v3). Relevant PRs: https://github.com/addthis/metrics-reporter-config/pull/26 https://github.com/addthis/metrics-reporter-config/pull/27 reporter-config 3.0.2+ can also be used in 2.1. Therefore it would be nice to have also update the jars in 2.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-11967) Export metrics for prometheus in its native format
[ https://issues.apache.org/jira/browse/CASSANDRA-11967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp resolved CASSANDRA-11967. -- Resolution: Won't Fix Reviewer: (was: Sam Tunnicliffe) Went another route to support prometheus: I've opened [a PR|https://github.com/addthis/metrics-reporter-config/pull/26] to support it via metrics-reporter. Reverted the commit. > Export metrics for prometheus in its native format > -- > > Key: CASSANDRA-11967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11967 > Project: Cassandra > Issue Type: Improvement >Reporter: Robert Stupp >Assignee: Robert Stupp >Priority: Minor > Fix For: 3.8 > > > https://github.com/snazy/prometheus-metrics-exporter allows to export > codahale metrics for prometheus.io. In order to integrate this, a minor > change to C* is necessary to load the library. > This eliminates the need to use the additional graphite-exporter tool and > therefore also allows prometheus to track the up/down status of C*. > (Will provide the patch soon) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11967) Export metrics for prometheus in its native format
[ https://issues.apache.org/jira/browse/CASSANDRA-11967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-11967: - Resolution: Fixed Fix Version/s: (was: 3.x) 3.8 Status: Resolved (was: Ready to Commit) Thanks! Committed as [33f2f844b6bef7b3e5977f649bb2bfaf2e4db904|https://github.com/apache/cassandra/commit/33f2f844b6bef7b3e5977f649bb2bfaf2e4db904] to [trunk|https://github.com/apache/cassandra/tree/trunk] > Export metrics for prometheus in its native format > -- > > Key: CASSANDRA-11967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11967 > Project: Cassandra > Issue Type: Improvement >Reporter: Robert Stupp >Assignee: Robert Stupp >Priority: Minor > Fix For: 3.8 > > > https://github.com/snazy/prometheus-metrics-exporter allows to export > codahale metrics for prometheus.io. In order to integrate this, a minor > change to C* is necessary to load the library. > This eliminates the need to use the additional graphite-exporter tool and > therefore also allows prometheus to track the up/down status of C*. > (Will provide the patch soon) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11967) Export metrics for prometheus in its native format
[
https://issues.apache.org/jira/browse/CASSANDRA-11967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15348490#comment-15348490
]
Robert Stupp commented on CASSANDRA-11967:
--
Yup - that's right. You need a mapping file like [this
one|https://github.com/snazy/prometheus-metrics-exporter/blob/master/mappings/cassandra-mappings.yaml]
in the {{conf}} directory and add
{{-Dorg.caffinitas.prometheus.config=cassandra-mappings.yaml}}. That helps to
shorten the names that appear e.g. in Grafana and to re-organize the metrics as
you personally prefer and to exclude metrics you don't want (like
{{org.apache.cassandra.metrics.Table.EstimatedPartitionCount}}, which touches
all sstables).
> Export metrics for prometheus in its native format
> --
>
> Key: CASSANDRA-11967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11967
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> https://github.com/snazy/prometheus-metrics-exporter allows to export
> codahale metrics for prometheus.io. In order to integrate this, a minor
> change to C* is necessary to load the library.
> This eliminates the need to use the additional graphite-exporter tool and
> therefore also allows prometheus to track the up/down status of C*.
> (Will provide the patch soon)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12034) Special handling for Netty's direct memory allocation failure
[
https://issues.apache.org/jira/browse/CASSANDRA-12034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15348479#comment-15348479
]
Robert Stupp commented on CASSANDRA-12034:
--
Alright - now the patch just adds two calls to {{JVMStabilityInspector}}.
Also took the freedom to remove the netty settings from {{cassandra-env}} and
moved it to {{jvm.options}}, also added some text about
{{-XX:MaxDirectMemorySize}}.
> Special handling for Netty's direct memory allocation failure
> -
>
> Key: CASSANDRA-12034
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12034
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Labels: doc-impacting
> Fix For: 3.x
>
>
> With CASSANDRA-12032, Netty throws a
> {{io.netty.util.internal.OutOfDirectMemoryError}} if there's not enough
> off-heap memory for the response buffer. We can easily handle this situation
> and return an error. This is not a condition that destabilizes the system and
> should therefore not passed to {{JVMStabilityInspector}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12034) Special handling for Netty's direct memory allocation failure
[
https://issues.apache.org/jira/browse/CASSANDRA-12034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-12034:
-
Labels: doc-impacting (was: )
> Special handling for Netty's direct memory allocation failure
> -
>
> Key: CASSANDRA-12034
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12034
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Labels: doc-impacting
> Fix For: 3.x
>
>
> With CASSANDRA-12032, Netty throws a
> {{io.netty.util.internal.OutOfDirectMemoryError}} if there's not enough
> off-heap memory for the response buffer. We can easily handle this situation
> and return an error. This is not a condition that destabilizes the system and
> should therefore not passed to {{JVMStabilityInspector}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12076) Add username to AuthenticationException messages
[
https://issues.apache.org/jira/browse/CASSANDRA-12076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15346148#comment-15346148
]
Robert Stupp commented on CASSANDRA-12076:
--
[~geoffxy], can you go ahead an address Sam's comments?
> Add username to AuthenticationException messages
>
>
> Key: CASSANDRA-12076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12076
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Geoffrey Yu
>Assignee: Geoffrey Yu
>Priority: Trivial
> Attachments: 12076-trunk.txt
>
>
> When an {{AuthenticationException}} is thrown, there are a few places where
> the user that initiated the request is not included in the exception message.
> It can be useful to have this information included for logging purposes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12076) Add username to AuthenticationException messages
[
https://issues.apache.org/jira/browse/CASSANDRA-12076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15345795#comment-15345795
]
Robert Stupp commented on CASSANDRA-12076:
--
Patch LGTM - [~beobal], ok with this?
Would go ahead and trigger CI for it then.
> Add username to AuthenticationException messages
>
>
> Key: CASSANDRA-12076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12076
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Geoffrey Yu
>Assignee: Geoffrey Yu
>Priority: Trivial
> Attachments: 12076-trunk.txt
>
>
> When an {{AuthenticationException}} is thrown, there are a few places where
> the user that initiated the request is not included in the exception message.
> It can be useful to have this information included for logging purposes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12062) Prevent key invalidation if there's no key to invalidate
[
https://issues.apache.org/jira/browse/CASSANDRA-12062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-12062:
-
Fix Version/s: 3.x
Status: Patch Available (was: Open)
Patch available (just started CI)
||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:12062-invalidate-opts-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12062-invalidate-opts-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12062-invalidate-opts-trunk-dtest/lastSuccessfulBuild/]
> Prevent key invalidation if there's no key to invalidate
>
>
> Key: CASSANDRA-12062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12062
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> In {{SSTableRewriter}} we currently assume that there are keys to be
> invalidated in the key cache. That's not always true - especially if a bunch
> of tiny sstables have been generated.
> Patch saves one {{synchronized}} and a few objects if that's the case.
> Just a small optimisation, but maybe worth to include.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12062) Prevent key invalidation if there's no key to invalidate
Robert Stupp created CASSANDRA-12062:
Summary: Prevent key invalidation if there's no key to invalidate
Key: CASSANDRA-12062
URL: https://issues.apache.org/jira/browse/CASSANDRA-12062
Project: Cassandra
Issue Type: Improvement
Reporter: Robert Stupp
Assignee: Robert Stupp
Priority: Minor
In {{SSTableRewriter}} we currently assume that there are keys to be
invalidated in the key cache. That's not always true - especially if a bunch of
tiny sstables have been generated.
Patch saves one {{synchronized}} and a few objects if that's the case.
Just a small optimisation, but maybe worth to include.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12055) UDT named 'return' causes error in DESC TABLE
Robert Stupp created CASSANDRA-12055:
Summary: UDT named 'return' causes error in DESC TABLE
Key: CASSANDRA-12055
URL: https://issues.apache.org/jira/browse/CASSANDRA-12055
Project: Cassandra
Issue Type: Bug
Reporter: Robert Stupp
Priority: Minor
Having a schema like
{code}
CREATE TYPE foo.return ( a int, order_id text, b int, c text );
CREATE TABLE foo.bar ( pk int PRIMARY KEY,returns frozen>>
);
{code}
created in 2.2.6.
Executing {{DESC TABLE}} causes cqlsh to error out, if it's executed from 2.2
branch - but funnily it works fine with cqlsh on trunk. Funnily because both
2.2 and trunk use the same driver version and I don't really get what's
different there.
The error message on 2.2.3 (using driver version 2.7.2) on the original cluster
is:
{code}
Warning: Table abcd.efgh is incomplete because of an error processing metadata.
Traceback (most recent call last):
File
"/usr/share/cassandra/lib/cassandra-driver-internal-only-2.7.2.zip/cassandra-driver-2.7.2/cassandra/metadata.py",
line 438, in _build_table_metadata
column_meta = self._build_column_metadata(table_meta, col_row)
File
"/usr/share/cassandra/lib/cassandra-driver-internal-only-2.7.2.zip/cassandra-driver-2.7.2/cassandra/metadata.py",
line 471, in _build_column_metadata
data_type = types.lookup_casstype(row["validator"])
File
"/usr/share/cassandra/lib/cassandra-driver-internal-only-2.7.2.zip/cassandra-driver-2.7.2/cassandra/cqltypes.py",
line 184, in lookup_casstype
raise ValueError("Don't know how to parse type string %r: %s" % (casstype,
e))
ValueError: Don't know how to parse type string
u'org.apache.cassandra.db.marshal.FrozenType(org.apache.cassandra.db.marshal.ListType(org.apache.cassandra.db.marshal.UserType(foo,72657475726e,...:org.apache.cassandra.db.marshal.Int32Type,...:org.apache.cassandra.db.marshal.UTF8Type,...:org.apache.cassandra.db.marshal.Int32Type,...:org.apache.cassandra.db.marshal.UTF8Type)))':
Type names and field names cannot be a keyword: 'return'
{code}
The error message on latest 2.2 is:
{code}
Warning: Table foo.bar is incomplete because of an error processing metadata.
Traceback (most recent call last):
File
"/Users/snazy/devel/cassandra/2.2/bin/../lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/metadata.py",
line 1893, in _build_table_metadata
column_meta = self._build_column_metadata(table_meta, col_row)
File
"/Users/snazy/devel/cassandra/2.2/bin/../lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/metadata.py",
line 1931, in _build_column_metadata
data_type = types.lookup_casstype(type_string)
File
"/Users/snazy/devel/cassandra/2.2/bin/../lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cqltypes.py",
line 182, in lookup_casstype
return parse_casstype_args(casstype)
File
"/Users/snazy/devel/cassandra/2.2/bin/../lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cqltypes.py",
line 150, in parse_casstype_args
prev_types[-1] = prev_types[-1].apply_parameters(types, names)
File
"/Users/snazy/devel/cassandra/2.2/bin/../lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cqltypes.py",
line 883, in apply_parameters
return cls.make_udt_class(keyspace, udt_name, field_names,
tuple(subtypes[2:]))
File "/Users/snazy/devel/cassandra/2.2/bin/cqlsh.py", line 632, in
new_make_udt_class
formatter_for(udt_class.tuple_type.__name__)(format_value_utype)
AttributeError: 'NoneType' object has no attribute '__name__'
{code}
Both seem to be caused by the UDT name {{return}} (which is not a wise choice).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12034) Special handling for Netty's direct memory allocation failure
[
https://issues.apache.org/jira/browse/CASSANDRA-12034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15344128#comment-15344128
]
Robert Stupp edited comment on CASSANDRA-12034 at 6/22/16 11:10 AM:
bq. when it will resolve
Good point.
Shall I change the patch to call JVMStabilityInspector? OOMs are not handled
there at the moment (see CASSANDRA-11818).
EDIT: This would become superfluous when we can stream responses and do not
allocate buffers for the whole response and just for individual frames (or
however the impl would do it).
was (Author: snazy):
bq. when it will resolve
Good point.
Shall I change the patch to call JVMStabilityInspector? OOMs are not handled
there at the moment (see CASSANDRA-11818).
> Special handling for Netty's direct memory allocation failure
> -
>
> Key: CASSANDRA-12034
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12034
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Fix For: 3.x
>
>
> With CASSANDRA-12032, Netty throws a
> {{io.netty.util.internal.OutOfDirectMemoryError}} if there's not enough
> off-heap memory for the response buffer. We can easily handle this situation
> and return an error. This is not a condition that destabilizes the system and
> should therefore not passed to {{JVMStabilityInspector}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12034) Special handling for Netty's direct memory allocation failure
[
https://issues.apache.org/jira/browse/CASSANDRA-12034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15344128#comment-15344128
]
Robert Stupp commented on CASSANDRA-12034:
--
bq. when it will resolve
Good point.
Shall I change the patch to call JVMStabilityInspector? OOMs are not handled
there at the moment (see CASSANDRA-11818).
> Special handling for Netty's direct memory allocation failure
> -
>
> Key: CASSANDRA-12034
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12034
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Fix For: 3.x
>
>
> With CASSANDRA-12032, Netty throws a
> {{io.netty.util.internal.OutOfDirectMemoryError}} if there's not enough
> off-heap memory for the response buffer. We can easily handle this situation
> and return an error. This is not a condition that destabilizes the system and
> should therefore not passed to {{JVMStabilityInspector}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11870) Consider allocating direct buffers bypassing ByteBuffer.allocateDirect
[
https://issues.apache.org/jira/browse/CASSANDRA-11870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15344121#comment-15344121
]
Robert Stupp commented on CASSANDRA-11870:
--
It's a bit difficult to tell whether it's experienced in the wild, since before
3.x Netty buffers were on-heap and C* only had somewhat infrequent direct
memory allocations. However, with 3.0 and especially 3.6, we have more frequent
off-heap memory allocations. At least from my point of view, the majority is
still on 2.1.
What I intend to tackle is to prevent the (ugly) call to
{{java.nio.Bits#reserveMemory}} and also the global linked queue via
{{sun.misc.Cleaner}}, which has static synchronized methods {{add}} +
{{remove}}. My objection about {{ByteBuffer.allocateDirect()}} in general is
that if one thread runs into an _out-of-direct-memory_ situations, other thread
will likely run into that situation, too - and that will cause one CMS-GC
({{System.gc()}}) per thread.
However, I agree that maintaining a separate {{max_direct_memory_in_mb}} config
variable is probably not the best way. A better option could be to use the
already existing options that define off-heap memory bounds like
{{file_cache_size_in_mb}}, {{memtable_offheap_space_in_mb}},
{{index_summary_capacity_in_mb}}, sum them and use that value. WDYT?
I'm not sure, whether the following is a good idea: while testing OHC a while
ago with >30G of small allocations, it worked really nice (OHC does not use
BB.allocateDirect - that time I just realized that it's slow). What I'm
thinking of, is to not pool off-heap memory at all (and just keep track of the
total allocated amount, as currently in the patch) and leave alloc()/free() up
to the OS or jemalloc.
Your idea to centralize BB allocations in BufferPool sounds good!
> Consider allocating direct buffers bypassing ByteBuffer.allocateDirect
> --
>
> Key: CASSANDRA-11870
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11870
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> As outlined in CASSANDRA-11818, {{ByteBuffer.allocateDirect}} uses
> {{Bits.reserveMemory}}, which is there to respect the JVM setting
> {{-XX:MaxDirectMemorySize=...}}.
> {{Bits.reserveMemory}} first tries an "optimistic" {{tryReserveMemory}} and
> exits immediately on success. However, if that somehow doesn't succeed, it
> triggers a {{System.gc()}}, which is bad IMO (however, kind of how direct
> buffers work in Java). After that GC it sleeps and tries to reserve the
> memory up to 9 times - up to 511 ms - and then throws
> {{OutOfMemoryError("Direct buffer memory")}}.
> This is unnecessary for us since we always immediately "free" direct buffers
> as soon as we no longer need them.
> Proposal: Manage direct-memory reservations in our own code and skip
> {{Bits.reserveMemory}} that way.
> (However, Netty direct buffers are not under our control.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11969) Prevent duplicate ctx.channel().attr() call
[
https://issues.apache.org/jira/browse/CASSANDRA-11969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-11969:
-
Resolution: Fixed
Fix Version/s: (was: 3.x)
3.8
Status: Resolved (was: Patch Available)
Thanks!
Committed as
[4ae198765b21c644494cd902f6d127400d126de1|https://github.com/apache/cassandra/commit/4ae198765b21c644494cd902f6d127400d126de1]
to [trunk|https://github.com/apache/cassandra/tree/trunk]
> Prevent duplicate ctx.channel().attr() call
> ---
>
> Key: CASSANDRA-11969
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11969
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Trivial
> Fix For: 3.8
>
>
> In {{Frame}} we can save one call to
> {{ctx.channel().attr(Connection.attributeKey)}}.
> (Will provide a patch soon)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11971) More uses of DataOutputBuffer.RECYCLER
[
https://issues.apache.org/jira/browse/CASSANDRA-11971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-11971:
-
Resolution: Fixed
Fix Version/s: (was: 3.x)
3.8
Status: Resolved (was: Patch Available)
Thanks!
Committed as
[063e91754b22a28a43efccb0c238c577a6bd0b8a|https://github.com/apache/cassandra/commit/063e91754b22a28a43efccb0c238c577a6bd0b8a]
to [trunk|https://github.com/apache/cassandra/tree/trunk]
> More uses of DataOutputBuffer.RECYCLER
> --
>
> Key: CASSANDRA-11971
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11971
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.8
>
>
> There are a few more possible use cases for {{DataOutputBuffer.RECYCLER}},
> which prevents a couple of (larger) allocations.
> (Will provide a patch soon)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11937) Clean up buffer trimming large buffers in DataOutputBuffer after the Netty upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-11937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15341907#comment-15341907
]
Robert Stupp commented on CASSANDRA-11937:
--
Netty 4.0.37 is now in trunk.
> Clean up buffer trimming large buffers in DataOutputBuffer after the Netty
> upgrade
> --
>
> Key: CASSANDRA-11937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11937
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Alex Petrov
>Assignee: Alex Petrov
> Labels: lhf, netty, reminder
>
> In [https://issues.apache.org/jira/browse/CASSANDRA-11838|11838], we're
> trimming the large buffers in {{DataOutputBuffer}}. The patch is already
> submitted and merged in [Netty
> 4.1|https://github.com/netty/netty/commit/bbed330468b5b82c9e4defa59012d0fcdb70f1aa],
> we only need to make sure that we throw large buffers away1 alltogether
> instead of trimming them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12032) Update to Netty 4.0.37
[ https://issues.apache.org/jira/browse/CASSANDRA-12032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-12032: - Resolution: Fixed Fix Version/s: (was: 3.x) 3.8 Status: Resolved (was: Patch Available) Thanks! Committed as [e8d7fe8a289e16d18a83e598c589347ec080029f|https://github.com/apache/cassandra/commit/e8d7fe8a289e16d18a83e598c589347ec080029f] to [trunk|https://github.com/apache/cassandra/tree/trunk] > Update to Netty 4.0.37 > -- > > Key: CASSANDRA-12032 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12032 > Project: Cassandra > Issue Type: Improvement >Reporter: Robert Stupp >Assignee: Robert Stupp > Fix For: 3.8 > > > Update Netty to 4.0.37 > (no C* code changes in this ticket) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11723) Cassandra upgrade from 2.1.11 to 3.0.5 leads to unstable nodes (jemalloc to blame)
[
https://issues.apache.org/jira/browse/CASSANDRA-11723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339684#comment-15339684
]
Robert Stupp commented on CASSANDRA-11723:
--
Sorry for getting back to you after such a long time. Any recent version of
jemalloc should work.
> Cassandra upgrade from 2.1.11 to 3.0.5 leads to unstable nodes (jemalloc to
> blame)
> --
>
> Key: CASSANDRA-11723
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11723
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefano Ortolani
> Fix For: 3.0.x
>
>
> Upgrade seems fine, but any restart of the node might lead to a situation
> where the node just dies after 30 seconds / 1 minute.
> Nothing in the logs besides many "FailureDetector.java:456 - Ignoring
> interval time of 3000892567 for /10.12.a.x" output every second (against all
> other nodes) in debug.log plus some spurious GraphiteErrors/ReadRepair
> notifications:
> {code:xml}
> DEBUG [GossipStage:1] 2016-05-05 22:29:03,921 FailureDetector.java:456 -
> Ignoring interval time of 2373187360 for /10.12.a.x
> DEBUG [GossipStage:1] 2016-05-05 22:29:03,921 FailureDetector.java:456 -
> Ignoring interval time of 2000276196 for /10.12.a.y
> DEBUG [ReadRepairStage:24] 2016-05-05 22:29:03,990 ReadCallback.java:234 -
> Digest mismatch:
> org.apache.cassandra.service.DigestMismatchException: Mismatch for key
> DecoratedKey(-152946356843306763, e859fdd2f264485f42030ce261e4e12e)
> (d6e617ece3b7bec6138b52b8974b8cab vs 31becca666a62b3c4b2fc0bab9902718)
> at
> org.apache.cassandra.service.DigestResolver.resolve(DigestResolver.java:85)
> ~[apache-cassandra-3.0.5.jar:3.0.5]
> at
> org.apache.cassandra.service.ReadCallback$AsyncRepairRunner.run(ReadCallback.java:225)
> ~[apache-cassandra-3.0.5.jar:3.0.5]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> DEBUG [GossipStage:1] 2016-05-05 22:29:04,841 FailureDetector.java:456 -
> Ignoring interval time of 3000299340 for /10.12.33.5
> ERROR [metrics-graphite-reporter-1-thread-1] 2016-05-05 22:29:05,692
> ScheduledReporter.java:119 - RuntimeException thrown from
> GraphiteReporter#report. Exception was suppressed.
> java.lang.IllegalStateException: Unable to compute ceiling for max when
> histogram overflowed
> at
> org.apache.cassandra.utils.EstimatedHistogram.rawMean(EstimatedHistogram.java:231)
> ~[apache-cassandra-3.0.5.jar:3.0.5]
> at
> org.apache.cassandra.metrics.EstimatedHistogramReservoir$HistogramSnapshot.getMean(EstimatedHistogramReservoir.java:103)
> ~[apache-cassandra-3.0.5.jar:3.0.5]
> at
> com.codahale.metrics.graphite.GraphiteReporter.reportHistogram(GraphiteReporter.java:252)
> ~[metrics-graphite-3.1.0.jar:3.1.0]
> at
> com.codahale.metrics.graphite.GraphiteReporter.report(GraphiteReporter.java:166)
> ~[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_60]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> {code}
> I know this is not much but nothing else gets to dmesg or to any other log.
> Any suggestion how to debug this further?
> I upgraded two nodes so far, and it happened on both nodes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12027) Provide metrics for thread pool heap and CPU usage
[ https://issues.apache.org/jira/browse/CASSANDRA-12027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp resolved CASSANDRA-12027. -- Resolution: Duplicate > Provide metrics for thread pool heap and CPU usage > -- > > Key: CASSANDRA-12027 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12027 > Project: Cassandra > Issue Type: Improvement >Reporter: Robert Stupp >Assignee: Robert Stupp >Priority: Minor > Fix For: 3.x > > > While working on some load tests and digging through the causes of certain > things, it was very useful to know which thread pools actually consume how > much heap and CPU. > I already have some general implementation in place, but this assumes that > the thread names stay constant. CASSANDRA-11966 is about to change this, so > the general approach no longer works. Instead, measuring CPU and heap usage > would need to be accumulated in SEPWorker for the actual (logical) thread > pool. > Purpose of this ticket is to provide the following metrics: > * CPU and heap usage per statically named C* thread > * CPU and heap usage per non-shared C* thread pool > * CPU and heap usage per shared C* thread pool > * CPU and heap usage for Netty thread pools > This information would be exposed as "ordinary" metrics. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11206) Support large partitions on the 3.0 sstable format
[ https://issues.apache.org/jira/browse/CASSANDRA-11206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339248#comment-15339248 ] Robert Stupp commented on CASSANDRA-11206: -- bq. RowIndexEntry$serializedSize used to return the size of the index for the entire row. The meaning of this method changed but hasn't been renamed accordingly - my bad. It just returns the serialized size of these fields, so without the actual "index payload". bq. Javadoc for IndexInfo The only real new thing in 3.0 index format is the table with the offsets to the IndexInfo objects. The rest has changed mostly by switching to vint encoding - "hidden" by the note for "ma" _store rows natively_. bq. Pre_C_11206_RowIndexEntry You can safely ignore (or even remove) the Pre-C-11206 stuff in RowIndexEntryTest. It just felt safer to have it initially as it was meant to ensure that the new implementation is binary compatible with the old one. > Support large partitions on the 3.0 sstable format > -- > > Key: CASSANDRA-11206 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11206 > Project: Cassandra > Issue Type: Improvement > Components: Local Write-Read Paths >Reporter: Jonathan Ellis >Assignee: Robert Stupp > Labels: docs-impacting > Fix For: 3.6 > > Attachments: 11206-gc.png, trunk-gc.png > > > Cassandra saves a sample of IndexInfo objects that store the offset within > each partition of every 64KB (by default) range of rows. To find a row, we > binary search this sample, then scan the partition of the appropriate range. > The problem is that this scales poorly as partitions grow: on a cache miss, > we deserialize the entire set of IndexInfo, which both creates a lot of GC > overhead (as noted in CASSANDRA-9754) but is also non-negligible i/o activity > (relative to reading a single 64KB row range) as partitions get truly large. > We introduced an "offset map" in CASSANDRA-10314 that allows us to perform > the IndexInfo bsearch while only deserializing IndexInfo that we need to > compare against, i.e. log(N) deserializations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11870) Consider allocating direct buffers bypassing ByteBuffer.allocateDirect
[
https://issues.apache.org/jira/browse/CASSANDRA-11870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339098#comment-15339098
]
Robert Stupp commented on CASSANDRA-11870:
--
It's default is calculated in {{DatabaseDescriptor.applyConfig()}} to at least
1GB. 1GB is the default max memory setting for direct memory in Java AFAIK.
> Consider allocating direct buffers bypassing ByteBuffer.allocateDirect
> --
>
> Key: CASSANDRA-11870
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11870
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> As outlined in CASSANDRA-11818, {{ByteBuffer.allocateDirect}} uses
> {{Bits.reserveMemory}}, which is there to respect the JVM setting
> {{-XX:MaxDirectMemorySize=...}}.
> {{Bits.reserveMemory}} first tries an "optimistic" {{tryReserveMemory}} and
> exits immediately on success. However, if that somehow doesn't succeed, it
> triggers a {{System.gc()}}, which is bad IMO (however, kind of how direct
> buffers work in Java). After that GC it sleeps and tries to reserve the
> memory up to 9 times - up to 511 ms - and then throws
> {{OutOfMemoryError("Direct buffer memory")}}.
> This is unnecessary for us since we always immediately "free" direct buffers
> as soon as we no longer need them.
> Proposal: Manage direct-memory reservations in our own code and skip
> {{Bits.reserveMemory}} that way.
> (However, Netty direct buffers are not under our control.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11870) Consider allocating direct buffers bypassing ByteBuffer.allocateDirect
[
https://issues.apache.org/jira/browse/CASSANDRA-11870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-11870:
-
Status: Patch Available (was: Open)
Patch for this:
||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:11870-own-off-heap-space-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-11870-own-off-heap-space-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-11870-own-off-heap-space-trunk-dtest/lastSuccessfulBuild/]
> Consider allocating direct buffers bypassing ByteBuffer.allocateDirect
> --
>
> Key: CASSANDRA-11870
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11870
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> As outlined in CASSANDRA-11818, {{ByteBuffer.allocateDirect}} uses
> {{Bits.reserveMemory}}, which is there to respect the JVM setting
> {{-XX:MaxDirectMemorySize=...}}.
> {{Bits.reserveMemory}} first tries an "optimistic" {{tryReserveMemory}} and
> exits immediately on success. However, if that somehow doesn't succeed, it
> triggers a {{System.gc()}}, which is bad IMO (however, kind of how direct
> buffers work in Java). After that GC it sleeps and tries to reserve the
> memory up to 9 times - up to 511 ms - and then throws
> {{OutOfMemoryError("Direct buffer memory")}}.
> This is unnecessary for us since we always immediately "free" direct buffers
> as soon as we no longer need them.
> Proposal: Manage direct-memory reservations in our own code and skip
> {{Bits.reserveMemory}} that way.
> (However, Netty direct buffers are not under our control.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11537) Give clear error when certain nodetool commands are issued before server is ready
[
https://issues.apache.org/jira/browse/CASSANDRA-11537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15338599#comment-15338599
]
Robert Stupp commented on CASSANDRA-11537:
--
Hm - now other tests fail:
http://cassci.datastax.com/job/snazy-CASSANDRA-11537-2-testall/2/#showFailuresLink
> Give clear error when certain nodetool commands are issued before server is
> ready
> -
>
> Key: CASSANDRA-11537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11537
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>Priority: Minor
> Labels: lhf
>
> As an ops person upgrading and servicing Cassandra servers, I require a more
> clear message when I issue a nodetool command that the server is not ready
> for it so that I am not confused.
> Technical description:
> If you deploy a new binary, restart, and issue nodetool
> scrub/compact/updatess etc you get unfriendly assertion. An exception would
> be easier to understand. Also if a user has turned assertions off it is
> unclear what might happen.
> {noformat}
> EC1: Throw exception to make it clear server is still in start up process.
> :~# nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:97)
> at
> org.apache.cassandra.service.StorageService.getValidKeyspace(StorageService.java:2573)
> at
> org.apache.cassandra.service.StorageService.getValidColumnFamilies(StorageService.java:2661)
> at
> org.apache.cassandra.service.StorageService.upgradeSSTables(StorageService.java:2421)
> {noformat}
> EC1:
> Patch against 2.1 (branch)
> https://github.com/apache/cassandra/compare/trunk...edwardcapriolo:exception-on-startup?expand=1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11972) Use byte[] instead of object tree in Frame.Header
[
https://issues.apache.org/jira/browse/CASSANDRA-11972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-11972:
-
Status: Patch Available (was: In Progress)
Yea - maybe. Unsure after I've sorted out all the other stuff. Had the patch
handy anyway. Wouldn't mind if it's considered not worth to commit.
||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:11972-bytes-in-header-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-11972-bytes-in-header-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-11972-bytes-in-header-trunk-dtest/lastSuccessfulBuild/]
> Use byte[] instead of object tree in Frame.Header
> -
>
> Key: CASSANDRA-11972
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11972
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> Replacing the object tree/references in {{Frame.Header}} with {{byte[9]}}
> saves a couple of object allocations. Also, not allocating the 9 bytes for
> the header off-heap is less expensive.
> (will provide a patch soon)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12010) UserTypesTest# is failing on trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-12010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15338583#comment-15338583 ] Robert Stupp commented on CASSANDRA-12010: -- Oops - sorry. Haven't seen this ticket. > UserTypesTest# is failing on trunk > -- > > Key: CASSANDRA-12010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12010 > Project: Cassandra > Issue Type: Test > Components: Testing >Reporter: Alex Petrov >Assignee: Alex Petrov > Fix For: 3.x > > > Test failure: > http://cassci.datastax.com/job/trunk_utest/1445/testReport/org.apache.cassandra.cql3.validation.entities/UserTypesTest/testAlteringUserTypeNestedWithinNonFrozenMap/ > This was caused by the merge after > [11604|https://issues.apache.org/jira/browse/CASSANDRA-11604] which probably > coincided with some other change, as this failure did not happen during the > [test run on the > branch|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-11604-trunk-testall/lastCompletedBuild/testReport/]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11967) Export metrics for prometheus in its native format
[ https://issues.apache.org/jira/browse/CASSANDRA-11967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-11967: - Status: Patch Available (was: In Progress) Patch for this: ||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:11967-prometheus-exporter-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-11967-prometheus-exporter-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-11967-prometheus-exporter-trunk-dtest/lastSuccessfulBuild/] Text from NEWS.txt: bq. Support for alternative metrics exporters has been added. To use them, the appropriate libraries need to be placed in the lib directory. Cassandra will load the class given in the system property cassandra.metricsExporter and instantiate it by calling the constructor taking an instance of com.codahale.metrics.MetricRegistry. If the provided class implements java.io.Closeable, its close() method will be called on shutdown. > Export metrics for prometheus in its native format > -- > > Key: CASSANDRA-11967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11967 > Project: Cassandra > Issue Type: Improvement >Reporter: Robert Stupp >Assignee: Robert Stupp >Priority: Minor > Fix For: 3.x > > > https://github.com/snazy/prometheus-metrics-exporter allows to export > codahale metrics for prometheus.io. In order to integrate this, a minor > change to C* is necessary to load the library. > This eliminates the need to use the additional graphite-exporter tool and > therefore also allows prometheus to track the up/down status of C*. > (Will provide the patch soon) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12034) Special handling for Netty's direct memory allocation failure
[
https://issues.apache.org/jira/browse/CASSANDRA-12034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-12034:
-
Fix Version/s: 3.x
> Special handling for Netty's direct memory allocation failure
> -
>
> Key: CASSANDRA-12034
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12034
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Fix For: 3.x
>
>
> With CASSANDRA-12032, Netty throws a
> {{io.netty.util.internal.OutOfDirectMemoryError}} if there's not enough
> off-heap memory for the response buffer. We can easily handle this situation
> and return an error. This is not a condition that destabilizes the system and
> should therefore not passed to {{JVMStabilityInspector}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12034) Special handling for Netty's direct memory allocation failure
[
https://issues.apache.org/jira/browse/CASSANDRA-12034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-12034:
-
Status: Patch Available (was: Open)
Trivial patch for this:
||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:12034-netty-oom-special-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12034-netty-oom-special-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12034-netty-oom-special-trunk-dtest/lastSuccessfulBuild/]
> Special handling for Netty's direct memory allocation failure
> -
>
> Key: CASSANDRA-12034
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12034
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>
> With CASSANDRA-12032, Netty throws a
> {{io.netty.util.internal.OutOfDirectMemoryError}} if there's not enough
> off-heap memory for the response buffer. We can easily handle this situation
> and return an error. This is not a condition that destabilizes the system and
> should therefore not passed to {{JVMStabilityInspector}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12034) Special handling for Netty's direct memory allocation failure
Robert Stupp created CASSANDRA-12034:
Summary: Special handling for Netty's direct memory allocation
failure
Key: CASSANDRA-12034
URL: https://issues.apache.org/jira/browse/CASSANDRA-12034
Project: Cassandra
Issue Type: Improvement
Reporter: Robert Stupp
Assignee: Robert Stupp
With CASSANDRA-12032, Netty throws a
{{io.netty.util.internal.OutOfDirectMemoryError}} if there's not enough
off-heap memory for the response buffer. We can easily handle this situation
and return an error. This is not a condition that destabilizes the system and
should therefore not passed to {{JVMStabilityInspector}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-11818) C* does neither recover nor trigger stability inspector on direct memory OOM
[
https://issues.apache.org/jira/browse/CASSANDRA-11818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp resolved CASSANDRA-11818.
--
Resolution: Done
The major cause of this behaviour is {{ByteBuffer.allocateDirect}} resp
{{Bits.reserveMemory}}, which is addressed in CASSANDRA-12032 and
CASSANDRA-11870.
> C* does neither recover nor trigger stability inspector on direct memory OOM
>
>
> Key: CASSANDRA-11818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11818
> Project: Cassandra
> Issue Type: Bug
>Reporter: Robert Stupp
> Attachments: 11818-direct-mem-unpooled.png, 11818-direct-mem.png,
> oom-histo-live.txt, oom-stack.txt
>
>
> The following stack trace is not caught by {{JVMStabilityInspector}}.
> Situation was caused by a load test with a lot of parallel writes and reads
> against a single node.
> {code}
> ERROR [SharedPool-Worker-1] 2016-05-17 18:38:44,187 Message.java:611 -
> Unexpected exception during request; channel = [id: 0x1e02351b,
> L:/127.0.0.1:9042 - R:/127.0.0.1:51087]
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:693) ~[na:1.8.0_92]
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> ~[na:1.8.0_92]
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> ~[na:1.8.0_92]
> at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:672)
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
> at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:234)
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
> at io.netty.buffer.PoolArena.allocate(PoolArena.java:218)
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
> at io.netty.buffer.PoolArena.allocate(PoolArena.java:138)
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
> at
> io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:270)
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
> at
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:177)
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
> at
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:168)
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
> at
> io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:105)
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
> at
> org.apache.cassandra.transport.Message$ProtocolEncoder.encode(Message.java:349)
> ~[main/:na]
> at
> org.apache.cassandra.transport.Message$ProtocolEncoder.encode(Message.java:314)
> ~[main/:na]
> at
> io.netty.handler.codec.MessageToMessageEncoder.write(MessageToMessageEncoder.java:89)
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:619)
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:676)
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:612)
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
> at
> org.apache.cassandra.transport.Message$Dispatcher$Flusher.run(Message.java:445)
> ~[main/:na]
> at
> io.netty.util.concurrent.PromiseTask$RunnableAdapter.call(PromiseTask.java:38)
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
> at
> io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:120)
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:374)
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
> at
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
> ~[netty-all-4.0.36.Final.jar:4.0.36.Final]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_92]
> {code}
> The situation does not get better when the load driver is stopped.
> I can reproduce this scenario at will. Managed to get histogram, stack traces
> and heap dump. Already increased {{-XX:MaxDirectMemorySize}} to {{2g}}.
> A {{nodetool flush}} causes the daemon to exit (as that direct-memory OOM is
> caught by {{JVMStabilityInspector}}).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11968) More metrics on native protocol requests & responses
[ https://issues.apache.org/jira/browse/CASSANDRA-11968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-11968: - Status: Patch Available (was: In Progress) Patch to add these metrics: ||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:19968-transport-metrics-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-19968-transport-metrics-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-19968-transport-metrics-trunk-dtest/lastSuccessfulBuild/] > More metrics on native protocol requests & responses > > > Key: CASSANDRA-11968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11968 > Project: Cassandra > Issue Type: Improvement >Reporter: Robert Stupp >Assignee: Robert Stupp >Priority: Minor > Fix For: 3.x > > > Proposal to add more metrics to the native protocol: > - number of requests per request-type > - number of responses by response-type > - size of request messages in bytes > - size of response messages in bytes > - number of in-flight requests (from request arrival to response) > (Will provide a patch soon) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12033) Use Netty's off-heap allocator instead of ByteBuffer.allocateDirect()
[ https://issues.apache.org/jira/browse/CASSANDRA-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp resolved CASSANDRA-12033. -- Resolution: Invalid Misunderstanding - Netty 4.0.37 already changes to use it's own off-heap space management. No additional ticket needed. > Use Netty's off-heap allocator instead of ByteBuffer.allocateDirect() > - > > Key: CASSANDRA-12033 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12033 > Project: Cassandra > Issue Type: Improvement >Reporter: Robert Stupp >Assignee: Robert Stupp > > As outlined in CASSANDRA-11818, ByteBuffer.allocateDirect() has some major > issues. > This ticket configured Netty to use use its own off-heap "space". Requires > Netty 4.0.37 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12032) Update to Netty 4.0.37
[ https://issues.apache.org/jira/browse/CASSANDRA-12032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-12032: - Status: Patch Available (was: Open) "trivial" patch: ||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:12032-netty-4.0.37-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12032-netty-4.0.37-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12032-netty-4.0.37-trunk-dtest/lastSuccessfulBuild/] > Update to Netty 4.0.37 > -- > > Key: CASSANDRA-12032 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12032 > Project: Cassandra > Issue Type: Improvement >Reporter: Robert Stupp >Assignee: Robert Stupp > Fix For: 3.x > > > Update Netty to 4.0.37 > (no C* code changes in this ticket) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-11921) Upgrade to Netty 4.1 + PR5314
[
https://issues.apache.org/jira/browse/CASSANDRA-11921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp resolved CASSANDRA-11921.
--
Resolution: Later
Fix Version/s: (was: 3.x)
4.x
Resolving this as later (4.x?). Using CASSANDRA-12032 + CASSANDRA-12033 +
CASSANDRA-11870 for 3.x versions.
> Upgrade to Netty 4.1 + PR5314
> -
>
> Key: CASSANDRA-11921
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11921
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 4.x
>
>
> Netty [PR5314|https://github.com/netty/netty/pull/5314] works around
> {{Bits.reserveMemory}}+{{Cleaner}} and introduces an independent off-heap
> memory pool.
> Requirement for CASSANDRA-11870
> Local tests of Netty4.1+PR5314 against trunk were running fine.
> Any incompatibilities or else to consider when upgrading from Netty 4.0 to
> 4.1?
> /cc [~norman] ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11870) Consider allocating direct buffers bypassing ByteBuffer.allocateDirect
[
https://issues.apache.org/jira/browse/CASSANDRA-11870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15338546#comment-15338546
]
Robert Stupp commented on CASSANDRA-11870:
--
(removed link to CASSANDRA-11921)
This code change by itself is independent, but related to CASSANDRA-12032 +
CASSANDRA-12033.
> Consider allocating direct buffers bypassing ByteBuffer.allocateDirect
> --
>
> Key: CASSANDRA-11870
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11870
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> As outlined in CASSANDRA-11818, {{ByteBuffer.allocateDirect}} uses
> {{Bits.reserveMemory}}, which is there to respect the JVM setting
> {{-XX:MaxDirectMemorySize=...}}.
> {{Bits.reserveMemory}} first tries an "optimistic" {{tryReserveMemory}} and
> exits immediately on success. However, if that somehow doesn't succeed, it
> triggers a {{System.gc()}}, which is bad IMO (however, kind of how direct
> buffers work in Java). After that GC it sleeps and tries to reserve the
> memory up to 9 times - up to 511 ms - and then throws
> {{OutOfMemoryError("Direct buffer memory")}}.
> This is unnecessary for us since we always immediately "free" direct buffers
> as soon as we no longer need them.
> Proposal: Manage direct-memory reservations in our own code and skip
> {{Bits.reserveMemory}} that way.
> (However, Netty direct buffers are not under our control.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-11870) Consider allocating direct buffers bypassing ByteBuffer.allocateDirect
[
https://issues.apache.org/jira/browse/CASSANDRA-11870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp reassigned CASSANDRA-11870:
Assignee: Robert Stupp
> Consider allocating direct buffers bypassing ByteBuffer.allocateDirect
> --
>
> Key: CASSANDRA-11870
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11870
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> As outlined in CASSANDRA-11818, {{ByteBuffer.allocateDirect}} uses
> {{Bits.reserveMemory}}, which is there to respect the JVM setting
> {{-XX:MaxDirectMemorySize=...}}.
> {{Bits.reserveMemory}} first tries an "optimistic" {{tryReserveMemory}} and
> exits immediately on success. However, if that somehow doesn't succeed, it
> triggers a {{System.gc()}}, which is bad IMO (however, kind of how direct
> buffers work in Java). After that GC it sleeps and tries to reserve the
> memory up to 9 times - up to 511 ms - and then throws
> {{OutOfMemoryError("Direct buffer memory")}}.
> This is unnecessary for us since we always immediately "free" direct buffers
> as soon as we no longer need them.
> Proposal: Manage direct-memory reservations in our own code and skip
> {{Bits.reserveMemory}} that way.
> (However, Netty direct buffers are not under our control.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12033) Use Netty's off-heap allocator instead of ByteBuffer.allocateDirect()
Robert Stupp created CASSANDRA-12033: Summary: Use Netty's off-heap allocator instead of ByteBuffer.allocateDirect() Key: CASSANDRA-12033 URL: https://issues.apache.org/jira/browse/CASSANDRA-12033 Project: Cassandra Issue Type: Improvement Reporter: Robert Stupp Assignee: Robert Stupp As outlined in CASSANDRA-11818, ByteBuffer.allocateDirect() has some major issues. This ticket configured Netty to use use its own off-heap "space". Requires Netty 4.0.37 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12032) Update to Netty 4.0.37
Robert Stupp created CASSANDRA-12032: Summary: Update to Netty 4.0.37 Key: CASSANDRA-12032 URL: https://issues.apache.org/jira/browse/CASSANDRA-12032 Project: Cassandra Issue Type: Improvement Reporter: Robert Stupp Assignee: Robert Stupp Fix For: 3.x Update Netty to 4.0.37 (no C* code changes in this ticket) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11970) Reuse DataOutputBuffer from ColumnIndex
[
https://issues.apache.org/jira/browse/CASSANDRA-11970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-11970:
-
Status: Patch Available (was: In Progress)
Patch available:
||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:11970-reuse-DOB-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-11970-reuse-DOB-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-11970-reuse-DOB-trunk-dtest/lastSuccessfulBuild/]
> Reuse DataOutputBuffer from ColumnIndex
> ---
>
> Key: CASSANDRA-11970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11970
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> With a simple change, the {{DataOutputBuffer}} used in {{ColumnIndex}} can be
> reused. This saves a couple of (larger) object allocations.
> (Will provide a patch soon)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11971) More uses of DataOutputBuffer.RECYCLER
[
https://issues.apache.org/jira/browse/CASSANDRA-11971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-11971:
-
Status: Patch Available (was: In Progress)
Patch uses recycled {{DataOutputBuffer}}s instead of allocating new ones.
Also introduces {{DataOutputBuffer.asNewBuffer()}} to replace some
{{ByteBuffer.wrap(out.getData(), 0, out.getLength())}}.
||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:11971-more-recycler-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-11971-more-recycler-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-11971-more-recycler-trunk-dtest/lastSuccessfulBuild/]
> More uses of DataOutputBuffer.RECYCLER
> --
>
> Key: CASSANDRA-11971
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11971
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> There are a few more possible use cases for {{DataOutputBuffer.RECYCLER}},
> which prevents a couple of (larger) allocations.
> (Will provide a patch soon)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
