[jira] [Assigned] (CASSANDRA-13978) dtest failure in cqlsh_tests/cqlsh_tests.py:TestCqlsh.test_pep8_compliance due to deprecation warning
[
https://issues.apache.org/jira/browse/CASSANDRA-13978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi reassigned CASSANDRA-13978:
---
Assignee: Mahdi Mohammadi
> dtest failure in cqlsh_tests/cqlsh_tests.py:TestCqlsh.test_pep8_compliance
> due to deprecation warning
> -
>
> Key: CASSANDRA-13978
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13978
> Project: Cassandra
> Issue Type: Test
> Components: Testing
>Reporter: Joel Knighton
>Assignee: Mahdi Mohammadi
>Priority: Trivial
> Labels: lhf, low-hanging-fruit
>
> The dtest {{cqlsh_tests/cqlsh_tests.py:TestCqlsh.test_pep8_compliance}} fails
> on all branches with pep8 package version 1.7.1. The pep8 package has been
> deprecated and renamed pycodestyle.
> {code}
> ==
> FAIL: test_pep8_compliance (cqlsh_tests.cqlsh_tests.TestCqlsh)
> --
> Traceback (most recent call last):
> File "/home/jkni/projects/cassandra-dtest/tools/decorators.py", line 48, in
> wrapped
> f(obj)
> File "/home/jkni/projects/cassandra-dtest/cqlsh_tests/cqlsh_tests.py", line
> 68, in test_pep8_compliance
> self.assertEqual(len(stderr), 0, stderr)
> AssertionError:
> /home/jkni/projects/cassandra-dtest/venv/lib/python2.7/site-packages/pep8.py:2124:
> UserWarning:
> pep8 has been renamed to pycodestyle (GitHub issue #466)
> Use of the pep8 tool will be removed in a future release.
> Please install and use `pycodestyle` instead.
> $ pip install pycodestyle
> $ pycodestyle ...
> '\n\n'
> {code}
> We should update this dependency from pep8 to pycodestyle. With this change,
> several new errors are thrown. I don't know if these are new checks that we
> should choose to ignore, false positives due to new behaviors, or false
> negatives that are now successfully caught. If they were previously false
> negatives, we'll need to fix these in cqlsh on some branches.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12922) Bloom filter miss counts are not measured correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-12922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15691849#comment-15691849
]
Mahdi Mohammadi commented on CASSANDRA-12922:
-
Ok. I will add a test.
> Bloom filter miss counts are not measured correctly
> ---
>
> Key: CASSANDRA-12922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12922
> Project: Cassandra
> Issue Type: Bug
>Reporter: Branimir Lambov
>Assignee: Mahdi Mohammadi
>
> Bloom filter hits and misses are evaluated incorrectly in
> {{BigTableReader.getPosition}}: we properly record hits, but not misses. In
> particular, if we don't find a match for a key in the index, which is where
> almost all non-matches will be rejected, [we don't record a bloom filter
> false
> positive|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/big/BigTableReader.java#L228].
> This leads to very misleading output from e.g. {{nodetool tablestats}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12922) Bloom filter miss counts are not measured correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-12922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15685644#comment-15685644
]
Mahdi Mohammadi edited comment on CASSANDRA-12922 at 11/22/16 4:24 AM:
---
||trunk|3.X||
|[branch|https://github.com/apache/cassandra/compare/trunk...mm-binary:trunk-12922]|[branch|https://github.com/apache/cassandra/compare/trunk...mm-binary:12922-3.X]|
was (Author: mahdix):
||trunk|3.X||
|[branch|https://github.com/apache/cassandra/compare/trunk...mm-binary:trunk-12922]|
|[branch|https://github.com/apache/cassandra/compare/trunk...mm-binary:12922-3.X]|
> Bloom filter miss counts are not measured correctly
> ---
>
> Key: CASSANDRA-12922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12922
> Project: Cassandra
> Issue Type: Bug
>Reporter: Branimir Lambov
>Assignee: Mahdi Mohammadi
>
> Bloom filter hits and misses are evaluated incorrectly in
> {{BigTableReader.getPosition}}: we properly record hits, but not misses. In
> particular, if we don't find a match for a key in the index, which is where
> almost all non-matches will be rejected, [we don't record a bloom filter
> false
> positive|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/big/BigTableReader.java#L228].
> This leads to very misleading output from e.g. {{nodetool tablestats}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12922) Bloom filter miss counts are not measured correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-12922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15685653#comment-15685653
]
Mahdi Mohammadi commented on CASSANDRA-12922:
-
Can someone take a look?
> Bloom filter miss counts are not measured correctly
> ---
>
> Key: CASSANDRA-12922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12922
> Project: Cassandra
> Issue Type: Bug
>Reporter: Branimir Lambov
>Assignee: Mahdi Mohammadi
>
> Bloom filter hits and misses are evaluated incorrectly in
> {{BigTableReader.getPosition}}: we properly record hits, but not misses. In
> particular, if we don't find a match for a key in the index, which is where
> almost all non-matches will be rejected, [we don't record a bloom filter
> false
> positive|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/big/BigTableReader.java#L228].
> This leads to very misleading output from e.g. {{nodetool tablestats}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12922) Bloom filter miss counts are not measured correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-12922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-12922:
Status: Patch Available (was: Open)
> Bloom filter miss counts are not measured correctly
> ---
>
> Key: CASSANDRA-12922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12922
> Project: Cassandra
> Issue Type: Bug
>Reporter: Branimir Lambov
>Assignee: Mahdi Mohammadi
>
> Bloom filter hits and misses are evaluated incorrectly in
> {{BigTableReader.getPosition}}: we properly record hits, but not misses. In
> particular, if we don't find a match for a key in the index, which is where
> almost all non-matches will be rejected, [we don't record a bloom filter
> false
> positive|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/big/BigTableReader.java#L228].
> This leads to very misleading output from e.g. {{nodetool tablestats}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12922) Bloom filter miss counts are not measured correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-12922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15685644#comment-15685644
]
Mahdi Mohammadi edited comment on CASSANDRA-12922 at 11/22/16 4:24 AM:
---
||trunk||3.X||
|[branch|https://github.com/apache/cassandra/compare/trunk...mm-binary:trunk-12922]|[branch|https://github.com/apache/cassandra/compare/trunk...mm-binary:12922-3.X]|
was (Author: mahdix):
||trunk|3.X||
|[branch|https://github.com/apache/cassandra/compare/trunk...mm-binary:trunk-12922]|[branch|https://github.com/apache/cassandra/compare/trunk...mm-binary:12922-3.X]|
> Bloom filter miss counts are not measured correctly
> ---
>
> Key: CASSANDRA-12922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12922
> Project: Cassandra
> Issue Type: Bug
>Reporter: Branimir Lambov
>Assignee: Mahdi Mohammadi
>
> Bloom filter hits and misses are evaluated incorrectly in
> {{BigTableReader.getPosition}}: we properly record hits, but not misses. In
> particular, if we don't find a match for a key in the index, which is where
> almost all non-matches will be rejected, [we don't record a bloom filter
> false
> positive|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/big/BigTableReader.java#L228].
> This leads to very misleading output from e.g. {{nodetool tablestats}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12922) Bloom filter miss counts are not measured correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-12922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15685644#comment-15685644
]
Mahdi Mohammadi edited comment on CASSANDRA-12922 at 11/22/16 4:23 AM:
---
||trunk|3.X||
|[branch|https://github.com/apache/cassandra/compare/trunk...mm-binary:trunk-12922]|
|[branch|https://github.com/apache/cassandra/compare/trunk...mm-binary:12922-3.X]|
was (Author: mahdix):
||trunk||
|[branch|https://github.com/apache/cassandra/compare/trunk...mm-binary:trunk-12922]|
> Bloom filter miss counts are not measured correctly
> ---
>
> Key: CASSANDRA-12922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12922
> Project: Cassandra
> Issue Type: Bug
>Reporter: Branimir Lambov
>Assignee: Mahdi Mohammadi
>
> Bloom filter hits and misses are evaluated incorrectly in
> {{BigTableReader.getPosition}}: we properly record hits, but not misses. In
> particular, if we don't find a match for a key in the index, which is where
> almost all non-matches will be rejected, [we don't record a bloom filter
> false
> positive|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/big/BigTableReader.java#L228].
> This leads to very misleading output from e.g. {{nodetool tablestats}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12922) Bloom filter miss counts are not measured correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-12922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15685644#comment-15685644
]
Mahdi Mohammadi commented on CASSANDRA-12922:
-
||trunk||
|[branch|https://github.com/apache/cassandra/compare/trunk...mm-binary:trunk-12922]|
> Bloom filter miss counts are not measured correctly
> ---
>
> Key: CASSANDRA-12922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12922
> Project: Cassandra
> Issue Type: Bug
>Reporter: Branimir Lambov
>Assignee: Mahdi Mohammadi
>
> Bloom filter hits and misses are evaluated incorrectly in
> {{BigTableReader.getPosition}}: we properly record hits, but not misses. In
> particular, if we don't find a match for a key in the index, which is where
> almost all non-matches will be rejected, [we don't record a bloom filter
> false
> positive|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/big/BigTableReader.java#L228].
> This leads to very misleading output from e.g. {{nodetool tablestats}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-12922) Bloom filter miss counts are not measured correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-12922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi reassigned CASSANDRA-12922:
---
Assignee: Mahdi Mohammadi
> Bloom filter miss counts are not measured correctly
> ---
>
> Key: CASSANDRA-12922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12922
> Project: Cassandra
> Issue Type: Bug
>Reporter: Branimir Lambov
>Assignee: Mahdi Mohammadi
>
> Bloom filter hits and misses are evaluated incorrectly in
> {{BigTableReader.getPosition}}: we properly record hits, but not misses. In
> particular, if we don't find a match for a key in the index, which is where
> almost all non-matches will be rejected, [we don't record a bloom filter
> false
> positive|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/big/BigTableReader.java#L228].
> This leads to very misleading output from e.g. {{nodetool tablestats}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11949) GC log directory should be created in startup scripts
[
https://issues.apache.org/jira/browse/CASSANDRA-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566806#comment-15566806
]
Mahdi Mohammadi commented on CASSANDRA-11949:
-
[~mshuler], [~JoshuaMcKenzie] Shall I close this ticket?
> GC log directory should be created in startup scripts
> -
>
> Key: CASSANDRA-11949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11949
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> In [CASSANDRA-10140], we enabled GC logging by default, since the overhead
> was low and asking people providing diagnostics to restart can often make it
> more difficult to diagnose problems.
> The default GC log path is set to {{$CASSANDRA_HOME/logs/gc.log}} in
> {{cassandra-env.sh}}, a directory that is not present in a fresh
> clone/install. Even if logback creates this directory later in startup, it is
> not present when the JVM initiates GC logging, so GC logging will silently
> fail for this first Cassandra run
> I haven't tested this in Windows but suspect the same problem may occur.
> Since lots of tooling around Cassandra won't create this directory, we should
> instead consider attempting to create it in our startup scripts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11949) GC log directory should be created in startup scripts
[
https://issues.apache.org/jira/browse/CASSANDRA-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407838#comment-15407838
]
Mahdi Mohammadi commented on CASSANDRA-11949:
-
[~mshuler], [~JoshuaMcKenzie] Shall I close this ticket?
> GC log directory should be created in startup scripts
> -
>
> Key: CASSANDRA-11949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11949
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Fix For: 2.2.8, 3.0.9, 3.9
>
>
> In [CASSANDRA-10140], we enabled GC logging by default, since the overhead
> was low and asking people providing diagnostics to restart can often make it
> more difficult to diagnose problems.
> The default GC log path is set to {{$CASSANDRA_HOME/logs/gc.log}} in
> {{cassandra-env.sh}}, a directory that is not present in a fresh
> clone/install. Even if logback creates this directory later in startup, it is
> not present when the JVM initiates GC logging, so GC logging will silently
> fail for this first Cassandra run
> I haven't tested this in Windows but suspect the same problem may occur.
> Since lots of tooling around Cassandra won't create this directory, we should
> instead consider attempting to create it in our startup scripts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-12154) "SELECT * FROM foo LIMIT ;" does not error out
[
https://issues.apache.org/jira/browse/CASSANDRA-12154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi reassigned CASSANDRA-12154:
---
Assignee: Mahdi Mohammadi
> "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
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
>
> 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-11949) GC log directory should be created in startup scripts
[
https://issues.apache.org/jira/browse/CASSANDRA-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11949:
Status: Patch Available (was: Reopened)
> GC log directory should be created in startup scripts
> -
>
> Key: CASSANDRA-11949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11949
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Fix For: 2.2.8, 3.0.9, 3.9
>
>
> In [CASSANDRA-10140], we enabled GC logging by default, since the overhead
> was low and asking people providing diagnostics to restart can often make it
> more difficult to diagnose problems.
> The default GC log path is set to {{$CASSANDRA_HOME/logs/gc.log}} in
> {{cassandra-env.sh}}, a directory that is not present in a fresh
> clone/install. Even if logback creates this directory later in startup, it is
> not present when the JVM initiates GC logging, so GC logging will silently
> fail for this first Cassandra run
> I haven't tested this in Windows but suspect the same problem may occur.
> Since lots of tooling around Cassandra won't create this directory, we should
> instead consider attempting to create it in our startup scripts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11949) GC log directory should be created in startup scripts
[
https://issues.apache.org/jira/browse/CASSANDRA-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15389777#comment-15389777
]
Mahdi Mohammadi commented on CASSANDRA-11949:
-
[Branch for 2.2+|https://github.com/mm-binary/cassandra/tree/11949-2.2]
> GC log directory should be created in startup scripts
> -
>
> Key: CASSANDRA-11949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11949
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Fix For: 2.2.8, 3.0.9, 3.9
>
>
> In [CASSANDRA-10140], we enabled GC logging by default, since the overhead
> was low and asking people providing diagnostics to restart can often make it
> more difficult to diagnose problems.
> The default GC log path is set to {{$CASSANDRA_HOME/logs/gc.log}} in
> {{cassandra-env.sh}}, a directory that is not present in a fresh
> clone/install. Even if logback creates this directory later in startup, it is
> not present when the JVM initiates GC logging, so GC logging will silently
> fail for this first Cassandra run
> I haven't tested this in Windows but suspect the same problem may occur.
> Since lots of tooling around Cassandra won't create this directory, we should
> instead consider attempting to create it in our startup scripts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11949) GC log directory should be created in startup scripts
[
https://issues.apache.org/jira/browse/CASSANDRA-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357927#comment-15357927
]
Mahdi Mohammadi commented on CASSANDRA-11949:
-
Ok. I will fix this.
> GC log directory should be created in startup scripts
> -
>
> Key: CASSANDRA-11949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11949
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Fix For: 2.2.7, 3.0.9, 3.9
>
>
> In [CASSANDRA-10140], we enabled GC logging by default, since the overhead
> was low and asking people providing diagnostics to restart can often make it
> more difficult to diagnose problems.
> The default GC log path is set to {{$CASSANDRA_HOME/logs/gc.log}} in
> {{cassandra-env.sh}}, a directory that is not present in a fresh
> clone/install. Even if logback creates this directory later in startup, it is
> not present when the JVM initiates GC logging, so GC logging will silently
> fail for this first Cassandra run
> I haven't tested this in Windows but suspect the same problem may occur.
> Since lots of tooling around Cassandra won't create this directory, we should
> instead consider attempting to create it in our startup scripts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11949) GC log directory should be created in startup scripts
[
https://issues.apache.org/jira/browse/CASSANDRA-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356520#comment-15356520
]
Mahdi Mohammadi commented on CASSANDRA-11949:
-
Thank you.
> GC log directory should be created in startup scripts
> -
>
> Key: CASSANDRA-11949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11949
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Fix For: 2.2.7, 3.0.9, 3.9
>
>
> In [CASSANDRA-10140], we enabled GC logging by default, since the overhead
> was low and asking people providing diagnostics to restart can often make it
> more difficult to diagnose problems.
> The default GC log path is set to {{$CASSANDRA_HOME/logs/gc.log}} in
> {{cassandra-env.sh}}, a directory that is not present in a fresh
> clone/install. Even if logback creates this directory later in startup, it is
> not present when the JVM initiates GC logging, so GC logging will silently
> fail for this first Cassandra run
> I haven't tested this in Windows but suspect the same problem may occur.
> Since lots of tooling around Cassandra won't create this directory, we should
> instead consider attempting to create it in our startup scripts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11949) GC log directory should be created in startup scripts
[
https://issues.apache.org/jira/browse/CASSANDRA-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11949:
Status: Patch Available (was: In Progress)
I tested the 2.2 branch on "Windows 7". It's fine except that it requires me to
run some command to enable some policy in the PowerShell console to be able to
create the directory.
> GC log directory should be created in startup scripts
> -
>
> Key: CASSANDRA-11949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11949
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Mahdi Mohammadi
>Priority: Minor
>
> In [CASSANDRA-10140], we enabled GC logging by default, since the overhead
> was low and asking people providing diagnostics to restart can often make it
> more difficult to diagnose problems.
> The default GC log path is set to {{$CASSANDRA_HOME/logs/gc.log}} in
> {{cassandra-env.sh}}, a directory that is not present in a fresh
> clone/install. Even if logback creates this directory later in startup, it is
> not present when the JVM initiates GC logging, so GC logging will silently
> fail for this first Cassandra run
> I haven't tested this in Windows but suspect the same problem may occur.
> Since lots of tooling around Cassandra won't create this directory, we should
> instead consider attempting to create it in our startup scripts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11949) GC log directory should be created in startup scripts
[
https://issues.apache.org/jira/browse/CASSANDRA-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15344043#comment-15344043
]
Mahdi Mohammadi commented on CASSANDRA-11949:
-
||2.2||3.0||
|[branch|https://github.com/mm-binary/cassandra/tree/11949-2.2]|[branch|https://github.com/mm-binary/cassandra/tree/11949-3.0]|
> GC log directory should be created in startup scripts
> -
>
> Key: CASSANDRA-11949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11949
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Mahdi Mohammadi
>Priority: Minor
>
> In [CASSANDRA-10140], we enabled GC logging by default, since the overhead
> was low and asking people providing diagnostics to restart can often make it
> more difficult to diagnose problems.
> The default GC log path is set to {{$CASSANDRA_HOME/logs/gc.log}} in
> {{cassandra-env.sh}}, a directory that is not present in a fresh
> clone/install. Even if logback creates this directory later in startup, it is
> not present when the JVM initiates GC logging, so GC logging will silently
> fail for this first Cassandra run
> I haven't tested this in Windows but suspect the same problem may occur.
> Since lots of tooling around Cassandra won't create this directory, we should
> instead consider attempting to create it in our startup scripts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12035) Structure for tpstats output (JSON, YAML)
[ https://issues.apache.org/jira/browse/CASSANDRA-12035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15340474#comment-15340474 ] Mahdi Mohammadi commented on CASSANDRA-12035: - Please assign the ticket to yourself. > Structure for tpstats output (JSON, YAML) > - > > Key: CASSANDRA-12035 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12035 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Hiroyuki Nishi >Priority: Minor > Attachments: CASSANDRA-12035-trunk.patch, > tablestats_sample_result.json, tablestats_sample_result.txt, > tablestats_sample_result.yaml, tpstats_sample_result.json, > tpstats_sample_result.txt, tpstats_sample_result.yaml > > > In CASSANDRA-5977, some extra output formats such as JSON and YAML were added > for nodetool tablestats. > Similarly, I would like to add the output formats in nodetool tpstats. > Also, I tried to refactor the tablestats's code about the output formats to > integrate the existing code with my code. > Please review the attached patch. -- 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=15338935#comment-15338935
]
Mahdi Mohammadi commented on CASSANDRA-11870:
-
Shouldn't we set a default value for `max_direct_memory_in_mb` in Config.java?
> 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-11949) GC log directory should be created in startup scripts
[
https://issues.apache.org/jira/browse/CASSANDRA-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15332627#comment-15332627
]
Mahdi Mohammadi commented on CASSANDRA-11949:
-
Branch: [2.2|https://github.com/mm-binary/cassandra/tree/11949-2.2]
> GC log directory should be created in startup scripts
> -
>
> Key: CASSANDRA-11949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11949
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Mahdi Mohammadi
>Priority: Minor
>
> In [CASSANDRA-10140], we enabled GC logging by default, since the overhead
> was low and asking people providing diagnostics to restart can often make it
> more difficult to diagnose problems.
> The default GC log path is set to {{$CASSANDRA_HOME/logs/gc.log}} in
> {{cassandra-env.sh}}, a directory that is not present in a fresh
> clone/install. Even if logback creates this directory later in startup, it is
> not present when the JVM initiates GC logging, so GC logging will silently
> fail for this first Cassandra run
> I haven't tested this in Windows but suspect the same problem may occur.
> Since lots of tooling around Cassandra won't create this directory, we should
> instead consider attempting to create it in our startup scripts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-12012) CQLSSTableWriter and composite clustering keys trigger NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-12012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi reassigned CASSANDRA-12012:
---
Assignee: Mahdi Mohammadi
> CQLSSTableWriter and composite clustering keys trigger NPE
> --
>
> Key: CASSANDRA-12012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12012
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Pierre N.
>Assignee: Mahdi Mohammadi
>
> It triggers when using multiple clustering keys in the primary keys
> {code}
> package tests;
> import java.io.File;
> import org.apache.cassandra.io.sstable.CQLSSTableWriter;
> import org.apache.cassandra.config.Config;
> public class DefaultWriter {
>
> public static void main(String[] args) throws Exception {
> Config.setClientMode(true);
>
> String createTableQuery = "CREATE TABLE ks_test.table_test ("
> + "pk1 int,"
> + "ck1 int,"
> + "ck2 int,"
> + "PRIMARY KEY ((pk1), ck1, ck2)"
> + ");";
> String insertQuery = "INSERT INTO ks_test.table_test(pk1, ck1, ck2)
> VALUES(?,?,?)";
>
> CQLSSTableWriter writer = CQLSSTableWriter.builder()
> .inDirectory(File.createTempFile("sstdir", "-tmp"))
> .forTable(createTableQuery)
> .using(insertQuery)
> .build();
> writer.close();
> }
> }
> {code}
> Exception :
> {code}
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at org.apache.cassandra.db.Keyspace.openAndGetStore(Keyspace.java:159)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.hasSupportingIndex(PrimaryKeyRestrictionSet.java:156)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.(PrimaryKeyRestrictionSet.java:118)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.mergeWith(PrimaryKeyRestrictionSet.java:213)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addSingleColumnRestriction(StatementRestrictions.java:266)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addRestriction(StatementRestrictions.java:250)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.(StatementRestrictions.java:159)
> at
> org.apache.cassandra.cql3.statements.UpdateStatement$ParsedInsert.prepareInternal(UpdateStatement.java:183)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:782)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:768)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:505)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.getStatement(CQLSSTableWriter.java:508)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.using(CQLSSTableWriter.java:439)
> at tests.DefaultWriter.main(DefaultWriter.java:29)
> Caused by: java.lang.NullPointerException
> at
> org.apache.cassandra.config.DatabaseDescriptor.getFlushWriters(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:127)
> ... 18 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11933) Cache local ranges when calculating repair neighbors
[
https://issues.apache.org/jira/browse/CASSANDRA-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15330566#comment-15330566
]
Mahdi Mohammadi commented on CASSANDRA-11933:
-
Wow! This is great.
> Cache local ranges when calculating repair neighbors
>
>
> Key: CASSANDRA-11933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11933
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Cyril Scetbon
>Assignee: Mahdi Mohammadi
>
> During a full repair on a ~ 60 nodes cluster, I've been able to see that
> this stage can be significant (up to 60 percent of the whole time) :
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/StorageService.java#L2983-L2997
> It's merely caused by the fact that
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/ActiveRepairService.java#L189
> calls {code}ss.getLocalRanges(keyspaceName){code} everytime and that it
> takes more than 99% of the time. This call takes 600ms when there is no load
> on the cluster and more if there is. So for 10k ranges, you can imagine that
> it takes at least 1.5 hours just to compute ranges.
> Underneath it calls
> [ReplicationStrategy.getAddressRanges|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L170]
> which can get pretty inefficient ([~jbellis]'s
> [words|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L165])
> *ss.getLocalRanges(keyspaceName)* should be cached to avoid having to spend
> hours on it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11933) Improve Repair performance
[
https://issues.apache.org/jira/browse/CASSANDRA-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328318#comment-15328318
]
Mahdi Mohammadi commented on CASSANDRA-11933:
-
Can someone setup CI for this ticket?
> Improve Repair performance
> --
>
> Key: CASSANDRA-11933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11933
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Cyril Scetbon
>Assignee: Mahdi Mohammadi
>
> During a full repair on a ~ 60 nodes cluster, I've been able to see that
> this stage can be significant (up to 60 percent of the whole time) :
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/StorageService.java#L2983-L2997
> It's merely caused by the fact that
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/ActiveRepairService.java#L189
> calls {code}ss.getLocalRanges(keyspaceName){code} everytime and that it
> takes more than 99% of the time. This call takes 600ms when there is no load
> on the cluster and more if there is. So for 10k ranges, you can imagine that
> it takes at least 1.5 hours just to compute ranges.
> Underneath it calls
> [ReplicationStrategy.getAddressRanges|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L170]
> which can get pretty inefficient ([~jbellis]'s
> [words|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L165])
> *ss.getLocalRanges(keyspaceName)* should be cached to avoid having to spend
> hours on it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8700) replace the wiki with docs in the git repo
[ https://issues.apache.org/jira/browse/CASSANDRA-8700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326059#comment-15326059 ] Mahdi Mohammadi commented on CASSANDRA-8700: In this way, it will be much easier for non-committers to update documentation. > replace the wiki with docs in the git repo > -- > > Key: CASSANDRA-8700 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8700 > Project: Cassandra > Issue Type: Improvement > Components: Documentation and Website >Reporter: Jon Haddad >Assignee: Sylvain Lebresne >Priority: Minor > Attachments: drivers_list.md, installation.md > > > The wiki as it stands is pretty terrible. It takes several minutes to apply > a single update, and as a result, it's almost never updated. The information > there has very little context as to what version it applies to. Most people > I've talked to that try to use the information they find there find it is > more confusing than helpful. > I'd like to propose that instead of using the wiki, the doc directory in the > cassandra repo be used for docs (already used for CQL3 spec) in a format that > can be built to a variety of output formats like HTML / epub / etc. I won't > start the bikeshedding on which markup format is preferable - but there are > several options that can work perfectly fine. I've personally use sphinx w/ > restructured text, and markdown. Both can build easily and as an added bonus > be pushed to readthedocs (or something similar) automatically. For an > example, see cqlengine's documentation, which I think is already > significantly better than the wiki: > http://cqlengine.readthedocs.org/en/latest/ > In addition to being overall easier to maintain, putting the documentation in > the git repo adds context, since it evolves with the versions of Cassandra. > If the wiki were kept even remotely up to date, I wouldn't bother with this, > but not having at least some basic documentation in the repo, or anywhere > associated with the project, is frustrating. > For reference, the last 3 updates were: > 1/15/15 - updating committers list > 1/08/15 - updating contributers and how to contribute > 12/16/14 - added a link to CQL docs from wiki frontpage (by me) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-11949) GC log directory should be created in startup scripts
[
https://issues.apache.org/jira/browse/CASSANDRA-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi reassigned CASSANDRA-11949:
---
Assignee: Mahdi Mohammadi
> GC log directory should be created in startup scripts
> -
>
> Key: CASSANDRA-11949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11949
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Mahdi Mohammadi
>Priority: Minor
>
> In [CASSANDRA-10140], we enabled GC logging by default, since the overhead
> was low and asking people providing diagnostics to restart can often make it
> more difficult to diagnose problems.
> The default GC log path is set to {{$CASSANDRA_HOME/logs/gc.log}} in
> {{cassandra-env.sh}}, a directory that is not present in a fresh
> clone/install. Even if logback creates this directory later in startup, it is
> not present when the JVM initiates GC logging, so GC logging will silently
> fail for this first Cassandra run
> I haven't tested this in Windows but suspect the same problem may occur.
> Since lots of tooling around Cassandra won't create this directory, we should
> instead consider attempting to create it in our startup scripts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15325560#comment-15325560
]
Mahdi Mohammadi commented on CASSANDRA-11719:
-
No problem. Should I set this ticket to "Resolved"?
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11961) Nonfatal NPE in CompactionMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-11961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15322096#comment-15322096
]
Mahdi Mohammadi commented on CASSANDRA-11961:
-
Seems good to me. Please assign yourself to the issue.
> Nonfatal NPE in CompactionMetrics
> -
>
> Key: CASSANDRA-11961
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11961
> Project: Cassandra
> Issue Type: Bug
>Reporter: Robert Stupp
>Priority: Minor
> Labels: lhf
>
> Just saw the following NPE on trunk. Means, that {{metaData}} from
> {{CFMetaData metaData = compaction.getCompactionInfo().getCFMetaData();}} is
> {{null}}. A simple {{if (metaData == null) continue;}} should fix this.
> {code}
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.cassandra.metrics.CompactionMetrics$2.getValue(CompactionMetrics.java:103)
> ~[main/:na]
> at
> org.apache.cassandra.metrics.CompactionMetrics$2.getValue(CompactionMetrics.java:78)
> ~[main/:na]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11719:
Attachment: (was: 11719-trunk.patch)
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11719:
Status: Patch Available (was: In Progress)
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 11719-trunk.patch
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15321506#comment-15321506
]
Mahdi Mohammadi commented on CASSANDRA-11719:
-
Branch for trunk:
[branch|https://github.com/mm-binary/cassandra/tree/11719-trunk]
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 11719-trunk.patch
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11933) Improve Repair performance
[
https://issues.apache.org/jira/browse/CASSANDRA-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15321471#comment-15321471
]
Mahdi Mohammadi commented on CASSANDRA-11933:
-
[~pauloricardomg] Would you please setup CI for my branches?
> Improve Repair performance
> --
>
> Key: CASSANDRA-11933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11933
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Cyril Scetbon
>Assignee: Mahdi Mohammadi
>
> During a full repair on a ~ 60 nodes cluster, I've been able to see that
> this stage can be significant (up to 60 percent of the whole time) :
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/StorageService.java#L2983-L2997
> It's merely caused by the fact that
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/ActiveRepairService.java#L189
> calls {code}ss.getLocalRanges(keyspaceName){code} everytime and that it
> takes more than 99% of the time. This call takes 600ms when there is no load
> on the cluster and more if there is. So for 10k ranges, you can imagine that
> it takes at least 1.5 hours just to compute ranges.
> Underneath it calls
> [ReplicationStrategy.getAddressRanges|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L170]
> which can get pretty inefficient ([~jbellis]'s
> [words|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L165])
> *ss.getLocalRanges(keyspaceName)* should be cached to avoid having to spend
> hours on it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11933) Improve Repair performance
[
https://issues.apache.org/jira/browse/CASSANDRA-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11933:
Status: Patch Available (was: In Progress)
> Improve Repair performance
> --
>
> Key: CASSANDRA-11933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11933
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Cyril Scetbon
>Assignee: Mahdi Mohammadi
>
> During a full repair on a ~ 60 nodes cluster, I've been able to see that
> this stage can be significant (up to 60 percent of the whole time) :
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/StorageService.java#L2983-L2997
> It's merely caused by the fact that
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/ActiveRepairService.java#L189
> calls {code}ss.getLocalRanges(keyspaceName){code} everytime and that it
> takes more than 99% of the time. This call takes 600ms when there is no load
> on the cluster and more if there is. So for 10k ranges, you can imagine that
> it takes at least 1.5 hours just to compute ranges.
> Underneath it calls
> [ReplicationStrategy.getAddressRanges|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L170]
> which can get pretty inefficient ([~jbellis]'s
> [words|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L165])
> *ss.getLocalRanges(keyspaceName)* should be cached to avoid having to spend
> hours on it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11961) Nonfatal NPE in CompactionMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-11961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11961:
Labels: lhf (was: )
> Nonfatal NPE in CompactionMetrics
> -
>
> Key: CASSANDRA-11961
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11961
> Project: Cassandra
> Issue Type: Bug
>Reporter: Robert Stupp
>Priority: Minor
> Labels: lhf
>
> Just saw the following NPE on trunk. Means, that {{metaData}} from
> {{CFMetaData metaData = compaction.getCompactionInfo().getCFMetaData();}} is
> {{null}}. A simple {{if (metaData == null) continue;}} should fix this.
> {code}
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.cassandra.metrics.CompactionMetrics$2.getValue(CompactionMetrics.java:103)
> ~[main/:na]
> at
> org.apache.cassandra.metrics.CompactionMetrics$2.getValue(CompactionMetrics.java:78)
> ~[main/:na]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11933) Improve Repair performance
[
https://issues.apache.org/jira/browse/CASSANDRA-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15315660#comment-15315660
]
Mahdi Mohammadi commented on CASSANDRA-11933:
-
[~pauloricardomg] can you please set-up CI for my branches again?
> Improve Repair performance
> --
>
> Key: CASSANDRA-11933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11933
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Cyril Scetbon
>Assignee: Mahdi Mohammadi
>
> During a full repair on a ~ 60 nodes cluster, I've been able to see that
> this stage can be significant (up to 60 percent of the whole time) :
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/StorageService.java#L2983-L2997
> It's merely caused by the fact that
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/ActiveRepairService.java#L189
> calls {code}ss.getLocalRanges(keyspaceName){code} everytime and that it
> takes more than 99% of the time. This call takes 600ms when there is no load
> on the cluster and more if there is. So for 10k ranges, you can imagine that
> it takes at least 1.5 hours just to compute ranges.
> Underneath it calls
> [ReplicationStrategy.getAddressRanges|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L170]
> which can get pretty inefficient ([~jbellis]'s
> [words|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L165])
> *ss.getLocalRanges(keyspaceName)* should be cached to avoid having to spend
> hours on it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11933) Improve Repair performance
[
https://issues.apache.org/jira/browse/CASSANDRA-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15314971#comment-15314971
]
Mahdi Mohammadi edited comment on CASSANDRA-11933 at 6/4/16 10:03 PM:
--
||2.1||2.2||3.0||3.6||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...mm-binary:11933-2.1?expand=1]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...mm-binary:11933-2.2?expand=0]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...mm-binary:11933-3.0?expand=1]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.6...mm-binary:11933-3.6?diff=unified=1=11933-3.6]|
|testall|testall|testall|testall|
|dtest|dtest|dtest|dtest|
The 3.6 branch can be automatically merged into cassandra-3.7 so no need for a
separate branch.
was (Author: mahdix):
||2.1||2.2||3.0||3.6||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...mm-binary:11933-2.1?expand=1]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...mm-binary:11933-2.2?expand=0]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...mm-binary:11933-3.0?expand=1]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.6...mm-binary:11933-3.6?diff=unified=1=11933-3.6]|
|testall|testall|testall|testall|
|dtest|dtest|dtest|dtest|
Will continue to add remaining branches if can't be auto-merged.
> Improve Repair performance
> --
>
> Key: CASSANDRA-11933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11933
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Cyril Scetbon
>Assignee: Mahdi Mohammadi
>
> During a full repair on a ~ 60 nodes cluster, I've been able to see that
> this stage can be significant (up to 60 percent of the whole time) :
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/StorageService.java#L2983-L2997
> It's merely caused by the fact that
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/ActiveRepairService.java#L189
> calls {code}ss.getLocalRanges(keyspaceName){code} everytime and that it
> takes more than 99% of the time. This call takes 600ms when there is no load
> on the cluster and more if there is. So for 10k ranges, you can imagine that
> it takes at least 1.5 hours just to compute ranges.
> Underneath it calls
> [ReplicationStrategy.getAddressRanges|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L170]
> which can get pretty inefficient ([~jbellis]'s
> [words|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L165])
> *ss.getLocalRanges(keyspaceName)* should be cached to avoid having to spend
> hours on it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11933) Improve Repair performance
[
https://issues.apache.org/jira/browse/CASSANDRA-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15314971#comment-15314971
]
Mahdi Mohammadi edited comment on CASSANDRA-11933 at 6/4/16 10:01 PM:
--
||2.1||2.2||3.0||3.6||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...mm-binary:11933-2.1?expand=1]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...mm-binary:11933-2.2?expand=0]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...mm-binary:11933-3.0?expand=1]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.6...mm-binary:11933-3.6?diff=unified=1=11933-3.6]|
|testall|testall|testall|testall|
|dtest|dtest|dtest|dtest|
Will continue to add remaining branches if can't be auto-merged.
was (Author: mahdix):
||2.1||2.2||3.0||3.6||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...mm-binary:11933-2.1?expand=1]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...mm-binary:11933-2.2?expand=0]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...mm-binary:11933-3.0?expand=1]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.6...mm-binary:11933-3.6?diff=unified=1=11933-3.6]|
|testall|testall|testall|
|dtest|dtest|dtest|
Will continue to add remaining branches if can't be auto-merged.
> Improve Repair performance
> --
>
> Key: CASSANDRA-11933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11933
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Cyril Scetbon
>Assignee: Mahdi Mohammadi
>
> During a full repair on a ~ 60 nodes cluster, I've been able to see that
> this stage can be significant (up to 60 percent of the whole time) :
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/StorageService.java#L2983-L2997
> It's merely caused by the fact that
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/ActiveRepairService.java#L189
> calls {code}ss.getLocalRanges(keyspaceName){code} everytime and that it
> takes more than 99% of the time. This call takes 600ms when there is no load
> on the cluster and more if there is. So for 10k ranges, you can imagine that
> it takes at least 1.5 hours just to compute ranges.
> Underneath it calls
> [ReplicationStrategy.getAddressRanges|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L170]
> which can get pretty inefficient ([~jbellis]'s
> [words|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L165])
> *ss.getLocalRanges(keyspaceName)* should be cached to avoid having to spend
> hours on it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11933) Improve Repair performance
[
https://issues.apache.org/jira/browse/CASSANDRA-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15314971#comment-15314971
]
Mahdi Mohammadi edited comment on CASSANDRA-11933 at 6/4/16 9:59 PM:
-
||2.1||2.2||3.0||3.6||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...mm-binary:11933-2.1?expand=1]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...mm-binary:11933-2.2?expand=0]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...mm-binary:11933-3.0?expand=1]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.6...mm-binary:11933-3.6?diff=unified=1=11933-3.6]|
|testall|testall|testall|
|dtest|dtest|dtest|
Will continue to add remaining branches if can't be auto-merged.
was (Author: mahdix):
||2.1||2.2||3.0||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...mm-binary:11933-2.1?expand=1]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...mm-binary:11933-2.2?expand=0]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...mm-binary:11933-3.0?expand=1]
|testall|testall|testall|
|dtest|dtest|dtest|
Will continue to add remaining branches if can't be auto-merged.
> Improve Repair performance
> --
>
> Key: CASSANDRA-11933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11933
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Cyril Scetbon
>Assignee: Mahdi Mohammadi
>
> During a full repair on a ~ 60 nodes cluster, I've been able to see that
> this stage can be significant (up to 60 percent of the whole time) :
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/StorageService.java#L2983-L2997
> It's merely caused by the fact that
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/ActiveRepairService.java#L189
> calls {code}ss.getLocalRanges(keyspaceName){code} everytime and that it
> takes more than 99% of the time. This call takes 600ms when there is no load
> on the cluster and more if there is. So for 10k ranges, you can imagine that
> it takes at least 1.5 hours just to compute ranges.
> Underneath it calls
> [ReplicationStrategy.getAddressRanges|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L170]
> which can get pretty inefficient ([~jbellis]'s
> [words|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L165])
> *ss.getLocalRanges(keyspaceName)* should be cached to avoid having to spend
> hours on it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11933) Improve Repair performance
[
https://issues.apache.org/jira/browse/CASSANDRA-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15314971#comment-15314971
]
Mahdi Mohammadi edited comment on CASSANDRA-11933 at 6/4/16 9:26 PM:
-
||2.1||2.2||3.0||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...mm-binary:11933-2.1?expand=1]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...mm-binary:11933-2.2?expand=0]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...mm-binary:11933-3.0?expand=1]
|testall|testall|testall|
|dtest|dtest|dtest|
Will continue to add remaining branches if can't be auto-merged.
was (Author: mahdix):
||2.1||2.2||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...mm-binary:11933-2.1?expand=1]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...mm-binary:11933-2.2?expand=0]|
|testall|testall|
|dtest|dtest|
Will continue to add remaining branches if can't be auto-merged.
> Improve Repair performance
> --
>
> Key: CASSANDRA-11933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11933
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Cyril Scetbon
>Assignee: Mahdi Mohammadi
>
> During a full repair on a ~ 60 nodes cluster, I've been able to see that
> this stage can be significant (up to 60 percent of the whole time) :
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/StorageService.java#L2983-L2997
> It's merely caused by the fact that
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/ActiveRepairService.java#L189
> calls {code}ss.getLocalRanges(keyspaceName){code} everytime and that it
> takes more than 99% of the time. This call takes 600ms when there is no load
> on the cluster and more if there is. So for 10k ranges, you can imagine that
> it takes at least 1.5 hours just to compute ranges.
> Underneath it calls
> [ReplicationStrategy.getAddressRanges|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L170]
> which can get pretty inefficient ([~jbellis]'s
> [words|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L165])
> *ss.getLocalRanges(keyspaceName)* should be cached to avoid having to spend
> hours on it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11933) Improve Repair performance
[
https://issues.apache.org/jira/browse/CASSANDRA-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15314971#comment-15314971
]
Mahdi Mohammadi commented on CASSANDRA-11933:
-
||2.1||2.2||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...mm-binary:11933-2.1?expand=1]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...mm-binary:11933-2.2?expand=0]|
|testall|testall|
|dtest|dtest|
Will continue to add remaining branches if can't be auto-merged.
> Improve Repair performance
> --
>
> Key: CASSANDRA-11933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11933
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Cyril Scetbon
>Assignee: Mahdi Mohammadi
>
> During a full repair on a ~ 60 nodes cluster, I've been able to see that
> this stage can be significant (up to 60 percent of the whole time) :
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/StorageService.java#L2983-L2997
> It's merely caused by the fact that
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/ActiveRepairService.java#L189
> calls {code}ss.getLocalRanges(keyspaceName){code} everytime and that it
> takes more than 99% of the time. This call takes 600ms when there is no load
> on the cluster and more if there is. So for 10k ranges, you can imagine that
> it takes at least 1.5 hours just to compute ranges.
> Underneath it calls
> [ReplicationStrategy.getAddressRanges|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L170]
> which can get pretty inefficient ([~jbellis]'s
> [words|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L165])
> *ss.getLocalRanges(keyspaceName)* should be cached to avoid having to spend
> hours on it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11719:
Status: In Progress (was: Patch Available)
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 11719-trunk.patch
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15313871#comment-15313871
]
Mahdi Mohammadi commented on CASSANDRA-11719:
-
Ok. Thanks. Will fix.
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 11719-trunk.patch
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11933) Improve Repair performance
[
https://issues.apache.org/jira/browse/CASSANDRA-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15313430#comment-15313430
]
Mahdi Mohammadi commented on CASSANDRA-11933:
-
CI Reports 5 test failures in dtest and testall together. Does that mean
something is wrong with my change?
> Improve Repair performance
> --
>
> Key: CASSANDRA-11933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11933
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Cyril Scetbon
>Assignee: Mahdi Mohammadi
>
> During a full repair on a ~ 60 nodes cluster, I've been able to see that
> this stage can be significant (up to 60 percent of the whole time) :
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/StorageService.java#L2983-L2997
> It's merely caused by the fact that
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/ActiveRepairService.java#L189
> calls {code}ss.getLocalRanges(keyspaceName){code} everytime and that it
> takes more than 99% of the time. This call takes 600ms when there is no load
> on the cluster and more if there is. So for 10k ranges, you can imagine that
> it takes at least 1.5 hours just to compute ranges.
> Underneath it calls
> [ReplicationStrategy.getAddressRanges|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L170]
> which can get pretty inefficient ([~jbellis]'s
> [words|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L165])
> *ss.getLocalRanges(keyspaceName)* should be cached to avoid having to spend
> hours on it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11933) Improve Repair performance
[
https://issues.apache.org/jira/browse/CASSANDRA-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15313426#comment-15313426
]
Mahdi Mohammadi commented on CASSANDRA-11933:
-
You are right. Will rename that and check for other versions too.
> Improve Repair performance
> --
>
> Key: CASSANDRA-11933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11933
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Cyril Scetbon
>Assignee: Mahdi Mohammadi
>
> During a full repair on a ~ 60 nodes cluster, I've been able to see that
> this stage can be significant (up to 60 percent of the whole time) :
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/StorageService.java#L2983-L2997
> It's merely caused by the fact that
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/ActiveRepairService.java#L189
> calls {code}ss.getLocalRanges(keyspaceName){code} everytime and that it
> takes more than 99% of the time. This call takes 600ms when there is no load
> on the cluster and more if there is. So for 10k ranges, you can imagine that
> it takes at least 1.5 hours just to compute ranges.
> Underneath it calls
> [ReplicationStrategy.getAddressRanges|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L170]
> which can get pretty inefficient ([~jbellis]'s
> [words|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L165])
> *ss.getLocalRanges(keyspaceName)* should be cached to avoid having to spend
> hours on it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11933) Improve Repair performance
[
https://issues.apache.org/jira/browse/CASSANDRA-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15313183#comment-15313183
]
Mahdi Mohammadi commented on CASSANDRA-11933:
-
How can I run my branch in ci (for testall and dtests)?
> Improve Repair performance
> --
>
> Key: CASSANDRA-11933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11933
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Cyril Scetbon
>Assignee: Mahdi Mohammadi
>
> During a full repair on a ~ 60 nodes cluster, I've been able to see that
> this stage can be significant (up to 60 percent of the whole time) :
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/StorageService.java#L2983-L2997
> It's merely caused by the fact that
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/ActiveRepairService.java#L189
> calls {code}ss.getLocalRanges(keyspaceName){code} everytime and that it
> takes more than 99% of the time. This call takes 600ms when there is no load
> on the cluster and more if there is. So for 10k ranges, you can imagine that
> it takes at least 1.5 hours just to compute ranges.
> Underneath it calls
> [ReplicationStrategy.getAddressRanges|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L170]
> which can get pretty inefficient ([~jbellis]'s
> [words|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L165])
> *ss.getLocalRanges(keyspaceName)* should be cached to avoid having to spend
> hours on it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11933) Improve Repair performance
[
https://issues.apache.org/jira/browse/CASSANDRA-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15313181#comment-15313181
]
Mahdi Mohammadi commented on CASSANDRA-11933:
-
[Branch for 2.1|https://github.com/mm-binary/cassandra/tree/11933-2.1]
> Improve Repair performance
> --
>
> Key: CASSANDRA-11933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11933
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Cyril Scetbon
>Assignee: Mahdi Mohammadi
>
> During a full repair on a ~ 60 nodes cluster, I've been able to see that
> this stage can be significant (up to 60 percent of the whole time) :
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/StorageService.java#L2983-L2997
> It's merely caused by the fact that
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/ActiveRepairService.java#L189
> calls {code}ss.getLocalRanges(keyspaceName){code} everytime and that it
> takes more than 99% of the time. This call takes 600ms when there is no load
> on the cluster and more if there is. So for 10k ranges, you can imagine that
> it takes at least 1.5 hours just to compute ranges.
> Underneath it calls
> [ReplicationStrategy.getAddressRanges|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L170]
> which can get pretty inefficient ([~jbellis]'s
> [words|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L165])
> *ss.getLocalRanges(keyspaceName)* should be cached to avoid having to spend
> hours on it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11933) Improve Repair performance
[
https://issues.apache.org/jira/browse/CASSANDRA-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15310024#comment-15310024
]
Mahdi Mohammadi commented on CASSANDRA-11933:
-
Can I work on this ticket?
> Improve Repair performance
> --
>
> Key: CASSANDRA-11933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11933
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Cyril Scetbon
>
> During a full repair on a ~ 60 nodes cluster, I've been able to see that
> this stage can be significant (up to 60 percent of the whole time) :
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/StorageService.java#L2983-L2997
> It's merely caused by the fact that
> https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/service/ActiveRepairService.java#L189
> calls {code}ss.getLocalRanges(keyspaceName){code} everytime and that it
> takes more than 99% of the time. This call takes 600ms when there is no load
> on the cluster and more if there is. So for 10k ranges, you can imagine that
> it takes at least 1.5 hours just to compute ranges.
> Underneath it calls
> [ReplicationStrategy.getAddressRanges|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L170]
> which can get pretty inefficient ([~jbellis]'s
> [words|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java#L165])
> *ss.getLocalRanges(keyspaceName)* should be cached to avoid having to spend
> hours on it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11664) Tab completion in cqlsh doesn't work for capitalized letters
[
https://issues.apache.org/jira/browse/CASSANDRA-11664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308674#comment-15308674
]
Mahdi Mohammadi commented on CASSANDRA-11664:
-
Ok. Thanks.
> Tab completion in cqlsh doesn't work for capitalized letters
>
>
> Key: CASSANDRA-11664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11664
> Project: Cassandra
> Issue Type: Bug
>Reporter: J.B. Langston
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: cqlsh
>
> Tab completion in cqlsh doesn't work for capitalized letters, either in
> keyspace names or table names. Typing quotes and a corresponding capital
> letter should complete the table/keyspace name and the closing quote.
> {code}
> cqlsh> create keyspace "Test" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use "Tes
> cqlsh> use tes
> cqlsh> use Test;
> InvalidRequest: code=2200 [Invalid query] message="Keyspace 'test' does not
> exist"
> cqlsh> use "Test";
> cqlsh:Test> drop keyspace "Test"
> cqlsh:Test> create table "TestTable" (a text primary key, b text);
> cqlsh:Test> select * from "TestTable";
> a | b
> ---+---
> (0 rows)
> cqlsh:Test> select * from "Test
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11664) Tab completion in cqlsh doesn't work for capitalized letters
[
https://issues.apache.org/jira/browse/CASSANDRA-11664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11664:
Status: Patch Available (was: Open)
> Tab completion in cqlsh doesn't work for capitalized letters
>
>
> Key: CASSANDRA-11664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11664
> Project: Cassandra
> Issue Type: Bug
>Reporter: J.B. Langston
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: cqlsh
>
> Tab completion in cqlsh doesn't work for capitalized letters, either in
> keyspace names or table names. Typing quotes and a corresponding capital
> letter should complete the table/keyspace name and the closing quote.
> {code}
> cqlsh> create keyspace "Test" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use "Tes
> cqlsh> use tes
> cqlsh> use Test;
> InvalidRequest: code=2200 [Invalid query] message="Keyspace 'test' does not
> exist"
> cqlsh> use "Test";
> cqlsh:Test> drop keyspace "Test"
> cqlsh:Test> create table "TestTable" (a text primary key, b text);
> cqlsh:Test> select * from "TestTable";
> a | b
> ---+---
> (0 rows)
> cqlsh:Test> select * from "Test
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11664) Tab completion in cqlsh doesn't work for capitalized letters
[
https://issues.apache.org/jira/browse/CASSANDRA-11664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306964#comment-15306964
]
Mahdi Mohammadi commented on CASSANDRA-11664:
-
Branch for [trunk|https://github.com/mm-binary/cassandra/tree/11664-trunk]
> Tab completion in cqlsh doesn't work for capitalized letters
>
>
> Key: CASSANDRA-11664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11664
> Project: Cassandra
> Issue Type: Bug
>Reporter: J.B. Langston
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: cqlsh
>
> Tab completion in cqlsh doesn't work for capitalized letters, either in
> keyspace names or table names. Typing quotes and a corresponding capital
> letter should complete the table/keyspace name and the closing quote.
> {code}
> cqlsh> create keyspace "Test" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use "Tes
> cqlsh> use tes
> cqlsh> use Test;
> InvalidRequest: code=2200 [Invalid query] message="Keyspace 'test' does not
> exist"
> cqlsh> use "Test";
> cqlsh:Test> drop keyspace "Test"
> cqlsh:Test> create table "TestTable" (a text primary key, b text);
> cqlsh:Test> select * from "TestTable";
> a | b
> ---+---
> (0 rows)
> cqlsh:Test> select * from "Test
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11587) Cfstats estimate number of keys should return 0 for empty table
[
https://issues.apache.org/jira/browse/CASSANDRA-11587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11587:
Fix Version/s: 3.0.x
2.2.x
3.6
Status: Patch Available (was: In Progress)
> Cfstats estimate number of keys should return 0 for empty table
> ---
>
> Key: CASSANDRA-11587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11587
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Cassandra 2.1.13
> Nodeltool
>Reporter: Jane Deng
>Assignee: Mahdi Mohammadi
>Priority: Trivial
> Labels: lhf
> Fix For: 3.6, 2.2.x, 3.0.x
>
>
> If sstable count is 0, the "estimate number of keys" in cfstats shows -1.
> {noformat}
> SSTable count: 0
> Number of keys (estimate): -1
> {noformat}
> The initial value of keyCount in SSTableReader is -1. When there is no
> sstable, nor entry in memtable, the keyCount isn't increased. Cfstats should
> have some boundary check and return 0 for this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11587) Cfstats estimate number of keys should return 0 for empty table
[
https://issues.apache.org/jira/browse/CASSANDRA-11587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15304837#comment-15304837
]
Mahdi Mohammadi commented on CASSANDRA-11587:
-
Branch for [2.2|https://github.com/mm-binary/cassandra/tree/11587-2.2]
Branch for [3.0|https://github.com/mm-binary/cassandra/tree/11587-3.0]
Branch for [3.6|https://github.com/mm-binary/cassandra/tree/11587-3.6]
> Cfstats estimate number of keys should return 0 for empty table
> ---
>
> Key: CASSANDRA-11587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11587
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Cassandra 2.1.13
> Nodeltool
>Reporter: Jane Deng
>Assignee: Mahdi Mohammadi
>Priority: Trivial
> Labels: lhf
>
> If sstable count is 0, the "estimate number of keys" in cfstats shows -1.
> {noformat}
> SSTable count: 0
> Number of keys (estimate): -1
> {noformat}
> The initial value of keyCount in SSTableReader is -1. When there is no
> sstable, nor entry in memtable, the keyCount isn't increased. Cfstats should
> have some boundary check and return 0 for this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11664) Tab completion in cqlsh doesn't work for capitalized letters
[
https://issues.apache.org/jira/browse/CASSANDRA-11664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15301023#comment-15301023
]
Mahdi Mohammadi commented on CASSANDRA-11664:
-
Thanks. So I will just work on the tab completion part.
> Tab completion in cqlsh doesn't work for capitalized letters
>
>
> Key: CASSANDRA-11664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11664
> Project: Cassandra
> Issue Type: Bug
>Reporter: J.B. Langston
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: cqlsh
>
> Tab completion in cqlsh doesn't work for capitalized letters, either in
> keyspace names or table names. Typing quotes and a corresponding capital
> letter should complete the table/keyspace name and the closing quote.
> {code}
> cqlsh> create keyspace "Test" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use "Tes
> cqlsh> use tes
> cqlsh> use Test;
> InvalidRequest: code=2200 [Invalid query] message="Keyspace 'test' does not
> exist"
> cqlsh> use "Test";
> cqlsh:Test> drop keyspace "Test"
> cqlsh:Test> create table "TestTable" (a text primary key, b text);
> cqlsh:Test> select * from "TestTable";
> a | b
> ---+---
> (0 rows)
> cqlsh:Test> select * from "Test
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11587) Cfstats estimate number of keys should return 0 for empty table
[
https://issues.apache.org/jira/browse/CASSANDRA-11587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299303#comment-15299303
]
Mahdi Mohammadi edited comment on CASSANDRA-11587 at 5/25/16 1:36 AM:
--
My changes are applied against `trunk`. The issue indicates 2.1.13 as affected
version, but there is no such branch. Should I apply my changes to '2.1.13' tag?
was (Author: mahdix):
My changes are applied against `trunk`. The issue indicates 2.1.13 as affected
version, but there is no such branch. Should I apply my changes against
'2.1.13' tag?
> Cfstats estimate number of keys should return 0 for empty table
> ---
>
> Key: CASSANDRA-11587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11587
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Cassandra 2.1.13
> Nodeltool
>Reporter: Jane Deng
>Assignee: Mahdi Mohammadi
>Priority: Trivial
> Labels: lhf
>
> If sstable count is 0, the "estimate number of keys" in cfstats shows -1.
> {noformat}
> SSTable count: 0
> Number of keys (estimate): -1
> {noformat}
> The initial value of keyCount in SSTableReader is -1. When there is no
> sstable, nor entry in memtable, the keyCount isn't increased. Cfstats should
> have some boundary check and return 0 for this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11587) Cfstats estimate number of keys should return 0 for empty table
[
https://issues.apache.org/jira/browse/CASSANDRA-11587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299303#comment-15299303
]
Mahdi Mohammadi commented on CASSANDRA-11587:
-
My changes are applied against `trunk`. The issue indicates 2.1.13 as affected
version, but there is no such branch. Should I apply my changes against
'2.1.13' tag?
> Cfstats estimate number of keys should return 0 for empty table
> ---
>
> Key: CASSANDRA-11587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11587
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Cassandra 2.1.13
> Nodeltool
>Reporter: Jane Deng
>Assignee: Mahdi Mohammadi
>Priority: Trivial
> Labels: lhf
>
> If sstable count is 0, the "estimate number of keys" in cfstats shows -1.
> {noformat}
> SSTable count: 0
> Number of keys (estimate): -1
> {noformat}
> The initial value of keyCount in SSTableReader is -1. When there is no
> sstable, nor entry in memtable, the keyCount isn't increased. Cfstats should
> have some boundary check and return 0 for this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11587) Cfstats estimate number of keys should return 0 for empty table
[
https://issues.apache.org/jira/browse/CASSANDRA-11587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299270#comment-15299270
]
Mahdi Mohammadi commented on CASSANDRA-11587:
-
Corresponding commit:
https://github.com/mm-binary/cassandra/commit/a6526b6b63be68804ce6f17db2ed514de0861eac
Corresponding branch:
https://github.com/mm-binary/cassandra/tree/fix_cfstate_keycount
> Cfstats estimate number of keys should return 0 for empty table
> ---
>
> Key: CASSANDRA-11587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11587
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Cassandra 2.1.13
> Nodeltool
>Reporter: Jane Deng
>Assignee: Mahdi Mohammadi
>Priority: Trivial
> Labels: lhf
>
> If sstable count is 0, the "estimate number of keys" in cfstats shows -1.
> {noformat}
> SSTable count: 0
> Number of keys (estimate): -1
> {noformat}
> The initial value of keyCount in SSTableReader is -1. When there is no
> sstable, nor entry in memtable, the keyCount isn't increased. Cfstats should
> have some boundary check and return 0 for this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-11587) Cfstats estimate number of keys should return 0 for empty table
[
https://issues.apache.org/jira/browse/CASSANDRA-11587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi reassigned CASSANDRA-11587:
---
Assignee: Mahdi Mohammadi
> Cfstats estimate number of keys should return 0 for empty table
> ---
>
> Key: CASSANDRA-11587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11587
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Cassandra 2.1.13
> Nodeltool
>Reporter: Jane Deng
>Assignee: Mahdi Mohammadi
>Priority: Trivial
> Labels: lhf
>
> If sstable count is 0, the "estimate number of keys" in cfstats shows -1.
> {noformat}
> SSTable count: 0
> Number of keys (estimate): -1
> {noformat}
> The initial value of keyCount in SSTableReader is -1. When there is no
> sstable, nor entry in memtable, the keyCount isn't increased. Cfstats should
> have some boundary check and return 0 for this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11664) Tab completion in cqlsh doesn't work for capitalized letters
[
https://issues.apache.org/jira/browse/CASSANDRA-11664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298985#comment-15298985
]
Mahdi Mohammadi commented on CASSANDRA-11664:
-
There are two separate issues here:
1) cqlsh auto-complete does not consider mixed-case candidates.
2) When you type a mixed-case name without double quote, it is not accepted.
(e.g. use Test; issues an error, while use "Test"; works fine).
The first one seems to be only related to cqlsh part.
The second one is related to the server side, where when parsing the statement,
removes casing from the identifier. If you debug the server side, you will
notice that the casing is preserved until before parsing the statement.
> Tab completion in cqlsh doesn't work for capitalized letters
>
>
> Key: CASSANDRA-11664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11664
> Project: Cassandra
> Issue Type: Bug
>Reporter: J.B. Langston
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: cqlsh
>
> Tab completion in cqlsh doesn't work for capitalized letters, either in
> keyspace names or table names. Typing quotes and a corresponding capital
> letter should complete the table/keyspace name and the closing quote.
> {code}
> cqlsh> create keyspace "Test" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use "Tes
> cqlsh> use tes
> cqlsh> use Test;
> InvalidRequest: code=2200 [Invalid query] message="Keyspace 'test' does not
> exist"
> cqlsh> use "Test";
> cqlsh:Test> drop keyspace "Test"
> cqlsh:Test> create table "TestTable" (a text primary key, b text);
> cqlsh:Test> select * from "TestTable";
> a | b
> ---+---
> (0 rows)
> cqlsh:Test> select * from "Test
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297484#comment-15297484
]
Mahdi Mohammadi commented on CASSANDRA-11719:
-
[~snazy] Can you please take a look at this?
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 11719-trunk.patch
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11664) Tab completion in cqlsh doesn't work for capitalized letters
[
https://issues.apache.org/jira/browse/CASSANDRA-11664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15295805#comment-15295805
]
Mahdi Mohammadi commented on CASSANDRA-11664:
-
In Parser.g Line 1193, the ANTLR rules indicate that when identifier is not
quoted, casing should not be kept:
`t=IDENT { $name.setKeyspace($t.text, false);`
In order to resolve this issue, I will need to change this behavior and do the
same for table-name.
Any objection?
> Tab completion in cqlsh doesn't work for capitalized letters
>
>
> Key: CASSANDRA-11664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11664
> Project: Cassandra
> Issue Type: Bug
>Reporter: J.B. Langston
>Assignee: Mahdi Mohammadi
>Priority: Minor
>
> Tab completion in cqlsh doesn't work for capitalized letters, either in
> keyspace names or table names. Typing quotes and a corresponding capital
> letter should complete the table/keyspace name and the closing quote.
> {code}
> cqlsh> create keyspace "Test" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use "Tes
> cqlsh> use tes
> cqlsh> use Test;
> InvalidRequest: code=2200 [Invalid query] message="Keyspace 'test' does not
> exist"
> cqlsh> use "Test";
> cqlsh:Test> drop keyspace "Test"
> cqlsh:Test> create table "TestTable" (a text primary key, b text);
> cqlsh:Test> select * from "TestTable";
> a | b
> ---+---
> (0 rows)
> cqlsh:Test> select * from "Test
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-11664) Tab completion in cqlsh doesn't work for capitalized letters
[
https://issues.apache.org/jira/browse/CASSANDRA-11664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi reassigned CASSANDRA-11664:
---
Assignee: Mahdi Mohammadi
> Tab completion in cqlsh doesn't work for capitalized letters
>
>
> Key: CASSANDRA-11664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11664
> Project: Cassandra
> Issue Type: Bug
>Reporter: J.B. Langston
>Assignee: Mahdi Mohammadi
>Priority: Minor
>
> Tab completion in cqlsh doesn't work for capitalized letters, either in
> keyspace names or table names. Typing quotes and a corresponding capital
> letter should complete the table/keyspace name and the closing quote.
> {code}
> cqlsh> create keyspace "Test" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use "Tes
> cqlsh> use tes
> cqlsh> use Test;
> InvalidRequest: code=2200 [Invalid query] message="Keyspace 'test' does not
> exist"
> cqlsh> use "Test";
> cqlsh:Test> drop keyspace "Test"
> cqlsh:Test> create table "TestTable" (a text primary key, b text);
> cqlsh:Test> select * from "TestTable";
> a | b
> ---+---
> (0 rows)
> cqlsh:Test> select * from "Test
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7693) Reminder: clean up Javadoc errors/warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-7693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15295724#comment-15295724
]
Mahdi Mohammadi commented on CASSANDRA-7693:
[~snazy] Is this issue still relevant? I tried running ant on trunk and got
only 1 warning (Java version 1.8)
> Reminder: clean up Javadoc errors/warnings
> --
>
> Key: CASSANDRA-7693
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7693
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Priority: Trivial
>
> Current C* build (trunk) reports > 100 errors + > 100 warnings (when building
> with Java8).
> Trivial but long ("keyboard monkey") task: Clean up the errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11719:
Status: Patch Available (was: Open)
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 11719-trunk.patch
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11719:
Attachment: 11719-trunk.patch
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 11719-trunk.patch
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11719:
Attachment: (was: 11719-trunk.patch)
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 11719-trunk.patch
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11719:
Attachment: 11719-trunk.patch
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 11719-trunk.patch
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11719:
Attachment: (was: 11719-2.1.patch)
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15292237#comment-15292237
]
Mahdi Mohammadi commented on CASSANDRA-11719:
-
[~snazy] The test file TraceCqlTest exists only on trunk branch. Should I
create my branch off trunk?
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 11719-2.1.patch
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15285761#comment-15285761
]
Mahdi Mohammadi edited comment on CASSANDRA-11719 at 5/17/16 10:18 PM:
---
Link to my branch in GitHub:
https://github.com/mm-binary/cassandra/tree/11719-2.1
was (Author: mahdix):
Link to my branch in GitHub:
https://github.com/mm-binary/cassandra/tree/11719-2.1
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 11719-2.1.patch
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11719:
Status: Open (was: Patch Available)
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 11719-2.1.patch
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15286213#comment-15286213
]
Mahdi Mohammadi commented on CASSANDRA-11719:
-
Sure. Will do that.
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 11719-2.1.patch
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11719:
Status: Patch Available (was: In Progress)
This patch adds bound variables to trace
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 2.1.0
>
> Attachments: 11719-2.1.patch
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15285761#comment-15285761
]
Mahdi Mohammadi commented on CASSANDRA-11719:
-
Link to my branch in GitHub:
https://github.com/mm-binary/cassandra/tree/11719-2.1
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 2.1.0
>
> Attachments: 11719-2.1.patch
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11719:
Attachment: 11719-2.1.patch
adding bound variables of the parsed statement to tracing output
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 2.1.0
>
> Attachments: 11719-2.1.patch
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11719:
Fix Version/s: 2.1.0
Status: Patch Available (was: Open)
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 2.1.0
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahdi Mohammadi updated CASSANDRA-11719:
Status: Open (was: Patch Available)
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Labels: lhf
> Fix For: 2.1.0
>
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11719) Add bind variables to trace
[
https://issues.apache.org/jira/browse/CASSANDRA-11719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15284147#comment-15284147
]
Mahdi Mohammadi commented on CASSANDRA-11719:
-
I want to work on this issue but seems there is no option to assign it to
myself. Can someone help?
> Add bind variables to trace
> ---
>
> Key: CASSANDRA-11719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11719
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Priority: Minor
> Labels: lhf
>
> {{org.apache.cassandra.transport.messages.ExecuteMessage#execute}} mentions a
> _TODO_ saying "we don't have [typed] access to CQL bind variables here".
> In fact, we now have access typed access to CQL bind variables there. So, it
> is now possible to show the bind variables in the trace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
