[jira] [Updated] (CASSANDRA-15043) Add heap dump inspections to sidecar
[ https://issues.apache.org/jira/browse/CASSANDRA-15043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-15043: - Reviewers: Dinesh Joshi > Add heap dump inspections to sidecar > > > Key: CASSANDRA-15043 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15043 > Project: Cassandra > Issue Type: New Feature > Components: Sidecar >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Major > > Add to ui a tool to view heap dumps cassandra produces when OOM to identify > the issue that caused it. Three views > 1. C* inspections - useful inspections like a list of the largest partitions, > most active partitions, largest (and most by table and partition) mutations. > 2. Threads - their stack traces, heap size, and values of things in local > processing scope (that can be clicked through and explored) > 3. Metrics - view state of all the metrics at time of heap dump > Additional requirement: since this runs on cassandra sidecar it should use > very low memory (ie sub 100mb) and not consume massive cpu -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-9191) Log and count failure to obtain requested consistency
[ https://issues.apache.org/jira/browse/CASSANDRA-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shaurya Gupta updated CASSANDRA-9191: - Status: Awaiting Feedback (was: Open) > Log and count failure to obtain requested consistency > - > > Key: CASSANDRA-9191 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9191 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination, Legacy/Observability >Reporter: Matt Stump >Priority: Minor > Labels: lhf > Attachments: patch_CASSANDRA-9191_trunk, patch_CASSANDRA-9191_v3.11.3 > > > Cassandra should have a way to log failed requests due to failure to obtain > requested consistency. This should be logged as error or warning by default. > Also exposed should be a counter for the benefit of opscenter. > Currently the only way to log this is at the client. Often the application > and DB teams are separate and it's very difficult to obtain client logs. Also > because it's only visible to the client no visibility is given to opscenter > making it difficult for the field to track down or isolate systematic or node > level errors. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9191) Log and count failure to obtain requested consistency
[ https://issues.apache.org/jira/browse/CASSANDRA-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786386#comment-16786386 ] Shaurya Gupta commented on CASSANDRA-9191: -- Hi, I have uploaded patches for trunk and 3.11.3 branches (will change to 3.11.x if required). Please have a look. I'm a bit new to Cassandra code base, please bear with me if I made some rookie mistake. Thanks [~mstump], [~slebresne] > Log and count failure to obtain requested consistency > - > > Key: CASSANDRA-9191 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9191 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination, Legacy/Observability >Reporter: Matt Stump >Priority: Minor > Labels: lhf > Attachments: patch_CASSANDRA-9191_trunk, patch_CASSANDRA-9191_v3.11.3 > > > Cassandra should have a way to log failed requests due to failure to obtain > requested consistency. This should be logged as error or warning by default. > Also exposed should be a counter for the benefit of opscenter. > Currently the only way to log this is at the client. Often the application > and DB teams are separate and it's very difficult to obtain client logs. Also > because it's only visible to the client no visibility is given to opscenter > making it difficult for the field to track down or isolate systematic or node > level errors. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-9191) Log and count failure to obtain requested consistency
[ https://issues.apache.org/jira/browse/CASSANDRA-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shaurya Gupta updated CASSANDRA-9191: - Attachment: patch_CASSANDRA-9191_v3.11.3 patch_CASSANDRA-9191_trunk > Log and count failure to obtain requested consistency > - > > Key: CASSANDRA-9191 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9191 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination, Legacy/Observability >Reporter: Matt Stump >Priority: Minor > Labels: lhf > Attachments: patch_CASSANDRA-9191_trunk, patch_CASSANDRA-9191_v3.11.3 > > > Cassandra should have a way to log failed requests due to failure to obtain > requested consistency. This should be logged as error or warning by default. > Also exposed should be a counter for the benefit of opscenter. > Currently the only way to log this is at the client. Often the application > and DB teams are separate and it's very difficult to obtain client logs. Also > because it's only visible to the client no visibility is given to opscenter > making it difficult for the field to track down or isolate systematic or node > level errors. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] 01/01: WIP: dual-JDK tar artifact build scripts
This is an automated email from the ASF dual-hosted git repository.
mshuler pushed a commit to branch tar-artifact-build
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git
commit d7b102bcded9146e11744121b33d61dc3fa41d83
Author: Michael Shuler
AuthorDate: Wed Mar 6 21:17:27 2019 -0600
WIP: dual-JDK tar artifact build scripts
---
docker/build-tars.sh | 75 ++
docker/buster-image.docker | 43 ++
2 files changed, 118 insertions(+)
diff --git a/docker/build-tars.sh b/docker/build-tars.sh
new file mode 100755
index 000..f0bd31e
--- /dev/null
+++ b/docker/build-tars.sh
@@ -0,0 +1,75 @@
+#!/bin/bash -x
+set -e
+
+if [ "$#" -ne 1 ]; then
+ echo "$0 "
+ exit 1
+fi
+
+CASSANDRA_BRANCH=$1
+
+cd $CASSANDRA_DIR
+git fetch
+git checkout $CASSANDRA_BRANCH || exit 1
+
+# Used version for build will always depend on the git referenced used for
checkout above
+# Branches will always be created as snapshots, while tags are releases
+tag=`git describe --tags --exact-match` 2> /dev/null || true
+branch=`git symbolic-ref -q --short HEAD` 2> /dev/null || true
+
+is_tag=false
+is_branch=false
+git_version=''
+
+if [ "$tag" ]; then
+ is_tag=true
+ # Official release
+ regx_tag="cassandra-([0-9.]+)$"
+ # Tentative release
+ regx_tag_tentative="([0-9.]+)-tentative$"
+ if [[ $tag =~ $regx_tag ]] || [[ $tag =~ $regx_tag_tentative ]]; then
+ git_version=${BASH_REMATCH[1]}
+ else
+ echo "Error: could not recognize version from tag $tag">&2
+ exit 2
+ fi
+elif [ "$branch" ]; then
+ # Dev branch
+ is_branch=true
+ regx_branch="cassandra-([0-9.]+)$"
+ if [[ $branch =~ $regx_branch ]]; then
+ git_version=${BASH_REMATCH[1]}
+ else
+ # This could be either trunk or any dev branch, so we won't be able to
get the version
+ # from the branch name. In this case, fall back to debian change log
version.
+ git_version=$(dpkg-parsechangelog | sed -ne 's/^Version:
\([^-|~|+]*\).*/\1/p')
+ if [ -z $git_version ]; then
+ echo "Error: could not recognize version from branch $branch">&2
+ exit 2
+ else
+ echo "Warning: could not recognize version from branch, using dpkg
version: $git_version"
+ fi
+ fi
+else
+ echo "Error: invalid git reference; must either be branch or tag">&2
+ exit 1
+fi
+
+# Version (base.version) in build.xml must be set manually as well. Let's
validate the set value.
+buildxml_version=`grep 'property\s*name="base.version"' build.xml |sed -ne
's/.*value="\([^"]*\)".*/\1/p'`
+if [ $buildxml_version != $git_version ]; then
+ echo "Error: build.xml version ($buildxml_version) not matching git tag
derived version ($git_version)">&2
+ exit 4
+fi
+
+# Dual JDK build for version >= 4.*
+if dpkg --compare-versions $buildxml_version ge 4; then
+ export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
+ export JAVA8_HOME=/usr/lib/jvm/java-8-openjdk-amd64
+fi
+
+#TODO: dev build - check release/tentative and pass '-Drelease=true'
+ant artifacts
+
+# Copy created artifacts to dist dir mapped to docker host directory (must
have proper permissions)
+cp build/apache-cassandra-*.tar.gz $DIST_DIR
diff --git a/docker/buster-image.docker b/docker/buster-image.docker
new file mode 100644
index 000..7eb120a
--- /dev/null
+++ b/docker/buster-image.docker
@@ -0,0 +1,43 @@
+FROM debian:buster
+
+ENV DIST_DIR=/dist
+ENV BUILD_HOME=/home/build
+ENV CASSANDRA_DIR=$BUILD_HOME/cassandra
+
+LABEL org.cassandra.buildenv=buster
+
+VOLUME ${DIST_DIR}
+
+# install deps
+RUN apt-get update && apt-get -y install \
+ ant \
+ build-essential \
+ curl \
+ devscripts \
+ git \
+ sudo
+
+RUN apt-get -y --no-install-recommends install \
+ openjdk-8-jdk-headless \
+ openjdk-11-jdk-headless
+
+RUN apt-get -y install \
+ python-sphinx \
+ python-sphinx-rtd-theme
+
+RUN update-java-alternatives --set java-1.8.0-openjdk-amd64
+
+# create and change to build user
+RUN adduser --disabled-login --gecos build build && gpasswd -a build sudo
+RUN echo "build ALL=(root) NOPASSWD:ALL" > /etc/sudoers.d/build && \
+ chmod 0440 /etc/sudoers.d/build
+
+USER build
+
+# clone Cassandra and cache maven artifacts
+ARG CASSANDRA_GIT_URL=https://gitbox.apache.org/repos/asf/cassandra.git
+RUN git clone ${CASSANDRA_GIT_URL} ${CASSANDRA_DIR}
+WORKDIR ${CASSANDRA_DIR}
+RUN ant maven-ant-tasks-retrieve-build
+
+COPY build-tars.sh $BUILD_HOME/
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch tar-artifact-build created (now d7b102b)
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a change to branch tar-artifact-build in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git. at d7b102b WIP: dual-JDK tar artifact build scripts This branch includes the following new commits: new d7b102b WIP: dual-JDK tar artifact build scripts The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15016) bootstrap_upgrade_test.py::test_simple_bootstrap_mixed_versions is failing on 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-15016:
---
Status: Ready to Commit (was: Patch Available)
> bootstrap_upgrade_test.py::test_simple_bootstrap_mixed_versions is failing on
> 3.11.4
>
>
> Key: CASSANDRA-15016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15016
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Vinay Chella
>Priority: Minor
> Labels: dtest, test, upgrade-dtest
>
> {{test_simple_bootstrap_mixed_versions}} is failing due to CASSANDRA-13004,
> which introduced "cassandra.force_3_0_protocol_version" for schema migrations
> during upgrades from 3.0.14 upwards. This flag is missing in
> `test_simple_bootstrap_mixed_versions` while we are adding/bootstrapping
> 3.11.4 node to an existing 3.5 version of C* node, which resulted in {{ks}}
> keyspace schema/data not being bootstrapped to the new node.
> I debugged and confirmed that
> [MigrationManager::is30Compatible|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L181-L185]
> is returning false which is forcing
> [MigrationManager::shouldPullSchemaFrom|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L168-L177]
> to return false as well.
> *from debug logs:*
> {code:java}
> DEBUG [GossipStage:1] 2019-02-06 23:20:47,392 MigrationManager.java:115 - Not
> pulling schema because versions match or shouldPullSchemaFrom returned fal
> {code}
> *Failed upgrade tests:
> [https://circleci.com/gh/aweisberg/cassandra/2593#tests/containers/11]*
> *From failed dtest:*
> {code:java}
> self = 0x7f1bec192eb8>
> @pytest.mark.no_vnodes
> @since('3.10', max_version='3.99')
> def test_simple_bootstrap_mixed_versions(self):
> > self._base_bootstrap_test(bootstrap_from_version="3.5")
> upgrade_tests/bootstrap_upgrade_test.py:20:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> bootstrap_test.py:114: in _base_bootstrap_test
> assert_almost_equal(size1, size2, error=0.3)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> args = (429.36, 133.1), kwargs = {'error': 0.3}, error = 0.3, vmax = 429.36
> vmin = 133.1, error_message = ''
> def assert_almost_equal(*args, **kwargs):
> """
> Assert variable number of arguments all fall within a margin of error.
> @params *args variable number of numerical arguments to check
> @params error Optional margin of error. Default 0.16
> @params error_message Optional error message to print. Default ''
>
> Examples:
> assert_almost_equal(sizes[2], init_size)
> assert_almost_equal(ttl_session1, ttl_session2[0][0], error=0.005)
> """
> error = kwargs['error'] if 'error' in kwargs else 0.16
> vmax = max(args)
> vmin = min(args)
> error_message = '' if 'error_message' not in kwargs else
> kwargs['error_message']
> assert vmin > vmax * (1.0 - error) or vmin == vmax, \
> > "values not within {:.2f}% of the max: {} ({})".format(error *
> > 100, args, error_message)
> E AssertionError: values not within 30.00% of the max: (429.36, 133.1)
> ()
> tools/assertions.py:206: AssertionError
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15016) bootstrap_upgrade_test.py::test_simple_bootstrap_mixed_versions is failing on 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786200#comment-16786200
]
Ariel Weisberg commented on CASSANDRA-15016:
+1 looks good. Thanks for fixing this.
> bootstrap_upgrade_test.py::test_simple_bootstrap_mixed_versions is failing on
> 3.11.4
>
>
> Key: CASSANDRA-15016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15016
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Vinay Chella
>Priority: Minor
> Labels: dtest, test, upgrade-dtest
>
> {{test_simple_bootstrap_mixed_versions}} is failing due to CASSANDRA-13004,
> which introduced "cassandra.force_3_0_protocol_version" for schema migrations
> during upgrades from 3.0.14 upwards. This flag is missing in
> `test_simple_bootstrap_mixed_versions` while we are adding/bootstrapping
> 3.11.4 node to an existing 3.5 version of C* node, which resulted in {{ks}}
> keyspace schema/data not being bootstrapped to the new node.
> I debugged and confirmed that
> [MigrationManager::is30Compatible|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L181-L185]
> is returning false which is forcing
> [MigrationManager::shouldPullSchemaFrom|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L168-L177]
> to return false as well.
> *from debug logs:*
> {code:java}
> DEBUG [GossipStage:1] 2019-02-06 23:20:47,392 MigrationManager.java:115 - Not
> pulling schema because versions match or shouldPullSchemaFrom returned fal
> {code}
> *Failed upgrade tests:
> [https://circleci.com/gh/aweisberg/cassandra/2593#tests/containers/11]*
> *From failed dtest:*
> {code:java}
> self = 0x7f1bec192eb8>
> @pytest.mark.no_vnodes
> @since('3.10', max_version='3.99')
> def test_simple_bootstrap_mixed_versions(self):
> > self._base_bootstrap_test(bootstrap_from_version="3.5")
> upgrade_tests/bootstrap_upgrade_test.py:20:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> bootstrap_test.py:114: in _base_bootstrap_test
> assert_almost_equal(size1, size2, error=0.3)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> args = (429.36, 133.1), kwargs = {'error': 0.3}, error = 0.3, vmax = 429.36
> vmin = 133.1, error_message = ''
> def assert_almost_equal(*args, **kwargs):
> """
> Assert variable number of arguments all fall within a margin of error.
> @params *args variable number of numerical arguments to check
> @params error Optional margin of error. Default 0.16
> @params error_message Optional error message to print. Default ''
>
> Examples:
> assert_almost_equal(sizes[2], init_size)
> assert_almost_equal(ttl_session1, ttl_session2[0][0], error=0.005)
> """
> error = kwargs['error'] if 'error' in kwargs else 0.16
> vmax = max(args)
> vmin = min(args)
> error_message = '' if 'error_message' not in kwargs else
> kwargs['error_message']
> assert vmin > vmax * (1.0 - error) or vmin == vmax, \
> > "values not within {:.2f}% of the max: {} ({})".format(error *
> > 100, args, error_message)
> E AssertionError: values not within 30.00% of the max: (429.36, 133.1)
> ()
> tools/assertions.py:206: AssertionError
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15021) TestBootstrapAfterUpgrade.test_upgrade_with_range_tombstone_eoc_0 upgrade test is failing with TypeError
[
https://issues.apache.org/jira/browse/CASSANDRA-15021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786198#comment-16786198
]
Ariel Weisberg commented on CASSANDRA-15021:
+1. This issue occurred hundreds of times throughout various tests. Thanks for
catching this one.
> TestBootstrapAfterUpgrade.test_upgrade_with_range_tombstone_eoc_0 upgrade
> test is failing with TypeError
>
>
> Key: CASSANDRA-15021
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15021
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Vinay Chella
>Priority: Minor
> Labels: dtest, test, upgrade-dtest
>
> While running upgrade tests for 3.11.4 candidate I noticed that
> {{upgrade_tests.storage_engine_upgrade_test.TestBootstrapAfterUpgrade.test_upgrade_with_range_tombstone_eoc_0}}
> is failing with TypeError.
> Example run with error:
> {code:java}
> self = object at 0x7f8db9908240>
> @since('3.0', max_version='3.99')
> def test_upgrade_with_range_tombstone_eoc_0(self):
> """
> Check sstable upgrading when the sstable contains a range
> tombstone with EOC=0.
>
> @jira_ticket CASSANDRA-12423
> """
> session = self._setup_cluster(cluster_options={'start_rpc': 'true'})
>
> session.execute("CREATE TABLE rt (id INT, c1 TEXT, c2 TEXT, v INT,
> PRIMARY KEY (id, c1, c2)) "
> "with compact storage and compression =
> {'sstable_compression': ''};")
>
> range_delete = {
> i32(1): {
> 'rt': [Mutation(deletion=Deletion(2470761440040513,
>
> predicate=SlicePredicate(slice_range=SliceRange(
> > start=composite('a',
> > eoc='\x00'),
> finish=composite('asd',
> eoc='\x00')]
> }
> }
> upgrade_tests/storage_engine_upgrade_test.py:434:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> item1 = b'a', item2 = None, eoc = '\x00'
> def composite(item1, item2=None, eoc=b'\x00'):
> if isinstance(item1, str):
> item1 = utf8encode(item1)
> if isinstance(item2, str):
> item2 = utf8encode(item2)
>
> > packed = _i16(len(item1)) + item1 + eoc
> E TypeError: can't concat str to bytes
> thrift_test.py:153: TypeError
> {code}
> This TypeError is from Python3 migration. Python 3's standard string type is
> Unicode based, and Python 3 adds a dedicated bytes type, but critically, no
> automatic coercion between bytes and unicode strings is provided -
> [context|https://www.python.org/dev/peps/pep-0404/#strings-and-bytes]
> This change in python3 is leading to "TypeError: can't concat str to bytes"
> while appending bytes to string.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15021) TestBootstrapAfterUpgrade.test_upgrade_with_range_tombstone_eoc_0 upgrade test is failing with TypeError
[
https://issues.apache.org/jira/browse/CASSANDRA-15021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-15021:
---
Status: Ready to Commit (was: Patch Available)
> TestBootstrapAfterUpgrade.test_upgrade_with_range_tombstone_eoc_0 upgrade
> test is failing with TypeError
>
>
> Key: CASSANDRA-15021
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15021
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Vinay Chella
>Priority: Minor
> Labels: dtest, test, upgrade-dtest
>
> While running upgrade tests for 3.11.4 candidate I noticed that
> {{upgrade_tests.storage_engine_upgrade_test.TestBootstrapAfterUpgrade.test_upgrade_with_range_tombstone_eoc_0}}
> is failing with TypeError.
> Example run with error:
> {code:java}
> self = object at 0x7f8db9908240>
> @since('3.0', max_version='3.99')
> def test_upgrade_with_range_tombstone_eoc_0(self):
> """
> Check sstable upgrading when the sstable contains a range
> tombstone with EOC=0.
>
> @jira_ticket CASSANDRA-12423
> """
> session = self._setup_cluster(cluster_options={'start_rpc': 'true'})
>
> session.execute("CREATE TABLE rt (id INT, c1 TEXT, c2 TEXT, v INT,
> PRIMARY KEY (id, c1, c2)) "
> "with compact storage and compression =
> {'sstable_compression': ''};")
>
> range_delete = {
> i32(1): {
> 'rt': [Mutation(deletion=Deletion(2470761440040513,
>
> predicate=SlicePredicate(slice_range=SliceRange(
> > start=composite('a',
> > eoc='\x00'),
> finish=composite('asd',
> eoc='\x00')]
> }
> }
> upgrade_tests/storage_engine_upgrade_test.py:434:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> item1 = b'a', item2 = None, eoc = '\x00'
> def composite(item1, item2=None, eoc=b'\x00'):
> if isinstance(item1, str):
> item1 = utf8encode(item1)
> if isinstance(item2, str):
> item2 = utf8encode(item2)
>
> > packed = _i16(len(item1)) + item1 + eoc
> E TypeError: can't concat str to bytes
> thrift_test.py:153: TypeError
> {code}
> This TypeError is from Python3 migration. Python 3's standard string type is
> Unicode based, and Python 3 adds a dedicated bytes type, but critically, no
> automatic coercion between bytes and unicode strings is provided -
> [context|https://www.python.org/dev/peps/pep-0404/#strings-and-bytes]
> This change in python3 is leading to "TypeError: can't concat str to bytes"
> while appending bytes to string.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15043) Add heap dump inspections to sidecar
Chris Lohfink created CASSANDRA-15043: - Summary: Add heap dump inspections to sidecar Key: CASSANDRA-15043 URL: https://issues.apache.org/jira/browse/CASSANDRA-15043 Project: Cassandra Issue Type: New Feature Components: Sidecar Reporter: Chris Lohfink Assignee: Chris Lohfink Add to ui a tool to view heap dumps cassandra produces when OOM to identify the issue that caused it. Three views 1. C* inspections - useful inspections like a list of the largest partitions, most active partitions, largest (and most by table and partition) mutations. 2. Threads - their stack traces, heap size, and values of things in local processing scope (that can be clicked through and explored) 3. Metrics - view state of all the metrics at time of heap dump Additional requirement: since this runs on cassandra sidecar it should use very low memory (ie sub 100mb) and not consume massive cpu -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15042) cqlsh tracing output reports all secondary "Index mean cardinalities" are 1.
[
https://issues.apache.org/jira/browse/CASSANDRA-15042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Preston updated CASSANDRA-15042:
Component/s: Observability/Tracing
> cqlsh tracing output reports all secondary "Index mean cardinalities" are 1.
> -
>
> Key: CASSANDRA-15042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15042
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Tools, Observability/Tracing
>Reporter: William Preston
>Priority: Minor
>
> Cassandra 3.11.4
> Running a query in cqlsh with TRACING ON
> Secondary indexes all report cardinalities as *1*.
> trace output:
> {noformat}
> Index mean cardinalities are
> country_idx:1,company_idx:1,source_idx:1,domain_idx:1. Scanning with
> country_idx.
> {noformat}
> Cassandra 2.2.x and its' predecessors reported cardinalities > 1 in cqlsh
> tracing output:
> {noformat}
> Candidate index mean cardinalities are
> CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=country, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=country_idx, indexType=COMPOSITES}
> ]}:2, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=company, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=company_idx, indexType=COMPOSITES}
> ]}:1210, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=source, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=source_idx, indexType=COMPOSITES}
> ]}:501804, CompositesIndexOnRegular{columnDefs=[ColumnDefinition
> {name=domain, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR,
> componentIndex=0, indexName=domain, indexType=COMPOSITES}
> ]}:325801.
> Scanning with country_idx.{noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13433) RPM distribution improvements and known issues
[ https://issues.apache.org/jira/browse/CASSANDRA-13433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua McKenzie updated CASSANDRA-13433: Status: Open (was: Testing) > RPM distribution improvements and known issues > -- > > Key: CASSANDRA-13433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13433 > Project: Cassandra > Issue Type: Improvement > Components: Packaging >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Major > Attachments: cassandra-3.9-centos6.patch > > > Starting with CASSANDRA-13252, new releases will be provided as both official > RPM and Debian packages. While the Debian packages are already well > established with our user base, the RPMs just have been release for the first > time and still require some attention. > Feel free to discuss RPM related issues in this ticket and open a sub-task to > fill a bug report. > Please note that native systemd support will be implemented with > CASSANDRA-13148 and this is not strictly a RPM specific issue. We still > intent to offer non-systemd support based on the already working init scripts > that we ship. Therefor the first step is to make use of systemd backward > compatibility for SysV/LSB scripts, so we can provide RPMs for both systemd > and non-systemd environments. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13433) RPM distribution improvements and known issues
[ https://issues.apache.org/jira/browse/CASSANDRA-13433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua McKenzie updated CASSANDRA-13433: Status: Awaiting Feedback (was: Open) > RPM distribution improvements and known issues > -- > > Key: CASSANDRA-13433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13433 > Project: Cassandra > Issue Type: Improvement > Components: Packaging >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Major > Attachments: cassandra-3.9-centos6.patch > > > Starting with CASSANDRA-13252, new releases will be provided as both official > RPM and Debian packages. While the Debian packages are already well > established with our user base, the RPMs just have been release for the first > time and still require some attention. > Feel free to discuss RPM related issues in this ticket and open a sub-task to > fill a bug report. > Please note that native systemd support will be implemented with > CASSANDRA-13148 and this is not strictly a RPM specific issue. We still > intent to offer non-systemd support based on the already working init scripts > that we ship. Therefor the first step is to make use of systemd backward > compatibility for SysV/LSB scripts, so we can provide RPMs for both systemd > and non-systemd environments. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14802) calculatePendingRanges assigns more pending ranges than necessary
[
https://issues.apache.org/jira/browse/CASSANDRA-14802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785881#comment-16785881
]
Benedict commented on CASSANDRA-14802:
--
+1
bq. This isn't a new regression and getting it right (& validating it) is going
to be quite involved, so it feels a bit of a risk for the 4.0 timeframe.
FWIW, I will need to look at this class again soon because transient
replication complicated it, and it is known to not work with transient
replication. In the process, I may see how challenging it would be to more
comprehensively fix and test the class, as it is currently very non-obvious to
work with. It might be possible to formulate it in a clearer manner, but we'll
see; obviously, not if it risk 4.0.
> calculatePendingRanges assigns more pending ranges than necessary
> --
>
> Key: CASSANDRA-14802
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14802
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination, Legacy/Distributed Metadata
>Reporter: Benedict
>Priority: Major
> Fix For: 4.x
>
>
> This might be a good thing, but should probably be configurable, and made
> consistent. Presently, in a number of circumstances where there are multiple
> range movements, {{calculatePendingRanges}} will assign a pending range to a
> node that will not ultimately own it. If done consistently, this might make
> range movements resilient to node failures / aborted range movements, since
> all nodes will be receiving all ranges they might own under any incomplete
> range ownership movements. But done inconsistently it seems only to reduce
> availability in the cluster, by potentially increasing the number of pending
> nodes unnecessarily.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13433) RPM distribution improvements and known issues
[ https://issues.apache.org/jira/browse/CASSANDRA-13433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anonymous updated CASSANDRA-13433: -- Status: Testing (was: Awaiting Feedback) > RPM distribution improvements and known issues > -- > > Key: CASSANDRA-13433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13433 > Project: Cassandra > Issue Type: Improvement > Components: Packaging >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Major > Attachments: cassandra-3.9-centos6.patch > > > Starting with CASSANDRA-13252, new releases will be provided as both official > RPM and Debian packages. While the Debian packages are already well > established with our user base, the RPMs just have been release for the first > time and still require some attention. > Feel free to discuss RPM related issues in this ticket and open a sub-task to > fill a bug report. > Please note that native systemd support will be implemented with > CASSANDRA-13148 and this is not strictly a RPM specific issue. We still > intent to offer non-systemd support based on the already working init scripts > that we ship. Therefor the first step is to make use of systemd backward > compatibility for SysV/LSB scripts, so we can provide RPMs for both systemd > and non-systemd environments. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
