[jira] [Comment Edited] (CASSANDRA-14655) Upgrade C* to use latest guava (27.0)
[ https://issues.apache.org/jira/browse/CASSANDRA-14655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16939150#comment-16939150 ] Michael Semb Wever edited comment on CASSANDRA-14655 at 9/27/19 6:02 AM: - {quote} bq. Status of Tests (https://circleci.com/workflow-run/6ff402e1-a68b-4092-bc6a-62b10cc36d2d) Thanks for that! It really is crap that dtests on asf jenkins is so flakey and circleci only works with paid accounts and lots of containers. {quote} This looks much better: https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/682/ [~sumanth.pasupuleti], the circleci dtests you linked to include an additional commit [78cf2db|https://github.com/apache/cassandra/commit/78cf2db056312145b77102ee3247d1f688786a0e], is this to be included in the patch? was (Author: mck): {quote} bq. Status of Tests (https://circleci.com/workflow-run/6ff402e1-a68b-4092-bc6a-62b10cc36d2d) Thanks for that! It really is crap that dtests on asf jenkins is so flakey and circleci only works with paid accounts and lots of containers. {quote} This looks much better: https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/682/ > Upgrade C* to use latest guava (27.0) > - > > Key: CASSANDRA-14655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14655 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Low > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > > C* currently uses guava 23.3. This JIRA is about changing C* to use latest > guava (26.0). Originated from a discussion in the mailing list. -- 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-14655) Upgrade C* to use latest guava (27.0)
[ https://issues.apache.org/jira/browse/CASSANDRA-14655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16939150#comment-16939150 ] Michael Semb Wever commented on CASSANDRA-14655: {quote} bq. Status of Tests (https://circleci.com/workflow-run/6ff402e1-a68b-4092-bc6a-62b10cc36d2d) Thanks for that! It really is crap that dtests on asf jenkins is so flakey and circleci only works with paid accounts and lots of containers. {quote} This looks much better: https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/682/ > Upgrade C* to use latest guava (27.0) > - > > Key: CASSANDRA-14655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14655 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Low > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > > C* currently uses guava 23.3. This JIRA is about changing C* to use latest > guava (26.0). Originated from a discussion in the mailing list. -- 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-15319) Add support for network topology and tracing to in-JVM dtests.
[ https://issues.apache.org/jira/browse/CASSANDRA-15319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938947#comment-16938947 ] Dinesh Joshi commented on CASSANDRA-15319: -- [~jmeredithco] the CircleCI links you've posted above 404. Could you please update the links? > Add support for network topology and tracing to in-JVM dtests. > -- > > Key: CASSANDRA-15319 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15319 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > While working on CASSANDRA-15318, testing it properly with an in-JVM test > requires setting up the network topology and tracing requests to check which > nodes performed forwarding. > > In support of testing, make it possible to create in-JVM clusters with nodes > appearing in different datacenter/racks and add support for executing queries > with tracing enabled. -- 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-14328) Invalid metadata has been detected for role
[ https://issues.apache.org/jira/browse/CASSANDRA-14328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938924#comment-16938924 ] Tania S Engel commented on CASSANDRA-14328: --- I also had this issue happen on one of our nodes after it joined the Cassandra cluster. I confirmed by using another role that worked and connecting with cqlsh and running >use system_auth; select * from roles; I could see that in the roles can_login column the role had null (rather than true or false). This is the root cause of your exception. In my case, joining looked as if it worked from our monitoring. nodetool netstats did show Mode: Joining but also showed "not sending any streams". nodetool netstats later was at Mode: normal. {color:#172b4d}nodetool status showed it was an up node. {color}On closer inspection, the join had not streamed. I did have debug.log and it showed the node bootstrapped but it never logged "Creating new streaming plan for bootstrap.." so there was no streaming. Shortly after the bad node bootstrap started, the debug.log on the good existing seed node shows a socket closed and failure to connect. It did reconnect, but perhaps that is the reason the streaming plan never commenced. It is misleading that the bad node then continued to run and appear as if it was bootstrapped. I tried to fix the bad node by running >nodetool repair system_auth but that did not work. I was able to fix the roles with >nodetool --full system_auth. I was able to fix the remaining data by running a full repair on all tables. > Invalid metadata has been detected for role > --- > > Key: CASSANDRA-14328 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14328 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Pranav Jindal >Priority: Normal > > Cassandra Version : 3.10 > One node was replaced and was successfully up and working but CQL-SH fails > with error. > > CQL-SH error: > > {code:java} > Connection error: ('Unable to connect to any servers', {'10.180.0.150': > AuthenticationFailed('Failed to authenticate to 10.180.0.150: Error from > server: code= [Server error] message="java.lang.RuntimeException: Invalid > metadata has been detected for role utorjwcnruzzlzafxffgyqmlvkxiqcgb"',)}) > {code} > > Cassandra server ERROR: > {code:java} > WARN [Native-Transport-Requests-1] 2018-03-20 13:37:17,894 > CassandraRoleManager.java:96 - An invalid value has been detected in the > roles table for role utorjwcnruzzlzafxffgyqmlvkxiqcgb. If you are unable to > login, you may need to disable authentication and confirm that values in that > table are accurate > ERROR [Native-Transport-Requests-1] 2018-03-20 13:37:17,895 Message.java:623 > - Unexpected exception during request; channel = [id: 0xdfc3604f, > L:/10.180.0.150:9042 - R:/10.180.0.150:51668] > java.lang.RuntimeException: Invalid metadata has been detected for role > utorjwcnruzzlzafxffgyqmlvkxiqcgb > at > org.apache.cassandra.auth.CassandraRoleManager$1.apply(CassandraRoleManager.java:99) > ~[apache-cassandra-3.10.jar:3.10] > at > org.apache.cassandra.auth.CassandraRoleManager$1.apply(CassandraRoleManager.java:82) > ~[apache-cassandra-3.10.jar:3.10] > at > org.apache.cassandra.auth.CassandraRoleManager.getRoleFromTable(CassandraRoleManager.java:528) > ~[apache-cassandra-3.10.jar:3.10] > at > org.apache.cassandra.auth.CassandraRoleManager.getRole(CassandraRoleManager.java:503) > ~[apache-cassandra-3.10.jar:3.10] > at > org.apache.cassandra.auth.CassandraRoleManager.canLogin(CassandraRoleManager.java:310) > ~[apache-cassandra-3.10.jar:3.10] > at org.apache.cassandra.service.ClientState.login(ClientState.java:271) > ~[apache-cassandra-3.10.jar:3.10] > at > org.apache.cassandra.transport.messages.AuthResponse.execute(AuthResponse.java:80) > ~[apache-cassandra-3.10.jar:3.10] > at > org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:517) > [apache-cassandra-3.10.jar:3.10] > at > org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410) > [apache-cassandra-3.10.jar:3.10] > at > io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) > [netty-all-4.0.39.Final.jar:4.0.39.Final] > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366) > [netty-all-4.0.39.Final.jar:4.0.39.Final] > at > io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35) > [netty-all-4.0.39.Final.jar:4.0.39.Final] > at > io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:357) > [netty-all-4.0.39.Final.jar:4.0.39.Final] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [na:
[jira] [Commented] (CASSANDRA-15258) Cassandra JDK11 Windows not working
[ https://issues.apache.org/jira/browse/CASSANDRA-15258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938879#comment-16938879 ] A Thomas B commented on CASSANDRA-15258: I think the issue is that the condition on cassandra-env.ps1:403 is miswritten. Just running {code:java} $env:JVM_VERSION=11 $env:JVM_VERSION.CompareTo("1.8.0"){code} returns "1" However, even when commenting out the entire condition: {code:java} if ($env:JVM_VERSION.CompareTo("1.8.0") -eq -1 -or [convert]::ToInt32($env:JVM_PATCH_VERSION) -lt 151) { echo "Cassandra 4.0 requires either Java 8 (update 151 or newer) or Java 11 (or newer). Java $env:JVM_VERSION is not supported." exit }{code} but then it fails with {code:java} [0.014s][error ][logging] Error opening log file 'C:\Users\bugorskia\cassandra/logs/gc.log': No such file or directory [0.015s][error ][logging] Initialization of output 'file=C:\Users\bugorskia\cassandra/logs/gc.log' using options '(null)' failed. Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. {code} so I created a folder called "logs" and then when I run it I get a Java exception: {code:java} Caused by: java.lang.IllegalAccessException: access to public member failed: jdk.internal.ref.Cleaner.clean[Ljava.lang.Object;@4097cac/invokeVirtual, from org.apache.cassandra.io.util.FileUtils (unnamed module @78a773fd) {code} which is a reoccuring theme of Cassandra failing due to the changes from Java 9 modules. > Cassandra JDK11 Windows not working > --- > > Key: CASSANDRA-15258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15258 > Project: Cassandra > Issue Type: Bug > Components: Build, Local/Startup and Shutdown >Reporter: RamyaK >Priority: Urgent > Labels: windows > > I'm trying to setup Cassandra 4.0 trunk with OpenJDK11, but getting below > error on start up. > > + $content = Get-Content "$env:CASSANDRA_CONF\jvm.options" > + ~ > + CategoryInfo : ObjectNotFound: > (D:\Stuff\save\C...onf\jvm.options:String) [Get-Content], > ItemNotFoundException > + FullyQualifiedErrorId : > PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand > Also JVM_VERSION is 11, still its showing as > Cassandra 4.0 requires either Java 8 (update 151 or newer) or Java 11 (or > newer). Java 11 is not supported. > > Please suggest. > -- 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-15329) in-JVM dtest fails on java 11 since system ClassLoader is not a URLClassLoader
[ https://issues.apache.org/jira/browse/CASSANDRA-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938812#comment-16938812 ] David Capwell commented on CASSANDRA-15329: --- Moved patch to GitHub, can be found [here|https://github.com/dcapwell/cassandra/commit/15dc0531631032fe60ff52e416739f4fd3108bb2] > in-JVM dtest fails on java 11 since system ClassLoader is not a URLClassLoader > -- > > Key: CASSANDRA-15329 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15329 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Attachments: CASSANDRA-15329.patch > > > When running the in-JVM dtests on on java 11 they fail while trying to cast > the Versions.class.getClassLoader to URLClassLoader, which is no longer the > default ClassLoader on java 11. -- 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-15286) Refactor CompactionController to allow custom implementations
[ https://issues.apache.org/jira/browse/CASSANDRA-15286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15286: Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Refactor CompactionController to allow custom implementations > - > > Key: CASSANDRA-15286 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15286 > Project: Cassandra > Issue Type: New Feature > Components: Local/Compaction >Reporter: James Berragan >Assignee: Marcus Eriksson >Priority: Normal > Attachments: diff.patch > > > The CompactionController is tied closely with the SSTableReader and reference > tracking. For the purpose of reading and compacting SSTables through > tooling, it would be helpful to have a ‘purging’ compaction controller that > purges all tombstones and allows a user to open a CompactionIterator without > needing to open a bunch of SSTableReaders. -- 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-15263) LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null
[ https://issues.apache.org/jira/browse/CASSANDRA-15263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938558#comment-16938558 ] feroz shaik commented on CASSANDRA-15263: - Dear [~benedict] & Shalom, I have been working on this lately with my engineering and business to move with upgrade task but there is some ambiguity and checking with you if you can assist. We want to be absolutely sure that post upgrade the app continues to work as normal and this can be only answered by providing test results. So i have started testing this on my lab (3 nodes). I was able to reproduce the error with some other table but cant replicate the problem using my table that app uses. I got the exact query patterns from the application team by enabling debug: static String INSERT_SCHEDULED_DELETION_QUERY = "INSERT INTO \"sal_purge\" (key,column1,value) VALUES (?,?,?) USING TIMESTAMP ?;"; static String SELECT_SCHEDULED_DELETION_QUERY = "SELECT column1, value FROM sal_purge where key=? AND column1>=? LIMIT ?;"; static String DELETE_SCHEDULED_DELETION_QUERY = "DELETE FROM \"sal_purge\" USING TIMESTAMP ? WHERE key=? AND column1=?;"; My table structure if you remember: CREATE TABLE "SAL".sal_purge (CREATE TABLE "SAL".sal_purge ( key text, column1 text, column2 text, value text, PRIMARY KEY (key, column1, column2) ) WITH COMPACT STORAGE AND CLUSTERING ORDER BY (column1 ASC, column2 ASC) AND bloom_filter_fp_chance = 0.1 AND caching = '\{"keys":"NONE", "rows_per_partition":"NONE"}' AND comment = 'Holds items to be removed as [shardid][salid][timestamp]. The table records SALIDs to be deleted along with their deletion times (which may be modified)' AND compaction = \{'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'} AND compression = \{'chunk_length_kb': '64', 'sstable_compression': 'org.apache.cassandra.io.compress.SnappyCompressor'} AND dclocal_read_repair_chance = 0.0 AND default_time_to_live = 0 AND gc_grace_seconds = 864000 AND max_index_interval = 2048 AND memtable_flush_period_in_ms = 0 AND min_index_interval = 128 AND read_repair_chance = 0.1 AND speculative_retry = '99.0PERCENTILE'; **I really cannot understand how can this "DELETE FROM \"sal_purge\" USING TIMESTAMP ? WHERE key=? AND column1=?;"; cause a range tombstone..I can only see they can be row deletions isnt it? Now, I tried to insert some data, do some delete, upgrade 1st node while i hit a range select from node 2. I am still unable to replicate the problem. cqlsh> select * from "SAL".sal_purge;cqlsh> select * from "SAL".sal_purge; key | column1 | column2 | value -+--+-+--- 15e | 15e000b946229403b2010e542724cb9af7b939df0c5dd7c5cb680b28881b0905 | null | 1568628121530 15e | 15e000cdbcadb3ea81fe66a2023ccae8dde2cd1c0cdcd25c1b011f5cf4520411 | null | 1568661805145 15e | 15e000d5d1b5ea0e692046b51901d6efe7e1e9beb1f873f5bf62cd9b8b78b6a7 | null | 1568717250061 15e | 15e00205a8a8beafb571f0824022061975f239ffdfec02ae5ec2282d6db76e5b | null | 1568776769724 15e | 15e00322575230ed208cfa101afac66e790582ecd179339e16ee811d41bbac08 | null | 1568755358394 15e | 15e003fb651375db41cbcba3c37f0ab02f9308ba2e3708a5e7be359189583f26 | null | 1568630537539 15e | 15e0049bce42be7e46c7beb6f8f878abd83350556de3864477e94fc33643e818 | null | 1568675019827 15e | 15e005cb926ca2b723260927c3ba9d16ee8092d6adb78d01e129815617e26251 | null | 1568642160143 15e | 15e007f24dd7c31358a23869b06fbc24095e133cdee9cc9e5af88e2a836e9c03 | null | 1568749318982 15e | 15e0088cdb99f399290e531a452e4c2c32d547a852607cb2819ff8fbd565ed53 | null | 1568690314042 (10 rows) cqlsh> DELETE FROM "SAL".sal_purge USING TIMESTAMP 400 where key='15e' and column1='15e0049bce42be7e46c7beb6f8f878abd83350556de3864477e94fc33643e818';cqlsh> DELETE FROM "SAL".sal_purge USING TIMESTAMP 400 where key='15e' and column1='15e0049bce42be7e46c7beb6f8f878abd83350556de3864477e94fc33643e818'; cqlsh> DELETE FROM "SAL".sal_purge USING TIMESTAMP 300 where key='15e' and column1='15e005cb926ca2b723260927c3ba9d16ee8092d6adb78d01e129815617e26251'; cqlsh> DELETE FROM "SAL".sal_purge USING TIMESTAMP 200 where key='15e' and column1='15e007f24dd7c31358a23869b06fbc24095e133cdee9cc9e5af88e2a836e9c03'; cqlsh> cqlsh> cqlsh> select key,column1,writetime(value) from "SAL".sal_purge where key='15e'; key | column1 | writetime(value) -+--+-- 15e | 15e000b946229403b2010e542724cb9af7b939df0c5dd7c5cb680b28881b0905 | 1000 15e | 15e000cdbcadb3ea81fe66a2023ccae8dde2cd1c0cdcd25c1b011f5
[jira] [Commented] (CASSANDRA-15273) cassandra does not start with new systemd version
[ https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938502#comment-16938502 ] Jonas Bartho commented on CASSANDRA-15273: -- [~jolynch] [~jasobrown], can any of you guys assist with this issue? :) > cassandra does not start with new systemd version > - > > Key: CASSANDRA-15273 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15273 > Project: Cassandra > Issue Type: Bug >Reporter: Aleksandr Yatskin >Priority: Urgent > > After update systemd with fixed vulnerability > https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service > does not start correctly. > Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1 > (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm) > --- > systemctl status cassandra > ● cassandra.service - LSB: distributed storage system for structured data > Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled) > Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago > Docs: man:systemd-sysv-generator(8) > Process: 2414 ExecStop=/etc/rc.d/init.d/cassandra stop (code=exited, > status=0/SUCCESS) > Process: 2463 ExecStart=/etc/rc.d/init.d/cassandra start (code=exited, > status=0/SUCCESS) > Main PID: 1884 (code=exited, status=143) > Aug 09 17:20:23 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:23 desktop43.example.com systemd[1]: cassandra.service failed. > Aug 09 17:20:23 desktop43.example.com systemd[1]: Starting LSB: distributed > storage system for structured data... > Aug 09 17:20:23 desktop43.example.com su[2473]: (to cassandra) root on none > Aug 09 17:20:26 desktop43.example.com cassandra[2463]: Starting Cassandra: OK > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: Failed to start LSB: > distributed storage system for structured data. > Aug 09 17:20:26 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:26 desktop43.example.com systemd[1]: cassandra.service failed. -- 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-15273) cassandra does not start with new systemd version
[ https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonas Bartho updated CASSANDRA-15273: - Severity: Critical > cassandra does not start with new systemd version > - > > Key: CASSANDRA-15273 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15273 > Project: Cassandra > Issue Type: Bug >Reporter: Aleksandr Yatskin >Priority: Urgent > > After update systemd with fixed vulnerability > https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service > does not start correctly. > Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1 > (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm) > --- > systemctl status cassandra > ● cassandra.service - LSB: distributed storage system for structured data > Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled) > Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago > Docs: man:systemd-sysv-generator(8) > Process: 2414 ExecStop=/etc/rc.d/init.d/cassandra stop (code=exited, > status=0/SUCCESS) > Process: 2463 ExecStart=/etc/rc.d/init.d/cassandra start (code=exited, > status=0/SUCCESS) > Main PID: 1884 (code=exited, status=143) > Aug 09 17:20:23 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:23 desktop43.example.com systemd[1]: cassandra.service failed. > Aug 09 17:20:23 desktop43.example.com systemd[1]: Starting LSB: distributed > storage system for structured data... > Aug 09 17:20:23 desktop43.example.com su[2473]: (to cassandra) root on none > Aug 09 17:20:26 desktop43.example.com cassandra[2463]: Starting Cassandra: OK > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: Failed to start LSB: > distributed storage system for structured data. > Aug 09 17:20:26 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:26 desktop43.example.com systemd[1]: cassandra.service failed. -- 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-15273) cassandra does not start with new systemd version
[ https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938501#comment-16938501 ] Jonas Bartho commented on CASSANDRA-15273: -- Hi, Is there any update on this? This is still a big issue. We cannot patch our systems due to this bug. :/ > cassandra does not start with new systemd version > - > > Key: CASSANDRA-15273 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15273 > Project: Cassandra > Issue Type: Bug >Reporter: Aleksandr Yatskin >Priority: Normal > > After update systemd with fixed vulnerability > https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service > does not start correctly. > Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1 > (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm) > --- > systemctl status cassandra > ● cassandra.service - LSB: distributed storage system for structured data > Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled) > Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago > Docs: man:systemd-sysv-generator(8) > Process: 2414 ExecStop=/etc/rc.d/init.d/cassandra stop (code=exited, > status=0/SUCCESS) > Process: 2463 ExecStart=/etc/rc.d/init.d/cassandra start (code=exited, > status=0/SUCCESS) > Main PID: 1884 (code=exited, status=143) > Aug 09 17:20:23 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:23 desktop43.example.com systemd[1]: cassandra.service failed. > Aug 09 17:20:23 desktop43.example.com systemd[1]: Starting LSB: distributed > storage system for structured data... > Aug 09 17:20:23 desktop43.example.com su[2473]: (to cassandra) root on none > Aug 09 17:20:26 desktop43.example.com cassandra[2463]: Starting Cassandra: OK > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: Failed to start LSB: > distributed storage system for structured data. > Aug 09 17:20:26 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:26 desktop43.example.com systemd[1]: cassandra.service failed. -- 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-14655) Upgrade C* to use latest guava (27.0)
[ https://issues.apache.org/jira/browse/CASSANDRA-14655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-14655: --- Reviewers: Michael Semb Wever (was: mck) > Upgrade C* to use latest guava (27.0) > - > > Key: CASSANDRA-14655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14655 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Low > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > > C* currently uses guava 23.3. This JIRA is about changing C* to use latest > guava (26.0). Originated from a discussion in the mailing list. -- 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-14655) Upgrade C* to use latest guava (27.0)
[ https://issues.apache.org/jira/browse/CASSANDRA-14655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938464#comment-16938464 ] Michael Semb Wever commented on CASSANDRA-14655: bq. Made changes to remove nativePort parameter from NativeSSTableLoaderClient's constructor. LoaderOptions.Builder.build() already puts nativePort into the hosts (line 152), so I didn't have to make any changes there - please let me know in case I missed out anything here. Line 152 is only adding the default nativePort onto the {{hostArgs}} array, but that array is not parsed anymore (it's only part of a deprecated setter). The newer {{hosts}} array, which accepts custom ports, does add the default nativePort if need be, ref line 376. But a problem here is that the default {{nativePort}} is not parsed until later on, ref line 432. bq. Status of Tests (https://circleci.com/workflow-run/6ff402e1-a68b-4092-bc6a-62b10cc36d2d) Thanks for that! It really is crap that travis is so flakey and circleci only works with paid accounts and lots of containers. > Upgrade C* to use latest guava (27.0) > - > > Key: CASSANDRA-14655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14655 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Low > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > > C* currently uses guava 23.3. This JIRA is about changing C* to use latest > guava (26.0). Originated from a discussion in the mailing list. -- 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-14655) Upgrade C* to use latest guava (27.0)
[ https://issues.apache.org/jira/browse/CASSANDRA-14655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938464#comment-16938464 ] Michael Semb Wever edited comment on CASSANDRA-14655 at 9/26/19 10:12 AM: -- bq. Made changes to remove nativePort parameter from NativeSSTableLoaderClient's constructor. LoaderOptions.Builder.build() already puts nativePort into the hosts (line 152), so I didn't have to make any changes there - please let me know in case I missed out anything here. Line 152 is only adding the default nativePort onto the {{hostArgs}} array, but that array is not parsed anymore (it's only part of a deprecated setter). The newer {{hosts}} array, which accepts custom ports, does add the default nativePort if need be, ref line 376. But a problem here is that the default {{nativePort}} is not parsed until later on, ref line 432. bq. Status of Tests (https://circleci.com/workflow-run/6ff402e1-a68b-4092-bc6a-62b10cc36d2d) Thanks for that! It really is crap that dtests on asf jenkins is so flakey and circleci only works with paid accounts and lots of containers. was (Author: mck): bq. Made changes to remove nativePort parameter from NativeSSTableLoaderClient's constructor. LoaderOptions.Builder.build() already puts nativePort into the hosts (line 152), so I didn't have to make any changes there - please let me know in case I missed out anything here. Line 152 is only adding the default nativePort onto the {{hostArgs}} array, but that array is not parsed anymore (it's only part of a deprecated setter). The newer {{hosts}} array, which accepts custom ports, does add the default nativePort if need be, ref line 376. But a problem here is that the default {{nativePort}} is not parsed until later on, ref line 432. bq. Status of Tests (https://circleci.com/workflow-run/6ff402e1-a68b-4092-bc6a-62b10cc36d2d) Thanks for that! It really is crap that travis is so flakey and circleci only works with paid accounts and lots of containers. > Upgrade C* to use latest guava (27.0) > - > > Key: CASSANDRA-14655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14655 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Low > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > > C* currently uses guava 23.3. This JIRA is about changing C* to use latest > guava (26.0). Originated from a discussion in the mailing list. -- 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-14655) Upgrade C* to use latest guava (27.0)
[ https://issues.apache.org/jira/browse/CASSANDRA-14655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938410#comment-16938410 ] Sumanth Pasupuleti commented on CASSANDRA-14655: [~michaelsembwever] Incorporated your feedback and here is the consolidated commit : [https://github.com/sumanth-pasupuleti/cassandra/commit/0798bfe9b54b0c1cd49b41beffb9f09c1c5c8305]. Diff from trunk: [https://github.com/apache/cassandra/compare/trunk...sumanth-pasupuleti:guava_27_trunk?expand=1] {quote}i think the "cassandra-driver-core" lines in the build.xml can now be updated and uncommented, see "UPDATE AND UNCOMMENT" sections, {quote} Fixed {quote}for LoaderOptions and CqlConfigHelper are there docs we want to update? (ie to use `host:port`? {quote} Could not find existing documentation around these tools. {quote}is the nativePort parameter needed anymore in NativeSSTableLoaderClient's constructor? the caller can put that into the hosts parameter, (and then in the init(..) method (line 73) the cluster builder called instead with addContactPointsWithPorts(hosts) {quote} Made changes to remove nativePort parameter from NativeSSTableLoaderClient's constructor. LoaderOptions.Builder.build() already puts nativePort into the hosts (line 152), so I didn't have to make any changes there - please let me know in case I missed out anything here. Status of Tests ([https://circleci.com/workflow-run/6ff402e1-a68b-4092-bc6a-62b10cc36d2d]) * Passing UTs and jvm dtests * DTests without vnodes - 1 failure (cql_test.TestCQLSlowQuery) * DTests with vnodes - 1 failure (repair_tests.incremental_repair_test.TestIncRepair) > Upgrade C* to use latest guava (27.0) > - > > Key: CASSANDRA-14655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14655 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Low > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > > C* currently uses guava 23.3. This JIRA is about changing C* to use latest > guava (26.0). Originated from a discussion in the mailing list. -- 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