[jira] [Commented] (CASSANDRA-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[ https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116318#comment-17116318 ] Ben Bromhead commented on CASSANDRA-14361: -- Rebased (I think, my git foo is weak). I'll look to move the threshold property into cassandra.yaml as well. I'm not sure if we want to revert to the old behaviour as the old behavior is probably less deterministic that people realise. For example if you get entries in an A records for a single query most Java implementations will maintain the order of those records, but some OSs will do ordering differently (e.g. Windows Vista will order records based on which address shares the most number of significant bits with the network adapters IP??... which broke a lot of round robin implementations back in the day). On top of this, the DNS resolver also doesn't provide ordering guarantees and most by default will round robin the order of the entries in an A record. Plus this is all ignoring DNS caching behaviour, which on the other hand, is probably masking a lot of the above. So any reliance on old behavior is potentially non-deterministic anyway! Plus its 4.0 and I would guess the majority of people are using IP addresses or single entries A records anyway? > Allow SimpleSeedProvider to resolve multiple IPs per DNS name > - > > Key: CASSANDRA-14361 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14361 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ben Bromhead >Assignee: Ben Bromhead >Priority: Low > Fix For: 4.0 > > > Currently SimpleSeedProvider can accept a comma separated string of IPs or > hostnames as the set of Cassandra seeds. hostnames are resolved via > InetAddress.getByName, which will only return the first IP associated with an > A, or CNAME record. > By changing to InetAddress.getAllByName, existing behavior is preserved, but > now Cassandra can discover multiple IP address per record, allowing seed > discovery by DNS to be a little easier. > Some examples of improved workflows with this change include: > * specify the DNS name of a headless service in Kubernetes which will > resolve to all IP addresses of pods within that service. > * seed discovery for multi-region clusters via AWS route53, AzureDNS etc > * Other common DNS service discovery mechanisms. > The only behavior this is likely to impact would be where users are relying > on the fact that getByName only returns a single IP address. > I can't imagine any scenario where that is a sane choice. Even when that > choice has been made, it only impacts the first startup of Cassandra and > would not be on any critical path. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15832) Typo in website documentation for file "mvs.rst"
Tajinder Singh created CASSANDRA-15832:
--
Summary: Typo in website documentation for file "mvs.rst"
Key: CASSANDRA-15832
URL: https://issues.apache.org/jira/browse/CASSANDRA-15832
Project: Cassandra
Issue Type: Bug
Components: Documentation/Website
Reporter: Tajinder Singh
It appears that there is a typo in the doc for mvs.rst file. Please refer this
link -
[https://cassandra.apache.org/doc/latest/cql/mvs.html#drop-materialized-view]
_Current sentence in doc:_
"Dropping a materialized view {color:#de350b}*users* {color}the DROP
MATERIALIZED VIEW statement:"
_Expected sentence in doc:_
"Dropping a materialized view {color:#00875a}*using* {color}the DROP
MATERIALIZED VIEW statement:"
_Patch for proposed fix:_
[https://github.com/tsingh2k15/cassandra/commit/1a56c295843bd74f2e856c01fa76a4676875dc7c]
Please review and let me know if this patch can be accepted as a fix?
--
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-15667) StreamResultFuture check for completeness is inconsistent, leading to races
[
https://issues.apache.org/jira/browse/CASSANDRA-15667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15667:
---
Fix Version/s: 3.11.7
3.0.21
Since Version: 3.0.0
Source Control Link:
https://github.com/apache/cassandra/commit/a4b6deb906d846c2532174fcebfce0398b4b3c29
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into 3.0 at a4b6deb906d846c2532174fcebfce0398b4b3c29 and merged into
3.11 and trunk
> StreamResultFuture check for completeness is inconsistent, leading to races
> ---
>
> Key: CASSANDRA-15667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15667
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: Massimiliano Tomassi
>Priority: Normal
> Fix For: 3.0.21, 3.11.7, 4.0-alpha
>
> Attachments: log_bootstrap_resumable
>
>
> {{StreamResultFuture#maybeComplete()}} uses
> {{StreamCoordinator#hasActiveSessions()}} to determine if all sessions are
> completed, but then accesses each session state via
> {{StreamCoordinator#getAllSessionInfo()}}: this is inconsistent, as the
> former relies on the actual {{StreamSession}} state, while the latter on the
> {{SessionInfo}} state, and the two are concurrently updated with no
> coordination whatsoever.
> This leads to races, i.e. apparent in some dtest spurious failures, such as
> {{TestBootstrap.resumable_bootstrap_test}} in CASSANDRA-15614 cc
> [~e.dimitrova].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (9519eb3 -> 3cda9d7)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 9519eb3 Merge branch 'cassandra-3.0' into cassandra-3.11 add a4b6deb Rely on snapshotted session infos on StreamResultFuture.maybeComplete to avoid races add 3cda9d7 Merge branch cassandra-3.0 into cassandra-3.11 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/streaming/StreamCoordinator.java | 4 ++- .../cassandra/streaming/StreamResultFuture.java| 12 - .../apache/cassandra/streaming/StreamSession.java | 29 -- 4 files changed, 37 insertions(+), 9 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15667) StreamResultFuture check for completeness is inconsistent, leading to races
[
https://issues.apache.org/jira/browse/CASSANDRA-15667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15667:
---
Status: Ready to Commit (was: Review In Progress)
> StreamResultFuture check for completeness is inconsistent, leading to races
> ---
>
> Key: CASSANDRA-15667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15667
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: Massimiliano Tomassi
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: log_bootstrap_resumable
>
>
> {{StreamResultFuture#maybeComplete()}} uses
> {{StreamCoordinator#hasActiveSessions()}} to determine if all sessions are
> completed, but then accesses each session state via
> {{StreamCoordinator#getAllSessionInfo()}}: this is inconsistent, as the
> former relies on the actual {{StreamSession}} state, while the latter on the
> {{SessionInfo}} state, and the two are concurrently updated with no
> coordination whatsoever.
> This leads to races, i.e. apparent in some dtest spurious failures, such as
> {{TestBootstrap.resumable_bootstrap_test}} in CASSANDRA-15614 cc
> [~e.dimitrova].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (43c1987 -> c17af2d)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 43c1987 Fix flaky test o.a.c.u.binlog.BinLogTest patch by Yifan Cai; reviewed by Vinay Chella for CASSANDRA-15797 add a4b6deb Rely on snapshotted session infos on StreamResultFuture.maybeComplete to avoid races add 3cda9d7 Merge branch cassandra-3.0 into cassandra-3.11 new c17af2d Merge branch cassandra-3.11 into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt | 1 + .../org/apache/cassandra/streaming/StreamCoordinator.java| 2 ++ .../org/apache/cassandra/streaming/StreamResultFuture.java | 12 +++- 3 files changed, 14 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (ea202ce -> a4b6deb)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from ea202ce EmptyType doesn't override writeValue so could attempt to write bytes when expected not to add a4b6deb Rely on snapshotted session infos on StreamResultFuture.maybeComplete to avoid races No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/streaming/StreamCoordinator.java | 4 ++- .../cassandra/streaming/StreamResultFuture.java| 12 - .../apache/cassandra/streaming/StreamSession.java | 29 -- 4 files changed, 37 insertions(+), 9 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch cassandra-3.11 into trunk
This is an automated email from the ASF dual-hosted git repository.
blerer pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit c17af2d6babe803418b69b9ac7956f4f4bf09c84
Merge: 43c1987 3cda9d7
Author: Benjamin Lerer
AuthorDate: Mon May 25 16:34:57 2020 +0200
Merge branch cassandra-3.11 into trunk
CHANGES.txt | 1 +
.../org/apache/cassandra/streaming/StreamCoordinator.java| 2 ++
.../org/apache/cassandra/streaming/StreamResultFuture.java | 12 +++-
3 files changed, 14 insertions(+), 1 deletion(-)
diff --cc CHANGES.txt
index c6c2358,11515c4..01f74f0
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,37 -1,8 +1,38 @@@
-3.11.7
+4.0-alpha5
+ * Provide ability to configure IAuditLogger (CASSANDRA-15748)
+ * Fix nodetool enablefullquerylog blocking param parsing (CASSANDRA-15819)
+ * Add isTransient to SSTableMetadataView (CASSANDRA-15806)
+ * Fix tools/bin/fqltool for all shells (CASSANDRA-15820)
+ * Fix clearing of legacy size_estimates (CASSANDRA-15776)
+ * Update port when reconnecting to pre-4.0 SSL storage (CASSANDRA-15727)
+ * Only calculate dynamicBadnessThreshold once per loop in
DynamicEndpointSnitch (CASSANDRA-15798)
+ * Cleanup redundant nodetool commands added in 4.0 (CASSANDRA-15256)
+ * Update to Python driver 3.23 for cqlsh (CASSANDRA-15793)
+ * Add tunable initial size and growth factor to RangeTombstoneList
(CASSANDRA-15763)
+ * Improve debug logging in SSTableReader for index summary (CASSANDRA-15755)
+ * bin/sstableverify should support user provided token ranges
(CASSANDRA-15753)
+ * Improve logging when mutation passed to commit log is too large
(CASSANDRA-14781)
+ * replace LZ4FastDecompressor with LZ4SafeDecompressor (CASSANDRA-15560)
+ * Fix buffer pool NPE with concurrent release due to in-progress tiny pool
eviction (CASSANDRA-15726)
+ * Avoid race condition when completing stream sessions (CASSANDRA-15666)
+ * Flush with fast compressors by default (CASSANDRA-15379)
+ * Fix CqlInputFormat regression from the switch to system.size_estimates
(CASSANDRA-15637)
+ * Allow sending Entire SSTables over SSL (CASSANDRA-15740)
+ * Fix CQLSH UTF-8 encoding issue for Python 2/3 compatibility
(CASSANDRA-15739)
+ * Fix batch statement preparation when multiple tables and parameters are
used (CASSANDRA-15730)
+ * Fix regression with traceOutgoingMessage printing message size
(CASSANDRA-15687)
+ * Ensure repaired data tracking reads a consistent amount of data across
replicas (CASSANDRA-15601)
+ * Fix CQLSH to avoid arguments being evaluated (CASSANDRA-15660)
+ * Correct Visibility and Improve Safety of Methods in LatencyMetrics
(CASSANDRA-15597)
+ * Allow cqlsh to run with Python2.7/Python3.6+
(CASSANDRA-15659,CASSANDRA-15573)
+ * Improve logging around incremental repair (CASSANDRA-15599)
+ * Do not check cdc_raw_directory filesystem space if CDC disabled
(CASSANDRA-15688)
+ * Replace array iterators with get by index (CASSANDRA-15394)
+ * Minimize BTree iterator allocations (CASSANDRA-15389)
+Merged from 3.11:
* Fix CQL formatting of read command restrictions for slow query log
(CASSANDRA-15503)
- * Allow sstableloader to use SSL on the native port (CASSANDRA-14904)
Merged from 3.0:
+ * Rely on snapshotted session infos on StreamResultFuture.maybeComplete to
avoid race conditions (CASSANDRA-15667)
* EmptyType doesn't override writeValue so could attempt to write bytes when
expected not to (CASSANDRA-15790)
* Fix index queries on partition key columns when some partitions contains
only static data (CASSANDRA-13666)
* Avoid creating duplicate rows during major upgrades (CASSANDRA-15789)
diff --cc src/java/org/apache/cassandra/streaming/StreamCoordinator.java
index c8ebabb,b801ecc..e590e96
--- a/src/java/org/apache/cassandra/streaming/StreamCoordinator.java
+++ b/src/java/org/apache/cassandra/streaming/StreamCoordinator.java
@@@ -285,9 -294,9 +285,10 @@@ public class StreamCoordinato
// create
if (streamSessions.size() < connectionsPerHost)
{
-StreamSession session = new StreamSession(peer, connecting,
factory, streamSessions.size(), keepSSTableLevel, isIncremental);
+StreamSession session = new StreamSession(streamOperation,
peer, factory, isFollower(), streamSessions.size(),
+ pendingRepair,
previewKind);
streamSessions.put(++lastReturned, session);
+ sessionInfos.put(lastReturned, session.getSessionInfo());
return session;
}
// get
@@@ -318,8 -327,9 +319,9 @@@
StreamSession session = streamSessions.get(id);
if (session == null)
{
-session = new StreamSession(peer, connecting, factory, id,
keepSSTableLevel, isIncremental);
+
[jira] [Assigned] (CASSANDRA-15825) Fix flaky test incrementalSSTableSelection - org.apache.cassandra.db.streaming.CassandraStreamManagerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-15825:
--
Assignee: Benjamin Lerer
> Fix flaky test incrementalSSTableSelection -
> org.apache.cassandra.db.streaming.CassandraStreamManagerTest
> -
>
> Key: CASSANDRA-15825
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15825
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Build link:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/287/workflows/06baf3db-7094-431f-920d-e8fcd1da9cce/jobs/1398
>
> {code}
> java.lang.RuntimeException: java.nio.file.NoSuchFileException:
> /tmp/cassandra/build/test/cassandra/data:2/ks_1589913975959/tbl-051c0a709a0111eab5fb6f52366536f8/na-4-big-Statistics.db
> at
> org.apache.cassandra.io.util.ChannelProxy.openChannel(ChannelProxy.java:55)
> at
> org.apache.cassandra.io.util.ChannelProxy.(ChannelProxy.java:66)
> at
> org.apache.cassandra.io.util.RandomAccessReader.open(RandomAccessReader.java:315)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:126)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:136)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.reloadSSTableMetadata(SSTableReader.java:2047)
> at
> org.apache.cassandra.db.streaming.CassandraStreamManagerTest.mutateRepaired(CassandraStreamManagerTest.java:128)
> at
> org.apache.cassandra.db.streaming.CassandraStreamManagerTest.incrementalSSTableSelection(CassandraStreamManagerTest.java:175)
> Caused by: java.nio.file.NoSuchFileException:
> /tmp/cassandra/build/test/cassandra/data:2/ks_1589913975959/tbl-051c0a709a0111eab5fb6f52366536f8/na-4-big-Statistics.db
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at
> sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177)
> at java.nio.channels.FileChannel.open(FileChannel.java:287)
> at java.nio.channels.FileChannel.open(FileChannel.java:335)
> at
> org.apache.cassandra.io.util.ChannelProxy.openChannel(ChannelProxy.java:51)
> {code}
--
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] [Issue Comment Deleted] (CASSANDRA-14594) No validation for repeated fields in cqlsh and misbehaviour in data display
[ https://issues.apache.org/jira/browse/CASSANDRA-14594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chakravarthi Manepalli updated CASSANDRA-14594: --- Comment: was deleted (was: Hi harini, can you please let me know regarding the status of my bug report?) > No validation for repeated fields in cqlsh and misbehaviour in data display > --- > > Key: CASSANDRA-14594 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14594 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools > Environment: Operating System: Ubuntu 14.04(64 bit) (Image : > cqlshbug.png) > Operating System: ubuntu 16.04 (64 bit) (Image: > cqlsh_select_repeated_fields.png) > Apache cassandra version : 3.11.1 >Reporter: Chakravarthi Manepalli >Priority: Normal > Attachments: cqlsh bug.png, cqlsh_select_repeated_fields.png > > > In a table, if the fields(columns) are repeated in select call, the > displaying information is not correct. -- 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-15725) Add support for adding custom Verbs
[ https://issues.apache.org/jira/browse/CASSANDRA-15725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17115906#comment-17115906 ] Marcus Eriksson commented on CASSANDRA-15725: - All good ideas, pushed a commit to the branch above, could you have a look [~benedict]? > Add support for adding custom Verbs > --- > > Key: CASSANDRA-15725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15725 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-alpha > > Attachments: feedback_15725.patch > > > It should be possible to safely add custom/internal Verbs - without risking > conflicts when new ones are added. -- 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-15166) Cassandra startup error
[
https://issues.apache.org/jira/browse/CASSANDRA-15166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17115894#comment-17115894
]
Alex Petrov commented on CASSANDRA-15166:
-
Looks like we're using a {{ConcurrentBiMap}} with an expectation that there's
no way to have two tables with same id. It looks like the easiest way to fix
the node is to create keyspaces and tables anew, with distinct ids, and copy
sstables over.
> Cassandra startup error
> ---
>
> Key: CASSANDRA-15166
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15166
> Project: Cassandra
> Issue Type: Task
> Components: Consistency/Repair
>Reporter: abalakrishna
>Priority: Normal
>
> We have Cassandra cluster with three nodes installed in ubuntu,
> We are getting below startup error while restarting ,same error for all the
> three nodes.
> Can anyone please help with the solution to start the Cassandra back.
> ERROR
> *ERROR [main] CassandraDaemon.java:731 - Exception encountered during startup*
> *java.lang.IllegalArgumentException: c997e340-2939-11e9-bf8c-edeff921e924 is
> already bound in reverseMap to (cli_150,_track)*
--
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-15830) Invalid version value: 4.0~alpha4 during startup
[
https://issues.apache.org/jira/browse/CASSANDRA-15830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17115884#comment-17115884
]
Eric Wong commented on CASSANDRA-15830:
---
I actually found out this morning. If I replaced
apache-cassandra-4.0-alpha4.jar from the binary distribution, instead of the
rpm version, I can shutdown and restart the db without issue.
> Invalid version value: 4.0~alpha4 during startup
>
>
> Key: CASSANDRA-15830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15830
> Project: Cassandra
> Issue Type: Bug
>Reporter: Eric Wong
>Priority: Normal
>
> Hi:
> We are testing the latest cassandra-4.0 on Centos 7 using a clean database.
> When we started cassandra the first time, everything is fine. However, when
> we stop and restart cassandra, we got the following error and the db refuses
> to startup:
> {code}
> ERROR [main] 2020-05-22 05:58:18,698 CassandraDaemon.java:789 - Exception
> encountered during startup
> java.lang.IllegalArgumentException: Invalid version value: 4.0~alpha4
> at
> org.apache.cassandra.utils.CassandraVersion.(CassandraVersion.java:64)
> at
> org.apache.cassandra.io.sstable.SSTableHeaderFix.fixNonFrozenUDTIfUpgradeFrom30(SSTableHeaderFix.java:84)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:250)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:650)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:767)
> {code}
> The only way to get the node up and running again is by deleting all data
> under /var/lib/cassandra.
>
> Is that a known issue?
> Thanks, Eric
>
>
>
--
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-15830) Invalid version value: 4.0~alpha4 during startup
[
https://issues.apache.org/jira/browse/CASSANDRA-15830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-15830:
Description:
Hi:
We are testing the latest cassandra-4.0 on Centos 7 using a clean database.
When we started cassandra the first time, everything is fine. However, when we
stop and restart cassandra, we got the following error and the db refuses to
startup:
{code}
ERROR [main] 2020-05-22 05:58:18,698 CassandraDaemon.java:789 - Exception
encountered during startup
java.lang.IllegalArgumentException: Invalid version value: 4.0~alpha4
at org.apache.cassandra.utils.CassandraVersion.(CassandraVersion.java:64)
at
org.apache.cassandra.io.sstable.SSTableHeaderFix.fixNonFrozenUDTIfUpgradeFrom30(SSTableHeaderFix.java:84)
at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:250)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:650)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:767)
{code}
The only way to get the node up and running again is by deleting all data under
/var/lib/cassandra.
Is that a known issue?
Thanks, Eric
was:
Hi:
We are testing the latest cassandra-4.0 on Centos 7 using a clean database.
When we started cassandra the first time, everything is fine. However, when we
stop and restart cassandra, we got the following error and the db refuses to
startup:
{{code}}
ERROR [main] 2020-05-22 05:58:18,698 CassandraDaemon.java:789 - Exception
encountered during startup
java.lang.IllegalArgumentException: Invalid version value: 4.0~alpha4
at org.apache.cassandra.utils.CassandraVersion.(CassandraVersion.java:64)
at
org.apache.cassandra.io.sstable.SSTableHeaderFix.fixNonFrozenUDTIfUpgradeFrom30(SSTableHeaderFix.java:84)
at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:250)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:650)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:767)
{{code}}
The only way to get the node up and running again is by deleting all data under
/var/lib/cassandra.
Is that a known issue?
Thanks, Eric
> Invalid version value: 4.0~alpha4 during startup
>
>
> Key: CASSANDRA-15830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15830
> Project: Cassandra
> Issue Type: Bug
>Reporter: Eric Wong
>Priority: Normal
>
> Hi:
> We are testing the latest cassandra-4.0 on Centos 7 using a clean database.
> When we started cassandra the first time, everything is fine. However, when
> we stop and restart cassandra, we got the following error and the db refuses
> to startup:
> {code}
> ERROR [main] 2020-05-22 05:58:18,698 CassandraDaemon.java:789 - Exception
> encountered during startup
> java.lang.IllegalArgumentException: Invalid version value: 4.0~alpha4
> at
> org.apache.cassandra.utils.CassandraVersion.(CassandraVersion.java:64)
> at
> org.apache.cassandra.io.sstable.SSTableHeaderFix.fixNonFrozenUDTIfUpgradeFrom30(SSTableHeaderFix.java:84)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:250)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:650)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:767)
> {code}
> The only way to get the node up and running again is by deleting all data
> under /var/lib/cassandra.
>
> Is that a known issue?
> Thanks, Eric
>
>
>
--
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-15830) Invalid version value: 4.0~alpha4 during startup
[
https://issues.apache.org/jira/browse/CASSANDRA-15830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-15830:
Description:
Hi:
We are testing the latest cassandra-4.0 on Centos 7 using a clean database.
When we started cassandra the first time, everything is fine. However, when we
stop and restart cassandra, we got the following error and the db refuses to
startup:
{{code}}
ERROR [main] 2020-05-22 05:58:18,698 CassandraDaemon.java:789 - Exception
encountered during startup
java.lang.IllegalArgumentException: Invalid version value: 4.0~alpha4
at org.apache.cassandra.utils.CassandraVersion.(CassandraVersion.java:64)
at
org.apache.cassandra.io.sstable.SSTableHeaderFix.fixNonFrozenUDTIfUpgradeFrom30(SSTableHeaderFix.java:84)
at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:250)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:650)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:767)
{{code}}
The only way to get the node up and running again is by deleting all data under
/var/lib/cassandra.
Is that a known issue?
Thanks, Eric
was:
Hi:
We are testing the latest cassandra-4.0 on Centos 7 using a clean database.
When we started cassandra the first time, everything is fine. However, when we
stop and restart cassandra, we got the following error and the db refuses to
startup:
ERROR [main] 2020-05-22 05:58:18,698 CassandraDaemon.java:789 - Exception
encountered during startup
java.lang.IllegalArgumentException: Invalid version value: 4.0~alpha4
at org.apache.cassandra.utils.CassandraVersion.(CassandraVersion.java:64)
at
org.apache.cassandra.io.sstable.SSTableHeaderFix.fixNonFrozenUDTIfUpgradeFrom30(SSTableHeaderFix.java:84)
at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:250)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:650)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:767)
The only way to get the node up and running again is by deleting all data under
/var/lib/cassandra.
Is that a known issue?
Thanks, Eric
> Invalid version value: 4.0~alpha4 during startup
>
>
> Key: CASSANDRA-15830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15830
> Project: Cassandra
> Issue Type: Bug
>Reporter: Eric Wong
>Priority: Normal
>
> Hi:
> We are testing the latest cassandra-4.0 on Centos 7 using a clean database.
> When we started cassandra the first time, everything is fine. However, when
> we stop and restart cassandra, we got the following error and the db refuses
> to startup:
> {{code}}
> ERROR [main] 2020-05-22 05:58:18,698 CassandraDaemon.java:789 - Exception
> encountered during startup
> java.lang.IllegalArgumentException: Invalid version value: 4.0~alpha4
> at
> org.apache.cassandra.utils.CassandraVersion.(CassandraVersion.java:64)
> at
> org.apache.cassandra.io.sstable.SSTableHeaderFix.fixNonFrozenUDTIfUpgradeFrom30(SSTableHeaderFix.java:84)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:250)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:650)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:767)
> {{code}}
> The only way to get the node up and running again is by deleting all data
> under /var/lib/cassandra.
>
> Is that a known issue?
> Thanks, Eric
>
>
>
--
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-10968) When taking snapshot, manifest.json contains incorrect or no files when column family has secondary indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-10968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17115875#comment-17115875 ] Alex Petrov commented on CASSANDRA-10968: - To me, this looks like an issue that is rather important to fix (even though it's trivial and theoretically possible to work around), since manifest files shouldn't be empty, might break someone's automation, etc., so I think it's legit to commit it to 2.2 and up. > When taking snapshot, manifest.json contains incorrect or no files when > column family has secondary indexes > --- > > Key: CASSANDRA-10968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10968 > Project: Cassandra > Issue Type: Bug > Components: Feature/2i Index >Reporter: Fred A >Assignee: Aleksandr Sorokoumov >Priority: Normal > Labels: lhf > Fix For: 2.2.x, 3.0.x, 3.11.x > > > xNoticed indeterminate behaviour when taking snapshot on column families that > has secondary indexes setup. The created manifest.json created when doing > snapshot, sometimes contains no file names at all and sometimes some file > names. > I don't know if this post is related but that was the only thing I could find: > http://www.mail-archive.com/user%40cassandra.apache.org/msg42019.html -- 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-10968) When taking snapshot, manifest.json contains incorrect or no files when column family has secondary indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-10968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17115844#comment-17115844 ] Aleksandr Sorokoumov commented on CASSANDRA-10968: -- [~ifesdjeen] I would like to rebase and retest the patches. Can you please advise on the lowest target version? AFAIU it should land at either the lowest affected version if we consider this a serious enough issue or 4.0 otherwise. > When taking snapshot, manifest.json contains incorrect or no files when > column family has secondary indexes > --- > > Key: CASSANDRA-10968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10968 > Project: Cassandra > Issue Type: Bug > Components: Feature/2i Index >Reporter: Fred A >Assignee: Aleksandr Sorokoumov >Priority: Normal > Labels: lhf > Fix For: 2.2.x, 3.0.x, 3.11.x > > > xNoticed indeterminate behaviour when taking snapshot on column families that > has secondary indexes setup. The created manifest.json created when doing > snapshot, sometimes contains no file names at all and sometimes some file > names. > I don't know if this post is related but that was the only thing I could find: > http://www.mail-archive.com/user%40cassandra.apache.org/msg42019.html -- 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
