[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=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=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=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:1.8.0_121]
> at
[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=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=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=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 |
15e000cdbcadb3ea81fe66a2023ccae8dde2cd1c0cdcd25c1b011f5cf4520411 |
[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=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=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=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=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=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
