[jira] [Commented] (CASSANDRA-18560) Incorrect IP used for gossip across DCs with prefer_local=true
[
https://issues.apache.org/jira/browse/CASSANDRA-18560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741204#comment-17741204
]
Brad Vernon commented on CASSANDRA-18560:
-
We did an upgrade with an existing instance from 4.1.1 to 4.1.2 and the same
exact issue happened with nodes that previously had no issues connecting across
DC using the public IP assigned. Only outbound connections were affected and it
was random across the nodes not being able to use the public IP. Downgrading to
4.1.1 restored normal operations.
This seems like a much larger bug that will definitely impact clusters that
have both local private IPs and public IPs for cross dc access.
Error message for one node which should be using IP 34.248. but
instead is using 10.34.37.10 which is the private IP of the host and only
available in the local VPC.
{code:java}
WARN [Messaging-EventLoop-3-3] 2023-07-07 21:52:27,929 NoSpamLogger.java:108 -
/3.114.:7000->/34.248:7000-URGENT_MESSAGES-[no-channel]
dropping message of type ECHO_RSP whose timeout expired before reaching the
networkINFO [Messaging-EventLoop-3-3] 2023-07-07 21:52:47,391
NoSpamLogger.java:105 -
/3.114.:7000->/34.248.:7000-URGENT_MESSAGES-[no-channel]
failed to connectio.netty.channel.ConnectTimeoutException: connection timed
out: /10.34.37.10:7000 at
io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe$2.run(AbstractEpollChannel.java:576)
at io.netty.util.concurrent.PromiseTask.runTask(PromiseTask.java:98) at
io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:170)
at
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
at
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:384) at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829) {code}
Nodetool status showing the randomness of the cross-dc nodes picking to use the
private ip.
{code:java}
ubuntu@10.34.51.10(ap-northeast-1-cassandra-node0):~# ntool status
Datacenter: ap-northeast-1
==
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID
Rack
UN 54.238. 4.26 GiB 8 100.0%
4affb962-7bf0-42f7-9956-fdbec1c07e5f 1d
UN 52.196. 3.71 GiB 8 100.0%
6857d4de-c497-440f-a2ff-c4d18907fa39 1c
UN 3.114. 4.28 GiB 8 100.0%
d43d2fb3-27a0-4ecd-9887-741c9fc010da 1a
Datacenter: eu-west-1
=
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID
Rack
UN 54.229. 4.06 GiB 8 100.0%
a8c866d3-bde0-453d-8892-dbe544b7e910 1a
UN 52.18. 4.06 GiB 8 100.0%
4530631d-7e2c-455d-89ff-3ddd3e9c64b7 1b
DN 34.248. 4.06 GiB 8 100.0%
26daf7cf-5f1a-4969-a7be-c58ff36e9176 1c
Datacenter: us-east-1
=
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID
Rack
DN 52.54. 4.06 GiB 8 100.0%
a2edd4b1-d286-441d-a0b1-5d98b88ee2f2 1c
UN 34.203.2 4.08 GiB 8 100.0%
5c64292f-df51-45f3-b3b6-ed325ea669ff 1a
UN 3.229. 4.06 GiB 8 100.0%
53a6d308-25b6-4d87-8581-3cc3fd43c165 1b
Datacenter: us-west-2
=
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID
Rack
DN 44.233. 4.26 GiB 8 100.0%
d53ab9bf-2606-4516-a689-7e19d053d857 2b
UN 54.200. 4.26 GiB 8 100.0%
4ec7c54d-465c-489a-8aed-5ba38264cec8 2a
DN 52.27. 4.26 GiB 8 100.0%
8ae55f1a-bf5a-4ce4-892b-4812773036fa 2c {code}
> Incorrect IP used for gossip across DCs with prefer_local=true
> --
>
> Key: CASSANDRA-18560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18560
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brad Vernon
>Assignee: Brandon Williams
>Priority: Urgent
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> After installing a new node using 4.0.10 we experienced a situation where the
> new node attempted to connect to the private ip of a random number of nodes
[jira] [Commented] (CASSANDRA-18560) Incorrect IP used for gossip across DCs with prefer_local=true
[
https://issues.apache.org/jira/browse/CASSANDRA-18560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735959#comment-17735959
]
Brad Vernon commented on CASSANDRA-18560:
-
Is there something I can do on my end to help facilitate testing or get you
additional info?
> Incorrect IP used for gossip across DCs with prefer_local=true
> --
>
> Key: CASSANDRA-18560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18560
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brad Vernon
>Assignee: Brandon Williams
>Priority: Urgent
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> After installing a new node using 4.0.10 we experienced a situation where the
> new node attempted to connect to the private ip of a random number of nodes
> remote DCs which are only accessible via public ip for cross dc
> communications.
> The only impact was new nodes outbound connections, inbound from pre-4.0.10
> were not affected. system.peers_v2 (below) showed that the preferred_ip and
> preferred_port as null, only those in 4.0.10 nodes dc have perferred_ip
> values as expected.
> We believe the issue originated with
> https://issues.apache.org/jira/browse/CASSANDRA-16718
> Details on cluster:
> * All nodes have public IP configured as well as private IP
> * Listen/rpc addressrs are configured for private ip, broadcast is public IP
> * prefer_local=true is enabled for all nodes
> The log that showed the connection failing:
> {code:java}
> INFO [Messaging-EventLoop-3-8] 2023-06-01 00:14:21,565 NoSpamLogger.java:92
> -
> /99.81.:7000->/44.208.:7000-URGENT_MESSAGES-[no-channel]
> failed to connectio.netty.channel.ConnectTimeoutException: connection timed
> out: /10.26.5.11:7000 at
> io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe$2.run(AbstractEpollChannel.java:576){code}
> 99 and 44 instances can only access each other using public ips.
> gossipinfo output from 4.0.10 node
> {code:java}
> /44.208.
> generation:1661113358
> heartbeat:25267691
> LOAD:25267683:1.7882044268E10
> SCHEMA:24692061:e98b918d-499f-3ccc-8dbe-5af31f685bda
> DC:13:us-east-1
> RACK:15:1a
> RELEASE_VERSION:6:4.0.5
> NET_VERSION:2:12
> HOST_ID:3:9a41e668-060d-4cfe-bb1e-013f5116422d
> RPC_READY:1407:true
> INTERNAL_ADDRESS_AND_PORT:9:10.26.5.11:7000
> NATIVE_ADDRESS_AND_PORT:4:44.208.:9042
> STATUS_WITH_PORT:1393:NORMAL,-2262036356854762881
> SSTABLE_VERSIONS:7:big-nb
> TOKENS:1392: {code}
> Peers output from 4.0.10 node:
> {code:java}
>peer | peer_port | data_center | host_id
> | native_address | native_port | preferred_ip | preferred_port |
> rack | release_version | schema_version |
> tokens+---+-+--++-+--++--+-+--+---
> 44.208. | 7000 | us-east-1 |
> 9a41e668-060d-4cfe-bb1e-013f5116422d | 44.208. |9042 |
> null | null | 1a | 4.0.5 |
> e98b918d-499f-3ccc-8dbe-5af31f685bda |{'-2262036356854762881',
> '-4197710115038136897', '-7072386316096662315', '2085255826742630980',
> '249732489387853170', '4976300208126705818', '7187184456885833289',
> '8777189009399731927'} {code}
> To solve temporarily we routed outbound traffic to the private ip to public
> using iptables which resulted in successful outbound connections.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18560) Incorrect IP used for gossip across DCs with prefer_local=true
[
https://issues.apache.org/jira/browse/CASSANDRA-18560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733110#comment-17733110
]
Brad Vernon commented on CASSANDRA-18560:
-
[~brandon.williams] I don't have a debug log when this happened, we only keep
them for a short period of time, but it looks like you were able find the cause
of the problem. The connection timeout I shared was the only relevant log I
could find since the errors were only on the node joining trying to connect to
remote hosts.
I appreciate the quick investigation and attention. If we have another node
that exhibits the same issue I will capture the full logs to share.
> Incorrect IP used for gossip across DCs with prefer_local=true
> --
>
> Key: CASSANDRA-18560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18560
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brad Vernon
>Assignee: Brandon Williams
>Priority: Urgent
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> After installing a new node using 4.0.10 we experienced a situation where the
> new node attempted to connect to the private ip of a random number of nodes
> remote DCs which are only accessible via public ip for cross dc
> communications.
> The only impact was new nodes outbound connections, inbound from pre-4.0.10
> were not affected. system.peers_v2 (below) showed that the preferred_ip and
> preferred_port as null, only those in 4.0.10 nodes dc have perferred_ip
> values as expected.
> We believe the issue originated with
> https://issues.apache.org/jira/browse/CASSANDRA-16718
> Details on cluster:
> * All nodes have public IP configured as well as private IP
> * Listen/rpc addressrs are configured for private ip, broadcast is public IP
> * prefer_local=true is enabled for all nodes
> The log that showed the connection failing:
> {code:java}
> INFO [Messaging-EventLoop-3-8] 2023-06-01 00:14:21,565 NoSpamLogger.java:92
> -
> /99.81.:7000->/44.208.:7000-URGENT_MESSAGES-[no-channel]
> failed to connectio.netty.channel.ConnectTimeoutException: connection timed
> out: /10.26.5.11:7000 at
> io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe$2.run(AbstractEpollChannel.java:576){code}
> 99 and 44 instances can only access each other using public ips.
> gossipinfo output from 4.0.10 node
> {code:java}
> /44.208.
> generation:1661113358
> heartbeat:25267691
> LOAD:25267683:1.7882044268E10
> SCHEMA:24692061:e98b918d-499f-3ccc-8dbe-5af31f685bda
> DC:13:us-east-1
> RACK:15:1a
> RELEASE_VERSION:6:4.0.5
> NET_VERSION:2:12
> HOST_ID:3:9a41e668-060d-4cfe-bb1e-013f5116422d
> RPC_READY:1407:true
> INTERNAL_ADDRESS_AND_PORT:9:10.26.5.11:7000
> NATIVE_ADDRESS_AND_PORT:4:44.208.:9042
> STATUS_WITH_PORT:1393:NORMAL,-2262036356854762881
> SSTABLE_VERSIONS:7:big-nb
> TOKENS:1392: {code}
> Peers output from 4.0.10 node:
> {code:java}
>peer | peer_port | data_center | host_id
> | native_address | native_port | preferred_ip | preferred_port |
> rack | release_version | schema_version |
> tokens+---+-+--++-+--++--+-+--+---
> 44.208. | 7000 | us-east-1 |
> 9a41e668-060d-4cfe-bb1e-013f5116422d | 44.208. |9042 |
> null | null | 1a | 4.0.5 |
> e98b918d-499f-3ccc-8dbe-5af31f685bda |{'-2262036356854762881',
> '-4197710115038136897', '-7072386316096662315', '2085255826742630980',
> '249732489387853170', '4976300208126705818', '7187184456885833289',
> '8777189009399731927'} {code}
> To solve temporarily we routed outbound traffic to the private ip to public
> using iptables which resulted in successful outbound connections.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18560) Incorrect IP used for gossip across DCs with prefer_local=true
Brad Vernon created CASSANDRA-18560:
---
Summary: Incorrect IP used for gossip across DCs with
prefer_local=true
Key: CASSANDRA-18560
URL: https://issues.apache.org/jira/browse/CASSANDRA-18560
Project: Cassandra
Issue Type: Bug
Reporter: Brad Vernon
After installing a new node using 4.0.10 we experienced a situation where the
new node attempted to connect to the private ip of a random number of nodes
remote DCs which are only accessible via public ip for cross dc communications.
The only impact was new nodes outbound connections, inbound from pre-4.0.10
were not affected. system.peers_v2 (below) showed that the preferred_ip and
preferred_port as null, only those in 4.0.10 nodes dc have perferred_ip values
as expected.
We believe the issue originated with
https://issues.apache.org/jira/browse/CASSANDRA-16718
Details on cluster:
* All nodes have public IP configured as well as private IP
* Listen/rpc addressrs are configured for private ip, broadcast is public IP
* prefer_local=true is enabled for all nodes
The log that showed the connection failing:
{code:java}
INFO [Messaging-EventLoop-3-8] 2023-06-01 00:14:21,565 NoSpamLogger.java:92 -
/99.81.:7000->/44.208.:7000-URGENT_MESSAGES-[no-channel]
failed to connectio.netty.channel.ConnectTimeoutException: connection timed
out: /10.26.5.11:7000 at
io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe$2.run(AbstractEpollChannel.java:576){code}
99 and 44 instances can only access each other using public ips.
gossipinfo output from 4.0.10 node
{code:java}
/44.208.
generation:1661113358
heartbeat:25267691
LOAD:25267683:1.7882044268E10
SCHEMA:24692061:e98b918d-499f-3ccc-8dbe-5af31f685bda
DC:13:us-east-1
RACK:15:1a
RELEASE_VERSION:6:4.0.5
NET_VERSION:2:12
HOST_ID:3:9a41e668-060d-4cfe-bb1e-013f5116422d
RPC_READY:1407:true
INTERNAL_ADDRESS_AND_PORT:9:10.26.5.11:7000
NATIVE_ADDRESS_AND_PORT:4:44.208.:9042
STATUS_WITH_PORT:1393:NORMAL,-2262036356854762881
SSTABLE_VERSIONS:7:big-nb
TOKENS:1392: {code}
Peers output from 4.0.10 node:
{code:java}
peer | peer_port | data_center | host_id
| native_address | native_port | preferred_ip | preferred_port |
rack | release_version | schema_version |
tokens+---+-+--++-+--++--+-+--+---
44.208. | 7000 | us-east-1 |
9a41e668-060d-4cfe-bb1e-013f5116422d | 44.208. |9042 |
null | null | 1a | 4.0.5 |
e98b918d-499f-3ccc-8dbe-5af31f685bda |{'-2262036356854762881',
'-4197710115038136897', '-7072386316096662315', '2085255826742630980',
'249732489387853170', '4976300208126705818', '7187184456885833289',
'8777189009399731927'} {code}
To solve temporarily we routed outbound traffic to the private ip to public
using iptables which resulted in successful outbound connections.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13179) Remove offheap_buffer as option for memtable_allocation_type in cassandra.yaml
[ https://issues.apache.org/jira/browse/CASSANDRA-13179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Vernon updated CASSANDRA-13179: Labels: configuration (was: ) Fix Version/s: 3.0.x Status: Patch Available (was: Open) > Remove offheap_buffer as option for memtable_allocation_type in cassandra.yaml > -- > > Key: CASSANDRA-13179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13179 > Project: Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Brad Vernon > Labels: configuration > Fix For: 3.0.x > > Attachments: cassandra-3.0-offheap_buffer_docs.patch > > > With [CASSANDRA-11039] disallowing offheap_buffers as option for > memtable_allocation_type the cassandra.yaml included documentation should be > updated to match. > Patch included. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CASSANDRA-13179) Remove offheap_buffer as option for memtable_allocation_type in cassandra.yaml
[ https://issues.apache.org/jira/browse/CASSANDRA-13179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Vernon updated CASSANDRA-13179: Attachment: cassandra-3.0-offheap_buffer_docs.patch Adding updated patch with new wording recommended by [~snazy] > Remove offheap_buffer as option for memtable_allocation_type in cassandra.yaml > -- > > Key: CASSANDRA-13179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13179 > Project: Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Brad Vernon > Attachments: cassandra-3.0-offheap_buffer_docs.patch > > > With [CASSANDRA-11039] disallowing offheap_buffers as option for > memtable_allocation_type the cassandra.yaml included documentation should be > updated to match. > Patch included. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CASSANDRA-13179) Remove offheap_buffer as option for memtable_allocation_type in cassandra.yaml
[ https://issues.apache.org/jira/browse/CASSANDRA-13179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Vernon updated CASSANDRA-13179: Attachment: (was: 3.0-cass_yaml_offheap_doc.patch) > Remove offheap_buffer as option for memtable_allocation_type in cassandra.yaml > -- > > Key: CASSANDRA-13179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13179 > Project: Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Brad Vernon > > With [CASSANDRA-11039] disallowing offheap_buffers as option for > memtable_allocation_type the cassandra.yaml included documentation should be > updated to match. > Patch included. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13179) Remove offheap_buffer as option for memtable_allocation_type in cassandra.yaml
[
https://issues.apache.org/jira/browse/CASSANDRA-13179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855174#comment-15855174
]
Brad Vernon commented on CASSANDRA-13179:
-
How about:
{code}
# Note: offheap_buffers are not supported in Cassandra 3.0-3.3.
# They have been re-introduced in Cassandra 3.4. For details see
# https://issues.apache.org/jira/browse/CASSANDRA-9472 and
# https://issues.apache.org/jira/browse/CASSANDRA-11039
{code}
> Remove offheap_buffer as option for memtable_allocation_type in cassandra.yaml
> --
>
> Key: CASSANDRA-13179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13179
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Brad Vernon
> Attachments: 3.0-cass_yaml_offheap_doc.patch
>
>
> With [CASSANDRA-11039] disallowing offheap_buffers as option for
> memtable_allocation_type the cassandra.yaml included documentation should be
> updated to match.
> Patch included.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CASSANDRA-13179) Remove offheap_buffer as option for memtable_allocation_type in cassandra.yaml
Brad Vernon created CASSANDRA-13179: --- Summary: Remove offheap_buffer as option for memtable_allocation_type in cassandra.yaml Key: CASSANDRA-13179 URL: https://issues.apache.org/jira/browse/CASSANDRA-13179 Project: Cassandra Issue Type: Improvement Components: Configuration Reporter: Brad Vernon Attachments: 3.0-cass_yaml_offheap_doc.patch With [CASSANDRA-11039] disallowing offheap_buffers as option for memtable_allocation_type the cassandra.yaml included documentation should be updated to match. Patch included. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CASSANDRA-12739) Nodetool uses cassandra-env.sh MAX_HEAP_SIZE if set
[ https://issues.apache.org/jira/browse/CASSANDRA-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Vernon updated CASSANDRA-12739: Summary: Nodetool uses cassandra-env.sh MAX_HEAP_SIZE if set (was: Cassandra Tools use cassandra-env.sh MAX_HEAP_SIZE if set) > Nodetool uses cassandra-env.sh MAX_HEAP_SIZE if set > --- > > Key: CASSANDRA-12739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12739 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Brad Vernon > Attachments: nodetool_xmx.patch > > > Nodetool and other bash startup scripts load cassandra-env.sh variables > including MAX_HEAP_SIZE as part of CASSANDRA-10679. If cassandra-env.sh has > MAX_HEAP_SIZE set to any value the default heap size needed for the cassandra > tool to run is overridden. > This is a problem if the using a large heap in C* i.e. 16-32G due to each > instance of nodetool or other tool will allocate large heap regardless of > need and could exceed the total RAM available on the system. > Patch removes the check for MAX_HEAP_SIZE being set and uses the default heap > size needed for each tool. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12739) Cassandra Tools use cassandra-env.sh MAX_HEAP_SIZE if set
[ https://issues.apache.org/jira/browse/CASSANDRA-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Vernon updated CASSANDRA-12739: Attachment: nodetool_xmx.patch Changes: - Reduced patch to be only for nodetool - Saved orginal MAX_HEAP_SIZE value and restored it after loading cassandra-env.sh > Cassandra Tools use cassandra-env.sh MAX_HEAP_SIZE if set > - > > Key: CASSANDRA-12739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12739 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Brad Vernon > Attachments: nodetool_xmx.patch > > > Nodetool and other bash startup scripts load cassandra-env.sh variables > including MAX_HEAP_SIZE as part of CASSANDRA-10679. If cassandra-env.sh has > MAX_HEAP_SIZE set to any value the default heap size needed for the cassandra > tool to run is overridden. > This is a problem if the using a large heap in C* i.e. 16-32G due to each > instance of nodetool or other tool will allocate large heap regardless of > need and could exceed the total RAM available on the system. > Patch removes the check for MAX_HEAP_SIZE being set and uses the default heap > size needed for each tool. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12739) Cassandra Tools use cassandra-env.sh MAX_HEAP_SIZE if set
[ https://issues.apache.org/jira/browse/CASSANDRA-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Vernon updated CASSANDRA-12739: Attachment: (was: cass-21_tools_xmx.patch) > Cassandra Tools use cassandra-env.sh MAX_HEAP_SIZE if set > - > > Key: CASSANDRA-12739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12739 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Brad Vernon > > Nodetool and other bash startup scripts load cassandra-env.sh variables > including MAX_HEAP_SIZE as part of CASSANDRA-10679. If cassandra-env.sh has > MAX_HEAP_SIZE set to any value the default heap size needed for the cassandra > tool to run is overridden. > This is a problem if the using a large heap in C* i.e. 16-32G due to each > instance of nodetool or other tool will allocate large heap regardless of > need and could exceed the total RAM available on the system. > Patch removes the check for MAX_HEAP_SIZE being set and uses the default heap > size needed for each tool. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12739) Cassandra Tools use cassandra-env.sh MAX_HEAP_SIZE if set
[ https://issues.apache.org/jira/browse/CASSANDRA-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Vernon updated CASSANDRA-12739: Attachment: (was: cass-3x_tools_xmx.patch) > Cassandra Tools use cassandra-env.sh MAX_HEAP_SIZE if set > - > > Key: CASSANDRA-12739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12739 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Brad Vernon > > Nodetool and other bash startup scripts load cassandra-env.sh variables > including MAX_HEAP_SIZE as part of CASSANDRA-10679. If cassandra-env.sh has > MAX_HEAP_SIZE set to any value the default heap size needed for the cassandra > tool to run is overridden. > This is a problem if the using a large heap in C* i.e. 16-32G due to each > instance of nodetool or other tool will allocate large heap regardless of > need and could exceed the total RAM available on the system. > Patch removes the check for MAX_HEAP_SIZE being set and uses the default heap > size needed for each tool. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12739) Cassandra Tools use cassandra-env.sh MAX_HEAP_SIZE if set
[ https://issues.apache.org/jira/browse/CASSANDRA-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Vernon updated CASSANDRA-12739: Attachment: (was: cass-22_tools_xmx.patch) > Cassandra Tools use cassandra-env.sh MAX_HEAP_SIZE if set > - > > Key: CASSANDRA-12739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12739 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Brad Vernon > > Nodetool and other bash startup scripts load cassandra-env.sh variables > including MAX_HEAP_SIZE as part of CASSANDRA-10679. If cassandra-env.sh has > MAX_HEAP_SIZE set to any value the default heap size needed for the cassandra > tool to run is overridden. > This is a problem if the using a large heap in C* i.e. 16-32G due to each > instance of nodetool or other tool will allocate large heap regardless of > need and could exceed the total RAM available on the system. > Patch removes the check for MAX_HEAP_SIZE being set and uses the default heap > size needed for each tool. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12739) Cassandra Tools use cassandra-env.sh MAX_HEAP_SIZE if set
[ https://issues.apache.org/jira/browse/CASSANDRA-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15537184#comment-15537184 ] Brad Vernon commented on CASSANDRA-12739: - Good point, will change. > Cassandra Tools use cassandra-env.sh MAX_HEAP_SIZE if set > - > > Key: CASSANDRA-12739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12739 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Brad Vernon > Attachments: cass-21_tools_xmx.patch, cass-22_tools_xmx.patch, > cass-3x_tools_xmx.patch > > > Nodetool and other bash startup scripts load cassandra-env.sh variables > including MAX_HEAP_SIZE as part of CASSANDRA-10679. If cassandra-env.sh has > MAX_HEAP_SIZE set to any value the default heap size needed for the cassandra > tool to run is overridden. > This is a problem if the using a large heap in C* i.e. 16-32G due to each > instance of nodetool or other tool will allocate large heap regardless of > need and could exceed the total RAM available on the system. > Patch removes the check for MAX_HEAP_SIZE being set and uses the default heap > size needed for each tool. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12739) Cassandra Tools use cassandra-env.sh MAX_HEAP_SIZE if set
[ https://issues.apache.org/jira/browse/CASSANDRA-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Vernon updated CASSANDRA-12739: Reproduced In: 3.0.5, 2.2.6 (was: 2.2.6, 3.0.5) Status: Patch Available (was: Open) Patch attached. Needs CI and review > Cassandra Tools use cassandra-env.sh MAX_HEAP_SIZE if set > - > > Key: CASSANDRA-12739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12739 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Brad Vernon > Attachments: cass-21_tools_xmx.patch, cass-22_tools_xmx.patch, > cass-3x_tools_xmx.patch > > > Nodetool and other bash startup scripts load cassandra-env.sh variables > including MAX_HEAP_SIZE as part of CASSANDRA-10679. If cassandra-env.sh has > MAX_HEAP_SIZE set to any value the default heap size needed for the cassandra > tool to run is overridden. > This is a problem if the using a large heap in C* i.e. 16-32G due to each > instance of nodetool or other tool will allocate large heap regardless of > need and could exceed the total RAM available on the system. > Patch removes the check for MAX_HEAP_SIZE being set and uses the default heap > size needed for each tool. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12739) Cassandra Tools use cassandra-env.sh MAX_HEAP_SIZE if set
[ https://issues.apache.org/jira/browse/CASSANDRA-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Vernon updated CASSANDRA-12739: Summary: Cassandra Tools use cassandra-env.sh MAX_HEAP_SIZE if set (was: Nodetool uses cassandra-env.sh MAX_HEAP_SIZE if set) > Cassandra Tools use cassandra-env.sh MAX_HEAP_SIZE if set > - > > Key: CASSANDRA-12739 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12739 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Brad Vernon > Attachments: cass-21_tools_xmx.patch, cass-22_tools_xmx.patch, > cass-3x_tools_xmx.patch > > > Nodetool and other bash startup scripts load cassandra-env.sh variables > including MAX_HEAP_SIZE as part of CASSANDRA-10679. If cassandra-env.sh has > MAX_HEAP_SIZE set to any value the default heap size needed for the cassandra > tool to run is overridden. > This is a problem if the using a large heap in C* i.e. 16-32G due to each > instance of nodetool or other tool will allocate large heap regardless of > need and could exceed the total RAM available on the system. > Patch removes the check for MAX_HEAP_SIZE being set and uses the default heap > size needed for each tool. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12739) Nodetool uses cassandra-env.sh MAX_HEAP_SIZE if set
Brad Vernon created CASSANDRA-12739: --- Summary: Nodetool uses cassandra-env.sh MAX_HEAP_SIZE if set Key: CASSANDRA-12739 URL: https://issues.apache.org/jira/browse/CASSANDRA-12739 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Brad Vernon Attachments: cass-21_tools_xmx.patch, cass-22_tools_xmx.patch, cass-3x_tools_xmx.patch Nodetool and other bash startup scripts load cassandra-env.sh variables including MAX_HEAP_SIZE as part of CASSANDRA-10679. If cassandra-env.sh has MAX_HEAP_SIZE set to any value the default heap size needed for the cassandra tool to run is overridden. This is a problem if the using a large heap in C* i.e. 16-32G due to each instance of nodetool or other tool will allocate large heap regardless of need and could exceed the total RAM available on the system. Patch removes the check for MAX_HEAP_SIZE being set and uses the default heap size needed for each tool. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12411) Do not store passwords in .cassandra/cqlsh_history
[ https://issues.apache.org/jira/browse/CASSANDRA-12411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15412515#comment-15412515 ] Brad Vernon commented on CASSANDRA-12411: - Couldn't cqlsh just ignore for those cql commands that use the pattern "WITH PASSWORD '.*'" and if matched via RegEx don't store in the history or replace with the common *. It would only match on CREATE USER, ALTER USER and CREATE ROLE commands. If using a standard non-User/role based command like INSERT or UPDATE logging would make sense since there is no understanding that the command being run is specific to a C* User's login, but in the above cases it's known. > Do not store passwords in .cassandra/cqlsh_history > -- > > Key: CASSANDRA-12411 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12411 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: jonathan lacefield > > This is a request to ensure that passwords are not stored in the > cqlsh_history file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
