[jira] [Commented] (CASSANDRA-16999) system.peers and system.peers_v2 do not contain the native_transport and/or native_transport_port_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767876#comment-17767876 ] Ahmed ELJAMI commented on CASSANDRA-16999: -- Hi, Would this fix be included in the next release of Cassandra 4.0.12 ? Greetings, > system.peers and system.peers_v2 do not contain the native_transport and/or > native_transport_port_ssl > - > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- 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-16999) system.peers and system.peers_v2 do not contain the native_transport and/or native_transport_port_ssl
[
https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762995#comment-17762995
]
Ahmed ELJAMI commented on CASSANDRA-16999:
--
Hi,
_Cassandra version: 4.0.5_
_Java Driver Version: 3.11.4_
We are trying to enable SSL between the client and Cassandra cluster but we
encountered the same issue as described here.
With a cluster of 2 nodes (The client uses these 2 nodes as contact_points), we
saw that the driver tried to connect to the second node using the port 9042:
{code:java}
10:26:31.474 [cluster1-nio-worker-0] WARN c.d.driver.core.HostConnectionPool -
Error creating connection to X.X.X.X/X.X.X.X:9042
com.datastax.driver.core.exceptions.TransportException: [X.X.X.X/X.X.X.X:9042]
Channel has been closed
10:26:31.475 [cluster1-nio-worker-0] WARN com.datastax.driver.core.Session -
Error creating pool to X.X.X.X/X.X.X.X:9042
com.datastax.driver.core.exceptions.ConnectionException: [X.X.X.X/X.X.X.X:9042]
Pool was closed during initialization{code}
Do you think that the fix will also be applied for 4.0.X ?
Thanks :)
> system.peers and system.peers_v2 do not contain the native_transport and/or
> native_transport_port_ssl
> -
>
> Key: CASSANDRA-16999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16999
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Steve Lacerda
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> system.peers_v2 includes a “native_port” but has no notion of
> native_transport_port vs. native_transport_port_ssl. Given this limited
> information, there’s no clear way for the driver to know that different ports
> are being used for SSL vs. non-SSL or which of those two ports is identified
> by “native_port”.
>
> The issue we ran into is that the java driver, since it has no notion of the
> transport port SSL, the driver was only using the contact points and was not
> load balancing.
>
> The customer had both set:
> native_transport_port: 9042
> native_transport_port_ssl: 9142
>
> They were attempting to connect to 9142, but that was failing. They could
> only use 9042, and so their applications load balancing was failing. We found
> that any node that was a contact point was connecting, but the other nodes
> were never acting as coordinators.
>
> There are still issues in the driver, for which I have created JAVA-2967,
> which also refers to JAVA-2638, but the system.peers and system.peers_v2
> tables should both contain native_transport_port and
> native_transport_port_ssl.
>
>
--
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] [Comment Edited] (CASSANDRA-16465) Increased Read Latency With Cassandra >= 3.11.7
[ https://issues.apache.org/jira/browse/CASSANDRA-16465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17331874#comment-17331874 ] Ahmed ELJAMI edited comment on CASSANDRA-16465 at 4/26/21, 7:54 AM: [~jaid] in our case, regression was observed for the LCS. The same behaviour as mentioned by [~nvest], SStable reads increases after upgrading from 3.11.3 to 3.11.9. [~cscetbon]We have only tested the 3.11.9 but I have refered to [~nvest]'s mail when I opened a new Jira who have observed the regression even with 3.11.7 was (Author: ahmedeljami): [~jaid] in our case, regression was observed for the LCS. The same behaviour as mentioned by [~nvest], SStable reads increases after upgrading from 3.11.3 to 3.11.9. [~cscetbon]We have only tested the 3.11.9 but I have refered to [~nvest] mail's when I opened a new Jira who have observed the regression even with 3.11.7 > Increased Read Latency With Cassandra >= 3.11.7 > --- > > Key: CASSANDRA-16465 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16465 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ahmed ELJAMI >Priority: Normal > Fix For: 3.11.x, 4.0.x > > Attachments: Screenshot from 2021-04-24 20-50-47.png > > > After upgrading Cassandra from 3.11.3 to 3.11.9, Cassandra read latency 99% > increased significantly. Getting back to 3.11.3 immediately fixed the issue. > I have observed "SStable reads" increases after upgrading to 3.11.9. > The same behavior was observed by some other users: > [https://www.mail-archive.com/user@cassandra.apache.org/msg61247.html] > According to Paulo Motta's comment, this behavior may be caused by > https://issues.apache.org/jira/browse/CASSANDRA-15690 which was introduced on > 3.11.7 and removed an optimization that may cause a correctness issue when > there are partition deletions. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16465) Increased Read Latency With Cassandra >= 3.11.7
[ https://issues.apache.org/jira/browse/CASSANDRA-16465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17331874#comment-17331874 ] Ahmed ELJAMI commented on CASSANDRA-16465: -- [~jaid] in our case, regression was observed for the LCS. The same behaviour as mentioned by [~nvest], SStable reads increases after upgrading from 3.11.3 to 3.11.9. [~cscetbon]We have only tested the 3.11.9 but I have refered to [~nvest] mail's when I opened a new Jira who have observed the regression even with 3.11.7 > Increased Read Latency With Cassandra >= 3.11.7 > --- > > Key: CASSANDRA-16465 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16465 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ahmed ELJAMI >Priority: Normal > Fix For: 3.11.x, 4.0.x > > Attachments: Screenshot from 2021-04-24 20-50-47.png > > > After upgrading Cassandra from 3.11.3 to 3.11.9, Cassandra read latency 99% > increased significantly. Getting back to 3.11.3 immediately fixed the issue. > I have observed "SStable reads" increases after upgrading to 3.11.9. > The same behavior was observed by some other users: > [https://www.mail-archive.com/user@cassandra.apache.org/msg61247.html] > According to Paulo Motta's comment, this behavior may be caused by > https://issues.apache.org/jira/browse/CASSANDRA-15690 which was introduced on > 3.11.7 and removed an optimization that may cause a correctness issue when > there are partition deletions. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16465) Increased Read Latency With Cassandra >= 3.11.7
Ahmed ELJAMI created CASSANDRA-16465: Summary: Increased Read Latency With Cassandra >= 3.11.7 Key: CASSANDRA-16465 URL: https://issues.apache.org/jira/browse/CASSANDRA-16465 Project: Cassandra Issue Type: Bug Reporter: Ahmed ELJAMI After upgrading Cassandra from 3.11.3 to 3.11.9, Cassandra read latency 99% increased significantly. Getting back to 3.11.3 immediately fixed the issue. I have observed "SStable reads" increases after upgrading to 3.11.9. The same behavior was observed by some other users: [https://www.mail-archive.com/user@cassandra.apache.org/msg61247.html] According to Paulo Motta's comment, this behavior may be caused by https://issues.apache.org/jira/browse/CASSANDRA-15690 which was introduced on 3.11.7 and removed an optimization that may cause a correctness issue when there are partition deletions. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9935) Repair fails with RuntimeException
[
https://issues.apache.org/jira/browse/CASSANDRA-9935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15312239#comment-15312239
]
Ahmed ELJAMI commented on CASSANDRA-9935:
-
[~mlowicki] When you had a problem with repair, streamthroughput had the
default value (200Mb/s) ? We lowered this value (50Mb/s) and since the repair
fails with the same error like you!
> Repair fails with RuntimeException
> --
>
> Key: CASSANDRA-9935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9935
> Project: Cassandra
> Issue Type: Bug
> Environment: C* 2.1.8, Debian Wheezy
>Reporter: mlowicki
>Assignee: Paulo Motta
> Fix For: 2.1.15, 3.6, 3.0.6, 2.2.7
>
> Attachments: 9935.patch, db1.sync.lati.osa.cassandra.log,
> db5.sync.lati.osa.cassandra.log, system.log.10.210.3.117,
> system.log.10.210.3.221, system.log.10.210.3.230
>
>
> We had problems with slow repair in 2.1.7 (CASSANDRA-9702) but after upgrade
> to 2.1.8 it started to work faster but now it fails with:
> {code}
> ...
> [2015-07-29 20:44:03,956] Repair session 23a811b0-3632-11e5-a93e-4963524a8bde
> for range (-5474076923322749342,-5468600594078911162] finished
> [2015-07-29 20:44:03,957] Repair session 336f8740-3632-11e5-a93e-4963524a8bde
> for range (-8631877858109464676,-8624040066373718932] finished
> [2015-07-29 20:44:03,957] Repair session 4ccd8430-3632-11e5-a93e-4963524a8bde
> for range (-5372806541854279315,-5369354119480076785] finished
> [2015-07-29 20:44:03,957] Repair session 59f129f0-3632-11e5-a93e-4963524a8bde
> for range (8166489034383821955,8168408930184216281] finished
> [2015-07-29 20:44:03,957] Repair session 6ae7a9a0-3632-11e5-a93e-4963524a8bde
> for range (6084602890817326921,6088328703025510057] finished
> [2015-07-29 20:44:03,957] Repair session 8938e4a0-3632-11e5-a93e-4963524a8bde
> for range (-781874602493000830,-781745173070807746] finished
> [2015-07-29 20:44:03,957] Repair command #4 finished
> error: nodetool failed, check server logs
> -- StackTrace --
> java.lang.RuntimeException: nodetool failed, check server logs
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:290)
> at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:202)
> {code}
> After running:
> {code}
> nodetool repair --partitioner-range --parallel --in-local-dc sync
> {code}
> Last records in logs regarding repair are:
> {code}
> INFO [Thread-173887] 2015-07-29 20:44:03,956 StorageService.java:2952 -
> Repair session 09ff9e40-3632-11e5-a93e-4963524a8bde for range
> (-7695808664784761779,-7693529816291585568] finished
> INFO [Thread-173887] 2015-07-29 20:44:03,956 StorageService.java:2952 -
> Repair session 17d8d860-3632-11e5-a93e-4963524a8bde for range
> (806371695398849,8065203836608925992] finished
> INFO [Thread-173887] 2015-07-29 20:44:03,956 StorageService.java:2952 -
> Repair session 23a811b0-3632-11e5-a93e-4963524a8bde for range
> (-5474076923322749342,-5468600594078911162] finished
> INFO [Thread-173887] 2015-07-29 20:44:03,956 StorageService.java:2952 -
> Repair session 336f8740-3632-11e5-a93e-4963524a8bde for range
> (-8631877858109464676,-8624040066373718932] finished
> INFO [Thread-173887] 2015-07-29 20:44:03,957 StorageService.java:2952 -
> Repair session 4ccd8430-3632-11e5-a93e-4963524a8bde for range
> (-5372806541854279315,-5369354119480076785] finished
> INFO [Thread-173887] 2015-07-29 20:44:03,957 StorageService.java:2952 -
> Repair session 59f129f0-3632-11e5-a93e-4963524a8bde for range
> (8166489034383821955,8168408930184216281] finished
> INFO [Thread-173887] 2015-07-29 20:44:03,957 StorageService.java:2952 -
> Repair session 6ae7a9a0-3632-11e5-a93e-4963524a8bde for range
> (6084602890817326921,6088328703025510057] finished
> INFO [Thread-173887] 2015-07-29 20:44:03,957 StorageService.java:2952 -
> Repair session 8938e4a0-3632-11e5-a93e-4963524a8bde for range
> (-781874602493000830,-781745173070807746] finished
> {code}
> but a bit above I see (at least two times in attached log):
> {code}
> ERROR [Thread-173887] 2015-07-29 20:44:03,853 StorageService.java:2959 -
> Repair session 1b07ea50-3608-11e5-a93e-4963524a8bde for range
> (5765414319217852786,5781018794516851576] failed with error
> org.apache.cassandra.exceptions.RepairException: [repair
> #1b07ea50-3608-11e5-a93e-4963524a8bde on sync/entity_by_id2,
> (5765414319217852786,5781018794516851576]] Validation failed in /10.195.15.162
> java.util.concurrent.ExecutionException: java.lang.RuntimeException:
> org.apache.cassandra.exceptions.RepairException: [repair
> #1b07ea50-3608-11e5-a93e-4963524a8bde on sync/entity_by_id2,
> (5765414319217852786,5781018794516851576]] Validation failed in /10.195.15.162
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> [na:1.7.0_80]
>
[jira] [Created] (CASSANDRA-10663) cassandra-stress timers
Ahmed ELJAMI created CASSANDRA-10663: Summary: cassandra-stress timers Key: CASSANDRA-10663 URL: https://issues.apache.org/jira/browse/CASSANDRA-10663 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Ahmed ELJAMI Priority: Minor I think that is intresting as it is very practical to have an option to make mounted charge per time step, like Timers in Jmeter. We can use the new YAML file in cassandra-stress like: Timers: timers1: #500 op on 900 sec start: 500 #number of op timer: 900 #in second end: 500 #number of op #Then timers2: #up to 1000 op on 900 sec start: 1000 #number of op timer: 900 #in second end: 1000 #number of op What do you think ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9934) Read authorized with write survey
[ https://issues.apache.org/jira/browse/CASSANDRA-9934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648912#comment-14648912 ] Ahmed ELJAMI commented on CASSANDRA-9934: - Yes! keySpace with RF = 1 My Key exists on node node002(ip 192.168.1.2) When I stop the node, to be sur: cqlsh select * from myks.mytable where id = 1745; Unable to complete request: one or more nodes were unavailable. When I start my node002 with survey mode = true INFO [main] 2015-07-31 09:13:40,448 StorageService.java (line 853) Startup complete, but write survey mode is active, not becoming an active ring member. Use JMX (StorageService-joinRing()) to finalize ring joining. cqlsh select * from myks.mytable where id = 1745; id | fname | lname --+---+--- 1745 | john | smith Tracing: tracing session: cddd4bb0-3758-11e5-bc8a-95336b038b5d (192.168.1.1 is the coordinator, 192.168.1.2 is the node with survey mode = true and key = 1745) activity | timestamp| source | source_elapsed ---+--+-+ execute_cql3_query | 09:50:25,515 | 192.168.1.1 | 0 Message received from /192.168.1.1 | 09:50:25,515 | 192.168.1.2 | 69 Executing single-partition query on cf1 | 09:50:25,516 | 192.168.1.2 | 1132 Parsing select * from myks.mytable where id = 1745 LIMIT 1; | 09:50:25,516 | 192.168.1.2 | 56 Acquiring sstable references | 09:50:25,516 | 192.168.1.2 | 1224 Preparing statement | 09:50:25,516 | 192.168.1.1 |135 Merging memtable tombstones | 09:50:25,516 | 192.168.1.2 | 1294 Executing single-partition query on users | 09:50:25,516 | 192.168.1.1 |368 Read authorized with write survey - Key: CASSANDRA-9934 URL: https://issues.apache.org/jira/browse/CASSANDRA-9934 Project: Cassandra Issue Type: Bug Components: Config, Core Environment: Cassandra 2.0.10 Reporter: Ahmed ELJAMI Priority: Minor I start a node with the write survey = true -Dcassandra.write_survey=true Log: INFO [main] 2015-07-29 15:29:35,697 StorageService.java (line 853) Startup complete, but write survey mode is active, not becoming an active ring member. Use JMX (StorageService-joinRing()) to finalize ring joining. but the node allows read: cqlsh select * from myTable where id = 1745; id | fname | lname --+---+--- 1745 | john | smith (Key 1745 exists on node with the the write survey = true) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-9934) Read authorized with write survey
Ahmed ELJAMI created CASSANDRA-9934: --- Summary: Read authorized with write survey Key: CASSANDRA-9934 URL: https://issues.apache.org/jira/browse/CASSANDRA-9934 Project: Cassandra Issue Type: Bug Components: Config, Core Environment: Cassandra 2.0.10 Reporter: Ahmed ELJAMI Priority: Minor I start a node with the write survey = true -Dcassandra.write_survey=true Log: INFO [main] 2015-07-29 15:29:35,697 StorageService.java (line 853) Startup complete, but write survey mode is active, not becoming an active ring member. Use JMX (StorageService-joinRing()) to finalize ring joining. but the node allows read: cqlsh select * from myTable where id = 1745; id | fname | lname --+---+--- 1745 | john | smith (Key 1745 exists on node with the the write survey = true) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
