[jira] [Commented] (CASSANDRA-15079) Secondary Index not returning complete data
[ https://issues.apache.org/jira/browse/CASSANDRA-15079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912741#comment-16912741 ] Nirmal Singh KPS commented on CASSANDRA-15079: -- Need to understand the compaction strategy how its defined and is that health wise good for that table? > Secondary Index not returning complete data > --- > > Key: CASSANDRA-15079 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15079 > Project: Cassandra > Issue Type: Bug > Components: Feature/2i Index >Reporter: Chakravarthi Manepalli >Priority: High > Labels: performance > Attachments: missing_data_cassandra.png > > > The result response when we query using a secondary index does not give > complete data. Some of the rows are missing. After dropping the index and > creating it again, the query worked fine. > Observation: The missed data entry is last edited 20 days ago. > I suspect may be the data which is old is not getting indexed properly > through secondary indexes. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15044) LIST ALL; crashes with ServerError: java.lang.IllegalArgumentException: Name EESBKEYSPACE is not valid for any resource type
[
https://issues.apache.org/jira/browse/CASSANDRA-15044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912738#comment-16912738
]
Nirmal Singh KPS commented on CASSANDRA-15044:
--
To me its some kind of temporary HTTP issue ,. which cannot be reproduced .
Kindly close this ticket.
> LIST ALL; crashes with ServerError: java.lang.IllegalArgumentException: Name
> EESBKEYSPACE is not valid for any resource type
>
>
> Key: CASSANDRA-15044
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15044
> Project: Cassandra
> Issue Type: Bug
> Environment: [cqlsh 5.0.1 | Cassandra 3.11.2 | CQL spec 3.4.4 |
> Native protocol v4]
> Linux eu50mqvt006.area1.eurofins.local 3.10.0-693.17.1.el7.x86_64 #1 SMP Sun
> Jan 14 10:36:03 EST 2018 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Petr Kuzel
>Priority: Urgent
>
> Following crashes:
>
> *{{$CASSANDRA_HOME/bin/cqlsh -u admin -e "LIST ALL;"
> $HOSTNAME}}{{:1:ServerError: java.lang.IllegalArgumentException: Name
> EESBKEYSPACE is not valid for any resource type}}*
>
> While following passes:
> {{admin@cqlsh> list all of cassandra;}}
> {{role | username | resource | permission}}
> {{---+---+-+}}
> {{ cassandra | cassandra | | CREATE}}
> {{ cassandra | cassandra | | ALTER}}
> {{ cassandra | cassandra | | DROP}}
> {{ cassandra | cassandra | | SELECT}}
> {{ cassandra | cassandra | | MODIFY}}
> {{ cassandra | cassandra | | AUTHORIZE}}
> {{ cassandra | cassandra | |
> ALTER}}
> {{}}
>
> Apparently it depends on user because:
> {{admin@cqlsh> list all of admin;}}
> {{ServerError: java.lang.IllegalArgumentException: Name EESBKEYSPACE is not
> valid for any resource type}}
>
> When trying from the keyspace listing angle getting:
>
> {{admin@cqlsh> list all on eesbkeyspace.eesbmessage_monitoring;}}
> {{InvalidRequest: Error from server: code=2200 [Invalid query]
> message=" doesn't exist"}}
> Warning: This is strange as it comes from above list. Something is
> inconsistent/stale and might be related to the ServerError.
>
> Anyway let use existing table for the same:
> {{admin@cqlsh> list all on eesbkeyspace.message_monitoring;}}
> {{role | username | resource | permission}}
> {{---+---+-+}}
> {{ admin | admin | | CREATE}}
> {{ admin | admin | | ALTER}}
> {{ admin | admin | | DROP}}
> {{ admin | admin | | SELECT}}
> {{ admin | admin | | MODIFY}}
> {{ admin | admin | | AUTHORIZE}}
> {{ admin | admin | | ALTER}}
> {{ admin | admin | | DROP}}
> {{ admin | admin | | SELECT}}
> {{ admin | admin | | MODIFY}}
> {{ admin | admin | | AUTHORIZE}}
> {{ cassandra | cassandra | | CREATE}}
> {{ cassandra | cassandra | | ALTER}}
> {{ cassandra | cassandra | | DROP}}
> {{ cassandra | cassandra | | SELECT}}
> {{ cassandra | cassandra | | MODIFY}}
> {{ cassandra | cassandra | | AUTHORIZE}}
> {{ cassandra | cassandra | | ALTER}}
> {{ cassandra | cassandra | | DROP}}
> {{ cassandra | cassandra | | SELECT}}
> {{ cassandra | cassandra | | MODIFY}}
> {{ cassandra | cassandra | |
> AUTHORIZE}}
>
> That works.
>
> The keyspace itself:
> {{admin@cqlsh> describe keyspace eesbkeyspace;}}
> {{CREATE KEYSPACE eesbkeyspace WITH replication = \{'class':
> 'NetworkTopologyStrategy', ...} AND durable_writes = true;}}
> {{CREATE TABLE eesbkeyspace.coupa_monitoring (}}
> {{ ...}}
> {{}}{{CREATE TABLE eesbkeyspace.test_monitoring (}}
> {{...}}
> {{CREATE TABLE eesbkeyspace.genomics_monitoring (}}
> {{...}}
> {{CREATE TABLE eesbkeyspace.statistics (}}
> {{...}}
> {{CREATE TABLE eesbkeyspace.message_monitoring (}}
> {{...}}
> {{CREATE TABLE eesbkeyspace.genomics_monitoring_statistics (}}
> {{...}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11748) Schema version mismatch may leads to Casandra OOM at bootstrap during a rolling upgrade process
[
https://issues.apache.org/jira/browse/CASSANDRA-11748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912736#comment-16912736
]
Nirmal Singh KPS commented on CASSANDRA-11748:
--
I dont think this can be fixed in code , it should be gracefully handled from
the admin stuff.
Large or Small cluster , unless its a critical patch we dont need any RESTART
{color:#FF}Answering on ur steps followed {color}
# Update schema on a node, and wait until all nodes to be in schema version
agreemnt - via nodetool describeclulster *(Continue with this step)*
2. Restart a Cassandra node *(Why we wanna do this ?)*
3. After restart, there is a chance that the the restarted node has different
schema version. *(Why we wanna do this ?)***
4. All nodes in cluster start to rapidly exchange schema information, and any
of node could run into OOM.
> Schema version mismatch may leads to Casandra OOM at bootstrap during a
> rolling upgrade process
> ---
>
> Key: CASSANDRA-11748
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11748
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
> Environment: Rolling upgrade process from 1.2.19 to 2.0.17.
> CentOS 6.6
> Occurred in different C* node of different scale of deployment (2G ~ 5G)
>Reporter: Michael Fong
>Assignee: Nirmal Singh KPS
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We have observed multiple times when a multi-node C* (v2.0.17) cluster ran
> into OOM in bootstrap during a rolling upgrade process from 1.2.19 to 2.0.17.
> Here is the simple guideline of our rolling upgrade process
> 1. Update schema on a node, and wait until all nodes to be in schema version
> agreemnt - via nodetool describeclulster
> 2. Restart a Cassandra node
> 3. After restart, there is a chance that the the restarted node has different
> schema version.
> 4. All nodes in cluster start to rapidly exchange schema information, and any
> of node could run into OOM.
> The following is the system.log that occur in one of our 2-node cluster test
> bed
> --
> Before rebooting node 2:
> Node 1: DEBUG [MigrationStage:1] 2016-04-19 11:09:42,326
> MigrationManager.java (line 328) Gossiping my schema version
> 4cb463f8-5376-3baf-8e88-a5cc6a94f58f
> Node 2: DEBUG [MigrationStage:1] 2016-04-19 11:09:42,122
> MigrationManager.java (line 328) Gossiping my schema version
> 4cb463f8-5376-3baf-8e88-a5cc6a94f58f
> After rebooting node 2,
> Node 2: DEBUG [main] 2016-04-19 11:18:18,016 MigrationManager.java (line 328)
> Gossiping my schema version f5270873-ba1f-39c7-ab2e-a86db868b09b
> The node2 keeps submitting the migration task over 100+ times to the other
> node.
> INFO [GossipStage:1] 2016-04-19 11:18:18,261 Gossiper.java (line 1011) Node
> /192.168.88.33 has restarted, now UP
> INFO [GossipStage:1] 2016-04-19 11:18:18,262 TokenMetadata.java (line 414)
> Updating topology for /192.168.88.33
> ...
> DEBUG [GossipStage:1] 2016-04-19 11:18:18,265 MigrationManager.java (line
> 102) Submitting migration task for /192.168.88.33
> ... ( over 100+ times)
> --
> On the otherhand, Node 1 keeps updating its gossip information, followed by
> receiving and submitting migrationTask afterwards:
> INFO [RequestResponseStage:3] 2016-04-19 11:18:18,333 Gossiper.java (line
> 978) InetAddress /192.168.88.34 is now UP
> ...
> DEBUG [MigrationStage:1] 2016-04-19 11:18:18,496
> MigrationRequestVerbHandler.java (line 41) Received migration request from
> /192.168.88.34.
> …… ( over 100+ times)
> DEBUG [OptionalTasks:1] 2016-04-19 11:19:18,337 MigrationManager.java (line
> 127) submitting migration task for /192.168.88.34
> . (over 50+ times)
> On the side note, we have over 200+ column families defined in Cassandra
> database, which may related to this amount of rpc traffic.
> P.S.2 The over requested schema migration task will eventually have
> InternalResponseStage performing schema merge operation. Since this operation
> requires a compaction for each merge and is much slower to consume. Thus, the
> back-pressure of incoming schema migration content objects consumes all of
> the heap space and ultimately ends up OOM!
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12662) OOM when using SASI index
[ https://issues.apache.org/jira/browse/CASSANDRA-12662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912734#comment-16912734 ] Nirmal Singh KPS commented on CASSANDRA-12662: -- Potentially indexes gonna involve more memory in a distributed data base like Cassandra. It can index tables with less volume but not of big sizes. So creating indexes for big table should be questioned first , followed by if badly needed we can get typically faster machines with more RAM and force compaction to run faster on tables that needs to be indexed > OOM when using SASI index > - > > Key: CASSANDRA-12662 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12662 > Project: Cassandra > Issue Type: Bug > Environment: Linux, 4 CPU cores, 16Gb RAM, Cassandra process utilizes > ~8Gb, of which ~4Gb is Java heap >Reporter: Maxim Podkolzine >Priority: Urgent > Fix For: 3.11.x > > Attachments: memory-dump.png > > > 2.8Gb of the heap is taken by the index data, pending for flush (see the > screenshot). As a result the node fails with OOM. > Questions: > - Why can't Cassandra keep up with the inserted data and flush it? > - What resources/configuration should be changed to improve the performance? -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-11748) Schema version mismatch may leads to Casandra OOM at bootstrap during a rolling upgrade process
[ https://issues.apache.org/jira/browse/CASSANDRA-11748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nirmal Singh KPS reassigned CASSANDRA-11748: Assignee: Nirmal Singh KPS (was: s) > Schema version mismatch may leads to Casandra OOM at bootstrap during a > rolling upgrade process > --- > > Key: CASSANDRA-11748 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11748 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core > Environment: Rolling upgrade process from 1.2.19 to 2.0.17. > CentOS 6.6 > Occurred in different C* node of different scale of deployment (2G ~ 5G) >Reporter: Michael Fong >Assignee: Nirmal Singh KPS >Priority: Urgent > Fix For: 3.0.x, 3.11.x, 4.x > > > We have observed multiple times when a multi-node C* (v2.0.17) cluster ran > into OOM in bootstrap during a rolling upgrade process from 1.2.19 to 2.0.17. > Here is the simple guideline of our rolling upgrade process > 1. Update schema on a node, and wait until all nodes to be in schema version > agreemnt - via nodetool describeclulster > 2. Restart a Cassandra node > 3. After restart, there is a chance that the the restarted node has different > schema version. > 4. All nodes in cluster start to rapidly exchange schema information, and any > of node could run into OOM. > The following is the system.log that occur in one of our 2-node cluster test > bed > -- > Before rebooting node 2: > Node 1: DEBUG [MigrationStage:1] 2016-04-19 11:09:42,326 > MigrationManager.java (line 328) Gossiping my schema version > 4cb463f8-5376-3baf-8e88-a5cc6a94f58f > Node 2: DEBUG [MigrationStage:1] 2016-04-19 11:09:42,122 > MigrationManager.java (line 328) Gossiping my schema version > 4cb463f8-5376-3baf-8e88-a5cc6a94f58f > After rebooting node 2, > Node 2: DEBUG [main] 2016-04-19 11:18:18,016 MigrationManager.java (line 328) > Gossiping my schema version f5270873-ba1f-39c7-ab2e-a86db868b09b > The node2 keeps submitting the migration task over 100+ times to the other > node. > INFO [GossipStage:1] 2016-04-19 11:18:18,261 Gossiper.java (line 1011) Node > /192.168.88.33 has restarted, now UP > INFO [GossipStage:1] 2016-04-19 11:18:18,262 TokenMetadata.java (line 414) > Updating topology for /192.168.88.33 > ... > DEBUG [GossipStage:1] 2016-04-19 11:18:18,265 MigrationManager.java (line > 102) Submitting migration task for /192.168.88.33 > ... ( over 100+ times) > -- > On the otherhand, Node 1 keeps updating its gossip information, followed by > receiving and submitting migrationTask afterwards: > INFO [RequestResponseStage:3] 2016-04-19 11:18:18,333 Gossiper.java (line > 978) InetAddress /192.168.88.34 is now UP > ... > DEBUG [MigrationStage:1] 2016-04-19 11:18:18,496 > MigrationRequestVerbHandler.java (line 41) Received migration request from > /192.168.88.34. > …… ( over 100+ times) > DEBUG [OptionalTasks:1] 2016-04-19 11:19:18,337 MigrationManager.java (line > 127) submitting migration task for /192.168.88.34 > . (over 50+ times) > On the side note, we have over 200+ column families defined in Cassandra > database, which may related to this amount of rpc traffic. > P.S.2 The over requested schema migration task will eventually have > InternalResponseStage performing schema merge operation. Since this operation > requires a compaction for each merge and is much slower to consume. Thus, the > back-pressure of incoming schema migration content objects consumes all of > the heap space and ultimately ends up OOM! -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-11748) Schema version mismatch may leads to Casandra OOM at bootstrap during a rolling upgrade process
[ https://issues.apache.org/jira/browse/CASSANDRA-11748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nirmal Singh KPS reassigned CASSANDRA-11748: Assignee: s (was: Matt Byrd) > Schema version mismatch may leads to Casandra OOM at bootstrap during a > rolling upgrade process > --- > > Key: CASSANDRA-11748 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11748 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core > Environment: Rolling upgrade process from 1.2.19 to 2.0.17. > CentOS 6.6 > Occurred in different C* node of different scale of deployment (2G ~ 5G) >Reporter: Michael Fong >Assignee: s >Priority: Urgent > Fix For: 3.0.x, 3.11.x, 4.x > > > We have observed multiple times when a multi-node C* (v2.0.17) cluster ran > into OOM in bootstrap during a rolling upgrade process from 1.2.19 to 2.0.17. > Here is the simple guideline of our rolling upgrade process > 1. Update schema on a node, and wait until all nodes to be in schema version > agreemnt - via nodetool describeclulster > 2. Restart a Cassandra node > 3. After restart, there is a chance that the the restarted node has different > schema version. > 4. All nodes in cluster start to rapidly exchange schema information, and any > of node could run into OOM. > The following is the system.log that occur in one of our 2-node cluster test > bed > -- > Before rebooting node 2: > Node 1: DEBUG [MigrationStage:1] 2016-04-19 11:09:42,326 > MigrationManager.java (line 328) Gossiping my schema version > 4cb463f8-5376-3baf-8e88-a5cc6a94f58f > Node 2: DEBUG [MigrationStage:1] 2016-04-19 11:09:42,122 > MigrationManager.java (line 328) Gossiping my schema version > 4cb463f8-5376-3baf-8e88-a5cc6a94f58f > After rebooting node 2, > Node 2: DEBUG [main] 2016-04-19 11:18:18,016 MigrationManager.java (line 328) > Gossiping my schema version f5270873-ba1f-39c7-ab2e-a86db868b09b > The node2 keeps submitting the migration task over 100+ times to the other > node. > INFO [GossipStage:1] 2016-04-19 11:18:18,261 Gossiper.java (line 1011) Node > /192.168.88.33 has restarted, now UP > INFO [GossipStage:1] 2016-04-19 11:18:18,262 TokenMetadata.java (line 414) > Updating topology for /192.168.88.33 > ... > DEBUG [GossipStage:1] 2016-04-19 11:18:18,265 MigrationManager.java (line > 102) Submitting migration task for /192.168.88.33 > ... ( over 100+ times) > -- > On the otherhand, Node 1 keeps updating its gossip information, followed by > receiving and submitting migrationTask afterwards: > INFO [RequestResponseStage:3] 2016-04-19 11:18:18,333 Gossiper.java (line > 978) InetAddress /192.168.88.34 is now UP > ... > DEBUG [MigrationStage:1] 2016-04-19 11:18:18,496 > MigrationRequestVerbHandler.java (line 41) Received migration request from > /192.168.88.34. > …… ( over 100+ times) > DEBUG [OptionalTasks:1] 2016-04-19 11:19:18,337 MigrationManager.java (line > 127) submitting migration task for /192.168.88.34 > . (over 50+ times) > On the side note, we have over 200+ column families defined in Cassandra > database, which may related to this amount of rpc traffic. > P.S.2 The over requested schema migration task will eventually have > InternalResponseStage performing schema merge operation. Since this operation > requires a compaction for each merge and is much slower to consume. Thus, the > back-pressure of incoming schema migration content objects consumes all of > the heap space and ultimately ends up OOM! -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15172) LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912704#comment-16912704
]
mck commented on CASSANDRA-15172:
-
||branch||circleci||asf jenkins testall||asf jenkins dtests||
|[15172-3.0|https://github.com/apache/cassandra/compare/trunk...belliottsmith:15172-3.0]|[circleci|https://circleci.com/gh/belliottsmith/workflows/cassandra/tree/15172-3.0]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/44//badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/44/]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/679//badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/679]|
> LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException
>
>
> Key: CASSANDRA-15172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15172
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Shalom
>Assignee: Benedict
>Priority: Normal
>
> Hi All,
> This is the first time I open an issue, so apologies if I'm not following the
> rules properly.
>
> After upgrading a node from version 2.1.21 to 3.11.4, we've started seeing a
> lot of AbstractLocalAwareExecutorService exceptions. This happened right
> after the node successfully started up with the new 3.11.4 binaries.
> {noformat}
> INFO [main] 2019-06-05 04:41:37,730 Gossiper.java:1715 - No gossip backlog;
> proceeding
> INFO [main] 2019-06-05 04:41:38,036 NativeTransportService.java:70 - Netty
> using native Epoll event loop
> INFO [main] 2019-06-05 04:41:38,117 Server.java:155 - Using Netty Version:
> [netty-buffer=netty-buffer-4.0.44.Final.452812a,
> netty-codec=netty-codec-4.0.44.Final.452812a,
> netty-codec-haproxy=netty-codec-haproxy-4.0.44.Final.452812a,
> netty-codec-http=netty-codec-http-4.0.44.Final.452812a,
> netty-codec-socks=netty-codec-socks-4.0.44.Final.452812a,
> netty-common=netty-common-4.0.44.Final.452812a,
> netty-handler=netty-handler-4.0.44.Final.452812a,
> netty-tcnative=netty-tcnative-1.1.33.Fork26.142ecbb,
> netty-transport=netty-transport-4.0.44.Final.452812a,
> netty-transport-native-epoll=netty-transport-native-epoll-4.0.44.Final.452812a,
> netty-transport-rxtx=netty-transport-rxtx-4.0.44.Final.452812a,
> netty-transport-sctp=netty-transport-sctp-4.0.44.Final.452812a,
> netty-transport-udt=netty-transport-udt-4.0.44.Final.452812a]
> INFO [main] 2019-06-05 04:41:38,118 Server.java:156 - Starting listening for
> CQL clients on /0.0.0.0:9042 (unencrypted)...
> INFO [main] 2019-06-05 04:41:38,179 CassandraDaemon.java:556 - Not starting
> RPC server as requested. Use JMX (StorageService->startRPCServer()) or
> nodetool (enablethrift) to start it
> INFO [Native-Transport-Requests-21] 2019-06-05 04:41:39,145
> AuthCache.java:161 - (Re)initializing PermissionsCache (validity
> period/update interval/max entries) (2000/2000/1000)
> INFO [OptionalTasks:1] 2019-06-05 04:41:39,729 CassandraAuthorizer.java:409
> - Converting legacy permissions data
> INFO [HANDSHAKE-/10.10.10.8] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.8
> INFO [HANDSHAKE-/10.10.10.9] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.9
> INFO [HANDSHAKE-dc1_02/10.10.10.6] 2019-06-05 04:41:39,809
> OutboundTcpConnection.java:561 - Handshaking version with dc1_02/10.10.10.6
> WARN [ReadStage-2] 2019-06-05 04:41:39,857
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-2,5,main]: {}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.apache.cassandra.db.AbstractBufferClusteringPrefix.get(AbstractBufferClusteringPrefix.java:55)
> at
> org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSizeCompound(LegacyLayout.java:2545)
> at
> org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSize(LegacyLayout.java:2522)
> at
> org.apache.cassandra.db.LegacyLayout.serializedSizeAsLegacyPartition(LegacyLayout.java:565)
> at
> org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:446)
> at
> org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:352)
> at
> org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:171)
> at
> org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:77)
> at
> org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:802)
> at
>
[jira] [Commented] (CASSANDRA-15186) InternodeOutboundMetrics overloaded bytes/count mixup
[ https://issues.apache.org/jira/browse/CASSANDRA-15186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912693#comment-16912693 ] Josh Turner commented on CASSANDRA-15186: - Attached a simple patch correcting this mixup. > InternodeOutboundMetrics overloaded bytes/count mixup > - > > Key: CASSANDRA-15186 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15186 > Project: Cassandra > Issue Type: Bug > Components: Observability/Metrics >Reporter: Marcus Olsson >Priority: Normal > Attachments: 15186-trunk.txt > > > In > [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/metrics/InternodeOutboundMetrics.java] > there is a small mixup between overloaded count and bytes, in > [LargeMessageDroppedTasksDueToOverload|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/metrics/InternodeOutboundMetrics.java#L129] > and > [UrgentMessageDroppedTasksDueToOverload|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/metrics/InternodeOutboundMetrics.java#L151]. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15186) InternodeOutboundMetrics overloaded bytes/count mixup
[ https://issues.apache.org/jira/browse/CASSANDRA-15186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Turner updated CASSANDRA-15186: Attachment: 15186-trunk.txt > InternodeOutboundMetrics overloaded bytes/count mixup > - > > Key: CASSANDRA-15186 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15186 > Project: Cassandra > Issue Type: Bug > Components: Observability/Metrics >Reporter: Marcus Olsson >Priority: Normal > Attachments: 15186-trunk.txt > > > In > [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/metrics/InternodeOutboundMetrics.java] > there is a small mixup between overloaded count and bytes, in > [LargeMessageDroppedTasksDueToOverload|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/metrics/InternodeOutboundMetrics.java#L129] > and > [UrgentMessageDroppedTasksDueToOverload|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/metrics/InternodeOutboundMetrics.java#L151]. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15272) Enhance & reenable RepairTest
[ https://issues.apache.org/jira/browse/CASSANDRA-15272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912466#comment-16912466 ] Jon Meredith commented on CASSANDRA-15272: -- CASSANDRA-15170 changes are now merged, you should be good to commit when ready. > Enhance & reenable RepairTest > - > > Key: CASSANDRA-15272 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15272 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > > Currently the In-JVM RepairTest is not enabled on trunk (See for more info: > CASSANDRA-13938). This patch enables the In JVM RepairTest. It adds a new > test that tests the compression=off path for SSTables. It will help catch any > regressions in repair on this path. This does not fix the issue with the > compressed sstable streaming (CASSANDRA-13938). That should be addressed in > the original ticket. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15172) LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mck updated CASSANDRA-15172:
Reviewers: mck, mck (was: mck)
mck, mck
Status: Review In Progress (was: Patch Available)
> LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException
>
>
> Key: CASSANDRA-15172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15172
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Shalom
>Assignee: Benedict
>Priority: Normal
>
> Hi All,
> This is the first time I open an issue, so apologies if I'm not following the
> rules properly.
>
> After upgrading a node from version 2.1.21 to 3.11.4, we've started seeing a
> lot of AbstractLocalAwareExecutorService exceptions. This happened right
> after the node successfully started up with the new 3.11.4 binaries.
> {noformat}
> INFO [main] 2019-06-05 04:41:37,730 Gossiper.java:1715 - No gossip backlog;
> proceeding
> INFO [main] 2019-06-05 04:41:38,036 NativeTransportService.java:70 - Netty
> using native Epoll event loop
> INFO [main] 2019-06-05 04:41:38,117 Server.java:155 - Using Netty Version:
> [netty-buffer=netty-buffer-4.0.44.Final.452812a,
> netty-codec=netty-codec-4.0.44.Final.452812a,
> netty-codec-haproxy=netty-codec-haproxy-4.0.44.Final.452812a,
> netty-codec-http=netty-codec-http-4.0.44.Final.452812a,
> netty-codec-socks=netty-codec-socks-4.0.44.Final.452812a,
> netty-common=netty-common-4.0.44.Final.452812a,
> netty-handler=netty-handler-4.0.44.Final.452812a,
> netty-tcnative=netty-tcnative-1.1.33.Fork26.142ecbb,
> netty-transport=netty-transport-4.0.44.Final.452812a,
> netty-transport-native-epoll=netty-transport-native-epoll-4.0.44.Final.452812a,
> netty-transport-rxtx=netty-transport-rxtx-4.0.44.Final.452812a,
> netty-transport-sctp=netty-transport-sctp-4.0.44.Final.452812a,
> netty-transport-udt=netty-transport-udt-4.0.44.Final.452812a]
> INFO [main] 2019-06-05 04:41:38,118 Server.java:156 - Starting listening for
> CQL clients on /0.0.0.0:9042 (unencrypted)...
> INFO [main] 2019-06-05 04:41:38,179 CassandraDaemon.java:556 - Not starting
> RPC server as requested. Use JMX (StorageService->startRPCServer()) or
> nodetool (enablethrift) to start it
> INFO [Native-Transport-Requests-21] 2019-06-05 04:41:39,145
> AuthCache.java:161 - (Re)initializing PermissionsCache (validity
> period/update interval/max entries) (2000/2000/1000)
> INFO [OptionalTasks:1] 2019-06-05 04:41:39,729 CassandraAuthorizer.java:409
> - Converting legacy permissions data
> INFO [HANDSHAKE-/10.10.10.8] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.8
> INFO [HANDSHAKE-/10.10.10.9] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.9
> INFO [HANDSHAKE-dc1_02/10.10.10.6] 2019-06-05 04:41:39,809
> OutboundTcpConnection.java:561 - Handshaking version with dc1_02/10.10.10.6
> WARN [ReadStage-2] 2019-06-05 04:41:39,857
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-2,5,main]: {}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.apache.cassandra.db.AbstractBufferClusteringPrefix.get(AbstractBufferClusteringPrefix.java:55)
> at
> org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSizeCompound(LegacyLayout.java:2545)
> at
> org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSize(LegacyLayout.java:2522)
> at
> org.apache.cassandra.db.LegacyLayout.serializedSizeAsLegacyPartition(LegacyLayout.java:565)
> at
> org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:446)
> at
> org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:352)
> at
> org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:171)
> at
> org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:77)
> at
> org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:802)
> at
> org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:953)
> at
> org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:929)
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:62)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>
[jira] [Commented] (CASSANDRA-15172) LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912357#comment-16912357
]
mck commented on CASSANDRA-15172:
-
[~benedict], we've seen this in the wild as well, with an upgrade from 2.2.14
to 3.11.4.
I am jumping in to test and review it.
> LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException
>
>
> Key: CASSANDRA-15172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15172
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Shalom
>Assignee: Benedict
>Priority: Normal
>
> Hi All,
> This is the first time I open an issue, so apologies if I'm not following the
> rules properly.
>
> After upgrading a node from version 2.1.21 to 3.11.4, we've started seeing a
> lot of AbstractLocalAwareExecutorService exceptions. This happened right
> after the node successfully started up with the new 3.11.4 binaries.
> {noformat}
> INFO [main] 2019-06-05 04:41:37,730 Gossiper.java:1715 - No gossip backlog;
> proceeding
> INFO [main] 2019-06-05 04:41:38,036 NativeTransportService.java:70 - Netty
> using native Epoll event loop
> INFO [main] 2019-06-05 04:41:38,117 Server.java:155 - Using Netty Version:
> [netty-buffer=netty-buffer-4.0.44.Final.452812a,
> netty-codec=netty-codec-4.0.44.Final.452812a,
> netty-codec-haproxy=netty-codec-haproxy-4.0.44.Final.452812a,
> netty-codec-http=netty-codec-http-4.0.44.Final.452812a,
> netty-codec-socks=netty-codec-socks-4.0.44.Final.452812a,
> netty-common=netty-common-4.0.44.Final.452812a,
> netty-handler=netty-handler-4.0.44.Final.452812a,
> netty-tcnative=netty-tcnative-1.1.33.Fork26.142ecbb,
> netty-transport=netty-transport-4.0.44.Final.452812a,
> netty-transport-native-epoll=netty-transport-native-epoll-4.0.44.Final.452812a,
> netty-transport-rxtx=netty-transport-rxtx-4.0.44.Final.452812a,
> netty-transport-sctp=netty-transport-sctp-4.0.44.Final.452812a,
> netty-transport-udt=netty-transport-udt-4.0.44.Final.452812a]
> INFO [main] 2019-06-05 04:41:38,118 Server.java:156 - Starting listening for
> CQL clients on /0.0.0.0:9042 (unencrypted)...
> INFO [main] 2019-06-05 04:41:38,179 CassandraDaemon.java:556 - Not starting
> RPC server as requested. Use JMX (StorageService->startRPCServer()) or
> nodetool (enablethrift) to start it
> INFO [Native-Transport-Requests-21] 2019-06-05 04:41:39,145
> AuthCache.java:161 - (Re)initializing PermissionsCache (validity
> period/update interval/max entries) (2000/2000/1000)
> INFO [OptionalTasks:1] 2019-06-05 04:41:39,729 CassandraAuthorizer.java:409
> - Converting legacy permissions data
> INFO [HANDSHAKE-/10.10.10.8] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.8
> INFO [HANDSHAKE-/10.10.10.9] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.9
> INFO [HANDSHAKE-dc1_02/10.10.10.6] 2019-06-05 04:41:39,809
> OutboundTcpConnection.java:561 - Handshaking version with dc1_02/10.10.10.6
> WARN [ReadStage-2] 2019-06-05 04:41:39,857
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-2,5,main]: {}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.apache.cassandra.db.AbstractBufferClusteringPrefix.get(AbstractBufferClusteringPrefix.java:55)
> at
> org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSizeCompound(LegacyLayout.java:2545)
> at
> org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSize(LegacyLayout.java:2522)
> at
> org.apache.cassandra.db.LegacyLayout.serializedSizeAsLegacyPartition(LegacyLayout.java:565)
> at
> org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:446)
> at
> org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:352)
> at
> org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:171)
> at
> org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:77)
> at
> org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:802)
> at
> org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:953)
> at
> org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:929)
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:62)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
>
[jira] [Updated] (CASSANDRA-15172) LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mck updated CASSANDRA-15172:
Description:
Hi All,
This is the first time I open an issue, so apologies if I'm not following the
rules properly.
After upgrading a node from version 2.1.21 to 3.11.4, we've started seeing a
lot of AbstractLocalAwareExecutorService exceptions. This happened right after
the node successfully started up with the new 3.11.4 binaries.
{noformat}
INFO [main] 2019-06-05 04:41:37,730 Gossiper.java:1715 - No gossip backlog;
proceeding
INFO [main] 2019-06-05 04:41:38,036 NativeTransportService.java:70 - Netty
using native Epoll event loop
INFO [main] 2019-06-05 04:41:38,117 Server.java:155 - Using Netty Version:
[netty-buffer=netty-buffer-4.0.44.Final.452812a,
netty-codec=netty-codec-4.0.44.Final.452812a,
netty-codec-haproxy=netty-codec-haproxy-4.0.44.Final.452812a,
netty-codec-http=netty-codec-http-4.0.44.Final.452812a,
netty-codec-socks=netty-codec-socks-4.0.44.Final.452812a,
netty-common=netty-common-4.0.44.Final.452812a,
netty-handler=netty-handler-4.0.44.Final.452812a,
netty-tcnative=netty-tcnative-1.1.33.Fork26.142ecbb,
netty-transport=netty-transport-4.0.44.Final.452812a,
netty-transport-native-epoll=netty-transport-native-epoll-4.0.44.Final.452812a,
netty-transport-rxtx=netty-transport-rxtx-4.0.44.Final.452812a,
netty-transport-sctp=netty-transport-sctp-4.0.44.Final.452812a,
netty-transport-udt=netty-transport-udt-4.0.44.Final.452812a]
INFO [main] 2019-06-05 04:41:38,118 Server.java:156 - Starting listening for
CQL clients on /0.0.0.0:9042 (unencrypted)...
INFO [main] 2019-06-05 04:41:38,179 CassandraDaemon.java:556 - Not starting
RPC server as requested. Use JMX (StorageService->startRPCServer()) or nodetool
(enablethrift) to start it
INFO [Native-Transport-Requests-21] 2019-06-05 04:41:39,145 AuthCache.java:161
- (Re)initializing PermissionsCache (validity period/update interval/max
entries) (2000/2000/1000)
INFO [OptionalTasks:1] 2019-06-05 04:41:39,729 CassandraAuthorizer.java:409 -
Converting legacy permissions data
INFO [HANDSHAKE-/10.10.10.8] 2019-06-05 04:41:39,808
OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.8
INFO [HANDSHAKE-/10.10.10.9] 2019-06-05 04:41:39,808
OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.9
INFO [HANDSHAKE-dc1_02/10.10.10.6] 2019-06-05 04:41:39,809
OutboundTcpConnection.java:561 - Handshaking version with dc1_02/10.10.10.6
WARN [ReadStage-2] 2019-06-05 04:41:39,857
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-2,5,main]: {}
java.lang.ArrayIndexOutOfBoundsException: 1
at
org.apache.cassandra.db.AbstractBufferClusteringPrefix.get(AbstractBufferClusteringPrefix.java:55)
at
org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSizeCompound(LegacyLayout.java:2545)
at
org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSize(LegacyLayout.java:2522)
at
org.apache.cassandra.db.LegacyLayout.serializedSizeAsLegacyPartition(LegacyLayout.java:565)
at
org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:446)
at
org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:352)
at org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:171)
at
org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:77)
at
org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:802)
at
org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:953)
at
org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:929)
at
org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:62)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:114)
at java.lang.Thread.run(Thread.java:745)
{noformat}
After several of the above warnings, the following warning appeared as well:
{noformat}
WARN [ReadStage-9] 2019-06-05 04:42:04,369
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-9,5,main]: {}
java.lang.ArrayIndexOutOfBoundsException: null
WARN [ReadStage-11] 2019-06-05 04:42:04,381
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
[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=16911990#comment-16911990 ] Jonas B. commented on CASSANDRA-15273: -- We are experiencing the same! We are on cassandra-version 3.11.1-1. What is the status on this? > 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.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15269) Cassandra fails to process OperationExecutionException which causes ClassCastException
[
https://issues.apache.org/jira/browse/CASSANDRA-15269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911960#comment-16911960
]
Liudmila Kornilova commented on CASSANDRA-15269:
Hi [~andrew.tolbert],
Thank you for reviewing my commit!
I moved error code description from v4 to v5
How to find out versions of Cassandra and CQL that will use v5?
I know that I can execute {{"select release_version, cql_version,
native_protocol_version from system.local"}}, but it gives v4 protocol for
4.0-SNAPSHOT Cassandra and 3.4.5 cql
> Cassandra fails to process OperationExecutionException which causes
> ClassCastException
> --
>
> Key: CASSANDRA-15269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15269
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Liudmila Kornilova
>Assignee: Liudmila Kornilova
>Priority: Normal
>
> While working on CASSANDRA-15232 I noticed that OperationExecutionException
> is not processed correctly.
> How to reproduce the issue:
> 1. {{create table d (numerator decimal primary key, denominator decimal);}}
> 2. {{insert into d (numerator, denominator) values
> (123456789112345678921234567893123456, 2);}}
> 3. {{select numerator % denominator from d;}}
> What happens:
> 1. remainder operation throws ArithmeticException (BigDecimal:1854)
> 2. The exception is wrapped in OperationExecutionException
> 3. ClassCastException appears (OperationExecutionException cannot be cast to
> FunctionExecutionException at ErrorMessage.java:280)
> What should happen:
> OperationExecutionException with message "the operation 'decimal % decimal'
> failed: Division impossible" should be delivered to user
> Note that after fixing CASSANDRA-15232 {{select numerator % denominator from
> d;}} will produce correct result of remainder operation.
> Currently I am not aware of other cases when OperationExecutionException may
> be treated as FunctionExecutionException
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
