[jira] [Commented] (CASSANDRA-14241) Apache dtests not passing after pytest/python 3
[
https://issues.apache.org/jira/browse/CASSANDRA-14241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367994#comment-16367994
]
Ariel Weisberg commented on CASSANDRA-14241:
Not sure what is going on with Jolokia. Sure looks like it should be able to
attach.
{noformat}
Failed to start jolokia agent (command was:
/home/jenkins/tools/java/latest1.8/bin/java -cp
/home/jenkins/tools/java/latest1.8/lib/tools.jar:lib/jolokia-jvm-1.2.3-agent.jar
org.jolokia.jvmagent.client.AgentLauncher --host 127.0.0.1 start 16509):
Command '('/home/jenkins/tools/java/latest1.8/bin/java', '-cp',
'/home/jenkins/tools/java/latest1.8/lib/tools.jar:lib/jolokia-jvm-1.2.3-agent.jar',
'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', 'start',
'16509')' returned non-zero exit status 1
Exit status was: 1
Output was: b'Illegal Argument (command: start) : Cannot attach to process-ID
16509.\nSee --help for possible reasons.\n'
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 38016 5712 ?Ss2017 1:47
/lib/systemd/systemd --system --deserialize 28
root 2 0.0 0.0 0 0 ?S 2017 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ?S 2017 1:44 [ksoftirqd/0]
root 5 0.0 0.0 0 0 ?S<2017 0:00 [kworker/0:0H]
root 7 0.0 0.0 0 0 ?S 2017 53:00 [rcu_sched]
root 8 0.0 0.0 0 0 ?S 2017 0:00 [rcu_bh]
root 9 0.0 0.0 0 0 ?S 2017 0:20 [migration/0]
root10 0.0 0.0 0 0 ?S 2017 0:40 [watchdog/0]
root11 0.0 0.0 0 0 ?S 2017 0:33 [watchdog/1]
root12 0.0 0.0 0 0 ?S 2017 0:20 [migration/1]
root13 0.0 0.0 0 0 ?S 2017 1:55 [ksoftirqd/1]
root15 0.0 0.0 0 0 ?S<2017 0:00 [kworker/1:0H]
root16 0.0 0.0 0 0 ?S 2017 0:32 [watchdog/2]
root17 0.0 0.0 0 0 ?S 2017 0:30 [migration/2]
root18 0.0 0.0 0 0 ?S 2017 1:42 [ksoftirqd/2]
root20 0.0 0.0 0 0 ?S<2017 0:00 [kworker/2:0H]
root21 0.0 0.0 0 0 ?S 2017 0:33 [watchdog/3]
root22 0.0 0.0 0 0 ?S 2017 0:28 [migration/3]
root23 0.0 0.0 0 0 ?S 2017 2:02 [ksoftirqd/3]
root25 0.0 0.0 0 0 ?S<2017 0:00 [kworker/3:0H]
root26 0.0 0.0 0 0 ?S 2017 0:00 [kdevtmpfs]
root27 0.0 0.0 0 0 ?S<2017 0:00 [netns]
root28 0.0 0.0 0 0 ?S<2017 0:00 [perf]
root29 0.0 0.0 0 0 ?S 2017 0:00 [xenwatch]
root30 0.0 0.0 0 0 ?S 2017 0:00 [xenbus]
root32 0.0 0.0 0 0 ?S 2017 0:05 [khungtaskd]
root33 0.0 0.0 0 0 ?S<2017 0:00 [writeback]
root34 0.0 0.0 0 0 ?SN2017 0:00 [ksmd]
root35 0.0 0.0 0 0 ?SN2017 1:42 [khugepaged]
root36 0.0 0.0 0 0 ?S<2017 0:00 [crypto]
root37 0.0 0.0 0 0 ?S<2017 0:00 [kintegrityd]
root38 0.0 0.0 0 0 ?S<2017 0:00 [bioset]
root39 0.0 0.0 0 0 ?S<2017 0:00 [kblockd]
root40 0.0 0.0 0 0 ?S<2017 0:00 [ata_sff]
root41 0.0 0.0 0 0 ?S<2017 0:00 [md]
root42 0.0 0.0 0 0 ?S<2017 0:00 [devfreq_wq]
root48 0.0 0.0 0 0 ?S 2017 0:05 [kswapd0]
root49 0.0 0.0 0 0 ?S<2017 0:00 [vmstat]
root50 0.0 0.0 0 0 ?S 2017 0:00 [fsnotify_mark]
root51 0.0 0.0 0 0 ?S 2017 0:00
[ecryptfs-kthrea]
root67 0.0 0.0 0 0 ?S<2017 0:00 [kthrotld]
root68 0.0 0.0 0 0 ?S<2017 0:00 [bioset]
root69 0.0 0.0 0 0 ?S<2017 0:00 [bioset]
root70 0.0 0.0 0 0 ?S<2017 0:00 [bioset]
root71 0.0 0.0 0 0 ?S<2017 0:00 [bioset]
root72 0.0 0.0 0 0 ?S<2017 0:00 [bioset]
root73 0.0 0.0 0 0 ?S<2017 0:00 [bioset]
root74 0.0 0.0 0 0 ?S<2017 0:00 [bioset]
root75 0.0 0.0 0 0 ?S<2017 0:00 [bioset]
root76 0.0 0.0 0 0 ?S<2017 0:00 [bioset]
root77 0.0 0.0 0 0 ?S<
[jira] [Issue Comment Deleted] (CASSANDRA-14241) Apache dtests not passing after pytest/python 3
[ https://issues.apache.org/jira/browse/CASSANDRA-14241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-14241: --- Comment: was deleted (was: I think the Jolokia issue is that PID is coming out as a byte something or other in Python 3. It needs to be decoded before assignment. This is probably a ccm/python 3 issue.) > Apache dtests not passing after pytest/python 3 > --- > > Key: CASSANDRA-14241 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14241 > Project: Cassandra > Issue Type: Task > Components: Testing >Reporter: Ariel Weisberg >Priority: Major > > Apache dtests are still not running correctly yet with pytest. Most of the > tests are running and passing but a solid chunk are still failing and these > are tests that don't fail in CircleCI. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14241) Apache dtests not passing after pytest/python 3
[ https://issues.apache.org/jira/browse/CASSANDRA-14241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367990#comment-16367990 ] Ariel Weisberg commented on CASSANDRA-14241: I think the Jolokia issue is that PID is coming out as a byte something or other in Python 3. It needs to be decoded before assignment. This is probably a ccm/python 3 issue. > Apache dtests not passing after pytest/python 3 > --- > > Key: CASSANDRA-14241 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14241 > Project: Cassandra > Issue Type: Task > Components: Testing >Reporter: Ariel Weisberg >Priority: Major > > Apache dtests are still not running correctly yet with pytest. Most of the > tests are running and passing but a solid chunk are still failing and these > are tests that don't fail in CircleCI. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14241) Apache dtests not passing after pytest/python 3
[ https://issues.apache.org/jira/browse/CASSANDRA-14241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367913#comment-16367913 ] Ariel Weisberg commented on CASSANDRA-14241: I agree updating CCM is better we just need to fix the tests to not do the conversion. > Apache dtests not passing after pytest/python 3 > --- > > Key: CASSANDRA-14241 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14241 > Project: Cassandra > Issue Type: Task > Components: Testing >Reporter: Ariel Weisberg >Priority: Major > > Apache dtests are still not running correctly yet with pytest. Most of the > tests are running and passing but a solid chunk are still failing and these > are tests that don't fail in CircleCI. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14241) Apache dtests not passing after pytest/python 3
[ https://issues.apache.org/jira/browse/CASSANDRA-14241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367891#comment-16367891 ] Stefan Podkowinski commented on CASSANDRA-14241: I stumbled upon this through the failed dtest linked in the [PR|https://github.com/riptano/ccm/pull/664]. My assumption was that it would be preferable to restore the old behaviour, by having `handle_external_tool_process` return a string instead of binary value (which would be of little use). > Apache dtests not passing after pytest/python 3 > --- > > Key: CASSANDRA-14241 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14241 > Project: Cassandra > Issue Type: Task > Components: Testing >Reporter: Ariel Weisberg >Priority: Major > > Apache dtests are still not running correctly yet with pytest. Most of the > tests are running and passing but a solid chunk are still failing and these > are tests that don't fail in CircleCI. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14241) Apache dtests not passing after pytest/python 3
[ https://issues.apache.org/jira/browse/CASSANDRA-14241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367863#comment-16367863 ] Ariel Weisberg commented on CASSANDRA-14241: [~spod] [~spo...@gmail.com] this CCM change https://github.com/riptano/ccm/commit/07f788ab9b5b5d4426ae8303d25a45c88e1f172b is causing some failures in both CircleCI and the Apache cassandra dtests as we were doing the decoding in a bunch of the tests. > Apache dtests not passing after pytest/python 3 > --- > > Key: CASSANDRA-14241 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14241 > Project: Cassandra > Issue Type: Task > Components: Testing >Reporter: Ariel Weisberg >Priority: Major > > Apache dtests are still not running correctly yet with pytest. Most of the > tests are running and passing but a solid chunk are still failing and these > are tests that don't fail in CircleCI. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14241) Apache dtests not passing after pytest/python 3
[ https://issues.apache.org/jira/browse/CASSANDRA-14241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367863#comment-16367863 ] Ariel Weisberg edited comment on CASSANDRA-14241 at 2/16/18 8:51 PM: - [~spod] [~spo...@gmail.com] this CCM change https://github.com/riptano/ccm/commit/07f788ab9b5b5d4426ae8303d25a45c88e1f172b is causing some failures in both CircleCI and the Apache cassandra dtests as we were doing the decoding in a bunch of the tests. https://circleci.com/gh/aweisberg/cassandra/1042#tests/containers/16 was (Author: aweisberg): [~spod] [~spo...@gmail.com] this CCM change https://github.com/riptano/ccm/commit/07f788ab9b5b5d4426ae8303d25a45c88e1f172b is causing some failures in both CircleCI and the Apache cassandra dtests as we were doing the decoding in a bunch of the tests. > Apache dtests not passing after pytest/python 3 > --- > > Key: CASSANDRA-14241 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14241 > Project: Cassandra > Issue Type: Task > Components: Testing >Reporter: Ariel Weisberg >Priority: Major > > Apache dtests are still not running correctly yet with pytest. Most of the > tests are running and passing but a solid chunk are still failing and these > are tests that don't fail in CircleCI. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14241) Apache dtests not passing after pytest/python 3
Ariel Weisberg created CASSANDRA-14241: -- Summary: Apache dtests not passing after pytest/python 3 Key: CASSANDRA-14241 URL: https://issues.apache.org/jira/browse/CASSANDRA-14241 Project: Cassandra Issue Type: Task Components: Testing Reporter: Ariel Weisberg Apache dtests are still not running correctly yet with pytest. Most of the tests are running and passing but a solid chunk are still failing and these are tests that don't fail in CircleCI. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13474) Cassandra pluggable storage engine
[ https://issues.apache.org/jira/browse/CASSANDRA-13474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dikang Gu updated CASSANDRA-13474: -- Description: We did some experiment to switch Cassandra's storage engine to RocksDB. In the experiment, I built a prototype to integrate Cassandra 3.0.12 and RocksDB on single column (key-value) use case, shadowed one of our production use case, and saw about 4-6X P99 read latency drop during peak time, compared to 3.0.12. Also, the P99 latency became more predictable as well. Here is detailed note with more metrics: [https://docs.google.com/document/d/1Ztqcu8Jzh4USKoWBgDJQw82DBurQmsV-PmfiJYvu_Dc/edit?usp=sharing] I think the biggest latency win comes from we get rid of most Java garbages created by current read/write path and compactions, which reduces the JVM overhead and makes the latency to be more predictable. We are very excited about the potential performance gain. As the next step, I propose to make the Cassandra storage engine to be pluggable (like Mysql and MongoDB), and we are very interested in providing RocksDB as one storage option with more predictable performance, together with community. Design doc for pluggable storage engine: https://docs.google.com/document/d/1suZlvhzgB6NIyBNpM9nxoHxz_Ri7qAm-UEO8v8AIFsc/edit was: We did some experiment to switch Cassandra's storage engine to RocksDB. In the experiment, I built a prototype to integrate Cassandra 3.0.12 and RocksDB on single column (key-value) use case, shadowed one of our production use case, and saw about 4-6X P99 read latency drop during peak time, compared to 3.0.12. Also, the P99 latency became more predictable as well. Here is detailed note with more metrics: https://docs.google.com/document/d/1Ztqcu8Jzh4USKoWBgDJQw82DBurQmsV-PmfiJYvu_Dc/edit?usp=sharing I think the biggest latency win comes from we get rid of most Java garbages created by current read/write path and compactions, which reduces the JVM overhead and makes the latency to be more predictable. We are very excited about the potential performance gain. As the next step, I propose to make the Cassandra storage engine to be pluggable (like Mysql and MongoDB), and we are very interested in providing RocksDB as one storage option with more predictable performance, together with community. > Cassandra pluggable storage engine > -- > > Key: CASSANDRA-13474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13474 > Project: Cassandra > Issue Type: New Feature >Reporter: Dikang Gu >Priority: Major > > We did some experiment to switch Cassandra's storage engine to RocksDB. > In the experiment, I built a prototype to integrate Cassandra 3.0.12 and > RocksDB on single column (key-value) use case, shadowed one of our production > use case, and saw about 4-6X P99 read latency drop during peak time, compared > to 3.0.12. Also, the P99 latency became more predictable as well. > Here is detailed note with more metrics: > [https://docs.google.com/document/d/1Ztqcu8Jzh4USKoWBgDJQw82DBurQmsV-PmfiJYvu_Dc/edit?usp=sharing] > I think the biggest latency win comes from we get rid of most Java garbages > created by current read/write path and compactions, which reduces the JVM > overhead and makes the latency to be more predictable. > We are very excited about the potential performance gain. As the next step, I > propose to make the Cassandra storage engine to be pluggable (like Mysql and > MongoDB), and we are very interested in providing RocksDB as one storage > option with more predictable performance, together with community. > Design doc for pluggable storage engine: > https://docs.google.com/document/d/1suZlvhzgB6NIyBNpM9nxoHxz_Ri7qAm-UEO8v8AIFsc/edit -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r1824547 - in /cassandra/site: publish/download/index.html src/_data/releases.yaml
Author: mshuler Date: Fri Feb 16 18:17:05 2018 New Revision: 1824547 URL: http://svn.apache.org/viewvc?rev=1824547=rev Log: Update download page for 2.1.20 and 2.2.12 releases Modified: cassandra/site/publish/download/index.html cassandra/site/src/_data/releases.yaml Modified: cassandra/site/publish/download/index.html URL: http://svn.apache.org/viewvc/cassandra/site/publish/download/index.html?rev=1824547=1824546=1824547=diff == --- cassandra/site/publish/download/index.html (original) +++ cassandra/site/publish/download/index.html Fri Feb 16 18:17:05 2018 @@ -107,9 +107,9 @@ Apache Cassandra 3.0 is supported until 6 months after 4.0 release (date TBD). The latest release is http://www.apache.org/dyn/closer.lua/cassandra/3.0.15/apache-cassandra-3.0.15-bin.tar.gz;>3.0.15 (http://www.apache.org/dist/cassandra/3.0.15/apache-cassandra-3.0.15-bin.tar.gz.asc;>pgp, http://www.apache.org/dist/cassandra/3.0.15/apache-cassandra-3.0.15-bin.tar.gz.md5;>md5 and http://www.apache.org/dist/cassandra/3.0.15/apache-cassandra-3.0.15-bin.tar.gz.sha1;>sha1), released on 2017-10-10. - Apache Cassandra 2.2 is supported until 4.0 release (date TBD). The latest release is http://www.apache.org/dyn/closer.lua/cassandra/2.2.11/apache-cassandra-2.2.11-bin.tar.gz;>2.2.11 (http://www.apache.org/dist/cassandra/2.2.11/apache-cassandra-2.2.11-bin.tar.gz.asc;>pgp, http://www.apache.org/dist/cassandra/2.2.11/apache-cassandra-2.2.11-bin.tar.gz.md5;>md5 and http://www.apache.org/dist/cassandra/2.2.11/apache-cassandra-2.2.11-bin.tar.gz.sha1;>sha1), released on 2017-10-05. + Apache Cassandra 2.2 is supported until 4.0 release (date TBD). The latest release is http://www.apache.org/dyn/closer.lua/cassandra/2.2.12/apache-cassandra-2.2.12-bin.tar.gz;>2.2.12 (http://www.apache.org/dist/cassandra/2.2.12/apache-cassandra-2.2.12-bin.tar.gz.asc;>pgp, http://www.apache.org/dist/cassandra/2.2.12/apache-cassandra-2.2.12-bin.tar.gz.md5;>md5 and http://www.apache.org/dist/cassandra/2.2.12/apache-cassandra-2.2.12-bin.tar.gz.sha1;>sha1), released on 2018-02-16. Apache Cassandra 2.1 is supported until 4.0 release (date TBD) with critical fixes only. The latest release is -http://www.apache.org/dyn/closer.lua/cassandra/2.1.19/apache-cassandra-2.1.19-bin.tar.gz;>2.1.19 (http://www.apache.org/dist/cassandra/2.1.19/apache-cassandra-2.1.19-bin.tar.gz.asc;>pgp, http://www.apache.org/dist/cassandra/2.1.19/apache-cassandra-2.1.19-bin.tar.gz.md5;>md5 and http://www.apache.org/dist/cassandra/2.1.19/apache-cassandra-2.1.19-bin.tar.gz.sha1;>sha1), released on 2017-10-05. +http://www.apache.org/dyn/closer.lua/cassandra/2.1.20/apache-cassandra-2.1.20-bin.tar.gz;>2.1.20 (http://www.apache.org/dist/cassandra/2.1.20/apache-cassandra-2.1.20-bin.tar.gz.asc;>pgp, http://www.apache.org/dist/cassandra/2.1.20/apache-cassandra-2.1.20-bin.tar.gz.md5;>md5 and http://www.apache.org/dist/cassandra/2.1.20/apache-cassandra-2.1.20-bin.tar.gz.sha1;>sha1), released on 2018-02-16. Older (unsupported) versions of Cassandra are http://archive.apache.org/dist/cassandra/;>archived here. Modified: cassandra/site/src/_data/releases.yaml URL: http://svn.apache.org/viewvc/cassandra/site/src/_data/releases.yaml?rev=1824547=1824546=1824547=diff == --- cassandra/site/src/_data/releases.yaml (original) +++ cassandra/site/src/_data/releases.yaml Fri Feb 16 18:17:05 2018 @@ -7,9 +7,9 @@ latest: date: 2017-10-10 "2.2": - name: "2.2.11" - date: 2017-10-05 + name: "2.2.12" + date: 2018-02-16 "2.1": - name: "2.1.19" - date: 2017-10-05 + name: "2.1.20" + date: 2018-02-16 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14240) Backport circleci yaml
Jason Brown created CASSANDRA-14240:
---
Summary: Backport circleci yaml
Key: CASSANDRA-14240
URL: https://issues.apache.org/jira/browse/CASSANDRA-14240
Project: Cassandra
Issue Type: Task
Reporter: Jason Brown
Assignee: Jason Brown
Fix For: 2.2.x, 3.0.x, 3.11.x
Backport the circleci yaml (sha {{d6e508f33c1a7274b5826ad9d5ce814d719bd848}})
to earlier branches
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r25102 - in /release/cassandra: 2.1.18/ 2.2.10/
Author: mshuler Date: Fri Feb 16 17:55:50 2018 New Revision: 25102 Log: Drop 2.1.18 2.2.10 releases from dist svn Removed: release/cassandra/2.1.18/ release/cassandra/2.2.10/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r25101 [1/2] - in /release/cassandra: 2.1.20/ 2.2.12/ debian/dists/21x/ debian/dists/21x/main/binary-amd64/ debian/dists/21x/main/binary-i386/ debian/dists/21x/main/source/ debian/dists/22
Author: mshuler Date: Fri Feb 16 17:44:05 2018 New Revision: 25101 Log: Release Apache Cassandra 2.1.20 and 2.2.12 Added: release/cassandra/2.1.20/ release/cassandra/2.1.20/apache-cassandra-2.1.20-bin.tar.gz (with props) release/cassandra/2.1.20/apache-cassandra-2.1.20-bin.tar.gz.asc release/cassandra/2.1.20/apache-cassandra-2.1.20-bin.tar.gz.asc.md5 release/cassandra/2.1.20/apache-cassandra-2.1.20-bin.tar.gz.asc.sha1 release/cassandra/2.1.20/apache-cassandra-2.1.20-bin.tar.gz.md5 release/cassandra/2.1.20/apache-cassandra-2.1.20-bin.tar.gz.sha1 release/cassandra/2.1.20/apache-cassandra-2.1.20-src.tar.gz (with props) release/cassandra/2.1.20/apache-cassandra-2.1.20-src.tar.gz.asc release/cassandra/2.1.20/apache-cassandra-2.1.20-src.tar.gz.asc.md5 release/cassandra/2.1.20/apache-cassandra-2.1.20-src.tar.gz.asc.sha1 release/cassandra/2.1.20/apache-cassandra-2.1.20-src.tar.gz.md5 release/cassandra/2.1.20/apache-cassandra-2.1.20-src.tar.gz.sha1 release/cassandra/2.2.12/ release/cassandra/2.2.12/apache-cassandra-2.2.12-bin.tar.gz (with props) release/cassandra/2.2.12/apache-cassandra-2.2.12-bin.tar.gz.asc release/cassandra/2.2.12/apache-cassandra-2.2.12-bin.tar.gz.asc.md5 release/cassandra/2.2.12/apache-cassandra-2.2.12-bin.tar.gz.asc.sha1 release/cassandra/2.2.12/apache-cassandra-2.2.12-bin.tar.gz.md5 release/cassandra/2.2.12/apache-cassandra-2.2.12-bin.tar.gz.sha1 release/cassandra/2.2.12/apache-cassandra-2.2.12-src.tar.gz (with props) release/cassandra/2.2.12/apache-cassandra-2.2.12-src.tar.gz.asc release/cassandra/2.2.12/apache-cassandra-2.2.12-src.tar.gz.asc.md5 release/cassandra/2.2.12/apache-cassandra-2.2.12-src.tar.gz.asc.sha1 release/cassandra/2.2.12/apache-cassandra-2.2.12-src.tar.gz.md5 release/cassandra/2.2.12/apache-cassandra-2.2.12-src.tar.gz.sha1 release/cassandra/debian/pool/main/c/cassandra/cassandra-tools_2.1.20_all.deb (with props) release/cassandra/debian/pool/main/c/cassandra/cassandra-tools_2.2.12_all.deb (with props) release/cassandra/debian/pool/main/c/cassandra/cassandra_2.1.20.diff.gz (with props) release/cassandra/debian/pool/main/c/cassandra/cassandra_2.1.20.dsc release/cassandra/debian/pool/main/c/cassandra/cassandra_2.1.20.orig.tar.gz (with props) release/cassandra/debian/pool/main/c/cassandra/cassandra_2.1.20.orig.tar.gz.asc release/cassandra/debian/pool/main/c/cassandra/cassandra_2.1.20_all.deb (with props) release/cassandra/debian/pool/main/c/cassandra/cassandra_2.2.12.diff.gz (with props) release/cassandra/debian/pool/main/c/cassandra/cassandra_2.2.12.dsc release/cassandra/debian/pool/main/c/cassandra/cassandra_2.2.12.orig.tar.gz (with props) release/cassandra/debian/pool/main/c/cassandra/cassandra_2.2.12.orig.tar.gz.asc release/cassandra/debian/pool/main/c/cassandra/cassandra_2.2.12_all.deb (with props) release/cassandra/redhat/21x/cassandra-2.1.20-1.noarch.rpm (with props) release/cassandra/redhat/21x/cassandra-2.1.20-1.src.rpm (with props) release/cassandra/redhat/21x/cassandra-tools-2.1.20-1.noarch.rpm (with props) release/cassandra/redhat/21x/repodata/205846454520b839836ff9e7791157eec1a2d8e5c7ba099867a3a502eb96969e-other.xml.gz (with props) release/cassandra/redhat/21x/repodata/2fe775681b1bb01a1665e284397c532195192e960056843f098b73de1ae9fe02-filelists.sqlite.bz2 (with props) release/cassandra/redhat/21x/repodata/2fe775681b1bb01a1665e284397c532195192e960056843f098b73de1ae9fe02-filelists.sqlite.bz2.asc release/cassandra/redhat/21x/repodata/3012496897dc1cfd990a3e87c266d4f929ff7914791184e0cf40a2f3027cddc5-primary.xml.gz (with props) release/cassandra/redhat/21x/repodata/41d3dc698d71f757f9ac07d8043980786e4fb5c39f3acef2fa522130512410ee-other.sqlite.bz2 (with props) release/cassandra/redhat/21x/repodata/41d3dc698d71f757f9ac07d8043980786e4fb5c39f3acef2fa522130512410ee-other.sqlite.bz2.asc release/cassandra/redhat/21x/repodata/cf01b24ff859e555a7524dd37848059de4969c89ba852a345995ffadb2df4f23-filelists.xml.gz (with props) release/cassandra/redhat/21x/repodata/de299e49076cdc96e13859f217addd2ab9a8affb70500dd0a28b0189aac9ffd3-primary.sqlite.bz2 (with props) release/cassandra/redhat/21x/repodata/de299e49076cdc96e13859f217addd2ab9a8affb70500dd0a28b0189aac9ffd3-primary.sqlite.bz2.asc release/cassandra/redhat/22x/cassandra-2.2.12-1.noarch.rpm (with props) release/cassandra/redhat/22x/cassandra-2.2.12-1.src.rpm (with props) release/cassandra/redhat/22x/cassandra-tools-2.2.12-1.noarch.rpm (with props) release/cassandra/redhat/22x/repodata/0ec885a26ac37dd1840cb942b11126cbedc63d782b040b4084db2b7592238339-other.sqlite.bz2 (with props) release/cassandra/redhat/22x/repodata/0ec885a26ac37dd1840cb942b11126cbedc63d782b040b4084db2b7592238339-other.sqlite.bz2.asc
svn commit: r25101 [2/2] - in /release/cassandra: 2.1.20/ 2.2.12/ debian/dists/21x/ debian/dists/21x/main/binary-amd64/ debian/dists/21x/main/binary-i386/ debian/dists/21x/main/source/ debian/dists/22
Modified: release/cassandra/redhat/22x/repodata/repomd.xml == --- release/cassandra/redhat/22x/repodata/repomd.xml (original) +++ release/cassandra/redhat/22x/repodata/repomd.xml Fri Feb 16 17:44:05 2018 @@ -1,55 +1,55 @@ http://linux.duke.edu/metadata/repo; xmlns:rpm="http://linux.duke.edu/metadata/rpm;> - 1507208844 + 1518802327 - e932f6a98973a56a1e7e86758aaf512fae6a08e48953ff4eb7c92932465c53b9 - de353b443f776bf7f7c64e77a1518ff8ed88b290afc6f75b6a4c53d6c583 - - 1507208844 - 2361 - 27249 + 56c7ef9d963994554b3a455677f5fa3409491d72c3a8f7ee8c1522278e9997b0 + 227470a9a4de62d9aa9be4d60594691af4ef72d2219014710eac302712a34040 + + 1518802328 + 2691 + 40880 - fc742615e48fb768986b727dadeb96b5a255e294796fb407d9e774cab5f4d6cf - f9d42ab9bdb566df91d603fc6fd87ea534420f9b16eeac2adca3e6393c299bfe - - 1507208844 - 1942 - 15241 + c21caeaa904804c11326515e342c67a7e4007c8193e40e80dec5752e79c8f3b9 + 047b95cb1d65f6dd3e8f272e8649926f87a33bb14706b2e2a949cc3c439d46f0 + + 1518802328 + 2254 + 22778 - 5db28f5a800882fa537d72c6379c8f724de79f97303f4f81e2da37a06323fd4f - 7581961a83083cd742fc85f4a97419d718b09a06d599f8e101925ce77fe39356 - - 1507208844 + e435627100c8a5c06d740201c92992d6672fad8e9c36b23378cf2e2b4a87c82e + 13d3b459747387c349c78d6090b684397e44ae48441bc9b1cfb4d37d789db059 + + 1518802328 10 - 6165 - 38912 + 8089 + 49152 - 6858f7557bd0652eac312a989ea8517cf4b3bd7050afdc54c58f19672ab947c9 - 6493f5dff6fec997d88b805b69262f8467716294e4a6bbc5f8ec5116c77f2551 - - 1507208844 + 0ec885a26ac37dd1840cb942b11126cbedc63d782b040b4084db2b7592238339 + bed962f307d5f6eb5aaa8ef846b8b91f31eda2435fe02d204c420e257cf645b4 + + 1518802328 10 - 1227 + 1480 6144 - 4bc374af73ab8da8fa57ea654682bd82994a7f2b2b80dca95be842943b065b4c - fa9037770d7f73136465a58f100f8145341ea36614687e1c56c52ac6cd404a44 - - 1507208844 - 585 - 2071 + 5b5908d16d13cc6d0d12e95a8253117749723b989cab4565d7aa31706ac30c21 + 49b808a39eac965677227212a1b16b0781314f619debfae8bcb5d3554283f402 + + 1518802328 + 723 + 3046 - 22c01f83d9818c17aa28c6a4cf9dcdb4d6f34f0830f7b2366316fddada2d1d02 - c7aa513a6796279d0a64e48a67a9a22a0c3f18b3925d3b7f9dbd0439613829e9 - - 1507208844 + bf9e47581f71b59ac9125f688243d305585461f97da6348e87de23888d4956f6 + 4e67a9a8ceb80f7053e5f5fc50ef0b99c7f851b0d2a3fa92b837b9d021355950 + + 1518802328 10 - 4492 - 20480 + 5576 + 26624 Modified: release/cassandra/redhat/22x/repodata/repomd.xml.asc == --- release/cassandra/redhat/22x/repodata/repomd.xml.asc (original) +++ release/cassandra/redhat/22x/repodata/repomd.xml.asc Fri Feb 16 17:44:05 2018 @@ -1,17 +1,17 @@ -BEGIN PGP SIGNATURE- Version: GnuPG v1 -iQIcBAABCAAGBQJZ1i8iAAoJEKJ4t4H+SyvaweoP/Ai41A1elt3T5IFEIga6pHJM -gyo5Zwf4D9LUUxoZSo23yhKH5J8/Ke0VjzkLc+WHLj3QJXLkDKpV7yRuOMEHSlnM -/r5pga6BirjPGB8659iBT9CCDSfwYmyO+nQBUgCCSZp+CuIMnGQ4rawzlE827sMe -+enwvUrCCVdDw9d6wQS3whP/7ucUWLJmC+eG5fY8Mh76rK7VnnwkdgmglXNN3hOj -RfkGaZTpR697YyZntx9pK3J5Ya6EPhKFWiMt/IAi5dnOCVVMcolSbbXx7ejF6Nry -oCLxDHUC/22LnGt1O/sOe51NkvgJ0U4hXayKGbC4XbftzVAopAfTUKjH4gz1932W -ZeiOnwKiO8Z7P88CViTnoLu3BHz6/VMZa78tFTVDd4dUcD0lN/yVVDuEIekyzwV7 -73ocwPRDAVVqq4Gri61PQ3V/vfz833B4pcTk3TuCeUIM/Kzf5DguTQwKWLkGObw2 -xlNN4f9rwG1TuAvUmtAKx4saqyTPFtSeD6sP6U5aQ3sCFSF5eOMg2bRuprkpaAPN -9fUx0efgkRyPEyzGRGDtZWCFxBE8KO59kXMv9mgLdwaGwBAy6PAt9+b1hMCQrhWA -cJuZ5ZVHxlZyEwvPO9m+j9L0N4Ro/cwgZ1bZpPLOHAEHDKvUVXgnfWveHknhN/mc -wK7OR9Geg4PElBogtjQO -=o6N6 +iQIcBAABCAAGBQJahxWpAAoJEKJ4t4H+SyvaReUQAJKu3Kox49tBHuBjIT278qc4 +lqm1afsd9XX69EWvj/vpoXDDVYHZMSRQlE7RswPAc8GqYH6VulOvvRr4tgY7VjE4 +DoXjduTT3sKbYzaHiuJPxEVjiXqjt/nqo40/Jh5TJi/zmiafKKA0HdApe8Y2s+Bx +FzU5vbE5PgzulBkWRS8WjLRZkAfxEgCf5agAnNwAcPfaSdclV0mDNIshaqvjkqpD +RER5TF4Iw0hf53Ya62OrNxiAtjGVTRKGAoZMG5rqXd1KYkSsC04XrCBWHdJFWFLE +uYW5v7wiXKFbCRtu1yokx817dGaasfOuJUk2tNEeQWTYDpx/crOj7jkvWKSiqT7E +laF4bi6Lsvm5tfaS5bPLjalIURD9knaySKpeaZXazoE1wR0MihtQnAjoDQn3frrK +fSwKvufHIObod3k/eP248rllogUvQ2y0HNAIktQ++W+VyCpF5Sxmu3cMRq5F8YxC +He07w8DVSnYcy+xmMFyVVHMXBJl6u8ooOA1CFn7laZyYqeQZxlfL2BBV+0TcQnNG +AFR235OdlxtX9dUrGf9jqFTE/Xm78dPtgB+jcIfKD2bsS52IRLyHy98cwmcxuS+H +EkgqrZ0bzwWD5b0ub4UJK2/jU8au4vw4pzCzvUpXnYGtIrd8qfi3OQNcujtebYOI +yGtMSYKxaEF8cMd2OhBM +=dd5X -END PGP SIGNATURE- - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] Git Push Summary
Repository: cassandra Updated Tags: refs/tags/2.2.12-tentative [deleted] 1602e6063 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] Git Push Summary
Repository: cassandra Updated Tags: refs/tags/cassandra-2.2.12 [created] b3b03f041 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] Git Push Summary
Repository: cassandra Updated Tags: refs/tags/2.1.20-tentative [deleted] b2949439e - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] Git Push Summary
Repository: cassandra Updated Tags: refs/tags/cassandra-2.1.20 [created] 3297edc94 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14183) CVE-2017-5929 Security vulnerability and redefine default log rotation policy
[ https://issues.apache.org/jira/browse/CASSANDRA-14183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367564#comment-16367564 ] Ariel Weisberg commented on CASSANDRA-14183: Thanks for catching that. > CVE-2017-5929 Security vulnerability and redefine default log rotation policy > - > > Key: CASSANDRA-14183 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14183 > Project: Cassandra > Issue Type: Improvement > Components: Libraries >Reporter: Thiago Veronezi >Assignee: Thiago Veronezi >Priority: Major > Labels: patch, security > Fix For: 4.0, 2.1.21, 2.2.13, 3.0.17, 3.11.3 > > Attachments: > 0001-Update-to-logback-1.2.3-and-redefine-default-rotatio.patch > > > Cassandra 3.11.1 is patched with logback 1.1.3, which contains the security > vulnerability described here. > [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5929] > Also update to logback allows a simple date and size rotation policy to > replace the default fixed policy, which is broken by design. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16364865#comment-16364865 ] Eric Hubert edited comment on CASSANDRA-13396 at 2/16/18 2:42 PM: -- [~jasobrown], fair enough. From what I read/understood the majority of users (if not all, definitely including us) facing this issue, wanted to use Cassandra as an embedded server (mostly for integration testing purposes) utilizing class org.apache.cassandra.service.CassandraDaemon - so no production deployment of a standalone server or cluster. While running in the same JVM alongside an application using slf4j with any slf4j supported backend != logback after upgrading to Cassandra 3.10 or later you are in trouble and no longer able to start the Cassandra server, although logging/logging performance are none of your (primary) goals/concerns. I doubt there are many users who want to configure a standalone single or multi-node Cassandra installation using a different logging backend to use this in production and have your support, but many users want to write automated integration/scenario tests of their own application interacting with Cassandra using an embedded Cassandra server in addition to plain unit tests using mocks without being forced to switch the logging backend chosen for their application for similar reasons you have. Therefore I see no conflict at all. An implementation could even somehow enforce the differentiation between embedded and standalone usage similar to "runManaged" in CassandraDeamon to only allow/support other logging backends (skip special logging backend specific configuration) when CassandraDeamon is used/configured differently than done from main() used by a standalone server installation, if this is really a concern you want to see addressed. Even in this case one should exchange nasty runtime exceptions or even JVM errors (ClassCastException or NoClassDefFoundError) with a dedicated error message: "When using a Cassandra standalone installation the only supported logging backend is logback." For ClassCastException add something like "slf4j is currently bound to a different logging framework. Please ensure your classpath only contains logback implementations!" For NoClassDefFoundError add something like "No logback implementation was found. Please ensure your classpath contains the bundled logback implementation!" You can decide to abort the startup or have the same behavior as for the embedded case, but only providing a detailed error logging regarding the unsupported setup. For embedded use cases one could advice programmers to activate the CassandraDaemon differently (e.g. some parameter) and here I would propose to simply not execute all logback specific configuration logic - e.g. try loading specific logback classes via reflection, so in this mode logback could be easily replaced by any slf4j logging backend which the application currently uses without further adjustments. JUnit test cases might be a bit tricky, because I think they involve different classpath setups of the used test runner to simulate/trigger those type of issues. was (Author: ehubert): [~jasobrown], fair enough. From what I read/understood the majority of users (if not all, definitely including us) facing this issue, wanted to use Cassandra as an embedded server (mostly for integration testing purposes) utilizing class org.apache.cassandra.service.CassandraDaemon - so no production deployment of a standalone server or cluster. While running alongside an application using slf4j with any slf4j supported backend != logback your are in trouble and no longer able to start the cassandra server, although logging/logging performance are none of your (primary) goals/concerns. I doubt there are many users who want to configure a standalone single or multi-node Cassandra installation using a different logging backend to use this in production and have your support, but many users want to write automated integration/scenario tests of their own application interacting with Cassandra using an embedded Cassandra server in addition to plain unit tests using mocks without being forced to switch the logging backend chosen for their application for similar reasons you have. Therefore I see no conflict at all. An implementation could even somehow enforce the differentation between embedded and standalone similar to "runManaged" to only allow/support other logging backends (skip special logging backend specific configuration) if CassandraDeamon is used/configured differently than from main() as done by a standalone server installation, this this is really a concern you want to see addressed. > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396
[jira] [Updated] (CASSANDRA-14239) OutOfMemoryError when bootstrapping with less than 100GB RAM
[ https://issues.apache.org/jira/browse/CASSANDRA-14239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jürgen Albersdorfer updated CASSANDRA-14239: Attachment: jvm_opts.txt > OutOfMemoryError when bootstrapping with less than 100GB RAM > > > Key: CASSANDRA-14239 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14239 > Project: Cassandra > Issue Type: Bug > Environment: Details of the bootstrapping Node > * ProLiant BL460c G7 > * 56GB RAM > * 2x 146GB 10K HDD (One dedicated for Commitlog, one for Data, Hints and > saved_caches) > * CentOS 7.4 on SD-Card > * /tmp and /var/log on tmpfs > * Oracle JDK 1.8.0_151 > * Cassandra 3.11.1 > Cluster > * 10 existing Nodes (Up and Normal) >Reporter: Jürgen Albersdorfer >Priority: Major > Attachments: Objects-by-class.csv, > Objects-with-biggest-retained-size.csv, cassandra-env.sh, cassandra.yaml, > jvm.options, jvm_opts.txt, stack-traces.txt > > > Hi, I face an issue when bootstrapping a Node having less than 100GB RAM on > our 10 Node C* 3.11.1 Cluster. > During bootstrap, when I watch the cassandra.log I observe a growth in JVM > Heap Old Gen which gets not significantly freed up any more. > I know that JVM collects on Old Gen only when really needed. I can see > collections, but there is always a remainder which seems to grow forever > without ever getting freed. > After the Node successfully Joined the Cluster, I can remove the extra RAM I > have given it for bootstrapping without any further effect. > It feels like Cassandra will not forget about every single byte streamed over > the Network over time during bootstrapping, - which would be a memory leak > and a major problem, too. > I was able to produce a HeapDumpOnOutOfMemoryError from a 56GB Node (40 GB > assigned JVM Heap). YourKit Profiler shows huge amount of Memory allocated > for org.apache.cassandra.db.Memtable (22 GB) > org.apache.cassandra.db.rows.BufferCell (19 GB) and java.nio.HeapByteBuffer > (11 GB) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14239) OutOfMemoryError when bootstrapping with less than 100GB RAM
Jürgen Albersdorfer created CASSANDRA-14239: --- Summary: OutOfMemoryError when bootstrapping with less than 100GB RAM Key: CASSANDRA-14239 URL: https://issues.apache.org/jira/browse/CASSANDRA-14239 Project: Cassandra Issue Type: Bug Environment: Details of the bootstrapping Node * ProLiant BL460c G7 * 56GB RAM * 2x 146GB 10K HDD (One dedicated for Commitlog, one for Data, Hints and saved_caches) * CentOS 7.4 on SD-Card * /tmp and /var/log on tmpfs * Oracle JDK 1.8.0_151 * Cassandra 3.11.1 Cluster * 10 existing Nodes (Up and Normal) Reporter: Jürgen Albersdorfer Attachments: Objects-by-class.csv, Objects-with-biggest-retained-size.csv, cassandra-env.sh, cassandra.yaml, jvm.options, stack-traces.txt Hi, I face an issue when bootstrapping a Node having less than 100GB RAM on our 10 Node C* 3.11.1 Cluster. During bootstrap, when I watch the cassandra.log I observe a growth in JVM Heap Old Gen which gets not significantly freed up any more. I know that JVM collects on Old Gen only when really needed. I can see collections, but there is always a remainder which seems to grow forever without ever getting freed. After the Node successfully Joined the Cluster, I can remove the extra RAM I have given it for bootstrapping without any further effect. It feels like Cassandra will not forget about every single byte streamed over the Network over time during bootstrapping, - which would be a memory leak and a major problem, too. I was able to produce a HeapDumpOnOutOfMemoryError from a 56GB Node (40 GB assigned JVM Heap). YourKit Profiler shows huge amount of Memory allocated for org.apache.cassandra.db.Memtable (22 GB) org.apache.cassandra.db.rows.BufferCell (19 GB) and java.nio.HeapByteBuffer (11 GB) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
