[jira] [Updated] (CASSANDRA-15400) Cassandra 3.0.18 went OOM several hours after joining a cluster
[ https://issues.apache.org/jira/browse/CASSANDRA-15400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Steinmaurer updated CASSANDRA-15400: --- Attachment: oldgen_increase_nov12.jpg > Cassandra 3.0.18 went OOM several hours after joining a cluster > --- > > Key: CASSANDRA-15400 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15400 > Project: Cassandra > Issue Type: Bug > Components: Local/SSTable >Reporter: Thomas Steinmaurer >Assignee: Blake Eggleston >Priority: Normal > Fix For: 3.0.20, 3.11.6, 4.0 > > Attachments: cassandra_hprof_bigtablereader_statsmetadata.png, > cassandra_hprof_dominator_classes.png, cassandra_hprof_statsmetadata.png, > cassandra_jvm_metrics.png, cassandra_operationcount.png, > cassandra_sstables_pending_compactions.png, image.png, > oldgen_increase_nov12.jpg > > > We have been moving from Cassandra 2.1.18 to Cassandra 3.0.18 and have been > facing an OOM two times with 3.0.18 on newly added nodes joining an existing > cluster after several hours being successfully bootstrapped. > Running in AWS: > * m5.2xlarge, EBS SSD (gp2) > * Xms/Xmx12G, Xmn3G, CMS GC, OpenJDK8u222 > * 4 compaction threads, throttling set to 32 MB/s > What we see is a steady increase in the OLD gen over many hours. > !cassandra_jvm_metrics.png! > * The node started to join / auto-bootstrap the cluster on Oct 30 ~ 12:00 > * It basically finished joining the cluster (UJ => UN) ~ 19hrs later on Oct > 31 ~ 07:00 also starting to be a member of serving client read requests > !cassandra_operationcount.png! > Memory-wise (on-heap) it didn't look that bad at that time, but old gen usage > constantly increased. > We see a correlation in increased number of SSTables and pending compactions. > !cassandra_sstables_pending_compactions.png! > Until we reached the OOM somewhere in Nov 1 in the night. After a Cassandra > startup (metric gap in the chart above), number of SSTables + pending > compactions is still high, but without facing memory troubles since then. > This correlation is confirmed by the auto-generated heap dump with e.g. ~ 5K > BigTableReader instances with ~ 8.7GByte retained heap in total. > !cassandra_hprof_dominator_classes.png! > Having a closer look on a single object instance, seems like each instance is > ~ 2MByte in size. > !cassandra_hprof_bigtablereader_statsmetadata.png! > With 2 pre-allocated byte buffers (highlighted in the screen above) at 1 > MByte each > We have been running with 2.1.18 for > 3 years and I can't remember dealing > with such OOM in the context of extending a cluster. > While the MAT screens above are from our production cluster, we partly can > reproduce this behavior in our loadtest environment (although not going full > OOM there), thus I might be able to share a hprof from this non-prod > environment if needed. > Thanks a lot. -- 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-15400) Cassandra 3.0.18 went OOM several hours after joining a cluster
[ https://issues.apache.org/jira/browse/CASSANDRA-15400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973109#comment-16973109 ] Thomas Steinmaurer commented on CASSANDRA-15400: [~bdeggleston], thanks for the follow-up. Yes, causing quite some pain in prod in the moment, e.g. yesterday evening, close to running OOM again. !oldgen_increase_nov12.jpg! > Cassandra 3.0.18 went OOM several hours after joining a cluster > --- > > Key: CASSANDRA-15400 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15400 > Project: Cassandra > Issue Type: Bug > Components: Local/SSTable >Reporter: Thomas Steinmaurer >Assignee: Blake Eggleston >Priority: Normal > Fix For: 3.0.20, 3.11.6, 4.0 > > Attachments: cassandra_hprof_bigtablereader_statsmetadata.png, > cassandra_hprof_dominator_classes.png, cassandra_hprof_statsmetadata.png, > cassandra_jvm_metrics.png, cassandra_operationcount.png, > cassandra_sstables_pending_compactions.png, image.png, > oldgen_increase_nov12.jpg > > > We have been moving from Cassandra 2.1.18 to Cassandra 3.0.18 and have been > facing an OOM two times with 3.0.18 on newly added nodes joining an existing > cluster after several hours being successfully bootstrapped. > Running in AWS: > * m5.2xlarge, EBS SSD (gp2) > * Xms/Xmx12G, Xmn3G, CMS GC, OpenJDK8u222 > * 4 compaction threads, throttling set to 32 MB/s > What we see is a steady increase in the OLD gen over many hours. > !cassandra_jvm_metrics.png! > * The node started to join / auto-bootstrap the cluster on Oct 30 ~ 12:00 > * It basically finished joining the cluster (UJ => UN) ~ 19hrs later on Oct > 31 ~ 07:00 also starting to be a member of serving client read requests > !cassandra_operationcount.png! > Memory-wise (on-heap) it didn't look that bad at that time, but old gen usage > constantly increased. > We see a correlation in increased number of SSTables and pending compactions. > !cassandra_sstables_pending_compactions.png! > Until we reached the OOM somewhere in Nov 1 in the night. After a Cassandra > startup (metric gap in the chart above), number of SSTables + pending > compactions is still high, but without facing memory troubles since then. > This correlation is confirmed by the auto-generated heap dump with e.g. ~ 5K > BigTableReader instances with ~ 8.7GByte retained heap in total. > !cassandra_hprof_dominator_classes.png! > Having a closer look on a single object instance, seems like each instance is > ~ 2MByte in size. > !cassandra_hprof_bigtablereader_statsmetadata.png! > With 2 pre-allocated byte buffers (highlighted in the screen above) at 1 > MByte each > We have been running with 2.1.18 for > 3 years and I can't remember dealing > with such OOM in the context of extending a cluster. > While the MAT screens above are from our production cluster, we partly can > reproduce this behavior in our loadtest environment (although not going full > OOM there), thus I might be able to share a hprof from this non-prod > environment if needed. > Thanks a lot. -- 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-15421) CVE-2017-5929(QOS.ch Logback before 1.2.0 has a serialization vulnerability affecting the SocketServer and ServerSocketReceiver components.)
Abhishek Singh created CASSANDRA-15421: -- Summary: CVE-2017-5929(QOS.ch Logback before 1.2.0 has a serialization vulnerability affecting the SocketServer and ServerSocketReceiver components.) Key: CASSANDRA-15421 URL: https://issues.apache.org/jira/browse/CASSANDRA-15421 Project: Cassandra Issue Type: Bug Reporter: Abhishek Singh *Description :**Description :* *Severity :* CVE CVSS 2.0: 7.5Sonatype CVSS 3: 9.8 *Weakness :* CVE CWE: 502 *Source :* National Vulnerability Database *Categories :* Data *Description from CVE :* QOS.ch Logback before 1.2.0 has a serialization vulnerability affecting the SocketServer and ServerSocketReceiver components. *Explanation :* The RemoteStreamAppenderClient class in logback-classic and the SocketNode classes in logback-classic and logback-access allow data to be deserialized over a Java Socket, via an ObjectInputStream, without validating the data beforehand.When data is received from the Socket, to be logged, it is deserialized into Java objects.An attacker can exploit this vulnerability by sending malicious, serialized Java objects over the connection to the Socket, which may result in execution of arbitrary code when those objects are deserialized.Note that although logback-core is implicated by the Logback project here, the Sonatype Security Research team discovered that the vulnerability is actually present in the logback-classic and logback-access components. versions prior to 1.2.0, as stated in the advisory. *Detection :* The application is vulnerable by using this component. *Recommendation :* We recommend upgrading to a version of this component that is not vulnerable to this specific issue. *Root Cause :* apache-cassandra-3.11.4-bin.tar.gzch/qos/logback/classic/net/SocketNode.class : [1.0.12,1.2.0] *Advisories :* Project: https://logback.qos.ch/news.html *CVSS Details :* CVE CVSS 2.0: 7.5CVSS Vector: AV:N/AC:L/Au:N/C:P/I:P/A:P *Occurences (Paths) :* ["apache-cassandra.zip" ; "apache-cassandra.zip"] *CVE :* CVE-2017-5929 *URL :* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5929 *Remediation :* This component does not have any non-vulnerable Version. Please contact the vendor to get this vulnerability fixed. -- 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-15351) Allow configuring timeouts on the per-request basis
[ https://issues.apache.org/jira/browse/CASSANDRA-15351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973136#comment-16973136 ] Alex Petrov commented on CASSANDRA-15351: - I would say that the propagation mechanism is the same, and only capping mechanism is different. In case proposed in this ticket, we allow potentially longer requests to run and respect client timeout no matter what, and in 2848 we respect server-side timeout if it's lower than the one requested by client. I agree here that it's better to leave some control to Cassandra, let it time-out requests, and use its configuration as a worst-case scenario / cap. There's a stronger point by about not exposing this until we properly fix timeouts for SRP, digests, etc, but this seems to be fixed in [CASSANDRA-12256]. Probably too specific to the code produced for 2848, but there are some good points in the review of the patch as well, which should probably be taken into consideration. That said, I suggest we close this ticket as a dupe and continue discussion on the original ticket. > Allow configuring timeouts on the per-request basis > --- > > Key: CASSANDRA-15351 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15351 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client >Reporter: Alex Petrov >Assignee: Yifan Cai >Priority: Normal > > Some queries need to be ran with a higher timeout value, which should be > possible without allowing _all_ requests to be above this value. -- 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] [Updated] (CASSANDRA-15351) Allow configuring timeouts on the per-request basis
[ https://issues.apache.org/jira/browse/CASSANDRA-15351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15351: Resolution: Duplicate Status: Resolved (was: Triage Needed) > Allow configuring timeouts on the per-request basis > --- > > Key: CASSANDRA-15351 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15351 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client >Reporter: Alex Petrov >Assignee: Yifan Cai >Priority: Normal > > Some queries need to be ran with a higher timeout value, which should be > possible without allowing _all_ requests to be above this value. -- 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] [Comment Edited] (CASSANDRA-15351) Allow configuring timeouts on the per-request basis
[ https://issues.apache.org/jira/browse/CASSANDRA-15351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973136#comment-16973136 ] Alex Petrov edited comment on CASSANDRA-15351 at 11/13/19 9:00 AM: --- I would say that the propagation mechanism is the same, and only capping mechanism is different. In case proposed in this ticket, we allow potentially longer requests to run and respect client timeout no matter what, and in 2848 we respect server-side timeout if it's lower than the one requested by client. I agree here that it's better to leave some control to Cassandra, let it time-out requests, and use its configuration as a worst-case scenario / cap. My initial thinking was maintenance / bulk-read tasks, but I think this use-case is too narrow and even potentially dangerous, as it opens doors to tip the node over with a wrongly configured query despite node failsafe mechanisms. There's a stronger point by about not exposing this until we properly fix timeouts for SRP, digests, etc, but this seems to be fixed in [CASSANDRA-12256]. Probably too specific to the code produced for 2848, but there are some good points in the review of the patch as well, which should probably be taken into consideration. That said, I suggest we close this ticket as a dupe and continue discussion on the original ticket. was (Author: ifesdjeen): I would say that the propagation mechanism is the same, and only capping mechanism is different. In case proposed in this ticket, we allow potentially longer requests to run and respect client timeout no matter what, and in 2848 we respect server-side timeout if it's lower than the one requested by client. I agree here that it's better to leave some control to Cassandra, let it time-out requests, and use its configuration as a worst-case scenario / cap. There's a stronger point by about not exposing this until we properly fix timeouts for SRP, digests, etc, but this seems to be fixed in [CASSANDRA-12256]. Probably too specific to the code produced for 2848, but there are some good points in the review of the patch as well, which should probably be taken into consideration. That said, I suggest we close this ticket as a dupe and continue discussion on the original ticket. > Allow configuring timeouts on the per-request basis > --- > > Key: CASSANDRA-15351 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15351 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client >Reporter: Alex Petrov >Assignee: Yifan Cai >Priority: Normal > > Some queries need to be ran with a higher timeout value, which should be > possible without allowing _all_ requests to be above this value. -- 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] [Updated] (CASSANDRA-15407) Hint-dispatcher file-channel not closed, if "open()" fails with OOM
[ https://issues.apache.org/jira/browse/CASSANDRA-15407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-15407: - Reviewers: Robert Stupp > Hint-dispatcher file-channel not closed, if "open()" fails with OOM > --- > > Key: CASSANDRA-15407 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15407 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Hints >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Some places in the code base do not to close the file (some channel-proxy) in > case of errors. We should close the channel-proxy in those cases - at least > to not make the situation (due to that OOM) even worse. -- 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-15422) CVE-2018-1320(The libthrift component is vulnerable to Improper Access Control) on Cassendra 3.11.4
Abhishek Singh created CASSANDRA-15422: -- Summary: CVE-2018-1320(The libthrift component is vulnerable to Improper Access Control) on Cassendra 3.11.4 Key: CASSANDRA-15422 URL: https://issues.apache.org/jira/browse/CASSANDRA-15422 Project: Cassandra Issue Type: Bug Reporter: Abhishek Singh *Description :**Description :* *Severity :* CVE CVSS 3: 7.5Sonatype CVSS 3: 8.2 *Weakness :* CVE CWE: 20 *Source :* National Vulnerability Database *Categories :* Data *Description from CVE :* Apache Thrift Java client library versions 0.5.0 through 0.11.0 can bypass SASL negotiation isComplete validation in the org.apache.thrift.transport.TSaslTransport class. An assert used to determine if the SASL handshake had successfully completed could be disabled in production settings making the validation incomplete. *Explanation :* The libthrift component is vulnerable to Improper Access Control. The open[] method of the TSaslTransport class incorrectly uses an assertion to validate whether or not the SASL handshake has successfully completed. In some cases, such as production builds, the assertion functionality can be disabled rendering the validation incomplete. In such a case, an attacker can exploit this by being able to login without actually successfully completing the SASL handshake. *Detection :* The application is vulnerable by using this component. *Recommendation :* We recommend upgrading to a version of this component that is not vulnerable to this specific issue. *Root Cause :* apache-cassandra-3.11.4-bin.tar.gzorg/apache/thrift/transport/TSaslTransport.class : [0.5.0, 0.12.0] *Advisories :* Project: https://lists.apache.org/thread.html/da5234b5e78f1c99190407f… *CVSS Details :* CVE CVSS 3: 7.5CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N *Occurences (Paths) :* ["apache-cassandra.zip" ; "apache-cassandra.zip"] *CVE :* CVE-2018-1320 *URL :* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1320 *Remediation :* This component does not have any non-vulnerable Version. Please contact the vendor to get this vulnerability fixed. -- 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-15423) CVE-2015-2156 (Netty is vulnerable to Information Disclosure)
Abhishek Singh created CASSANDRA-15423: -- Summary: CVE-2015-2156 (Netty is vulnerable to Information Disclosure) Key: CASSANDRA-15423 URL: https://issues.apache.org/jira/browse/CASSANDRA-15423 Project: Cassandra Issue Type: Bug Reporter: Abhishek Singh *Description :**Description :* *Severity :* CVE CVSS 3.0: 7.5Sonatype CVSS 3.0: 7.5 *Weakness :* CVE CWE: 20 *Source :* National Vulnerability Database *Categories :* Data *Description from CVE :* Netty before 3.9.8.Final, 3.10.x before 3.10.3.Final, 4.0.x before 4.0.28.Final, and 4.1.x before 4.1.0.Beta5 and Play Framework 2.x before 2.3.9 might allow remote attackers to bypass the httpOnly flag on cookies and obtain sensitive information by leveraging improper validation of cookie name and value characters. *Explanation :* Netty is vulnerable to Information Disclosure.Multiple methods in multiple files improperly validate cookie names and values. This allows the presence of single-quote and double-quote characters to break tokenization.A remote attacker can exploit this vulnerability by inducing a victim to send a crafted request containing quote characters in any parameter value that sets a cookie.If that tainted cookie gets reflected in the response, the attacker can then use Cross-Site Scripting (XSS) to potentially retrieve the entire cookie header, despite the presence of an HttpOnly flag. The Sonatype security research team discovered that the vulnerability is present in all versions prior to 3.9.7.Final and 3.10.x before 3.10.2.Final, and not in all the versions before 3.9.8.Final and 3.10.x before 3.10.3.Final as the advisory states. *Detection :* The application is vulnerable by using this component if it reflects any cookie information in a HTML page, and that page is also prone to Cross-Site Scripting (XSS) attacks. *Recommendation :* We recommend upgrading to a version of this component that is not vulnerable to this specific issue. *Root Cause :* Cassandra-2.2.5.nupkgCookieDecoder.class : [5.0.0.Alpha1, 5.0.0.Alpha2) *Advisories :* Project: https://engineering.linkedin.com/security/look-netty_s-recen... *CVSS Details :* CVE CVSS 3.0: 7.5 *Occurences (Paths) :* [" apache-cassandra.zip/bin/cassandra.in.bat" ; " apache-cassandra.zip/bin/cassandra.in.sh" ; " apache-cassandra.zip/bin/cqlsh.bat" ; " apache-cassandra.zip/bin/debug-cql.bat" ; " apache-cassandra.zip/bin/source-conf.ps1" ; " apache-cassandra.zip/bin/sstableloader.bat" ; " apache-cassandra.zip/bin/sstablescrub.bat" ; " apache-cassandra.zip/bin/sstableupgrade.bat" ; " apache-cassandra.zip/bin/sstableverify.bat" ; " apache-cassandra.zip/bin/stop-server" ; " apache-cassandra.zip/bin/stop-server.bat" ; " apache-cassandra.zip/bin/stop-server.ps1" ; " apache-cassandra.zip/conf/README.txt" ; " apache-cassandra.zip/conf/cassandra-rackdc.properties" ; " apache-cassandra.zip/conf/cassandra-topology.properties" ; " apache-cassandra.zip/conf/commitlog_archiving.properties" ; " apache-cassandra.zip/conf/triggers/README.txt" ; " apache-cassandra.zip/lib/ST4-4.0.8.jar" ; " apache-cassandra.zip/lib/airline-0.6.jar" ; " apache-cassandra.zip/lib/antlr-runtime-3.5.2.jar" ; " apache-cassandra.zip/lib/commons-cli-1.1.jar" ; " apache-cassandra.zip/lib/commons-lang3-3.1.jar" ; " apache-cassandra.zip/lib/commons-math3-3.2.jar" ; " apache-cassandra.zip/lib/compress-lzf-0.8.4.jar" ; " apache-cassandra.zip/lib/concurrentlinkedhashmap-lru-1.4.jar" ; " apache-cassandra.zip/lib/disruptor-3.0.1.jar" ; " apache-cassandra.zip/lib/ecj-4.4.2.jar" ; " apache-cassandra.zip/lib/futures-2.1.6-py2.py3-none-any.zip" ; " apache-cassandra.zip/lib/high-scale-lib-1.0.6.jar" ; " apache-cassandra.zip/lib/jamm-0.3.0.jar" ; " apache-cassandra.zip/lib/javax.inject.jar" ; " apache-cassandra.zip/lib/jbcrypt-0.3m.jar" ; " apache-cassandra.zip/lib/jcl-over-slf4j-1.7.7.jar" ; " apache-cassandra.zip/lib/joda-time-2.4.jar" ; " apache-cassandra.zip/lib/json-simple-1.1.jar" ; " apache-cassandra.zip/lib/libthrift-0.9.2.jar" ; " apache-cassandra.zip/lib/licenses/ST4-4.0.8.txt" ; " apache-cassandra.zip/lib/licenses/antlr-runtime-3.5.2.txt" ; " apache-cassandra.zip/lib/licenses/compress-lzf-0.8.4.txt" ; " apache-cassandra.zip/lib/licenses/concurrent-trees-2.4.0.txt" ; " apache-cassandra.zip/lib/licenses/ecj-4.4.2.txt" ; " apache-cassandra.zip/lib/licenses/futures-2.1.6.txt" ; " apache-cassandra.zip/lib/licenses/high-scale-lib-1.0.6.txt" ; " apache-cassandra.zip/lib/licenses/jbcrypt-0.3m.txt" ; " apache-cassandra.zip/lib/licenses/jcl-over-slf4j-1.7.7.txt" ; " apache-cassandra.zip/lib/licenses/jna-4.2.2.txt" ; " apache-cassandra.zip/lib/licenses/jstackjunit-0.0.1.txt" ; " apache-cassandra.zip/lib/licenses/log4j-over-slf4j-1.7.7.txt" ; " apache-cassandra.zip/lib/licenses/logback-classic-1.1.3.txt" ; " apache-cassandra.zip/lib/licenses
[jira] [Created] (CASSANDRA-15424) CVE-2018-1320 (The libthrift component is vulnerable to Improper Access Control)
Abhishek Singh created CASSANDRA-15424: -- Summary: CVE-2018-1320 (The libthrift component is vulnerable to Improper Access Control) Key: CASSANDRA-15424 URL: https://issues.apache.org/jira/browse/CASSANDRA-15424 Project: Cassandra Issue Type: Bug Reporter: Abhishek Singh *Description :**Description :* *Severity :* CVE CVSS 3.0: 7.5Sonatype CVSS 3.0: 8.2 *Weakness :* CVE CWE: 20 *Source :* National Vulnerability Database *Categories :* Data *Description from CVE :* Apache Thrift Java client library versions 0.5.0 through 0.11.0 can bypass SASL negotiation isComplete validation in the org.apache.thrift.transport.TSaslTransport class. An assert used to determine if the SASL handshake had successfully completed could be disabled in production settings making the validation incomplete. *Explanation :* The libthrift component is vulnerable to Improper Access Control. The open() method of the TSaslTransport class incorrectly uses an assertion to validate whether or not the SASL handshake has successfully completed. In some cases, such as production builds, the assertion functionality can be disabled rendering the validation incomplete. In such a case, an attacker can exploit this by being able to login without actually successfully completing the SASL handshake. *Detection :* The application is vulnerable by using this component. *Recommendation :* We recommend upgrading to a version of this component that is not vulnerable to this specific issue. *Root Cause :* Cassandra-2.2.5.nupkgTSaslTransport.class : [0.5.0, 0.12.0) *Advisories :* Project: https://lists.apache.org/thread.html/da5234b5e78f1c99190407f... *CVSS Details :* CVE CVSS 3.0: 7.5 *Occurences (Paths) :* [" apache-cassandra.zip/bin/cassandra.in.bat" ; " apache-cassandra.zip/bin/cassandra.in.sh" ; " apache-cassandra.zip/bin/cqlsh.bat" ; " apache-cassandra.zip/bin/debug-cql.bat" ; " apache-cassandra.zip/bin/source-conf.ps1" ; " apache-cassandra.zip/bin/sstableloader.bat" ; " apache-cassandra.zip/bin/sstablescrub.bat" ; " apache-cassandra.zip/bin/sstableupgrade.bat" ; " apache-cassandra.zip/bin/sstableverify.bat" ; " apache-cassandra.zip/bin/stop-server" ; " apache-cassandra.zip/bin/stop-server.bat" ; " apache-cassandra.zip/bin/stop-server.ps1" ; " apache-cassandra.zip/conf/README.txt" ; " apache-cassandra.zip/conf/cassandra-rackdc.properties" ; " apache-cassandra.zip/conf/cassandra-topology.properties" ; " apache-cassandra.zip/conf/commitlog_archiving.properties" ; " apache-cassandra.zip/conf/triggers/README.txt" ; " apache-cassandra.zip/lib/ST4-4.0.8.jar" ; " apache-cassandra.zip/lib/airline-0.6.jar" ; " apache-cassandra.zip/lib/antlr-runtime-3.5.2.jar" ; " apache-cassandra.zip/lib/commons-cli-1.1.jar" ; " apache-cassandra.zip/lib/commons-lang3-3.1.jar" ; " apache-cassandra.zip/lib/commons-math3-3.2.jar" ; " apache-cassandra.zip/lib/compress-lzf-0.8.4.jar" ; " apache-cassandra.zip/lib/concurrentlinkedhashmap-lru-1.4.jar" ; " apache-cassandra.zip/lib/disruptor-3.0.1.jar" ; " apache-cassandra.zip/lib/ecj-4.4.2.jar" ; " apache-cassandra.zip/lib/futures-2.1.6-py2.py3-none-any.zip" ; " apache-cassandra.zip/lib/high-scale-lib-1.0.6.jar" ; " apache-cassandra.zip/lib/jamm-0.3.0.jar" ; " apache-cassandra.zip/lib/javax.inject.jar" ; " apache-cassandra.zip/lib/jbcrypt-0.3m.jar" ; " apache-cassandra.zip/lib/jcl-over-slf4j-1.7.7.jar" ; " apache-cassandra.zip/lib/joda-time-2.4.jar" ; " apache-cassandra.zip/lib/json-simple-1.1.jar" ; " apache-cassandra.zip/lib/libthrift-0.9.2.jar" ; " apache-cassandra.zip/lib/licenses/ST4-4.0.8.txt" ; " apache-cassandra.zip/lib/licenses/antlr-runtime-3.5.2.txt" ; " apache-cassandra.zip/lib/licenses/compress-lzf-0.8.4.txt" ; " apache-cassandra.zip/lib/licenses/concurrent-trees-2.4.0.txt" ; " apache-cassandra.zip/lib/licenses/ecj-4.4.2.txt" ; " apache-cassandra.zip/lib/licenses/futures-2.1.6.txt" ; " apache-cassandra.zip/lib/licenses/high-scale-lib-1.0.6.txt" ; " apache-cassandra.zip/lib/licenses/jbcrypt-0.3m.txt" ; " apache-cassandra.zip/lib/licenses/jcl-over-slf4j-1.7.7.txt" ; " apache-cassandra.zip/lib/licenses/jna-4.2.2.txt" ; " apache-cassandra.zip/lib/licenses/jstackjunit-0.0.1.txt" ; " apache-cassandra.zip/lib/licenses/log4j-over-slf4j-1.7.7.txt" ; " apache-cassandra.zip/lib/licenses/logback-classic-1.1.3.txt" ; " apache-cassandra.zip/lib/licenses/logback-core-1.1.3.txt" ; " apache-cassandra.zip/lib/licenses/lz4-1.3.0.txt" ; " apache-cassandra.zip/lib/licenses/metrics-core-3.1.0.txt" ; " apache-cassandra.zip/lib/licenses/metrics-jvm-3.1.0.txt" ; " apache-cassandra.zip/lib/licenses/ohc-0.4.4.txt" ; " apache-cassandra.zip/lib/licenses/reporter-config-base-3.0.3.txt" ; " apache-cassandra.zip/lib/licenses/reporter-config3-3.0.3.txt" ; " apache-cassandra.zip/lib/licenses/sigar-1.6.4.txt" ; " apache-cassandra.zip/lib/l
[jira] [Created] (CASSANDRA-15425) sonatype-2013-0069 (The setuptools package is vulnerable to Directory Traversal)
Abhishek Singh created CASSANDRA-15425: -- Summary: sonatype-2013-0069 (The setuptools package is vulnerable to Directory Traversal) Key: CASSANDRA-15425 URL: https://issues.apache.org/jira/browse/CASSANDRA-15425 Project: Cassandra Issue Type: Bug Reporter: Abhishek Singh *Description :**Description :* *Severity :* Sonatype CVSS 3.0: 7.5 *Weakness :* Sonatype CWE: 22 *Source :* Sonatype Data Research *Categories :* Data *Explanation :* The setuptools package is vulnerable to Directory Traversal. The _install() function and _build_egg() function in the ez_setup.py file creates setuptools as a .tar.gz file for distribution and allows files to be extracted to arbitrary locations. An attacker can exploit this vulnerability by uploading a tar archive that contains filenames starting with directory traversal characters such as (../../../../../etc/passwd) or symbolic links which, when untarred, will overwrite arbitrary files. *Detection :* The application is vulnerable by using this component. *Recommendation :* We recommend upgrading to a version of this component that is not vulnerable to this specific issue. *Root Cause :* Cassandra-2.2.5.nupkgez_setup.py : [0.7.3, 3.0b1) *Advisories :* Project: https://github.com/pypa/setuptools/issues/7 *CVSS Details :* Sonatype CVSS 3.0: 7.5 *Occurences (Paths) :* [" apache-cassandra.zip/bin/cassandra.in.bat" ; " apache-cassandra.zip/bin/cassandra.in.sh" ; " apache-cassandra.zip/bin/cqlsh.bat" ; " apache-cassandra.zip/bin/debug-cql.bat" ; " apache-cassandra.zip/bin/source-conf.ps1" ; " apache-cassandra.zip/bin/sstableloader.bat" ; " apache-cassandra.zip/bin/sstablescrub.bat" ; " apache-cassandra.zip/bin/sstableupgrade.bat" ; " apache-cassandra.zip/bin/sstableverify.bat" ; " apache-cassandra.zip/bin/stop-server" ; " apache-cassandra.zip/bin/stop-server.bat" ; " apache-cassandra.zip/bin/stop-server.ps1" ; " apache-cassandra.zip/conf/README.txt" ; " apache-cassandra.zip/conf/cassandra-rackdc.properties" ; " apache-cassandra.zip/conf/cassandra-topology.properties" ; " apache-cassandra.zip/conf/commitlog_archiving.properties" ; " apache-cassandra.zip/conf/triggers/README.txt" ; " apache-cassandra.zip/lib/ST4-4.0.8.jar" ; " apache-cassandra.zip/lib/airline-0.6.jar" ; " apache-cassandra.zip/lib/antlr-runtime-3.5.2.jar" ; " apache-cassandra.zip/lib/commons-cli-1.1.jar" ; " apache-cassandra.zip/lib/commons-lang3-3.1.jar" ; " apache-cassandra.zip/lib/commons-math3-3.2.jar" ; " apache-cassandra.zip/lib/compress-lzf-0.8.4.jar" ; " apache-cassandra.zip/lib/concurrentlinkedhashmap-lru-1.4.jar" ; " apache-cassandra.zip/lib/disruptor-3.0.1.jar" ; " apache-cassandra.zip/lib/ecj-4.4.2.jar" ; " apache-cassandra.zip/lib/futures-2.1.6-py2.py3-none-any.zip" ; " apache-cassandra.zip/lib/high-scale-lib-1.0.6.jar" ; " apache-cassandra.zip/lib/jamm-0.3.0.jar" ; " apache-cassandra.zip/lib/javax.inject.jar" ; " apache-cassandra.zip/lib/jbcrypt-0.3m.jar" ; " apache-cassandra.zip/lib/jcl-over-slf4j-1.7.7.jar" ; " apache-cassandra.zip/lib/joda-time-2.4.jar" ; " apache-cassandra.zip/lib/json-simple-1.1.jar" ; " apache-cassandra.zip/lib/libthrift-0.9.2.jar" ; " apache-cassandra.zip/lib/licenses/ST4-4.0.8.txt" ; " apache-cassandra.zip/lib/licenses/antlr-runtime-3.5.2.txt" ; " apache-cassandra.zip/lib/licenses/compress-lzf-0.8.4.txt" ; " apache-cassandra.zip/lib/licenses/concurrent-trees-2.4.0.txt" ; " apache-cassandra.zip/lib/licenses/ecj-4.4.2.txt" ; " apache-cassandra.zip/lib/licenses/futures-2.1.6.txt" ; " apache-cassandra.zip/lib/licenses/high-scale-lib-1.0.6.txt" ; " apache-cassandra.zip/lib/licenses/jbcrypt-0.3m.txt" ; " apache-cassandra.zip/lib/licenses/jcl-over-slf4j-1.7.7.txt" ; " apache-cassandra.zip/lib/licenses/jna-4.2.2.txt" ; " apache-cassandra.zip/lib/licenses/jstackjunit-0.0.1.txt" ; " apache-cassandra.zip/lib/licenses/log4j-over-slf4j-1.7.7.txt" ; " apache-cassandra.zip/lib/licenses/logback-classic-1.1.3.txt" ; " apache-cassandra.zip/lib/licenses/logback-core-1.1.3.txt" ; " apache-cassandra.zip/lib/licenses/lz4-1.3.0.txt" ; " apache-cassandra.zip/lib/licenses/metrics-core-3.1.0.txt" ; " apache-cassandra.zip/lib/licenses/metrics-jvm-3.1.0.txt" ; " apache-cassandra.zip/lib/licenses/ohc-0.4.4.txt" ; " apache-cassandra.zip/lib/licenses/reporter-config-base-3.0.3.txt" ; " apache-cassandra.zip/lib/licenses/reporter-config3-3.0.3.txt" ; " apache-cassandra.zip/lib/licenses/sigar-1.6.4.txt" ; " apache-cassandra.zip/lib/licenses/six-1.7.3.txt" ; " apache-cassandra.zip/lib/licenses/slf4j-api-1.7.7.txt" ; " apache-cassandra.zip/lib/licenses/stream-2.5.2.txt" ; " apache-cassandra.zip/lib/log4j-over-slf4j-1.7.7.jar" ; " apache-cassandra.zip/lib/logback-classic-1.1.3.jar" ; " apache-cassandra.zip/lib/logback-core-1.1.3.jar" ; " apache-cassandra.zip/lib/lz4-1.3.0.jar" ; " apache-cassandra.zi
[cassandra-diff] branch dependabot/maven/api-server/com.fasterxml.jackson.core-jackson-databind-2.9.10.1 created (now e0e49df)
This is an automated email from the ASF dual-hosted git repository. github-bot pushed a change to branch dependabot/maven/api-server/com.fasterxml.jackson.core-jackson-databind-2.9.10.1 in repository https://gitbox.apache.org/repos/asf/cassandra-diff.git. at e0e49df Bump jackson-databind from 2.9.9.2 to 2.9.10.1 in /api-server No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15413) Missing results on reading large frozen text map
[
https://issues.apache.org/jira/browse/CASSANDRA-15413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-15413:
Bug Category: Parent values: Correctness(12982)Level 1 values: Recoverable
Corruption / Loss(12986)
Complexity: Challenging
Component/s: Local/SSTable
Discovered By: User Report
Severity: Critical
Assignee: Alex Petrov
Status: Open (was: Triage Needed)
> Missing results on reading large frozen text map
>
>
> Key: CASSANDRA-15413
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15413
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Tyler Codispoti
>Assignee: Alex Petrov
>Priority: Normal
>
> Cassandra version: 2.2.15
> I have been running into a case where, when fetching the results from a table
> with a frozen>, if the number of results is greater than the
> fetch size (default 5000), we can end up with missing data.
> Side note: The table schema comes from using KairosDB, but we've isolated
> this issue to Cassandra itself. But it looks like this can cause problems for
> users of KairosDB as well.
> Repro case. Tested against fresh install of Cassandra 2.2.15.
> 1. Create table (csqlsh)
> {code:sql}
> CREATE KEYSPACE test
> WITH REPLICATION = {
>'class' : 'SimpleStrategy',
>'replication_factor' : 1
> };
> CREATE TABLE test.test (
> name text,
> tags frozen>,
> PRIMARY KEY (name, tags)
> ) WITH CLUSTERING ORDER BY (tags ASC);
> {code}
> 2. Insert data (python3)
> {code:python}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster(['127.0.0.1'])
> session = cluster.connect('test')
> for i in range(0, 2):
> session.execute(
> """
> INSERT INTO test (name, tags)
> VALUES (%s, %s)
> """,
> ("test_name", {'id':str(i)})
> )
> {code}
>
> 3. Flush
>
> {code:java}
> nodetools flush{code}
>
>
> 4. Fetch data (python3)
> {code:python}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster(['127.0.0.1'], control_connection_timeout=5000)
> session = cluster.connect('test')
> session.default_fetch_size = 5000
> session.default_timeout = 120
> count = 0
> rows = session.execute("select tags from test where name='test_name'")
> for row in rows:
> count += 1
> print(count)
> {code}
> Result: 10111 (expected 2)
>
> Changing the page size changes the result count. Some quick samples:
>
> ||default_fetch_size||count||
> |5000|10111|
> |1000|1830|
> |999|1840|
> |998|1850|
> |2|2|
> |10|2|
>
>
> In short, I cannot guarantee I'll get all the results back unless the page
> size > number of rows.
> This seems to get worse with multiple SSTables (eg nodetool flush between
> some of the insert batches). When using replication, the issue can get
> disgustingly bad - potentially giving a different result on each query.
> Interesting, if we pad the values on the tag map ("id" in this repro case) so
> that the insertion is in lexicographical order, there is no issue. I believe
> the issue also does not repro if I do not call "nodetools flush" before
> querying.
--
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-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[
https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973358#comment-16973358
]
Michael Semb Wever commented on CASSANDRA-14970:
This is work in progress, but I've pushed the following branches to
[cassandra|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_14970]
and
[cassandra-builds|https://github.com/apache/cassandra-builds/compare/master...thelastpickle:mck/14970_sha512-checksums].
The changes involve…
- remove the source and binary artefacts from being uploaded to nexus (nexus
is meant for maven artefacts)
- removes the use of people.apache.org for staging test artefacts (this
practice was deprecated, with a deadline of 31st December 2012)
- uses svnpubsub staging of all non-maven artefacts (ie
https://dist.apache.org/repos/dist/dev/cassandra/ )
- adds the rpm docker stuff into the script
- removes the copy of the source artefact in the debian binary's folder
- adds a "test announcement" email template (it is encouraged to be announcing
test builds a few days in advance of starting the vote)
Still to do is…
- generate the sha512 and gnupg asc signatures on the non-maven artefacts
- remove the `only_deb` flag (is it really needed?)
- make corresponding changes to {{finish_release.sh}} and
{{upload_bintray.sh}} scripts
- make patches for 2.2, 3.0, 3.11
[~mshuler], if you agree , shall i continue with this approach?
> New releases must supply SHA-256 and/or SHA-512 checksums
> -
>
> Key: CASSANDRA-14970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14970
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Michael Shuler
>Assignee: Michael Shuler
>Priority: Urgent
> Fix For: 2.2.16, 3.0.20, 3.11.6, 4.0
>
> Attachments:
> 0001-Update-downloads-for-sha256-sha512-checksum-files.patch,
> 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch,
> ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png
>
>
> Release policy was updated around 9/2018 to state:
> "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT
> supply MD5 or SHA-1. Existing releases do not need to be changed."
> build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both.
> cassandra-builds/cassandra-release scripts need to be updated to work with
> the new checksum files.
> http://www.apache.org/dev/release-distribution#sigs-and-sums
--
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] [Comment Edited] (CASSANDRA-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[
https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973358#comment-16973358
]
Michael Semb Wever edited comment on CASSANDRA-14970 at 11/13/19 1:56 PM:
--
This is work in progress, but I've pushed the following branches to
[cassandra|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_14970]
and
[cassandra-builds|https://github.com/apache/cassandra-builds/compare/master...thelastpickle:mck/14970_sha512-checksums].
The changes involve…
- remove the source and binary artefacts from being uploaded to nexus (nexus
is meant for maven artefacts)
- removes the use of people.apache.org for staging test artefacts (this
practice was deprecated, with a deadline of 31st December 2012)
- uses svnpubsub staging of all non-maven artefacts (ie
https://dist.apache.org/repos/dist/dev/cassandra/ )
- adds the rpm docker stuff into the script
- removes the copy of the source artefact in the debian binary's folder
- adds a "test announcement" email template (it is encouraged to be announcing
test builds a few days in advance of starting the vote)
Still to do is…
- generate the sha512 and gnupg asc signatures on the non-maven artefacts
- remove the `only_deb` flag (is it really needed?)
- make corresponding changes to {{finish_release.sh}} and
{{upload_bintray.sh}} scripts
- test rpm docker stuff inside script
- make patches for 2.2, 3.0, 3.11
[~mshuler], if you agree , shall i continue with this approach?
was (Author: michaelsembwever):
This is work in progress, but I've pushed the following branches to
[cassandra|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_14970]
and
[cassandra-builds|https://github.com/apache/cassandra-builds/compare/master...thelastpickle:mck/14970_sha512-checksums].
The changes involve…
- remove the source and binary artefacts from being uploaded to nexus (nexus
is meant for maven artefacts)
- removes the use of people.apache.org for staging test artefacts (this
practice was deprecated, with a deadline of 31st December 2012)
- uses svnpubsub staging of all non-maven artefacts (ie
https://dist.apache.org/repos/dist/dev/cassandra/ )
- adds the rpm docker stuff into the script
- removes the copy of the source artefact in the debian binary's folder
- adds a "test announcement" email template (it is encouraged to be announcing
test builds a few days in advance of starting the vote)
Still to do is…
- generate the sha512 and gnupg asc signatures on the non-maven artefacts
- remove the `only_deb` flag (is it really needed?)
- make corresponding changes to {{finish_release.sh}} and
{{upload_bintray.sh}} scripts
- make patches for 2.2, 3.0, 3.11
[~mshuler], if you agree , shall i continue with this approach?
> New releases must supply SHA-256 and/or SHA-512 checksums
> -
>
> Key: CASSANDRA-14970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14970
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Michael Shuler
>Assignee: Michael Shuler
>Priority: Urgent
> Fix For: 2.2.16, 3.0.20, 3.11.6, 4.0
>
> Attachments:
> 0001-Update-downloads-for-sha256-sha512-checksum-files.patch,
> 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch,
> ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png
>
>
> Release policy was updated around 9/2018 to state:
> "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT
> supply MD5 or SHA-1. Existing releases do not need to be changed."
> build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both.
> cassandra-builds/cassandra-release scripts need to be updated to work with
> the new checksum files.
> http://www.apache.org/dev/release-distribution#sigs-and-sums
--
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
[cassandra] branch trunk updated (a446aa5 -> 26a913f)
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 a446aa5 Merge branch 'cassandra-3.11' into trunk add 01b52de Make note of replicate_on_write and populate_io_cache_on_flush table options removal in NEWS.txt add 91b8a89 Merge branch 'cassandra-3.0' into cassandra-3.11 add 26a913f Merge branch 'cassandra-3.11' into trunk No new revisions were added by this update. Summary of changes: NEWS.txt | 2 ++ 1 file changed, 2 insertions(+) - 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 (1cc9413 -> 91b8a89)
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 1cc9413 Merge branch 'cassandra-3.0' into cassandra-3.11 add 01b52de Make note of replicate_on_write and populate_io_cache_on_flush table options removal in NEWS.txt add 91b8a89 Merge branch 'cassandra-3.0' into cassandra-3.11 No new revisions were added by this update. Summary of changes: NEWS.txt | 2 ++ 1 file changed, 2 insertions(+) - 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 (9382186 -> 01b52de)
This is an automated email from the ASF dual-hosted git repository. aleksey pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 9382186 Minimize clustering values in metadata collector add 01b52de Make note of replicate_on_write and populate_io_cache_on_flush table options removal in NEWS.txt No new revisions were added by this update. Summary of changes: NEWS.txt | 2 ++ 1 file changed, 2 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15408) Cassandra throws SyntaxException for obsolete keywords that Thrift API permits
[
https://issues.apache.org/jira/browse/CASSANDRA-15408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973512#comment-16973512
]
Aleksey Yeschenko commented on CASSANDRA-15408:
---
Thanks! Committed to 3.0 and merged upwards.
> Cassandra throws SyntaxException for obsolete keywords that Thrift API permits
> --
>
> Key: CASSANDRA-15408
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15408
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/NEWS.txt
>Reporter: Leon Zaruvinsky
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
> Attachments: CASSANDRA-15408.patch
>
>
> In [this
> refactor|https://github.com/apache/cassandra/commit/b31845c4a7982358a7c5bfd9bcf572fda6c1bfa9#diff-826a67bf1ae2e45372a35a6a2a6f3f3cL74]
> of CFPropDefs to TableAttributes for CASSANDRA-9712, three obsolete keywords
> were removed:
> {code:java}
> obsoleteKeywords.add("index_interval");
> obsoleteKeywords.add("replicate_on_write");
> obsoleteKeywords.add("populate_io_cache_on_flush");
> {code}
>
> The Thrift API continues to reference these keywords as deprecated, so it's
> not clear that they are actually unsupported.
> Could we either add them back as obsoleteKeywords, or add a change log that
> statements with these properties will fail (There is already a changelog
> about "index_interval" but not the other two)? I understand that the Thrift
> API is totally deprecated so I don't feel strongly about cleaning it up.
--
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] [Updated] (CASSANDRA-15408) Cassandra throws SyntaxException for obsolete keywords that Thrift API permits
[
https://issues.apache.org/jira/browse/CASSANDRA-15408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-15408:
--
Fix Version/s: (was: 3.11.x)
(was: 3.0.x)
3.11.6
3.0.20
Since Version: 3.0.0
Source Control Link:
https://github.com/apache/cassandra/commit/01b52de41e742d4c9a27d9d907839f1082af95a2
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Cassandra throws SyntaxException for obsolete keywords that Thrift API permits
> --
>
> Key: CASSANDRA-15408
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15408
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/NEWS.txt
>Reporter: Leon Zaruvinsky
>Priority: Normal
> Fix For: 3.0.20, 3.11.6
>
> Attachments: CASSANDRA-15408.patch
>
>
> In [this
> refactor|https://github.com/apache/cassandra/commit/b31845c4a7982358a7c5bfd9bcf572fda6c1bfa9#diff-826a67bf1ae2e45372a35a6a2a6f3f3cL74]
> of CFPropDefs to TableAttributes for CASSANDRA-9712, three obsolete keywords
> were removed:
> {code:java}
> obsoleteKeywords.add("index_interval");
> obsoleteKeywords.add("replicate_on_write");
> obsoleteKeywords.add("populate_io_cache_on_flush");
> {code}
>
> The Thrift API continues to reference these keywords as deprecated, so it's
> not clear that they are actually unsupported.
> Could we either add them back as obsoleteKeywords, or add a change log that
> statements with these properties will fail (There is already a changelog
> about "index_interval" but not the other two)? I understand that the Thrift
> API is totally deprecated so I don't feel strongly about cleaning it up.
--
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] [Updated] (CASSANDRA-15408) Cassandra throws SyntaxException for obsolete keywords that Thrift API permits
[
https://issues.apache.org/jira/browse/CASSANDRA-15408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-15408:
--
Reviewers: Aleksey Yeschenko, Aleksey Yeschenko (was: Aleksey Yeschenko)
Aleksey Yeschenko, Aleksey Yeschenko
Status: Review In Progress (was: Patch Available)
> Cassandra throws SyntaxException for obsolete keywords that Thrift API permits
> --
>
> Key: CASSANDRA-15408
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15408
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/NEWS.txt
>Reporter: Leon Zaruvinsky
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
> Attachments: CASSANDRA-15408.patch
>
>
> In [this
> refactor|https://github.com/apache/cassandra/commit/b31845c4a7982358a7c5bfd9bcf572fda6c1bfa9#diff-826a67bf1ae2e45372a35a6a2a6f3f3cL74]
> of CFPropDefs to TableAttributes for CASSANDRA-9712, three obsolete keywords
> were removed:
> {code:java}
> obsoleteKeywords.add("index_interval");
> obsoleteKeywords.add("replicate_on_write");
> obsoleteKeywords.add("populate_io_cache_on_flush");
> {code}
>
> The Thrift API continues to reference these keywords as deprecated, so it's
> not clear that they are actually unsupported.
> Could we either add them back as obsoleteKeywords, or add a change log that
> statements with these properties will fail (There is already a changelog
> about "index_interval" but not the other two)? I understand that the Thrift
> API is totally deprecated so I don't feel strongly about cleaning it up.
--
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] [Updated] (CASSANDRA-15408) Cassandra throws SyntaxException for obsolete keywords that Thrift API permits
[
https://issues.apache.org/jira/browse/CASSANDRA-15408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-15408:
--
Status: Ready to Commit (was: Review In Progress)
> Cassandra throws SyntaxException for obsolete keywords that Thrift API permits
> --
>
> Key: CASSANDRA-15408
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15408
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/NEWS.txt
>Reporter: Leon Zaruvinsky
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
> Attachments: CASSANDRA-15408.patch
>
>
> In [this
> refactor|https://github.com/apache/cassandra/commit/b31845c4a7982358a7c5bfd9bcf572fda6c1bfa9#diff-826a67bf1ae2e45372a35a6a2a6f3f3cL74]
> of CFPropDefs to TableAttributes for CASSANDRA-9712, three obsolete keywords
> were removed:
> {code:java}
> obsoleteKeywords.add("index_interval");
> obsoleteKeywords.add("replicate_on_write");
> obsoleteKeywords.add("populate_io_cache_on_flush");
> {code}
>
> The Thrift API continues to reference these keywords as deprecated, so it's
> not clear that they are actually unsupported.
> Could we either add them back as obsoleteKeywords, or add a change log that
> statements with these properties will fail (There is already a changelog
> about "index_interval" but not the other two)? I understand that the Thrift
> API is totally deprecated so I don't feel strongly about cleaning it up.
--
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] [Updated] (CASSANDRA-15409) nodetool compactionstats showing extra pending task for TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-15409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15409:
Bug Category: Parent values: Correctness(12982)Level 1 values:
Consistency(12989)
Complexity: Normal
Component/s: Tool/nodetool
Discovered By: User Report
Fix Version/s: 4.x
3.11.6
Severity: Low
Status: Open (was: Triage Needed)
> nodetool compactionstats showing extra pending task for TWCS
>
>
> Key: CASSANDRA-15409
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15409
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.11.6, 4.x
>
>
> Summary: nodetool compactionstats showing extra pending task for TWCS
> -
> The output of {{nodetool compactionstats}}can show "pending tasks: 1" when
> there are actually none. This seems to be a consistent problem in testing C*
> trunk. In my testing, it looks like the {{nodetool compactionstats}} counter
> output is consistently off by 1 as compared to the table output of the tasks
>
> testing with {{concurrent_compactors: 8}}
> In 12 hours it never ended, always showing 1 pending job
>
--
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-15409) nodetool compactionstats showing extra pending task for TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-15409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973583#comment-16973583
]
Ekaterina Dimitrova commented on CASSANDRA-15409:
-
Patch implemented for both v.3.11 and v.4
[Repository|https://github.com/ekaterinadimitrova2/cassandra]
branch 3.11 - CASSANDRA-15409-3.11
branch 4 - CASSANDRA-15409-trunk
> nodetool compactionstats showing extra pending task for TWCS
>
>
> Key: CASSANDRA-15409
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15409
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.11.6, 4.x
>
>
> Summary: nodetool compactionstats showing extra pending task for TWCS
> -
> The output of {{nodetool compactionstats}}can show "pending tasks: 1" when
> there are actually none. This seems to be a consistent problem in testing C*
> trunk. In my testing, it looks like the {{nodetool compactionstats}} counter
> output is consistently off by 1 as compared to the table output of the tasks
>
> testing with {{concurrent_compactors: 8}}
> In 12 hours it never ended, always showing 1 pending job
>
--
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] [Updated] (CASSANDRA-15409) nodetool compactionstats showing extra pending task for TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-15409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15409:
Test and Documentation Plan:
The issues was successfully reproduced and then tested again after the patch,
to confirm it is solved
DTests passed too
Status: Patch Available (was: Open)
> nodetool compactionstats showing extra pending task for TWCS
>
>
> Key: CASSANDRA-15409
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15409
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.11.6, 4.x
>
>
> Summary: nodetool compactionstats showing extra pending task for TWCS
> -
> The output of {{nodetool compactionstats}}can show "pending tasks: 1" when
> there are actually none. This seems to be a consistent problem in testing C*
> trunk. In my testing, it looks like the {{nodetool compactionstats}} counter
> output is consistently off by 1 as compared to the table output of the tasks
>
> testing with {{concurrent_compactors: 8}}
> In 12 hours it never ended, always showing 1 pending job
>
--
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] [Updated] (CASSANDRA-15399) Add ability to track state in repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15399:
--
Description:
To enhance the visibility in repair, we should expose internal state via
virtual tables; the state should include coordinator as well as participant
state (validation, sync, etc.)
I propose the following tables:
repairs - high level summary of the global state of repair; this should be
called on the coordinator.
{code:sql}
CREATE TABLE repairs (
id uuid,
keyspace_name text,
table_names frozen>,
ranges frozen>,
coordinator text,
participants frozen>,
state text,
progress_percentage float,
last_updated_at_millis bigint,
duration_micro bigint,
failure_cause text,
PRIMARY KEY ( (id) )
)
{code}
repair_tasks - represents RepairJob and participants state. This will show if
validations are running on participants and the progress they are making; this
should be called on the coordinator.
{code:sql}
CREATE TABLE repair_tasks (
id uuid,
session_id uuid,
keyspace_name text,
table_name text,
ranges frozen>,
coordinator text,
participant text,
state text,
state_description text,
progress_percentage float, -- between 0.0 and 100.0
last_updated_at_millis bigint,
duration_micro bigint,
failure_cause text,
PRIMARY KEY ( (id), session_id, table_name, participant )
)
{code}
repair_validations - shows the state of the validation task and updated
periodically while validation is running; this should be called on the
participants.
{code:sql}
CREATE TABLE repair_validations (
id uuid,
session_id uuid,
ranges frozen>,
keyspace_name text,
table_name text,
initiator text,
state text,
progress_percentage float,
queue_duration_ms bigint,
runtime_duration_ms bigint,
total_duration_ms bigint,
estimated_partitions bigint,
partitions_processed bigint,
estimated_total_bytes bigint,
failure_cause text,
PRIMARY KEY ( (id), session_id, table_name )
)
{code}
The main reason for exposing virtual tables rather than exposing through
durable tables is to make sure what is exposed is accurate. In cases of write
failures or node failures, the durable tables could become in-accurate and
could add edge cases where the repair is not running but the tables say it is;
by relying on repair's internal in-memory bookkeeping, these problems go away.
This jira does not try to solve the following:
1) repair resiliency - there are edge cases where repair hits an error and runs
forever (at least from nodetool's perspective).
2) repair stream tracking - I have not learned the streaming side yet and what
I see is multiple implementations exist, so seems like high scope. My hope is
to punt from this jira and tackle separately.
was:
To enhance the visibility in repair, we should add in-memory objects that can
be exposed via JMX and virtual tables to show the state of the coordinator, and
validations (leaving sync out for now).
These objects should expose the timing (create, start, complete), current state
(enum specific to the entity), and progress estimate (% complete); along with
any entity specific information useful.
To help with growth, ActiveRepairService should periodically cleanup completed
state after a configurable interval.
> Add ability to track state in repair
>
>
> Key: CASSANDRA-15399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15399
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To enhance the visibility in repair, we should expose internal state via
> virtual tables; the state should include coordinator as well as participant
> state (validation, sync, etc.)
> I propose the following tables:
> repairs - high level summary of the global state of repair; this should be
> called on the coordinator.
> {code:sql}
> CREATE TABLE repairs (
> id uuid,
> keyspace_name text,
> table_names frozen>,
> ranges frozen>,
> coordinator text,
> participants frozen>,
> state text,
> progress_percentage float,
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id) )
> )
> {code}
> repair_tasks - represents RepairJob and participants state. This will show
> if validations are running on participants and the progress they are making;
> this should be called on the coordinator.
> {code:sql}
> CREATE TABLE repair_tasks (
> id uuid,
> session_id uuid,
> keyspace_name text,
> table_name text,
> ranges frozen>,
> coordinator text,
> participant text,
> state text,
> state_description text,
[jira] [Commented] (CASSANDRA-15332) When repair is running with tracing, if a CorruptSSTableException is thrown while building Merkle Trees the DiskFailurePolicy does not get applied
[ https://issues.apache.org/jira/browse/CASSANDRA-15332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973766#comment-16973766 ] David Capwell commented on CASSANDRA-15332: --- thanks! [~marcuse] everything good then? Thanks everyone for the reviews! > When repair is running with tracing, if a CorruptSSTableException is thrown > while building Merkle Trees the DiskFailurePolicy does not get applied > -- > > Key: CASSANDRA-15332 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15332 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair, Observability/Tracing >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > When a repair is in the validation phase and is building MerkleTrees, if a > corrupt SSTable exception is thrown the disk failure policy does not get > applied -- 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
