[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
]
Vinay Chella updated CASSANDRA-15021:
-
Status: Patch Available (was: Open)
I went ahead and made
[composite|https://github.com/apache/cassandra-dtest/blob/master/thrift_test.py#L147]
function compatible with python2 and python3, this should fix the
{{TypeError}} in {{test_upgrade_with_range_tombstone_eoc_0}}
||dtest||upgrade-test||
|[dtest-fix-branch|https://github.com/vinaykumarchella/cassandra-dtest/tree/CASSANDRA-15021]|[!https://circleci.com/gh/vinaykumarchella/cassandra/tree/3.11.4-tentative.svg?circle-token=237fa63201f848ed64789902be862015f74bec9b!|https://circleci.com/gh/vinaykumarchella/cassandra/358]|
> 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
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. aleksey pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit b9b2e8e5744f10b7fcfea4acdeb4dee1dd071a8d Merge: 1268530 d7d0003 Author: Aleksey Yeshchenko AuthorDate: Fri Feb 15 09:41:18 2019 + Merge branch 'cassandra-3.0' into cassandra-3.11 CHANGES.txt| 3 +- .../apache/cassandra/tools/nodetool/Status.java| 45 +++--- 2 files changed, 25 insertions(+), 23 deletions(-) diff --cc CHANGES.txt index 00ca115,fb71bf5..2f9813e --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,7 -1,7 +1,8 @@@ -3.0.19 +3.11.5 - Merged from 3.0: ++Merged from 3.0: + * Improve `nodetool status -r` speed (CASSANDRA-14847) * Improve merkle tree size and time on heap (CASSANDRA-14096) - * Add missing commands to nodetool-completion (CASSANDRA-14916) + * Add missing commands to nodetool_completion (CASSANDRA-14916) * Anti-compaction temporarily corrupts sstable state for readers (CASSANDRA-15004) Merged from 2.2: * Multi-version in-JVM dtests (CASSANDRA-14937) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14847) improvement of nodetool status -r
[
https://issues.apache.org/jira/browse/CASSANDRA-14847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-14847:
--
Resolution: Fixed
Reviewers: Dinesh Joshi (was: Aleksey Yeschenko, Dinesh Joshi)
Status: Resolved (was: Patch Available)
> improvement of nodetool status -r
> -
>
> Key: CASSANDRA-14847
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14847
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Fumiya Yamashita
>Assignee: Fumiya Yamashita
>Priority: Major
> Fix For: 3.0.19, 3.11.5, 4.0
>
> Attachments: 3.11.1.patch
>
>
> Hello,
> When using "nodetool status -r", I found a problem that the response time
> becomes longer depending on the number of vnodes.
> In my testing environment, when the num_token is 256 and the number of nodes
> is 6, the response takes about 60 seconds.
> It turned out that the findMaxAddressLength method in status.java is causing
> the delay.
> Despite only obtaining the maximum length of the address by the number of
> vnodes, `tokenrange * vnode` times also loop processing, there is redundancy.
> To prevent duplicate host names from being referenced every time, I modified
> to check with hash.
> In my environment, the response time has been reduced from 60 seconds to 2
> seconds.
> I attached the patch, so please check it.
> Thank you
> {code:java}
> [before]
> Datacenter: dc1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN *** 559.32 KB 256 48.7% 0555746a-60c2-4717-b042-94ba951ef679 ***
> UN *** 721.48 KB 256 51.4% 1af4acb6-e0a0-4bcb-8bba-76ae2e225cd5 ***
> UN *** 699.98 KB 256 48.3% 5215c728-9b80-4e3c-b46b-c5b8e5eb753f ***
> UN *** 691.65 KB 256 48.1% 57da4edf-4acb-474d-b26c-27f048c37bd6 ***
> UN *** 705.66 KB 256 52.8% 07520eab-47d2-4f5d-aeeb-f6e599c9b084 ***
> UN *** 610.87 KB 256 50.7% 6b39acaf-6ed6-42e4-a357-0d258bdf87b7 ***
> time : 66s
> [after]
> Datacenter: dc1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN *** 559.32 KB 256 48.7% 0555746a-60c2-4717-b042-94ba951ef679 ***
> UN *** 721.48 KB 256 51.4% 1af4acb6-e0a0-4bcb-8bba-76ae2e225cd5 ***
> UN *** 699.98 KB 256 48.3% 5215c728-9b80-4e3c-b46b-c5b8e5eb753f ***
> UN *** 691.65 KB 256 48.1% 57da4edf-4acb-474d-b26c-27f048c37bd6 ***
> UN *** 705.66 KB 256 52.8% 07520eab-47d2-4f5d-aeeb-f6e599c9b084 ***
> UN *** 610.87 KB 256 50.7% 6b39acaf-6ed6-42e4-a357-0d258bdf87b7 ***
> time : 2s
> {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=16769173#comment-16769173
]
Vinay Chella commented on CASSANDRA-15016:
--
Thank you for the review [~aweisberg]
{quote}Why did you remove this assertion?
{quote}
[assert_almost_equal
|https://github.com/vinaykumarchella/cassandra-dtest/commit/adcc84d71de6f727d05647b21ff6c48d7bf6920b#diff-0b30b9f097df89d74be1d1af8205ac7eL115]
is flaky across the versions. I tried to change this to achieve a more
fine-grained size check. Context: this
[check|https://github.com/vinaykumarchella/cassandra-dtest/commit/adcc84d71de6f727d05647b21ff6c48d7bf6920b#diff-0b30b9f097df89d74be1d1af8205ac7eL115]
is to ensure that cleanup and compact did their job, but we end up checking
the entire node size which might be varying as additional tables that we *may*
introduce in new releases or already introduced ones from across the versions.
We also don't put in enough data to make that the dominant cost for test
keyspaces.
Based on our offline discussion and suggestions, I added table specific data
size check, and this enables to do data size check for tables that we are
interested in, with this change now we achieve our goal of size checking
without depending on external factors of system tables and their size.
{quote}Do you need check bootstrap_from_version? Seems like it is enough to
just check compatibility_flag_on.
{quote}
I made this better now, instead of exposing it as a {{compatibility_flag_on}},
now passing {{bootstrap}} function with compatibility_flag, this makes the
better use of
[bootstrap|https://github.com/apache/cassandra-dtest/blob/master/bootstrap_test.py#L46]
parameter in {{_base_bootstrap_test}}
{quote}Can you better document what is going on and why the compatibility flag
is being set in the tests, so the next person knows what is going on?
{quote}
I tried to add context in code and also referenced CASSANDRA-13004 in comments.
||dtest||upgrade-test||
|[dtest-fix-branch|https://github.com/vinaykumarchella/cassandra-dtest/tree/fix_failing_upgradetest]|[!https://circleci.com/gh/vinaykumarchella/cassandra/tree/3.11.4-tentative.svg?circle-token=237fa63201f848ed64789902be862015f74bec9b!|https://circleci.com/gh/vinaykumarchella/cassandra/352]|
> 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
>
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. aleksey pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit d75c438b21678eda3bf8ba3890fd7f61b9673548 Merge: 70e6f29 b9b2e8e Author: Aleksey Yeshchenko AuthorDate: Fri Feb 15 10:05:14 2019 + Merge branch 'cassandra-3.11' into trunk CHANGES.txt| 3 + .../apache/cassandra/tools/nodetool/Status.java| 111 - 2 files changed, 45 insertions(+), 69 deletions(-) diff --cc CHANGES.txt index 1394ea8,2f9813e..0c856c2 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,353 -1,11 +1,356 @@@ +4.0 + * SSL Cert Hot Reloading should check for sanity of the new keystore/truststore before loading it (CASSANDRA-14991) + * Avoid leaking threads when failing anticompactions and rate limit anticompactions (CASSANDRA-15002) + * Validate token() arguments early instead of throwing NPE at execution (CASSANDRA-14989) + * Add a new tool to dump audit logs (CASSANDRA-14885) + * Fix generating javadoc with Java11 (CASSANDRA-14988) + * Only cancel conflicting compactions when starting anticompactions and sub range compactions (CASSANDRA-14935) + * Use a stub IndexRegistry for non-daemon use cases (CASSANDRA-14938) + * Don't enable client transports when bootstrap is pending (CASSANDRA-14525) + * Make antiCompactGroup throw exception on error and anticompaction non cancellable + again (CASSANDRA-14936) + * Catch empty/invalid bounds in SelectStatement (CASSANDRA-14849) + * Auto-expand replication_factor for NetworkTopologyStrategy (CASSANDRA-14303) + * Transient Replication: support EACH_QUORUM (CASSANDRA-14727) + * BufferPool: allocating thread for new chunks should acquire directly (CASSANDRA-14832) + * Send correct messaging version in internode messaging handshake's third message (CASSANDRA-14896) + * Make Read and Write Latency columns consistent for proxyhistograms and tablehistograms (CASSANDRA-11939) + * Make protocol checksum type option case insensitive (CASSANDRA-14716) + * Forbid re-adding static columns as regular and vice versa (CASSANDRA-14913) + * Audit log allows system keyspaces to be audited via configuration options (CASSANDRA-14498) + * Lower default chunk_length_in_kb from 64kb to 16kb (CASSANDRA-13241) + * Startup checker should wait for count rather than percentage (CASSANDRA-14297) + * Fix incorrect sorting of replicas in SimpleStrategy.calculateNaturalReplicas (CASSANDRA-14862) + * Partitioned outbound internode TCP connections can occur when nodes restart (CASSANDRA-14358) + * Don't write to system_distributed.repair_history, system_traces.sessions, system_traces.events in mixed version 3.X/4.0 clusters (CASSANDRA-14841) + * Avoid running query to self through messaging service (CASSANDRA-14807) + * Allow using custom script for chronicle queue BinLog archival (CASSANDRA-14373) + * Transient->Full range movements mishandle consistency level upgrade (CASSANDRA-14759) + * ReplicaCollection follow-up (CASSANDRA-14726) + * Transient node receives full data requests (CASSANDRA-14762) + * Enable snapshot artifacts publish (CASSANDRA-12704) + * Introduce RangesAtEndpoint.unwrap to simplify StreamSession.addTransferRanges (CASSANDRA-14770) + * LOCAL_QUORUM may speculate to non-local nodes, resulting in Timeout instead of Unavailable (CASSANDRA-14735) + * Avoid creating empty compaction tasks after truncate (CASSANDRA-14780) + * Fail incremental repair prepare phase if it encounters sstables from un-finalized sessions (CASSANDRA-14763) + * Add a check for receiving digest response from transient node (CASSANDRA-14750) + * Fail query on transient replica if coordinator only expects full data (CASSANDRA-14704) + * Remove mentions of transient replication from repair path (CASSANDRA-14698) + * Fix handleRepairStatusChangedNotification to remove first then add (CASSANDRA-14720) + * Allow transient node to serve as a repair coordinator (CASSANDRA-14693) + * DecayingEstimatedHistogramReservoir.EstimatedHistogramReservoirSnapshot returns wrong value for size() and incorrectly calculates count (CASSANDRA-14696) + * AbstractReplicaCollection equals and hash code should throw due to conflict between order sensitive/insensitive uses (CASSANDRA-14700) + * Detect inconsistencies in repaired data on the read path (CASSANDRA-14145) + * Add checksumming to the native protocol (CASSANDRA-13304) + * Make AuthCache more easily extendable (CASSANDRA-14662) + * Extend RolesCache to include detailed role info (CASSANDRA-14497) + * Add fqltool compare (CASSANDRA-14619) + * Add fqltool replay (CASSANDRA-14618) + * Log keyspace in full query log (CASSANDRA-14656) + * Transient Replication and Cheap Quorums (CASSANDRA-14404) + * Log server-generated timestamp and nowInSeconds used by queries in FQL (CASSANDRA-14675) + * Add diagnostic events for read repairs (CASSANDRA-14668) +
[cassandra] branch trunk updated (70e6f29 -> d75c438)
This is an automated email from the ASF dual-hosted git repository. aleksey pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 70e6f29 Merge branch 'cassandra-3.11' into trunk add d7d0003 Improve `nodetool status -r` speed add b9b2e8e Merge branch 'cassandra-3.0' into cassandra-3.11 new d75c438 Merge branch 'cassandra-3.11' into trunk 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. Summary of changes: CHANGES.txt| 3 + .../apache/cassandra/tools/nodetool/Status.java| 111 - 2 files changed, 45 insertions(+), 69 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14847) improvement of nodetool status -r
[
https://issues.apache.org/jira/browse/CASSANDRA-14847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769162#comment-16769162
]
Aleksey Yeschenko commented on CASSANDRA-14847:
---
Committed as
[d7d00036e7bc49ceb7da7971e39063733ce50136|https://github.com/apache/cassandra/commit/d7d00036e7bc49ceb7da7971e39063733ce50136]
to 3.0, and merged with 3.11 and trunk. Thanks.
> improvement of nodetool status -r
> -
>
> Key: CASSANDRA-14847
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14847
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Fumiya Yamashita
>Assignee: Fumiya Yamashita
>Priority: Major
> Fix For: 4.0, 3.0.x, 3.11.x
>
> Attachments: 3.11.1.patch
>
>
> Hello,
> When using "nodetool status -r", I found a problem that the response time
> becomes longer depending on the number of vnodes.
> In my testing environment, when the num_token is 256 and the number of nodes
> is 6, the response takes about 60 seconds.
> It turned out that the findMaxAddressLength method in status.java is causing
> the delay.
> Despite only obtaining the maximum length of the address by the number of
> vnodes, `tokenrange * vnode` times also loop processing, there is redundancy.
> To prevent duplicate host names from being referenced every time, I modified
> to check with hash.
> In my environment, the response time has been reduced from 60 seconds to 2
> seconds.
> I attached the patch, so please check it.
> Thank you
> {code:java}
> [before]
> Datacenter: dc1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN *** 559.32 KB 256 48.7% 0555746a-60c2-4717-b042-94ba951ef679 ***
> UN *** 721.48 KB 256 51.4% 1af4acb6-e0a0-4bcb-8bba-76ae2e225cd5 ***
> UN *** 699.98 KB 256 48.3% 5215c728-9b80-4e3c-b46b-c5b8e5eb753f ***
> UN *** 691.65 KB 256 48.1% 57da4edf-4acb-474d-b26c-27f048c37bd6 ***
> UN *** 705.66 KB 256 52.8% 07520eab-47d2-4f5d-aeeb-f6e599c9b084 ***
> UN *** 610.87 KB 256 50.7% 6b39acaf-6ed6-42e4-a357-0d258bdf87b7 ***
> time : 66s
> [after]
> Datacenter: dc1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN *** 559.32 KB 256 48.7% 0555746a-60c2-4717-b042-94ba951ef679 ***
> UN *** 721.48 KB 256 51.4% 1af4acb6-e0a0-4bcb-8bba-76ae2e225cd5 ***
> UN *** 699.98 KB 256 48.3% 5215c728-9b80-4e3c-b46b-c5b8e5eb753f ***
> UN *** 691.65 KB 256 48.1% 57da4edf-4acb-474d-b26c-27f048c37bd6 ***
> UN *** 705.66 KB 256 52.8% 07520eab-47d2-4f5d-aeeb-f6e599c9b084 ***
> UN *** 610.87 KB 256 50.7% 6b39acaf-6ed6-42e4-a357-0d258bdf87b7 ***
> time : 2s
> {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
[cassandra] branch cassandra-3.11 updated (1268530 -> b9b2e8e)
This is an automated email from the ASF dual-hosted git repository. aleksey pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 1268530 Merge branch 'cassandra-3.0' into cassandra-3.11 add d7d0003 Improve `nodetool status -r` speed new b9b2e8e Merge branch 'cassandra-3.0' into cassandra-3.11 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. Summary of changes: CHANGES.txt| 3 +- .../apache/cassandra/tools/nodetool/Status.java| 45 +++--- 2 files changed, 25 insertions(+), 23 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated: Improve `nodetool status -r` speed
This is an automated email from the ASF dual-hosted git repository.
aleksey pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.0 by this push:
new d7d0003 Improve `nodetool status -r` speed
d7d0003 is described below
commit d7d00036e7bc49ceb7da7971e39063733ce50136
Author: Fumiya Yamashita
AuthorDate: Tue Feb 12 17:03:26 2019 -0800
Improve `nodetool status -r` speed
patch by Fumiya Yamashita; reviewed by Dinesh Joshi for CASSANDRA-14847
Co-authored-by: Fumiya Yamashita
Co-authored-by: Dinesh A. Joshi
---
CHANGES.txt| 1 +
.../apache/cassandra/tools/nodetool/Status.java| 45 +++---
2 files changed, 24 insertions(+), 22 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index b755751..fb71bf5 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0.19
+ * Improve `nodetool status -r` speed (CASSANDRA-14847)
* Improve merkle tree size and time on heap (CASSANDRA-14096)
* Add missing commands to nodetool-completion (CASSANDRA-14916)
* Anti-compaction temporarily corrupts sstable state for readers
(CASSANDRA-15004)
diff --git a/src/java/org/apache/cassandra/tools/nodetool/Status.java
b/src/java/org/apache/cassandra/tools/nodetool/Status.java
index 99f745d..091040b 100644
--- a/src/java/org/apache/cassandra/tools/nodetool/Status.java
+++ b/src/java/org/apache/cassandra/tools/nodetool/Status.java
@@ -25,8 +25,10 @@ import java.net.InetAddress;
import java.net.UnknownHostException;
import java.text.DecimalFormat;
import java.util.Collection;
+import java.util.HashSet;
import java.util.List;
import java.util.Map;
+import java.util.Set;
import java.util.SortedMap;
import org.apache.cassandra.locator.EndpointSnitchInfoMBean;
@@ -46,7 +48,6 @@ public class Status extends NodeToolCmd
private boolean resolveIp = false;
private boolean isTokenPerNode = true;
-private int maxAddressLength = 0;
private String format = null;
private Collection joiningNodes, leavingNodes, movingNodes,
liveNodes, unreachableNodes;
private Map loadMap, hostIDMap;
@@ -91,13 +92,13 @@ public class Status extends NodeToolCmd
if (dcs.values().size() < tokensToEndpoints.keySet().size())
isTokenPerNode = false;
-findMaxAddressLength(dcs);
+int maxAddressLength = computeMaxAddressLength(dcs);
// Datacenters
for (Map.Entry dc : dcs.entrySet())
{
String dcHeader = String.format("Datacenter: %s%n", dc.getKey());
-System.out.printf(dcHeader);
+System.out.print(dcHeader);
for (int i = 0; i < (dcHeader.length() - 1); i++)
System.out.print('=');
System.out.println();
@@ -105,7 +106,7 @@ public class Status extends NodeToolCmd
System.out.println("Status=Up/Down");
System.out.println("|/ State=Normal/Leaving/Joining/Moving");
-printNodesHeader(hasEffectiveOwns, isTokenPerNode);
+printNodesHeader(hasEffectiveOwns, isTokenPerNode,
maxAddressLength);
ArrayListMultimap hostToTokens =
ArrayListMultimap.create();
for (HostStat stat : dc.getValue())
@@ -115,29 +116,30 @@ public class Status extends NodeToolCmd
{
Float owns = ownerships.get(endpoint);
List tokens = hostToTokens.get(endpoint);
-printNode(endpoint.getHostAddress(), owns, tokens,
hasEffectiveOwns, isTokenPerNode);
+printNode(endpoint.getHostAddress(), owns, tokens,
hasEffectiveOwns, isTokenPerNode, maxAddressLength);
}
}
-System.out.printf("%n" + errors.toString());
+System.out.printf("%n" + errors);
}
-private void findMaxAddressLength(Map dcs)
+private int computeMaxAddressLength(Map dcs)
{
-maxAddressLength = 0;
-for (Map.Entry dc : dcs.entrySet())
-{
-for (HostStat stat : dc.getValue())
-{
-maxAddressLength = Math.max(maxAddressLength,
stat.ipOrDns().length());
-}
-}
+int maxAddressLength = 0;
+
+Set seenHosts = new HashSet<>();
+for (SetHostStat stats : dcs.values())
+for (HostStat stat : stats)
+if (seenHosts.add(stat.endpoint))
+maxAddressLength = Math.max(maxAddressLength,
stat.ipOrDns().length());
+
+return maxAddressLength;
}
-private void printNodesHeader(boolean hasEffectiveOwns, boolean
isTokenPerNode)
+private void printNodesHeader(boolean hasEffectiveOwns, boolean
isTokenPerNode, int maxAddressLength)
{
-String fmt = getFormat(hasEffectiveOwns, isTokenPerNode);
+String fmt = getFormat(hasEffectiveOwns, isTokenPerNode,
maxAddressLength);
String owns =
[jira] [Updated] (CASSANDRA-14811) RPC_READY flag handled inconsistently
[
https://issues.apache.org/jira/browse/CASSANDRA-14811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Repasi updated CASSANDRA-14811:
-
Description:
With version 3.0.17 we experience an inconsistent handling of the RPC_READY
flag. We identified 3 scenarios with an unexpected behaviour.
# Using {{nodetool disablebinary}} on a node in normal operation
** Observed behaviour:
*** (/) the CQL listener is closed and Netty shut down
*** (x) gossipinfo still contain the {{RPC_READY}} *true* advertisement.
** Expected behaviour: gossip announcement of the {{RPC_READY}} flag should
switch to *false.* This is what we observe with version 2.2.13
# Starting up a node with JVM option
{{-Dcassandra.start_native_transport=false}}
** Observed behaviour:
*** (/) Netty is not started to listen for CQL clients
*** (/) logging {{cassandra[1765]: INFO 13:58:46 Not starting native transport
as requested. Use JMX (StorageService->startNativeTransport()) or nodetool
(enablebinary) to start it}}
*** (?) the gossipinfo does not contain the {{RPC_READY}} flag at all,
however, this is also observed on 2.2.13.
# Issuing {{nodetool enablebinary}} command on a node started with
{{-Dcassandra.start_native_transport=false}}
** Observed behaviour:
*** (/) Netty is started up and open the CQL port for listening
*** (x) the {{RPC_READY}} flag is not announced for this node any more,
causing clients to not consider this node up and not trying to connect.
** Expected behaviour: gossip flag {{RPC_READY}} should be added to announce
*true*, as observed with version 2.2.13.
was:
With version 3.0.17 we experience an inconsistent handling of the RPC_READY
flag. We identified 3 scenarios with an unexpected behaviour.
# Using {{nodetool disablebinary}} on a node in normal operation
** Observed behaviour:
*** (/) the CQL listener is closed and Netty shut down
*** (x) gossipinfo still contain the {{RPC_READY}} *true* advertisement.
** Expected behaviour: gossip announcement of the {{RPC_READY}} flag should
switch to *false.* This is what we observe with version 2.2.13
# Starting up a node with JVM option
{{-Dcassandra.start_native_transport=false}}
** Observed behaviour:
*** (/) Netty is not started to listen for CQL clients
*** (/) logging {{cassandra[1765]: INFO 13:58:46 Not starting native transport
as requested. Use JMX (StorageService->startNativeTransport()) or nodetool
(enablebinary) to start it}}
*** (?) the gossipinfo does not contain the {{RPC_READY}} flag at all,
however, this is also observed on 2.2.13.
# Issuing {{nodetool enablebinary}} command on a node started with
{{-Dcassandra.start_native_transport=false}}
** Observed behaviour:
*** (/) Netty is started up and open the CQL port for listening
*** (x) the {{RPC_READY}} flag is not announced for this node any more,
causing clients to not consider this note up and not trying to connect.
** Expected behaviour: gossip flag {{RPC_READY}} should be added to announce
*true*, as observed with version 2.2.13.
> RPC_READY flag handled inconsistently
> -
>
> Key: CASSANDRA-14811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14811
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Distributed Metadata
>Reporter: Tibor Repasi
>Priority: Major
>
> With version 3.0.17 we experience an inconsistent handling of the RPC_READY
> flag. We identified 3 scenarios with an unexpected behaviour.
> # Using {{nodetool disablebinary}} on a node in normal operation
> ** Observed behaviour:
> *** (/) the CQL listener is closed and Netty shut down
> *** (x) gossipinfo still contain the {{RPC_READY}} *true* advertisement.
> ** Expected behaviour: gossip announcement of the {{RPC_READY}} flag should
> switch to *false.* This is what we observe with version 2.2.13
> # Starting up a node with JVM option
> {{-Dcassandra.start_native_transport=false}}
> ** Observed behaviour:
> *** (/) Netty is not started to listen for CQL clients
> *** (/) logging {{cassandra[1765]: INFO 13:58:46 Not starting native
> transport as requested. Use JMX (StorageService->startNativeTransport()) or
> nodetool (enablebinary) to start it}}
> *** (?) the gossipinfo does not contain the {{RPC_READY}} flag at all,
> however, this is also observed on 2.2.13.
> # Issuing {{nodetool enablebinary}} command on a node started with
> {{-Dcassandra.start_native_transport=false}}
> ** Observed behaviour:
> *** (/) Netty is started up and open the CQL port for listening
> *** (x) the {{RPC_READY}} flag is not announced for this node any more,
> causing clients to not consider this node up and not trying to connect.
> ** Expected behaviour: gossip flag {{RPC_READY}} should be added to announce
> *true*, as observed with version 2.2.13.
>
--
This message was
[jira] [Updated] (CASSANDRA-14847) improvement of nodetool status -r
[
https://issues.apache.org/jira/browse/CASSANDRA-14847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-14847:
--
Fix Version/s: (was: 3.11.x)
(was: 3.0.x)
3.11.5
3.0.19
> improvement of nodetool status -r
> -
>
> Key: CASSANDRA-14847
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14847
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Fumiya Yamashita
>Assignee: Fumiya Yamashita
>Priority: Major
> Fix For: 3.0.19, 3.11.5, 4.0
>
> Attachments: 3.11.1.patch
>
>
> Hello,
> When using "nodetool status -r", I found a problem that the response time
> becomes longer depending on the number of vnodes.
> In my testing environment, when the num_token is 256 and the number of nodes
> is 6, the response takes about 60 seconds.
> It turned out that the findMaxAddressLength method in status.java is causing
> the delay.
> Despite only obtaining the maximum length of the address by the number of
> vnodes, `tokenrange * vnode` times also loop processing, there is redundancy.
> To prevent duplicate host names from being referenced every time, I modified
> to check with hash.
> In my environment, the response time has been reduced from 60 seconds to 2
> seconds.
> I attached the patch, so please check it.
> Thank you
> {code:java}
> [before]
> Datacenter: dc1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN *** 559.32 KB 256 48.7% 0555746a-60c2-4717-b042-94ba951ef679 ***
> UN *** 721.48 KB 256 51.4% 1af4acb6-e0a0-4bcb-8bba-76ae2e225cd5 ***
> UN *** 699.98 KB 256 48.3% 5215c728-9b80-4e3c-b46b-c5b8e5eb753f ***
> UN *** 691.65 KB 256 48.1% 57da4edf-4acb-474d-b26c-27f048c37bd6 ***
> UN *** 705.66 KB 256 52.8% 07520eab-47d2-4f5d-aeeb-f6e599c9b084 ***
> UN *** 610.87 KB 256 50.7% 6b39acaf-6ed6-42e4-a357-0d258bdf87b7 ***
> time : 66s
> [after]
> Datacenter: dc1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN *** 559.32 KB 256 48.7% 0555746a-60c2-4717-b042-94ba951ef679 ***
> UN *** 721.48 KB 256 51.4% 1af4acb6-e0a0-4bcb-8bba-76ae2e225cd5 ***
> UN *** 699.98 KB 256 48.3% 5215c728-9b80-4e3c-b46b-c5b8e5eb753f ***
> UN *** 691.65 KB 256 48.1% 57da4edf-4acb-474d-b26c-27f048c37bd6 ***
> UN *** 705.66 KB 256 52.8% 07520eab-47d2-4f5d-aeeb-f6e599c9b084 ***
> UN *** 610.87 KB 256 50.7% 6b39acaf-6ed6-42e4-a357-0d258bdf87b7 ***
> time : 2s
> {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] [Updated] (CASSANDRA-15024) Don't try to cancel 2i compactions when starting anticompaction
[
https://issues.apache.org/jira/browse/CASSANDRA-15024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15024:
Reviewer: Blake Eggleston
Fix Version/s: 4.x
Status: Patch Available (was: Open)
Attaching patch to add option to simply avoid concatenating the index cfs when
calling {{runWithCompactionsDisabled}}.
patch: https://github.com/krummas/cassandra/commits/marcuse/2ianticompaction
tests:
https://circleci.com/gh/krummas/workflows/cassandra/tree/marcuse%2F2ianticompaction
> Don't try to cancel 2i compactions when starting anticompaction
> ---
>
> Key: CASSANDRA-15024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15024
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 4.x
>
>
> When we start an anticompaction we cancel ongoing compactions,
> {{runWithCompactionsDisabled}} always cancels compactions for secondary index
> cfs:es, this causes problem since CASSANDRA-14935 since we check for range
> intersection which will fail since 2i sstables are LocalPartitioner.
--
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-15006) Possible java.nio.DirectByteBuffer leak
[ https://issues.apache.org/jira/browse/CASSANDRA-15006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonas Borgström updated CASSANDRA-15006: Attachment: cassandra.yaml > Possible java.nio.DirectByteBuffer leak > --- > > Key: CASSANDRA-15006 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15006 > Project: Cassandra > Issue Type: Bug > Environment: cassandra: 3.11.3 > jre: openjdk version "1.8.0_181" > heap size: 2GB > memory limit: 3GB (cgroup) > I started one of the nodes with "-Djdk.nio.maxCachedBufferSize=262144" but > that did not seem to make any difference. >Reporter: Jonas Borgström >Priority: Major > Attachments: CASSANDRA-15006-reference-chains.png, > Screenshot_2019-02-04 Grafana - Cassandra.png, Screenshot_2019-02-14 Grafana > - Cassandra(1).png, Screenshot_2019-02-14 Grafana - Cassandra.png, > cassandra.yaml, cmdline.txt > > > While testing a 3 node 3.11.3 cluster I noticed that the nodes were suddenly > killed by the Linux OOM killer after running without issues for 4-5 weeks. > After enabling more metrics and leaving the nodes running for 12 days it sure > looks like the > "java.nio:type=BufferPool,name=direct" Mbean shows a very linear growth > (approx 15MiB/24h, see attached screenshot). Is this expected to keep growing > linearly after 12 days with a constant load? > > In my setup the growth/leak is about 15MiB/day so I guess in most setups it > would take quite a few days until it becomes noticeable. I'm able to see the > same type of slow growth in other production clusters even though the graph > data is more noisy. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15011) In-JVM Testing tooling for repair
[ https://issues.apache.org/jira/browse/CASSANDRA-15011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769440#comment-16769440 ] Alex Petrov edited comment on CASSANDRA-15011 at 2/15/19 3:55 PM: -- Preliminary patch [here|https://github.com/apache/cassandra/compare/trunk...ifesdjeen:CASSANDRA-15011-trunk] cc [~jolynch] [~jmeredithco]. I'll add options for incremental repair, rebase for all branches and add some more tests, but wanted to check the general direction. was (Author: ifesdjeen): Preliminary patch [here|https://github.com/apache/cassandra/compare/trunk...ifesdjeen:CASSANDRA-15011-trunk] cc [~jolynch] [~jmeredithco] > In-JVM Testing tooling for repair > - > > Key: CASSANDRA-15011 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15011 > Project: Cassandra > Issue Type: Test >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Major > > Add messaging service startup to in-jvm distributed testing as repairs are > not running through the same hander mechanism as “regular” internode. Add > simple repair test. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15011) In-JVM Testing tooling for repair
[ https://issues.apache.org/jira/browse/CASSANDRA-15011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769440#comment-16769440 ] Alex Petrov edited comment on CASSANDRA-15011 at 2/15/19 3:55 PM: -- Preliminary patch [here|https://github.com/apache/cassandra/compare/trunk...ifesdjeen:CASSANDRA-15011-trunk] cc [~jolynch] [~jmeredithco] was (Author: ifesdjeen): Preliminary patch [here|https://github.com/apache/cassandra/compare/trunk...ifesdjeen:CASSANDRA-15011-trunk] > In-JVM Testing tooling for repair > - > > Key: CASSANDRA-15011 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15011 > Project: Cassandra > Issue Type: Test >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Major > > Add messaging service startup to in-jvm distributed testing as repairs are > not running through the same hander mechanism as “regular” internode. Add > simple repair test. -- 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-14395) C* Management process
[
https://issues.apache.org/jira/browse/CASSANDRA-14395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769326#comment-16769326
]
Jason Brown commented on CASSANDRA-14395:
-
- inspecting the tarball via produced via \{{gradlew distTar}}, I don't see the
jolokia jar packaged in it. Admittedly, I didn't check on the last version of
this patch either.
- need a license file when including the jolokia jar. I propose we start simple
for now, and since there's only one jar for now (which is hopefully being
removed in an upcoming patch) - just add the license in a subfolder like we do
in cassandra.
- in \{{HealthCheck::check}}, when we get a \{{NoHostAvailableException}} from
the driver (which is thrown when we cannot connect), it would preferable to not
litter the logs with the stack trace. Or maybe log the exception at \{{DEBUG}}
or \{{TRACE}}. I discovered this by running c* locally, then terminating it,
and watching the logs from the sidecar.
- petty nit: sometimes a \{{catch}} keyword is on the same line as the closing
brace of a \{[try}} block. See \{{HealhCheck::createCluster}} for an example.
> C* Management process
> -
>
> Key: CASSANDRA-14395
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14395
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Major
> Attachments: Looking towards an Official Cassandra Sidecar -
> Netflix.pdf
>
>
> I would like to propose amending Cassandra's architecture to include a
> management process. The detailed description is here:
> https://docs.google.com/document/d/1UV9pE81NaIUF3g4L1wxq09nT11AkSQcMijgLFwGsY3s/edit
> I'd like to propose seeding this with a few simple use-cases such as Health
> Checks, Bulk Commands with a simple REST API interface.
--
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-15013) Message Flusher queue can grow unbounded, potentially running JVM out of memory
[
https://issues.apache.org/jira/browse/CASSANDRA-15013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769340#comment-16769340
]
Jason Brown commented on CASSANDRA-15013:
-
Ahh, I just reread the {{doc/native_protocol_v5.spec}}, and the OPTIONS are an
open map, basically. I thought they were a fixed listing (primarily because we
only support a fixed set of compression types). OK, so any version works for me
:).
> Message Flusher queue can grow unbounded, potentially running JVM out of
> memory
> ---
>
> Key: CASSANDRA-15013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15013
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Major
> Fix For: 4.0, 3.0.x, 3.11.x
>
> Attachments: BlockedEpollEventLoopFromHeapDump.png,
> BlockedEpollEventLoopFromThreadDump.png, RequestExecutorQueueFull.png, heap
> dump showing each ImmediateFlusher taking upto 600MB.png
>
>
> This is a follow-up ticket out of CASSANDRA-14855, to make the Flusher queue
> bounded, since, in the current state, items get added to the queue without
> any checks on queue size, nor with any checks on netty outbound buffer to
> check the isWritable state.
> We are seeing this issue hit our production 3.0 clusters quite often.
--
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
***UNCHECKED*** Re: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error:
>(Unable to connect to any servers,*
> *{127.0.0.1: ProtocolError(Unexpected response during
>Connection setup: AttributeError("\module\ object has no attribute
>\decompress\",),)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
>[https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
>tokenize;_file=/tmp/pip-build-P7pulc/python-snappy/setup.py;f=getattr(tokenize,
> open, open)(file);code=f.read().replace(\r\n,
>\n);f.close();exec(compile(code, __file_, exec))"
>bdist_wheel -d /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
>option: cffi_modules*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building snappy._snappy extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
>-Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
>-fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
>-fstack-protector-strong -Wformat -Werror=format-security -fPIC
>-I/usr/include/python2.7 -c snappy/snappymodule.cc -o
>build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option -Wstrict-prototypes is
>valid for C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
>directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command x86_64-linux-gnu-gcc failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
>tokenize;__file__=/tmp/pip-build-P7pulc/python-snappy/setup.py;f=getattr(tokenize,
> open, open)(__file__);code=f.read().replace(\r\n,
>\n);f.close();exec(compile(code, __file__, exec))"
>install --record /tmp/pip-4Ie8H2-record/install-record.txt
>--single-version-externally-managed --compile --user --prefix=:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
>option: cffi_modules*
> *warnings.warn(msg)*
> *running install*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying
[jira] [Created] (CASSANDRA-15024) Don't try to cancel 2i compactions when starting anticompaction
Marcus Eriksson created CASSANDRA-15024:
---
Summary: Don't try to cancel 2i compactions when starting
anticompaction
Key: CASSANDRA-15024
URL: https://issues.apache.org/jira/browse/CASSANDRA-15024
Project: Cassandra
Issue Type: Bug
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson
When we start an anticompaction we cancel ongoing compactions,
{{runWithCompactionsDisabled}} always cancels compactions for secondary index
cfs:es, this causes problem since CASSANDRA-14935 since we check for range
intersection which will fail since 2i sstables are LocalPartitioner.
--
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-15025) Avoid NPE in RepairRunnable.recordFailure
[
https://issues.apache.org/jira/browse/CASSANDRA-15025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15025:
Description: failureMessage parameter in {{RepairRunnable.recordFailure}}
can be null, avoid this happening and make sure we log the actual exception
(was: message parameter in {{RepairRunnable.recordFailure}} can be null, avoid
this happening and make sure we log the actual exception)
> Avoid NPE in RepairRunnable.recordFailure
> -
>
> Key: CASSANDRA-15025
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15025
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 4.x
>
>
> failureMessage parameter in {{RepairRunnable.recordFailure}} can be null,
> avoid this happening and make sure we log the actual exception
--
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-15006) Possible java.nio.DirectByteBuffer leak
[ https://issues.apache.org/jira/browse/CASSANDRA-15006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonas Borgström updated CASSANDRA-15006: Attachment: cmdline.txt > Possible java.nio.DirectByteBuffer leak > --- > > Key: CASSANDRA-15006 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15006 > Project: Cassandra > Issue Type: Bug > Environment: cassandra: 3.11.3 > jre: openjdk version "1.8.0_181" > heap size: 2GB > memory limit: 3GB (cgroup) > I started one of the nodes with "-Djdk.nio.maxCachedBufferSize=262144" but > that did not seem to make any difference. >Reporter: Jonas Borgström >Priority: Major > Attachments: CASSANDRA-15006-reference-chains.png, > Screenshot_2019-02-04 Grafana - Cassandra.png, Screenshot_2019-02-14 Grafana > - Cassandra(1).png, Screenshot_2019-02-14 Grafana - Cassandra.png, > cassandra.yaml, cmdline.txt > > > While testing a 3 node 3.11.3 cluster I noticed that the nodes were suddenly > killed by the Linux OOM killer after running without issues for 4-5 weeks. > After enabling more metrics and leaving the nodes running for 12 days it sure > looks like the > "java.nio:type=BufferPool,name=direct" Mbean shows a very linear growth > (approx 15MiB/24h, see attached screenshot). Is this expected to keep growing > linearly after 12 days with a constant load? > > In my setup the growth/leak is about 15MiB/day so I guess in most setups it > would take quite a few days until it becomes noticeable. I'm able to see the > same type of slow growth in other production clusters even though the graph > data is more noisy. -- 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-15006) Possible java.nio.DirectByteBuffer leak
[ https://issues.apache.org/jira/browse/CASSANDRA-15006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769406#comment-16769406 ] Jonas Borgström commented on CASSANDRA-15006: - Hi [~benedict]. Sorry I just missed your reply when I wrote my own reply yesterday. h4. About the graphs All graphed values are from standard java/cassandra JMX metrics. The name of each graph should explain exactly which MBean is used and what attribute of that MBean that is plotted. So for example the "java.nio:type=BufferPool,name=direct/MemoryUsed" graph plots the "MemoryUsed" attribute of the JMX Mbean with objectName "java.nio:type=BufferPool,name=direct". Let me know if I should explain any of the other graphs in more detail but they all follow the same naming pattern. h5. Memory limit I run cassandra using kubernetes. Kubernetes lets you define hard memory limits that are enforced using cgroups. When I initially ran into this issue I had a hard memory limit of 3GiB. But in order to see if this would eventually level out I changed that to 4GiB when started the current set of nodes. How did you determine that the process has "much more than this (3GiB)" committed to it? If we can assume that all "DirectByteBufferR" usage refer to mapped memory and not actual off-heap allocations I think the process still stays under the 4GiB for now. It just does not level out the way I expect. h5. Log files and configuration I'm afraid the log entries from the node startup have already been deleted but I've uploaded my cassandra.yaml and the command line used to start java. h5. Table truncation I did truncate a large table yesterday. And as expected the "java.nio:type=BufferPool,name=mapped/MemoryUsed" graphs shows that the amount of mapped memory immediately decreased from 6GiB to 0.6GiB corresponding well with the amount of data left on the system. This value also seems mostly unchanged now 24 hours later. Probably because not much new data has been written since yesterday. The "java.nio:type=BufferPool,name=direct/MemoryUsed" graph also immediately dropped from 800+MiB to around 500MiB. Interestingly this value has now almost 24h later almost made it's way back up to over 750MiB without that much more data being written to cassandra since yesterday. I forgot one detail. In addition to a fairly standard CQL load (mostly selects and some inserts) I've also been running "while true; nodetool repair --full && sleep 1h; done" since day 1. h5. Heap Dump I've saved a number of heap dumps during the test (both before and after I truncated the table for example) so I'll try to work out a way to make them downloadable > Possible java.nio.DirectByteBuffer leak > --- > > Key: CASSANDRA-15006 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15006 > Project: Cassandra > Issue Type: Bug > Environment: cassandra: 3.11.3 > jre: openjdk version "1.8.0_181" > heap size: 2GB > memory limit: 3GB (cgroup) > I started one of the nodes with "-Djdk.nio.maxCachedBufferSize=262144" but > that did not seem to make any difference. >Reporter: Jonas Borgström >Priority: Major > Attachments: CASSANDRA-15006-reference-chains.png, > Screenshot_2019-02-04 Grafana - Cassandra.png, Screenshot_2019-02-14 Grafana > - Cassandra(1).png, Screenshot_2019-02-14 Grafana - Cassandra.png, > Screenshot_2019-02-15 Grafana - Cassandra.png, cassandra.yaml, cmdline.txt > > > While testing a 3 node 3.11.3 cluster I noticed that the nodes were suddenly > killed by the Linux OOM killer after running without issues for 4-5 weeks. > After enabling more metrics and leaving the nodes running for 12 days it sure > looks like the > "java.nio:type=BufferPool,name=direct" Mbean shows a very linear growth > (approx 15MiB/24h, see attached screenshot). Is this expected to keep growing > linearly after 12 days with a constant load? > > In my setup the growth/leak is about 15MiB/day so I guess in most setups it > would take quite a few days until it becomes noticeable. I'm able to see the > same type of slow growth in other production clusters even though the graph > data is more noisy. -- 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-15011) In-JVM Testing tooling for repair
[ https://issues.apache.org/jira/browse/CASSANDRA-15011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769440#comment-16769440 ] Alex Petrov commented on CASSANDRA-15011: - Preliminary patch [here|https://github.com/apache/cassandra/compare/trunk...ifesdjeen:CASSANDRA-15011-trunk] > In-JVM Testing tooling for repair > - > > Key: CASSANDRA-15011 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15011 > Project: Cassandra > Issue Type: Test >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Major > > Add messaging service startup to in-jvm distributed testing as repairs are > not running through the same hander mechanism as “regular” internode. Add > simple repair test. -- 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-15011) In-JVM Testing tooling for repair
[ https://issues.apache.org/jira/browse/CASSANDRA-15011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15011: Reviewer: Jon Meredith > In-JVM Testing tooling for repair > - > > Key: CASSANDRA-15011 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15011 > Project: Cassandra > Issue Type: Test >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Major > > Add messaging service startup to in-jvm distributed testing as repairs are > not running through the same hander mechanism as “regular” internode. Add > simple repair test. -- 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-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
AvionTEq - Edelyn updated CASSANDRA-15017:
--
Attachment: AvionTEq.zip
Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
--
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
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Attachments: AvionTEq.zip, AvionTEq.zip, AvionTEq.zip, AvionTEq.zip,
> AvionTEq.zip
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install
[jira] [Commented] (CASSANDRA-15013) Message Flusher queue can grow unbounded, potentially running JVM out of memory
[
https://issues.apache.org/jira/browse/CASSANDRA-15013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769292#comment-16769292
]
Jason Brown commented on CASSANDRA-15013:
-
[~benedict] A, I see now that's what you intended by
\{{connection-configurable option}}. I'm fine with that.
I'm not sure if specifying the 'backpressure type' would require a change to
the native protocol. I think it would be most appropriate in the OPTIONS
section (and thus {{OptionasMessage}}), but I might be mistaken. However, I
wonder if we should break that work out into a separate ticket to unblock the
other work here, so that it can be backported and fixed in production. wdyt?
> Message Flusher queue can grow unbounded, potentially running JVM out of
> memory
> ---
>
> Key: CASSANDRA-15013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15013
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Major
> Fix For: 4.0, 3.0.x, 3.11.x
>
> Attachments: BlockedEpollEventLoopFromHeapDump.png,
> BlockedEpollEventLoopFromThreadDump.png, RequestExecutorQueueFull.png, heap
> dump showing each ImmediateFlusher taking upto 600MB.png
>
>
> This is a follow-up ticket out of CASSANDRA-14855, to make the Flusher queue
> bounded, since, in the current state, items get added to the queue without
> any checks on queue size, nor with any checks on netty outbound buffer to
> check the isWritable state.
> We are seeing this issue hit our production 3.0 clusters quite often.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15013) Message Flusher queue can grow unbounded, potentially running JVM out of memory
[
https://issues.apache.org/jira/browse/CASSANDRA-15013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769310#comment-16769310
]
Benedict edited comment on CASSANDRA-15013 at 2/15/19 1:30 PM:
---
I guess maybe let's wait and see how much more complicated it would be? You're
right that the {{OptionsMessage}} should be sufficient for supplying the
option, and I think the complicated bit is going to be negotiating safely with
the {{requestExecutor}} when we should start and stop reading.
If it turns out to be super challenging, by all means let's make it a 4.0-only
follow-up, but if (as I suspect) it's nominally extra work, I think it's better
to tie up the work while there's pressure to do so. WDYT?
was (Author: benedict):
I guess maybe let's wait and see how much more complicated it would be? You're
right that the {{OptionsMessage}} should be sufficient for supplying the
option, and I think the complicated bit is going to be negotiating safely with
the {{requestExecutor}} when we should start and stop reading.
If it turns out to be super challenging, by all means let's make it a 4.0-only
follow-up, but if (as I suspect) it's nominally extra work, I think it's better
to tie up the work while there's pressure to do so.
> Message Flusher queue can grow unbounded, potentially running JVM out of
> memory
> ---
>
> Key: CASSANDRA-15013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15013
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Major
> Fix For: 4.0, 3.0.x, 3.11.x
>
> Attachments: BlockedEpollEventLoopFromHeapDump.png,
> BlockedEpollEventLoopFromThreadDump.png, RequestExecutorQueueFull.png, heap
> dump showing each ImmediateFlusher taking upto 600MB.png
>
>
> This is a follow-up ticket out of CASSANDRA-14855, to make the Flusher queue
> bounded, since, in the current state, items get added to the queue without
> any checks on queue size, nor with any checks on netty outbound buffer to
> check the isWritable state.
> We are seeing this issue hit our production 3.0 clusters quite often.
--
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-15013) Message Flusher queue can grow unbounded, potentially running JVM out of memory
[ https://issues.apache.org/jira/browse/CASSANDRA-15013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769335#comment-16769335 ] Benedict commented on CASSANDRA-15013: -- I would be OK with either approach. There's no strong reason not to add a feature to the protocol that is optional, though - it's not actually a protocol change, just a behavioural change to a message that is permitted on the protocol today. Since the riskiest change will be fixing the underlying bug, I'd be in favour of at least supporting this option for clients in 3.0, if we intend to fix this behaviour that far back. But I'm also comfortable with limiting the client option to 4.0 > Message Flusher queue can grow unbounded, potentially running JVM out of > memory > --- > > Key: CASSANDRA-15013 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15013 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Major > Fix For: 4.0, 3.0.x, 3.11.x > > Attachments: BlockedEpollEventLoopFromHeapDump.png, > BlockedEpollEventLoopFromThreadDump.png, RequestExecutorQueueFull.png, heap > dump showing each ImmediateFlusher taking upto 600MB.png > > > This is a follow-up ticket out of CASSANDRA-14855, to make the Flusher queue > bounded, since, in the current state, items get added to the queue without > any checks on queue size, nor with any checks on netty outbound buffer to > check the isWritable state. > We are seeing this issue hit our production 3.0 clusters quite often. -- 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-15006) Possible java.nio.DirectByteBuffer leak
[ https://issues.apache.org/jira/browse/CASSANDRA-15006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonas Borgström updated CASSANDRA-15006: Attachment: Screenshot_2019-02-15 Grafana - Cassandra.png > Possible java.nio.DirectByteBuffer leak > --- > > Key: CASSANDRA-15006 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15006 > Project: Cassandra > Issue Type: Bug > Environment: cassandra: 3.11.3 > jre: openjdk version "1.8.0_181" > heap size: 2GB > memory limit: 3GB (cgroup) > I started one of the nodes with "-Djdk.nio.maxCachedBufferSize=262144" but > that did not seem to make any difference. >Reporter: Jonas Borgström >Priority: Major > Attachments: CASSANDRA-15006-reference-chains.png, > Screenshot_2019-02-04 Grafana - Cassandra.png, Screenshot_2019-02-14 Grafana > - Cassandra(1).png, Screenshot_2019-02-14 Grafana - Cassandra.png, > Screenshot_2019-02-15 Grafana - Cassandra.png, cassandra.yaml, cmdline.txt > > > While testing a 3 node 3.11.3 cluster I noticed that the nodes were suddenly > killed by the Linux OOM killer after running without issues for 4-5 weeks. > After enabling more metrics and leaving the nodes running for 12 days it sure > looks like the > "java.nio:type=BufferPool,name=direct" Mbean shows a very linear growth > (approx 15MiB/24h, see attached screenshot). Is this expected to keep growing > linearly after 12 days with a constant load? > > In my setup the growth/leak is about 15MiB/day so I guess in most setups it > would take quite a few days until it becomes noticeable. I'm able to see the > same type of slow growth in other production clusters even though the graph > data is more noisy. -- 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] [Issue Comment Deleted] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Comment: was deleted
(was: Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
--
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
)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
>
[jira] [Issue Comment Deleted] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Comment: was deleted
(was: Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
--
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
)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
>
***UNCHECKED*** Re: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error:
>(Unable to connect to any servers,*
> *{127.0.0.1: ProtocolError(Unexpected response during
>Connection setup: AttributeError("\module\ object has no attribute
>\decompress\",),)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
>[https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
>tokenize;_file=/tmp/pip-build-P7pulc/python-snappy/setup.py;f=getattr(tokenize,
> open, open)(file);code=f.read().replace(\r\n,
>\n);f.close();exec(compile(code, __file_, exec))"
>bdist_wheel -d /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
>option: cffi_modules*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building snappy._snappy extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
>-Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
>-fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
>-fstack-protector-strong -Wformat -Werror=format-security -fPIC
>-I/usr/include/python2.7 -c snappy/snappymodule.cc -o
>build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option -Wstrict-prototypes is
>valid for C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
>directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command x86_64-linux-gnu-gcc failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
>tokenize;__file__=/tmp/pip-build-P7pulc/python-snappy/setup.py;f=getattr(tokenize,
> open, open)(__file__);code=f.read().replace(\r\n,
>\n);f.close();exec(compile(code, __file__, exec))"
>install --record /tmp/pip-4Ie8H2-record/install-record.txt
>--single-version-externally-managed --compile --user --prefix=:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
>option: cffi_modules*
> *warnings.warn(msg)*
> *running install*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying
[jira] [Updated] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
AvionTEq - Edelyn updated CASSANDRA-15017:
--
Attachment: AvionTEq.zip
Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
--
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
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Attachments: AvionTEq.zip, AvionTEq.zip
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
>
[jira] [Comment Edited] (CASSANDRA-15013) Message Flusher queue can grow unbounded, potentially running JVM out of memory
[
https://issues.apache.org/jira/browse/CASSANDRA-15013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769340#comment-16769340
]
Jason Brown edited comment on CASSANDRA-15013 at 2/15/19 2:05 PM:
--
Ahh, I just reread the {{doc/native_protocol_v5.spec}}, and the OPTIONS are a
semi-defined map, basically. I thought they were a fixed listing (primarily
because we only support a fixed set of compression types). OK, so any version
works for me :).
was (Author: jasobrown):
Ahh, I just reread the {{doc/native_protocol_v5.spec}}, and the OPTIONS are an
open map, basically. I thought they were a fixed listing (primarily because we
only support a fixed set of compression types). OK, so any version works for me
:).
> Message Flusher queue can grow unbounded, potentially running JVM out of
> memory
> ---
>
> Key: CASSANDRA-15013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15013
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Major
> Fix For: 4.0, 3.0.x, 3.11.x
>
> Attachments: BlockedEpollEventLoopFromHeapDump.png,
> BlockedEpollEventLoopFromThreadDump.png, RequestExecutorQueueFull.png, heap
> dump showing each ImmediateFlusher taking upto 600MB.png
>
>
> This is a follow-up ticket out of CASSANDRA-14855, to make the Flusher queue
> bounded, since, in the current state, items get added to the queue without
> any checks on queue size, nor with any checks on netty outbound buffer to
> check the isWritable state.
> We are seeing this issue hit our production 3.0 clusters quite often.
--
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
***UNCHECKED*** Re: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error:
>(Unable to connect to any servers,*
> *{127.0.0.1: ProtocolError(Unexpected response during
>Connection setup: AttributeError("\module\ object has no attribute
>\decompress\",),)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
>[https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
>tokenize;_file=/tmp/pip-build-P7pulc/python-snappy/setup.py;f=getattr(tokenize,
> open, open)(file);code=f.read().replace(\r\n,
>\n);f.close();exec(compile(code, __file_, exec))"
>bdist_wheel -d /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
>option: cffi_modules*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building snappy._snappy extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
>-Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
>-fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
>-fstack-protector-strong -Wformat -Werror=format-security -fPIC
>-I/usr/include/python2.7 -c snappy/snappymodule.cc -o
>build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option -Wstrict-prototypes is
>valid for C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
>directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command x86_64-linux-gnu-gcc failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
>tokenize;__file__=/tmp/pip-build-P7pulc/python-snappy/setup.py;f=getattr(tokenize,
> open, open)(__file__);code=f.read().replace(\r\n,
>\n);f.close();exec(compile(code, __file__, exec))"
>install --record /tmp/pip-4Ie8H2-record/install-record.txt
>--single-version-externally-managed --compile --user --prefix=:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
>option: cffi_modules*
> *warnings.warn(msg)*
> *running install*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying
[jira] [Updated] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
AvionTEq - Edelyn updated CASSANDRA-15017:
--
Attachment: AvionTEq.zip
Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
--
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
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Attachments: AvionTEq.zip, AvionTEq.zip, AvionTEq.zip
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
>
[jira] [Comment Edited] (CASSANDRA-15013) Message Flusher queue can grow unbounded, potentially running JVM out of memory
[
https://issues.apache.org/jira/browse/CASSANDRA-15013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769331#comment-16769331
]
Jason Brown edited comment on CASSANDRA-15013 at 2/15/19 1:54 PM:
--
Yup, I agree the harder part, programming wise, is {{requestExecutor}} stuffs,
and let's plow through that first. The {{OptionsMessage/client protocol work}}
is significantly easier, as I think we agree, but would that qualify as a
change to the native protocol, for which we need to wait for a major rev (as
in, 4.0)? Or are additive additions ok acceptable for previous native protocol
versions? We might have a policy or general advice around this, but I don't
know.
Either way, [~sumanth.pasupuleti] has enough to work forward for now, and we
can figure out the native protocol-impacting stuffs in parallel.
was (Author: jasobrown):
Yup, I agree the harder part, programming wise, is {{requestExecutor}} stuffs,
and let's plow through that first. The {{OptionsMessage/client protocol work}}
is significantly easier, as I think we agree, but would that qualify as a
change to the native protocol, for which we need to wait for a major rev (as
in, 4.0)? Or are additive additions ok acceptable for previous native protocol
versions? We might have a policy or general advice around this, but I don't
know.
> Message Flusher queue can grow unbounded, potentially running JVM out of
> memory
> ---
>
> Key: CASSANDRA-15013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15013
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Major
> Fix For: 4.0, 3.0.x, 3.11.x
>
> Attachments: BlockedEpollEventLoopFromHeapDump.png,
> BlockedEpollEventLoopFromThreadDump.png, RequestExecutorQueueFull.png, heap
> dump showing each ImmediateFlusher taking upto 600MB.png
>
>
> This is a follow-up ticket out of CASSANDRA-14855, to make the Flusher queue
> bounded, since, in the current state, items get added to the queue without
> any checks on queue size, nor with any checks on netty outbound buffer to
> check the isWritable state.
> We are seeing this issue hit our production 3.0 clusters quite often.
--
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-15013) Message Flusher queue can grow unbounded, potentially running JVM out of memory
[
https://issues.apache.org/jira/browse/CASSANDRA-15013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769331#comment-16769331
]
Jason Brown commented on CASSANDRA-15013:
-
Yup, I agree the harder part, programming wise, is {{requestExecutor}} stuffs,
and let's plow through that first. The {{OptionsMessage/client protocol work}}
is significantly easier, as I think we agree, but would that qualify as a
change to the native protocol, for which we need to wait for a major rev (as
in, 4.0)? Or are additive additions ok acceptable for previous native protocol
versions? We might have a policy or general advice around this, but I don't
know.
> Message Flusher queue can grow unbounded, potentially running JVM out of
> memory
> ---
>
> Key: CASSANDRA-15013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15013
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Major
> Fix For: 4.0, 3.0.x, 3.11.x
>
> Attachments: BlockedEpollEventLoopFromHeapDump.png,
> BlockedEpollEventLoopFromThreadDump.png, RequestExecutorQueueFull.png, heap
> dump showing each ImmediateFlusher taking upto 600MB.png
>
>
> This is a follow-up ticket out of CASSANDRA-14855, to make the Flusher queue
> bounded, since, in the current state, items get added to the queue without
> any checks on queue size, nor with any checks on netty outbound buffer to
> check the isWritable state.
> We are seeing this issue hit our production 3.0 clusters quite often.
--
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
***UNCHECKED*** Re: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error:
>(Unable to connect to any servers,*
> *{127.0.0.1: ProtocolError(Unexpected response during
>Connection setup: AttributeError("\module\ object has no attribute
>\decompress\",),)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
>[https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
>tokenize;_file=/tmp/pip-build-P7pulc/python-snappy/setup.py;f=getattr(tokenize,
> open, open)(file);code=f.read().replace(\r\n,
>\n);f.close();exec(compile(code, __file_, exec))"
>bdist_wheel -d /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
>option: cffi_modules*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building snappy._snappy extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
>-Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
>-fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
>-fstack-protector-strong -Wformat -Werror=format-security -fPIC
>-I/usr/include/python2.7 -c snappy/snappymodule.cc -o
>build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option -Wstrict-prototypes is
>valid for C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
>directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command x86_64-linux-gnu-gcc failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
>tokenize;__file__=/tmp/pip-build-P7pulc/python-snappy/setup.py;f=getattr(tokenize,
> open, open)(__file__);code=f.read().replace(\r\n,
>\n);f.close();exec(compile(code, __file__, exec))"
>install --record /tmp/pip-4Ie8H2-record/install-record.txt
>--single-version-externally-managed --compile --user --prefix=:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
>option: cffi_modules*
> *warnings.warn(msg)*
> *running install*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying
***UNCHECKED*** Re: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error:
>(Unable to connect to any servers,*
> *{127.0.0.1: ProtocolError(Unexpected response during
>Connection setup: AttributeError("\module\ object has no attribute
>\decompress\",),)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
>[https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
>tokenize;_file=/tmp/pip-build-P7pulc/python-snappy/setup.py;f=getattr(tokenize,
> open, open)(file);code=f.read().replace(\r\n,
>\n);f.close();exec(compile(code, __file_, exec))"
>bdist_wheel -d /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
>option: cffi_modules*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building snappy._snappy extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
>-Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
>-fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
>-fstack-protector-strong -Wformat -Werror=format-security -fPIC
>-I/usr/include/python2.7 -c snappy/snappymodule.cc -o
>build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option -Wstrict-prototypes is
>valid for C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
>directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command x86_64-linux-gnu-gcc failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
>tokenize;__file__=/tmp/pip-build-P7pulc/python-snappy/setup.py;f=getattr(tokenize,
> open, open)(__file__);code=f.read().replace(\r\n,
>\n);f.close();exec(compile(code, __file__, exec))"
>install --record /tmp/pip-4Ie8H2-record/install-record.txt
>--single-version-externally-managed --compile --user --prefix=:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
>option: cffi_modules*
> *warnings.warn(msg)*
> *running install*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying
[jira] [Updated] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Attachment: (was: AvionTEq.zip)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
> --compile --user --prefix=:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running install*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG
[jira] [Updated] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Attachment: (was: AvionTEq.zip)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
> --compile --user --prefix=:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running install*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG
[jira] [Updated] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Attachment: (was: AvionTEq.zip)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
> --compile --user --prefix=:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running install*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG
[jira] [Commented] (CASSANDRA-14987) Add metrics for interrupted compactions
[ https://issues.apache.org/jira/browse/CASSANDRA-14987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769332#comment-16769332 ] Romain Hardouin commented on CASSANDRA-14987: - Hi, should compactions interrupted while stopping the node be counted? It would add some noise, not a big deal that said. > Add metrics for interrupted compactions > --- > > Key: CASSANDRA-14987 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14987 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Marcus Eriksson >Priority: Major > Fix For: 4.x > > > To be able to track how often we interrupt compactions (for example when > starting anticompactions) we should add a few metrics; > * number of interrupted compactions > * number of bytes written by interrupted compactions > We currently count an interrupted compaction as completed, which should > change with this -- 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-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
AvionTEq - Edelyn updated CASSANDRA-15017:
--
Attachment: AvionTEq.zip
Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
--
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
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Attachments: AvionTEq.zip, AvionTEq.zip, AvionTEq.zip, AvionTEq.zip
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
>
[jira] [Updated] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
AvionTEq - Edelyn updated CASSANDRA-15017:
--
Attachment: AvionTEq.zip
Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
--
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
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Attachments: AvionTEq.zip, AvionTEq.zip, AvionTEq.zip, AvionTEq.zip
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
>
[jira] [Issue Comment Deleted] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Comment: was deleted
(was: Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
--
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
)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
>
[jira] [Issue Comment Deleted] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Comment: was deleted
(was: Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
--
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
)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
>
[jira] [Commented] (CASSANDRA-15013) Message Flusher queue can grow unbounded, potentially running JVM out of memory
[
https://issues.apache.org/jira/browse/CASSANDRA-15013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769310#comment-16769310
]
Benedict commented on CASSANDRA-15013:
--
I guess maybe let's wait and see how much more complicated it would be? You're
right that the {{OptionsMessage}} should be sufficient for supplying the
option, and I think the complicated bit is going to be negotiating safely with
the {{requestExecutor}} when we should start and stop reading.
If it turns out to be super challenging, by all means let's make it a 4.0-only
follow-up, but if (as I suspect) it's nominally extra work, I think it's better
to tie up the work while there's pressure to do so.
> Message Flusher queue can grow unbounded, potentially running JVM out of
> memory
> ---
>
> Key: CASSANDRA-15013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15013
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Major
> Fix For: 4.0, 3.0.x, 3.11.x
>
> Attachments: BlockedEpollEventLoopFromHeapDump.png,
> BlockedEpollEventLoopFromThreadDump.png, RequestExecutorQueueFull.png, heap
> dump showing each ImmediateFlusher taking upto 600MB.png
>
>
> This is a follow-up ticket out of CASSANDRA-14855, to make the Flusher queue
> bounded, since, in the current state, items get added to the queue without
> any checks on queue size, nor with any checks on netty outbound buffer to
> check the isWritable state.
> We are seeing this issue hit our production 3.0 clusters quite often.
--
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-15025) Avoid NPE in RepairRunnable.recordFailure
Marcus Eriksson created CASSANDRA-15025:
---
Summary: Avoid NPE in RepairRunnable.recordFailure
Key: CASSANDRA-15025
URL: https://issues.apache.org/jira/browse/CASSANDRA-15025
Project: Cassandra
Issue Type: Bug
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson
Fix For: 4.x
message parameter in {{RepairRunnable.recordFailure}} can be null, avoid this
happening and make sure we log the actual exception
--
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-15025) Avoid NPE in RepairRunnable.recordFailure
[
https://issues.apache.org/jira/browse/CASSANDRA-15025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15025:
Reviewer: Blake Eggleston
Status: Patch Available (was: Open)
patch: https://github.com/krummas/cassandra/commits/marcuse/avoid_repair_npe
tests:
https://circleci.com/gh/krummas/workflows/cassandra/tree/marcuse%2Favoid_repair_npe
I'll submit a dtest for this early next week
> Avoid NPE in RepairRunnable.recordFailure
> -
>
> Key: CASSANDRA-15025
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15025
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 4.x
>
>
> failureMessage parameter in {{RepairRunnable.recordFailure}} can be null,
> avoid this happening and make sure we log the actual exception
--
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-14706) Support "IF EXISTS/IF NOT EXISTS" for all clauses of "ALTER TABLE"
[
https://issues.apache.org/jira/browse/CASSANDRA-14706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Lazurkin updated CASSANDRA-14706:
Component/s: CQL/Syntax
CQL/Interpreter
> Support "IF EXISTS/IF NOT EXISTS" for all clauses of "ALTER TABLE"
> --
>
> Key: CASSANDRA-14706
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14706
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Interpreter, CQL/Syntax, Legacy/CQL
>Reporter: Dmitry Lazurkin
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Like so:
> {noformat}
> ALTER TABLE ALTER TYPE ;
> ALTER TABLE [ IF EXISTS ] ADD [ IF NOT EXISTS ] ;
> ALTER TABLE [ IF EXISTS ] ADD [ IF NOT EXISTS ] (
> , . );
> ALTER TABLE [ IF EXISTS ] DROP [ IF EXISTS ] ;
> ALTER TABLE [ IF EXISTS ] DROP [ IF EXISTS ] (
> ,.);
> ALTER TABLE [ IF EXISTS ] RENAME [ IF EXISTS ] TO ;
> ALTER TABLE [ IF EXISTS ] WITH = ;
> {noformat}
> I think common IF EXISTS/IF NOT EXISTS clause for ADD/DROP/RENAME better than
> clause for each column.
--
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-14847) improvement of nodetool status -r
[
https://issues.apache.org/jira/browse/CASSANDRA-14847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769535#comment-16769535
]
Dinesh Joshi commented on CASSANDRA-14847:
--
Thanks, [~iamaleksey]
> improvement of nodetool status -r
> -
>
> Key: CASSANDRA-14847
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14847
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Fumiya Yamashita
>Assignee: Fumiya Yamashita
>Priority: Major
> Fix For: 3.0.19, 3.11.5, 4.0
>
> Attachments: 3.11.1.patch
>
>
> Hello,
> When using "nodetool status -r", I found a problem that the response time
> becomes longer depending on the number of vnodes.
> In my testing environment, when the num_token is 256 and the number of nodes
> is 6, the response takes about 60 seconds.
> It turned out that the findMaxAddressLength method in status.java is causing
> the delay.
> Despite only obtaining the maximum length of the address by the number of
> vnodes, `tokenrange * vnode` times also loop processing, there is redundancy.
> To prevent duplicate host names from being referenced every time, I modified
> to check with hash.
> In my environment, the response time has been reduced from 60 seconds to 2
> seconds.
> I attached the patch, so please check it.
> Thank you
> {code:java}
> [before]
> Datacenter: dc1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN *** 559.32 KB 256 48.7% 0555746a-60c2-4717-b042-94ba951ef679 ***
> UN *** 721.48 KB 256 51.4% 1af4acb6-e0a0-4bcb-8bba-76ae2e225cd5 ***
> UN *** 699.98 KB 256 48.3% 5215c728-9b80-4e3c-b46b-c5b8e5eb753f ***
> UN *** 691.65 KB 256 48.1% 57da4edf-4acb-474d-b26c-27f048c37bd6 ***
> UN *** 705.66 KB 256 52.8% 07520eab-47d2-4f5d-aeeb-f6e599c9b084 ***
> UN *** 610.87 KB 256 50.7% 6b39acaf-6ed6-42e4-a357-0d258bdf87b7 ***
> time : 66s
> [after]
> Datacenter: dc1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN *** 559.32 KB 256 48.7% 0555746a-60c2-4717-b042-94ba951ef679 ***
> UN *** 721.48 KB 256 51.4% 1af4acb6-e0a0-4bcb-8bba-76ae2e225cd5 ***
> UN *** 699.98 KB 256 48.3% 5215c728-9b80-4e3c-b46b-c5b8e5eb753f ***
> UN *** 691.65 KB 256 48.1% 57da4edf-4acb-474d-b26c-27f048c37bd6 ***
> UN *** 705.66 KB 256 52.8% 07520eab-47d2-4f5d-aeeb-f6e599c9b084 ***
> UN *** 610.87 KB 256 50.7% 6b39acaf-6ed6-42e4-a357-0d258bdf87b7 ***
> time : 2s
> {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] [Updated] (CASSANDRA-15024) Don't try to cancel 2i compactions when starting anticompaction
[
https://issues.apache.org/jira/browse/CASSANDRA-15024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-15024:
Status: Ready to Commit (was: Patch Available)
> Don't try to cancel 2i compactions when starting anticompaction
> ---
>
> Key: CASSANDRA-15024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15024
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 4.x
>
>
> When we start an anticompaction we cancel ongoing compactions,
> {{runWithCompactionsDisabled}} always cancels compactions for secondary index
> cfs:es, this causes problem since CASSANDRA-14935 since we check for range
> intersection which will fail since 2i sstables are LocalPartitioner.
--
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-15024) Don't try to cancel 2i compactions when starting anticompaction
[
https://issues.apache.org/jira/browse/CASSANDRA-15024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769570#comment-16769570
]
Blake Eggleston commented on CASSANDRA-15024:
-
+1
> Don't try to cancel 2i compactions when starting anticompaction
> ---
>
> Key: CASSANDRA-15024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15024
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 4.x
>
>
> When we start an anticompaction we cancel ongoing compactions,
> {{runWithCompactionsDisabled}} always cancels compactions for secondary index
> cfs:es, this causes problem since CASSANDRA-14935 since we check for range
> intersection which will fail since 2i sstables are LocalPartitioner.
--
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-15025) Avoid NPE in RepairRunnable.recordFailure
[
https://issues.apache.org/jira/browse/CASSANDRA-15025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-15025:
Status: Ready to Commit (was: Patch Available)
> Avoid NPE in RepairRunnable.recordFailure
> -
>
> Key: CASSANDRA-15025
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15025
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 4.x
>
>
> failureMessage parameter in {{RepairRunnable.recordFailure}} can be null,
> avoid this happening and make sure we log the actual exception
--
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-15025) Avoid NPE in RepairRunnable.recordFailure
[
https://issues.apache.org/jira/browse/CASSANDRA-15025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769578#comment-16769578
]
Blake Eggleston commented on CASSANDRA-15025:
-
+1
> Avoid NPE in RepairRunnable.recordFailure
> -
>
> Key: CASSANDRA-15025
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15025
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 4.x
>
>
> failureMessage parameter in {{RepairRunnable.recordFailure}} can be null,
> avoid this happening and make sure we log the actual exception
--
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-9384) Update jBCrypt dependency to version 0.4
[
https://issues.apache.org/jira/browse/CASSANDRA-9384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769688#comment-16769688
]
Stefan Podkowinski commented on CASSANDRA-9384:
---
First of all, this only effects users who set the
{{cassandra.auth_bcrypt_gensalt_log2_rounds}} system property to 31 for insane
hashing computation times (default is 10). For those who did, updating to 0.4
would now cause each bcrypt hashing call to fail
([0c28b698|https://github.com/djmdjm/jBCrypt/commit/0c28b698e79b132391be8333107040d774c79995])
and forces them to change the value to something else. I'm pretty sure you'd
also have to re-create all users, to update the stored hashes again with <31
rounds to make bcrypt.hashpw() accept those.
> Update jBCrypt dependency to version 0.4
>
>
> Key: CASSANDRA-9384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9384
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Dinesh Joshi
>Priority: Major
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x
>
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=2097
> Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4
> indicate that this is now fixed, so we should update.
> Thanks to [~Bereng] for identifying the issue.
--
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-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Attachment: (was: AvionTEq.zip)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
> --compile --user --prefix=:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running install*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG
[jira] [Updated] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Attachment: (was: AvionTEq.zip)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
> --compile --user --prefix=:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running install*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG
[jira] [Issue Comment Deleted] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Comment: was deleted
(was: Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
--
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
)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
>
[jira] [Updated] (CASSANDRA-15024) Don't try to cancel 2i compactions when starting anticompaction
[
https://issues.apache.org/jira/browse/CASSANDRA-15024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-15024:
-
Component/s: Feature/2i Index
Consistency/Repair
> Don't try to cancel 2i compactions when starting anticompaction
> ---
>
> Key: CASSANDRA-15024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15024
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Feature/2i Index
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 4.x
>
>
> When we start an anticompaction we cancel ongoing compactions,
> {{runWithCompactionsDisabled}} always cancels compactions for secondary index
> cfs:es, this causes problem since CASSANDRA-14935 since we check for range
> intersection which will fail since 2i sstables are LocalPartitioner.
--
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-9384) Update jBCrypt dependency to version 0.4
[ https://issues.apache.org/jira/browse/CASSANDRA-9384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769828#comment-16769828 ] Dinesh Joshi commented on CASSANDRA-9384: - Correct. We can include a warning in the release notes to that effect so they don't accidentally run into issues. > Update jBCrypt dependency to version 0.4 > > > Key: CASSANDRA-9384 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9384 > Project: Cassandra > Issue Type: Bug >Reporter: Sam Tunnicliffe >Assignee: Dinesh Joshi >Priority: Major > Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x > > > https://bugzilla.mindrot.org/show_bug.cgi?id=2097 > Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 > indicate that this is now fixed, so we should update. > Thanks to [~Bereng] for identifying the issue. -- 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-14395) C* Management process
[ https://issues.apache.org/jira/browse/CASSANDRA-14395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769826#comment-16769826 ] Dinesh Joshi commented on CASSANDRA-14395: -- Hi [~jasobrown], I have addressed your comments - # Jolokia is no longer checked in and is downloaded during the build and is included in tar created by distTar. # Included the Jolokia license # Made the log statement in healthcheck a debug statement. # Reformatted to comply with the code style. > C* Management process > - > > Key: CASSANDRA-14395 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14395 > Project: Cassandra > Issue Type: New Feature >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Major > Attachments: Looking towards an Official Cassandra Sidecar - > Netflix.pdf > > > I would like to propose amending Cassandra's architecture to include a > management process. The detailed description is here: > https://docs.google.com/document/d/1UV9pE81NaIUF3g4L1wxq09nT11AkSQcMijgLFwGsY3s/edit > I'd like to propose seeding this with a few simple use-cases such as Health > Checks, Bulk Commands with a simple REST API interface. -- 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
