[jira] [Updated] (CASSANDRA-19733) Add feature to filter streaming source when bootstrapping
[
https://issues.apache.org/jira/browse/CASSANDRA-19733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-19733:
---
Test and Documentation Plan: Unit test attched
Status: Patch Available (was: Open)
> Add feature to filter streaming source when bootstrapping
> -
>
> Key: CASSANDRA-19733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19733
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Membership
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> h2. Proposed improvement
> Right now, the stream sources for the bootstrap are chosen from the closest
> nodes of the bootstrapping node.
> Add the following system properties so that when bootstrap happens, the node
> can choose where to stream data from.
> * {{cassandra.bootstrap.include_dcs}}
> * {{cassandra.bootstrap.exclude_dcs}}
> * {{cassandra.bootstrap.include_sources}}
> {{cassandra.bootstrap.include_dcs and }}{{cassandra.bootstrap.exclude_dcs can
> take args like "dc1,dc2" to specify DCs or "dc1:rack1,dc1:rack2,..." to
> specify DC/Racks.}}
> {{cassandra.bootstrap.include_sources is used to specify ip address/port of
> the specific nodes to stream from.}}
> h2. Motivation
> Currently, when the node failure happens in the middle of the major cluster
> upgrade, general advice given to the user is to complete the upgrade of the
> cluster until all nodes are in the same version, and replace/remove the
> failed node. This is because the streaming breaks when there is unsupported
> SSTable version streamed from newer to the older.
> This approach can create availability issue when two nodes (the failed node
> from different rack and the node currently stopped for the upgrade) are down.
> With this improvement, the user can replace the failed node using, for
> example, specific rack in the same DC or another DC, to eliminate the
> availability issue described above.
> h2. Note
> The user also needs to set "-Dcassandra.skip_schema_check=true" when
> replacing the node during the major upgrade to complete the replacement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19733) Add feature to filter streaming source when bootstrapping
[
https://issues.apache.org/jira/browse/CASSANDRA-19733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-19733:
---
Change Category: Operability
Complexity: Normal
Status: Open (was: Triage Needed)
> Add feature to filter streaming source when bootstrapping
> -
>
> Key: CASSANDRA-19733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19733
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Membership
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> h2. Proposed improvement
> Right now, the stream sources for the bootstrap are chosen from the closest
> nodes of the bootstrapping node.
> Add the following system properties so that when bootstrap happens, the node
> can choose where to stream data from.
> * {{cassandra.bootstrap.include_dcs}}
> * {{cassandra.bootstrap.exclude_dcs}}
> * {{cassandra.bootstrap.include_sources}}
> {{cassandra.bootstrap.include_dcs and }}{{cassandra.bootstrap.exclude_dcs can
> take args like "dc1,dc2" to specify DCs or "dc1:rack1,dc1:rack2,..." to
> specify DC/Racks.}}
> {{cassandra.bootstrap.include_sources is used to specify ip address/port of
> the specific nodes to stream from.}}
> h2. Motivation
> Currently, when the node failure happens in the middle of the major cluster
> upgrade, general advice given to the user is to complete the upgrade of the
> cluster until all nodes are in the same version, and replace/remove the
> failed node. This is because the streaming breaks when there is unsupported
> SSTable version streamed from newer to the older.
> This approach can create availability issue when two nodes (the failed node
> from different rack and the node currently stopped for the upgrade) are down.
> With this improvement, the user can replace the failed node using, for
> example, specific rack in the same DC or another DC, to eliminate the
> availability issue described above.
> h2. Note
> The user also needs to set "-Dcassandra.skip_schema_check=true" when
> replacing the node during the major upgrade to complete the replacement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19733) Add feature to filter streaming source when bootstrapping
[
https://issues.apache.org/jira/browse/CASSANDRA-19733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860702#comment-17860702
]
Yuki Morishita commented on CASSANDRA-19733:
> It shouldn’t ever stream from same rack (same dc but not same rack)
Right, my bad. But still, there is a chance you cannot stream from another
racks mid upgrade.
And yes, this proposal is rather a workaround as you mentioned.
5.0+ already has `storage_compatibility_mode` so when upgrading 4.1 -> 5.0+,
the user can replace the node mid upgrade(Need more testing for this though).
So, the intention of this improvement is to help the users on 3.11.x, 4.0 to
upgrade to 4.1.
> Add feature to filter streaming source when bootstrapping
> -
>
> Key: CASSANDRA-19733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19733
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Membership
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> h2. Proposed improvement
> Right now, the stream sources for the bootstrap are chosen from the closest
> nodes of the bootstrapping node.
> Add the following system properties so that when bootstrap happens, the node
> can choose where to stream data from.
> * {{cassandra.bootstrap.include_dcs}}
> * {{cassandra.bootstrap.exclude_dcs}}
> * {{cassandra.bootstrap.include_sources}}
> {{cassandra.bootstrap.include_dcs and }}{{cassandra.bootstrap.exclude_dcs can
> take args like "dc1,dc2" to specify DCs or "dc1:rack1,dc1:rack2,..." to
> specify DC/Racks.}}
> {{cassandra.bootstrap.include_sources is used to specify ip address/port of
> the specific nodes to stream from.}}
> h2. Motivation
> Currently, when the node failure happens in the middle of the major cluster
> upgrade, general advice given to the user is to complete the upgrade of the
> cluster until all nodes are in the same version, and replace/remove the
> failed node. This is because the streaming breaks when there is unsupported
> SSTable version streamed from newer to the older.
> This approach can create availability issue when two nodes (the failed node
> from different rack and the node currently stopped for the upgrade) are down.
> With this improvement, the user can replace the failed node using, for
> example, specific rack in the same DC or another DC, to eliminate the
> availability issue described above.
> h2. Note
> The user also needs to set "-Dcassandra.skip_schema_check=true" when
> replacing the node during the major upgrade to complete the replacement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19733) Add feature to filter streaming source when bootstrapping
[
https://issues.apache.org/jira/browse/CASSANDRA-19733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-19733:
---
Description:
h2. Proposed improvement
Right now, the stream sources for the bootstrap are chosen from the closest
nodes of the bootstrapping node.
Add the following system properties so that when bootstrap happens, the node
can choose where to stream data from.
* {{cassandra.bootstrap.include_dcs}}
* {{cassandra.bootstrap.exclude_dcs}}
* {{cassandra.bootstrap.include_sources}}
{{cassandra.bootstrap.include_dcs and }}{{cassandra.bootstrap.exclude_dcs can
take args like "dc1,dc2" to specify DCs or "dc1:rack1,dc1:rack2,..." to specify
DC/Racks.}}
{{cassandra.bootstrap.include_sources is used to specify ip address/port of the
specific nodes to stream from.}}
h2. Motivation
Currently, when the node failure happens in the middle of the major cluster
upgrade, general advice given to the user is to complete the upgrade of the
cluster until all nodes are in the same version, and replace/remove the failed
node. This is because the streaming breaks when there is unsupported SSTable
version streamed from newer to the older.
This approach can create availability issue when two nodes (the failed node
from different rack and the node currently stopped for the upgrade) are down.
With this improvement, the user can replace the failed node using, for example,
specific rack in the same DC or another DC, to eliminate the availability issue
described above.
h2. Note
The user also needs to set "-Dcassandra.skip_schema_check=true" when replacing
the node during the major upgrade to complete the replacement.
was:
h2. Proposed improvement
Right now, the stream sources for the bootstrap are chosen from the closest
nodes (usually the same rack) of the bootstrapping node.
Add the following system properties so that when bootstrap happens, the node
can choose where to stream data from.
* {{cassandra.bootstrap.include_dcs}}
* {{cassandra.bootstrap.exclude_dcs}}
* {{cassandra.bootstrap.include_sources}}
{{cassandra.bootstrap.include_dcs and }}{{cassandra.bootstrap.exclude_dcs can
take args like "dc1,dc2" to specify DCs or "dc1:rack1,dc1:rack2,..." to specify
DC/Racks.}}
{{cassandra.bootstrap.include_sources is used to specify ip address/port of the
specific nodes to stream from.}}
h2. Motivation
Currently, when the node failure happens in the middle of the major cluster
upgrade, general advice given to the user is to complete the upgrade of the
cluster until all nodes are in the same version, and replace/remove the failed
node. This is because the streaming breaks when there is unsupported SSTable
version streamed from newer to the older.
This approach can create availability issue when two nodes (the failed node
from different rack and the node currently stopped for the upgrade) are down.
With this improvement, the user can replace the failed node using, for example,
specific rack in the same DC or another DC, to eliminate the availability issue
described above.
h2. Note
The user also needs to set "-Dcassandra.skip_schema_check=true" when replacing
the node during the major upgrade to complete the replacement.
> Add feature to filter streaming source when bootstrapping
> -
>
> Key: CASSANDRA-19733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19733
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Membership
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> h2. Proposed improvement
> Right now, the stream sources for the bootstrap are chosen from the closest
> nodes of the bootstrapping node.
> Add the following system properties so that when bootstrap happens, the node
> can choose where to stream data from.
> * {{cassandra.bootstrap.include_dcs}}
> * {{cassandra.bootstrap.exclude_dcs}}
> * {{cassandra.bootstrap.include_sources}}
> {{cassandra.bootstrap.include_dcs and }}{{cassandra.bootstrap.exclude_dcs can
> take args like "dc1,dc2" to specify DCs or "dc1:rack1,dc1:rack2,..." to
> specify DC/Racks.}}
> {{cassandra.bootstrap.include_sources is used to specify ip address/port of
> the specific nodes to stream from.}}
> h2. Motivation
> Currently, when the node failure happens in the middle of the major cluster
> upgrade, general advice given to the user is to complete the upgrade of the
> cluster until all nodes are in the same version, and replace/remove the
> failed node. This is because the streaming breaks when there is unsupported
> SSTable version streamed from newer to the older.
> This approach can create availability issue when two nodes (the failed node
> from different rack and the nod
[jira] [Updated] (CASSANDRA-19733) Add feature to filter streaming source when bootstrapping
[
https://issues.apache.org/jira/browse/CASSANDRA-19733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-19733:
---
Fix Version/s: 3.11.x
4.0.x
4.1.x
5.0.x
5.x
> Add feature to filter streaming source when bootstrapping
> -
>
> Key: CASSANDRA-19733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19733
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Membership
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> h2. Proposed improvement
> Right now, the stream sources for the bootstrap are chosen from the closest
> nodes (usually the same rack) of the bootstrapping node.
> Add the following system properties so that when bootstrap happens, the node
> can choose where to stream data from.
> * {{cassandra.bootstrap.include_dcs}}
> * {{cassandra.bootstrap.exclude_dcs}}
> * {{cassandra.bootstrap.include_sources}}
> {{cassandra.bootstrap.include_dcs and }}{{cassandra.bootstrap.exclude_dcs can
> take args like "dc1,dc2" to specify DCs or "dc1:rack1,dc1:rack2,..." to
> specify DC/Racks.}}
> {{cassandra.bootstrap.include_sources is used to specify ip address/port of
> the specific nodes to stream from.}}
> h2. Motivation
> Currently, when the node failure happens in the middle of the major cluster
> upgrade, general advice given to the user is to complete the upgrade of the
> cluster until all nodes are in the same version, and replace/remove the
> failed node. This is because the streaming breaks when there is unsupported
> SSTable version streamed from newer to the older.
> This approach can create availability issue when two nodes (the failed node
> from different rack and the node currently stopped for the upgrade) are down.
> With this improvement, the user can replace the failed node using, for
> example, specific rack in the same DC or another DC, to eliminate the
> availability issue described above.
> h2. Note
> The user also needs to set "-Dcassandra.skip_schema_check=true" when
> replacing the node during the major upgrade to complete the replacement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19733) Add feature to filter streaming source when bootstrapping
[
https://issues.apache.org/jira/browse/CASSANDRA-19733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita reassigned CASSANDRA-19733:
--
Assignee: Yuki Morishita
> Add feature to filter streaming source when bootstrapping
> -
>
> Key: CASSANDRA-19733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19733
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Membership
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Normal
>
> h2. Proposed improvement
> Right now, the stream sources for the bootstrap are chosen from the closest
> nodes (usually the same rack) of the bootstrapping node.
> Add the following system properties so that when bootstrap happens, the node
> can choose where to stream data from.
> * {{cassandra.bootstrap.include_dcs}}
> * {{cassandra.bootstrap.exclude_dcs}}
> * {{cassandra.bootstrap.include_sources}}
> {{cassandra.bootstrap.include_dcs and }}{{cassandra.bootstrap.exclude_dcs can
> take args like "dc1,dc2" to specify DCs or "dc1:rack1,dc1:rack2,..." to
> specify DC/Racks.}}
> {{cassandra.bootstrap.include_sources is used to specify ip address/port of
> the specific nodes to stream from.}}
> h2. Motivation
> Currently, when the node failure happens in the middle of the major cluster
> upgrade, general advice given to the user is to complete the upgrade of the
> cluster until all nodes are in the same version, and replace/remove the
> failed node. This is because the streaming breaks when there is unsupported
> SSTable version streamed from newer to the older.
> This approach can create availability issue when two nodes (the failed node
> from different rack and the node currently stopped for the upgrade) are down.
> With this improvement, the user can replace the failed node using, for
> example, specific rack in the same DC or another DC, to eliminate the
> availability issue described above.
> h2. Note
> The user also needs to set "-Dcassandra.skip_schema_check=true" when
> replacing the node during the major upgrade to complete the replacement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19733) Add feature to filter streaming source when bootstrapping
Yuki Morishita created CASSANDRA-19733:
--
Summary: Add feature to filter streaming source when bootstrapping
Key: CASSANDRA-19733
URL: https://issues.apache.org/jira/browse/CASSANDRA-19733
Project: Cassandra
Issue Type: Improvement
Components: Cluster/Membership
Reporter: Yuki Morishita
h2. Proposed improvement
Right now, the stream sources for the bootstrap are chosen from the closest
nodes (usually the same rack) of the bootstrapping node.
Add the following system properties so that when bootstrap happens, the node
can choose where to stream data from.
* {{cassandra.bootstrap.include_dcs}}
* {{cassandra.bootstrap.exclude_dcs}}
* {{cassandra.bootstrap.include_sources}}
{{cassandra.bootstrap.include_dcs and }}{{cassandra.bootstrap.exclude_dcs can
take args like "dc1,dc2" to specify DCs or "dc1:rack1,dc1:rack2,..." to specify
DC/Racks.}}
{{cassandra.bootstrap.include_sources is used to specify ip address/port of the
specific nodes to stream from.}}
h2. Motivation
Currently, when the node failure happens in the middle of the major cluster
upgrade, general advice given to the user is to complete the upgrade of the
cluster until all nodes are in the same version, and replace/remove the failed
node. This is because the streaming breaks when there is unsupported SSTable
version streamed from newer to the older.
This approach can create availability issue when two nodes (the failed node
from different rack and the node currently stopped for the upgrade) are down.
With this improvement, the user can replace the failed node using, for example,
specific rack in the same DC or another DC, to eliminate the availability issue
described above.
h2. Note
The user also needs to set "-Dcassandra.skip_schema_check=true" when replacing
the node during the major upgrade to complete the replacement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-8110) Make streaming forward & backwards compatible
[ https://issues.apache.org/jira/browse/CASSANDRA-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17772425#comment-17772425 ] Yuki Morishita commented on CASSANDRA-8110: --- [~jeromatron] I think it maybe sufficient for now (4.1 -> 5.0 upgrade). I think we need improvements for handling future changes though. Also, I'd like to test the streaming part in the mixed 4.1/5.0 version cluster, to see if we can safely replace the node during the upgrade. > Make streaming forward & backwards compatible > - > > Key: CASSANDRA-8110 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8110 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Streaming and Messaging >Reporter: Marcus Eriksson >Priority: Normal > Labels: gsoc2016, mentor > > To be able to seamlessly upgrade clusters we need to make it possible to > stream files between nodes with different StreamMessage.CURRENT_VERSION -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18336) Sstables were cleared when restarting
[
https://issues.apache.org/jira/browse/CASSANDRA-18336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711823#comment-17711823
]
Yuki Morishita commented on CASSANDRA-18336:
The `best_effort` behavior has been the same since 1.2.1. (CASSANDRA-4847)
> Sstables were cleared when restarting
> -
>
> Key: CASSANDRA-18336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18336
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: NAIZHEN QUE
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: 4031679897782_.pic.jpg, 4241679905694_.pic.jpg,
> system.log.2023-02-21.0
>
>
> 1.When this exception occurs in the system
> {code:java}
> //
> ERROR [CompactionExecutor:351627] 2023-02-21 17:59:20,721
> CassandraDaemon.java:581 - Exception in thread
> Thread[CompactionExecutor:351627,1,main]
> org.apache.cassandra.io.FSReadError: java.io.IOException: Map failed
> at org.apache.cassandra.io.util.ChannelProxy.map(ChannelProxy.java:167)
> at
> org.apache.cassandra.io.util.MmappedRegions$State.add(MmappedRegions.java:310)
> at
> org.apache.cassandra.io.util.MmappedRegions$State.access$400(MmappedRegions.java:246)
> at
> org.apache.cassandra.io.util.MmappedRegions.updateState(MmappedRegions.java:170)
> at
> org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:73)
> at
> org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:61)
> at
> org.apache.cassandra.io.util.MmappedRegions.map(MmappedRegions.java:104)
> at
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:365)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openEarly(BigTableWriter.java:337)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.maybeReopenEarly(SSTableRewriter.java:172)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:124)
> at
> org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:64)
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:137)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:193)
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:77)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:100)
> at
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:298)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.io.IOException: Map failed
> at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1016)
> at org.apache.cassandra.io.util.ChannelProxy.map(ChannelProxy.java:163)
> ... 23 common frames omitted
> Caused by: java.lang.OutOfMemoryError: Map failed
> at java.base/sun.nio.ch.FileChannelImpl.map0(Native Method)
> at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1013)
> {code}
> 2.Restart the node, Verifying logfile transaction ,All sstables are deleted
> {code:java}
> // code placeholder
> INFO [main] 2023-02-21 18:00:23,350 LogTransaction.java:240 - Unfinished
> transaction log, deleting
> /historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b/nb-8819408-big-Index.db
>
> INFO [main] 2023-02-21 18:00:23,615 LogTransaction.java:240 - Unfinished
> transaction log, deleting
> /historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b/nb-8819408-big-Data.db
>
> INFO [main] 2023-02-21 18:00:46,504 LogTransaction.java:240 - Unfinished
> transaction log, deleting
> /historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b/nb_txn_compaction_c923b230-b077-11ed-a081-5d5a5c990823.log
>
> INFO [main] 2023-02-21 18:00:46,510 LogTransaction.java:536 - Verifying
> logfile transaction
> [nb_txn_compaction_461935b0-b1ce-11ed-a081-5d5a5c990823.log in
> /historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b]
> INFO [main] 2023-02-21 18:00:46,517 LogTransaction.java:240 - Unfinished
> transacti
[jira] [Comment Edited] (CASSANDRA-8110) Make streaming forward & backwards compatible
[ https://issues.apache.org/jira/browse/CASSANDRA-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17641705#comment-17641705 ] Yuki Morishita edited comment on CASSANDRA-8110 at 12/7/22 4:05 AM: I'd like to propose a possible solution to achieve the goal to allow streaming in the cluster with mixed versions of nodes, which typically happens when rolling upgrading the cluster. The current consensus of the node failure during the upgrade process is to continue upgrading the cluster and perform the node replacement after the nodes are in the same version, since the streaming across the different versions are prevented/not guaranteed to work. This behavior makes a large cluster upgrade that requires high availability nearly impossible, since rolling upgrades can create downtime with failed nodes. To achieve this goal, I propose the following changes to Apache Cassandra: * Use the same (old) SSTable version in the upgraded node to write SSTables, until all the nodes in the cluster are in the same Cassandra version ** SSTable version has been in gossip state (SSTABLE_VERSIONS) since CASSANDRA-15897. We can use this to determine which SSTable version to use in the upgraded node. ** We need to bring back old SSTableWriter implementations or implement versioned serialization to SSTableWriter. ** The nodes in the cluster can switch to a new SSTable version using Cassandra Version (RELEASE_VERSION) in gossip state. * Accept the stream from older version ** Right now, the streaming protocol version needs to be the same in sender and receiver. We need to relax this constraint. These two can be worked on separately. SSTable version fixation alone can allow mixed version streaming using the *current* streaming protocol version. For example, if SSTable version is updated with this feature in 5.0, and still use the same streaming protocol version, Cassandra 4.0/4.1 and 5.0 can still perform streaming (forward compatibility). If we want to extend this feature to older versions of Cassandra (backward compatibility), we need to add a streaming protocol compatible layer to understand previous versions of streaming protocol (if any). I'd like to hear opinions about this approach from the community, and if it seems feasible, I'd like to start implementing this change. was (Author: yukim): I'd like to propose a possible solution to achieve the goal to allow streaming in the cluster with mixed versions of nodes, which typically happens when rolling upgrading the cluster. The current consensus of the node failure during the upgrade process is to continue upgrading the cluster and perform the node replacement after the nodes are in the same version, since the streaming across the different versions are prevented/not guaranteed to work. This behavior makes a large cluster upgrade that requires high availability nearly impossible, since rolling upgrades can create downtime with failed nodes. To achieve this goal, I propose the following changes to Apache Cassandra: * Use the same (old) SSTable version in the upgraded node to write SSTables, until all the nodes in the cluster are in the same Cassandra version * SSTable version has been in gossip state (SSTABLE_VERSIONS) since CASSANDRA-15897. We can use this to determine which SSTable version to use in the upgraded node. * We need to bring back old SSTableWriter implementations or implement versioned serialization to SSTableWriter. * The nodes in the cluster can switch to a new SSTable version using Cassandra Version (RELEASE_VERSION) in gossip state. * Accept the stream from older version * Right now, the streaming protocol version needs to be the same in sender and receiver. We need to relax this constraint. These two can be worked on separately. SSTable version fixation alone can allow mixed version streaming using the *current* streaming protocol version. For example, if SSTable version is updated with this feature in 5.0, and still use the same streaming protocol version, Cassandra 4.0/4.1 and 5.0 can still perform streaming (forward compatibility). If we want to extend this feature to older versions of Cassandra (backward compatibility), we need to add a streaming protocol compatible layer to understand previous versions of streaming protocol (if any). I'd like to hear opinions about this approach from the community, and if it seems feasible, I'd like to start implementing this change. > Make streaming forward & backwards compatible > - > > Key: CASSANDRA-8110 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8110 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Streaming and Messaging >Reporter: Marcus Eriksson >Priority: Normal >
[jira] [Commented] (CASSANDRA-8110) Make streaming forward & backwards compatible
[ https://issues.apache.org/jira/browse/CASSANDRA-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17641705#comment-17641705 ] Yuki Morishita commented on CASSANDRA-8110: --- I'd like to propose a possible solution to achieve the goal to allow streaming in the cluster with mixed versions of nodes, which typically happens when rolling upgrading the cluster. The current consensus of the node failure during the upgrade process is to continue upgrading the cluster and perform the node replacement after the nodes are in the same version, since the streaming across the different versions are prevented/not guaranteed to work. This behavior makes a large cluster upgrade that requires high availability nearly impossible, since rolling upgrades can create downtime with failed nodes. To achieve this goal, I propose the following changes to Apache Cassandra: * Use the same (old) SSTable version in the upgraded node to write SSTables, until all the nodes in the cluster are in the same Cassandra version * SSTable version has been in gossip state (SSTABLE_VERSIONS) since CASSANDRA-15897. We can use this to determine which SSTable version to use in the upgraded node. * We need to bring back old SSTableWriter implementations or implement versioned serialization to SSTableWriter. * The nodes in the cluster can switch to a new SSTable version using Cassandra Version (RELEASE_VERSION) in gossip state. * Accept the stream from older version * Right now, the streaming protocol version needs to be the same in sender and receiver. We need to relax this constraint. These two can be worked on separately. SSTable version fixation alone can allow mixed version streaming using the *current* streaming protocol version. For example, if SSTable version is updated with this feature in 5.0, and still use the same streaming protocol version, Cassandra 4.0/4.1 and 5.0 can still perform streaming (forward compatibility). If we want to extend this feature to older versions of Cassandra (backward compatibility), we need to add a streaming protocol compatible layer to understand previous versions of streaming protocol (if any). I'd like to hear opinions about this approach from the community, and if it seems feasible, I'd like to start implementing this change. > Make streaming forward & backwards compatible > - > > Key: CASSANDRA-8110 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8110 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Streaming and Messaging >Reporter: Marcus Eriksson >Priority: Normal > Labels: gsoc2016, mentor > > To be able to seamlessly upgrade clusters we need to make it possible to > stream files between nodes with different StreamMessage.CURRENT_VERSION -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16171) Remove Windows scripts
[ https://issues.apache.org/jira/browse/CASSANDRA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17633599#comment-17633599 ] Yuki Morishita commented on CASSANDRA-16171: > So my question comes this way: Is it reasonable that I cannot launch >Cassandra built from nowadays trunk branch with scripts for windows on release >3.11.14 ? I'm not sure, you can try. Though I believe launching Cassandra from trunk is still possible from IDE (I think some devs use Windows to develop Cassandra), and from tools like [https://github.com/riptano/ccm.] > Remove Windows scripts > -- > > Key: CASSANDRA-16171 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16171 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Normal > Fix For: 4.0-beta4, 4.0 > > Time Spent: 20m > Remaining Estimate: 0h > > As per the email thread in cassandra-dev mailing list[1], remove windows > scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests. > 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.html -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16171) Remove Windows scripts
[
https://issues.apache.org/jira/browse/CASSANDRA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17633460#comment-17633460
]
Yuki Morishita commented on CASSANDRA-16171:
Hi [~bigreybear] ,
I'm not sure which window script you are referring ("existed in release (4.3.0)
edition"), but the windows scripts were broken since Java11 support was
introduced in CASSANDRA-9608 (see CASSANDRA-14608).
Fix for CASSANDRA-14608 was posted, but decided to drop support for Windows
instead of fixing it in 4.0, due to the lack of testing.
> Remove Windows scripts
> --
>
> Key: CASSANDRA-16171
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16171
> Project: Cassandra
> Issue Type: Task
> Components: Packaging
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Normal
> Fix For: 4.0-beta4, 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As per the email thread in cassandra-dev mailing list[1], remove windows
> scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests.
> 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16535) Fail to init Cassandra Startup with an API connected with other cluster machines (3.11.9 version)
[ https://issues.apache.org/jira/browse/CASSANDRA-16535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-16535: --- Reviewers: Yuki Morishita > Fail to init Cassandra Startup with an API connected with other cluster > machines (3.11.9 version) > - > > Key: CASSANDRA-16535 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16535 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Aramis >Assignee: Aramis >Priority: Normal > Fix For: 3.11.11 > > Attachments: cassandra_modified.ps1, > image-2021-03-24-21-12-32-709.png, image-2021-03-24-21-13-46-704.png > > > The code in the function "VerifyPortsAreAvailable", look for the ports: 7000, > 9042, 7199 and 9160 in the "netstat -an" command output. > > If we have an API connected to the cluster in a node, and we try to start the > execution of cassandra (with that API working, accesing ports 9042 of the > other cluster machines), the output of that command return us that the port > is already in use, and Cassandra´s startup process fails, showing the output > message : "port already in use" in the .log file. > Thus, if we change the code of the function, adding the line: " -and $line > -match "LISTENING" ", just next to the "$line -match "TCP" ", we will only > interrupt the execution if the load port is in the state: "LISTENING", but no > if it´s an active connection on the other node of the cluster. > !image-2021-03-24-21-12-32-709.png|width=470,height=159! > !image-2021-03-24-21-13-46-704.png|width=526,height=119! -- 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-16171) Remove Windows scripts
[ https://issues.apache.org/jira/browse/CASSANDRA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241994#comment-17241994 ] Yuki Morishita commented on CASSANDRA-16171: Sorry, I appreciate if you can merge the change. > Remove Windows scripts > -- > > Key: CASSANDRA-16171 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16171 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > As per the email thread in cassandra-dev mailing list[1], remove windows > scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests. > 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.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-16171) Remove Windows scripts
[ https://issues.apache.org/jira/browse/CASSANDRA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241448#comment-17241448 ] Yuki Morishita commented on CASSANDRA-16171: [~Bereng] Sure, I'm fine with this gets merged. Thanks! > Remove Windows scripts > -- > > Key: CASSANDRA-16171 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16171 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > As per the email thread in cassandra-dev mailing list[1], remove windows > scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests. > 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.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-16173) Update "Getting Started" document for Windows users
[ https://issues.apache.org/jira/browse/CASSANDRA-16173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233594#comment-17233594 ] Yuki Morishita commented on CASSANDRA-16173: I meant this ticket to be adding the doc for Windows users how to run Cassandra on Windows after we removed all the scripts. So in that sense, this is a dupe for CASSANDRA-15887. And in my opinion, it is mandatory for 4.0 to add how to run on windows using WSL2/Docker, which is CASSANDRA-15887. > Update "Getting Started" document for Windows users > --- > > Key: CASSANDRA-16173 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16173 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Yuki Morishita >Priority: Normal > Fix For: 4.0 > > > This is a documentation follow up to CASSANDRA-16171. > Since we are removing support for Windows, we should update ["Getting > Started" > guide|https://cassandra.apache.org/doc/latest/getting_started/index.html] to > include how-to's for Windows users for setting up Cassandra for dev > evnironment. -- 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-16171) Remove Windows scripts
[
https://issues.apache.org/jira/browse/CASSANDRA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17228404#comment-17228404
]
Yuki Morishita commented on CASSANDRA-16171:
Thanks for the comment.
I'd like this ticket to just remove windows scripts (*.bat / *.ps1) from the
release artifact, as those are broken and should be a blocker for 4.0 GA
release.
{quote}We should add a note in docs about the removal, explanation and the
workaround for current Windows users. NEWS file is not enough imo. Otherwise
.bat scripts will just be gone with no explanation for them
We should remove from docs all references to Windows (grep -ri window in doc
folder) imo
{quote}
Yes we should, and these two can be handled in CASSANDRA-16173
{quote}We should run tests and also check test artifacts generation are not
broken.
{quote}
Agree. I will submit CI to run tests.
I don't think we have automated test to check artifacts generation, right?
{quote}Should we create a ticket to simplify the code by removing Windows
support from the code/pytests? There seems to be a bit of that
{quote}
There are many places that can be removed from the code, so eventually we can
remove those in the future.
> Remove Windows scripts
> --
>
> Key: CASSANDRA-16171
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16171
> Project: Cassandra
> Issue Type: Task
> Components: Packaging
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As per the email thread in cassandra-dev mailing list[1], remove windows
> scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests.
> 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.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-16171) Remove Windows scripts
[ https://issues.apache.org/jira/browse/CASSANDRA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17227386#comment-17227386 ] Yuki Morishita commented on CASSANDRA-16171: Sorry for delay. Updated my PR with: * removing install instruction from README * removing .bat/.ps1 ref from build.xml / rpm spec I think we don't have to touch CHANGES/NEWS. I left make.bat for doc, it is for development and it does not go into release artifacts. > Remove Windows scripts > -- > > Key: CASSANDRA-16171 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16171 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > As per the email thread in cassandra-dev mailing list[1], remove windows > scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests. > 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.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] [Updated] (CASSANDRA-16171) Remove Windows scripts
[ https://issues.apache.org/jira/browse/CASSANDRA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-16171: --- Status: Patch Available (was: In Progress) > Remove Windows scripts > -- > > Key: CASSANDRA-16171 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16171 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > As per the email thread in cassandra-dev mailing list[1], remove windows > scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests. > 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.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] [Updated] (CASSANDRA-16171) Remove Windows scripts
[ https://issues.apache.org/jira/browse/CASSANDRA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-16171: --- Status: In Progress (was: Changes Suggested) > Remove Windows scripts > -- > > Key: CASSANDRA-16171 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16171 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > As per the email thread in cassandra-dev mailing list[1], remove windows > scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests. > 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.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] [Updated] (CASSANDRA-16171) Remove Windows scripts
[ https://issues.apache.org/jira/browse/CASSANDRA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-16171: --- Test and Documentation Plan: Alternative setup for Windows users should be documented. See CASSANDRA-16173. Status: Patch Available (was: Open) [https://github.com/apache/cassandra/pull/765] PR removes all the *.bat and *.ps1 scripts, as well as reference to the files from cqlshlib test and the doc. > Remove Windows scripts > -- > > Key: CASSANDRA-16171 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16171 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > As per the email thread in cassandra-dev mailing list[1], remove windows > scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests. > 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.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] [Updated] (CASSANDRA-16171) Remove Windows scripts
[ https://issues.apache.org/jira/browse/CASSANDRA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-16171: --- Change Category: Quality Assurance Complexity: Normal Component/s: Packaging Status: Open (was: Triage Needed) > Remove Windows scripts > -- > > Key: CASSANDRA-16171 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16171 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > As per the email thread in cassandra-dev mailing list[1], remove windows > scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests. > 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.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] [Updated] (CASSANDRA-16171) Remove Windows scripts
[ https://issues.apache.org/jira/browse/CASSANDRA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-16171: --- Platform: Windows (was: All) > Remove Windows scripts > -- > > Key: CASSANDRA-16171 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16171 > Project: Cassandra > Issue Type: Task >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > As per the email thread in cassandra-dev mailing list[1], remove windows > scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests. > 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.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] [Assigned] (CASSANDRA-16171) Remove Windows scripts
[ https://issues.apache.org/jira/browse/CASSANDRA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita reassigned CASSANDRA-16171: -- Assignee: Yuki Morishita > Remove Windows scripts > -- > > Key: CASSANDRA-16171 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16171 > Project: Cassandra > Issue Type: Task >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Normal > Fix For: 4.0-rc > > Time Spent: 10m > Remaining Estimate: 0h > > As per the email thread in cassandra-dev mailing list[1], remove windows > scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests. > 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.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] [Created] (CASSANDRA-16173) Update "Getting Started" document for Windows users
Yuki Morishita created CASSANDRA-16173: -- Summary: Update "Getting Started" document for Windows users Key: CASSANDRA-16173 URL: https://issues.apache.org/jira/browse/CASSANDRA-16173 Project: Cassandra Issue Type: Task Reporter: Yuki Morishita This is a documentation follow up to CASSANDRA-16171. Since we are removing support for Windows, we should update ["Getting Started" guide|https://cassandra.apache.org/doc/latest/getting_started/index.html] to include how-to's for Windows users for setting up Cassandra for dev evnironment. -- 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-16171) Remove Windows scripts
[ https://issues.apache.org/jira/browse/CASSANDRA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-16171: --- Fix Version/s: 4.0-rc > Remove Windows scripts > -- > > Key: CASSANDRA-16171 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16171 > Project: Cassandra > Issue Type: Task >Reporter: Yuki Morishita >Priority: Normal > Fix For: 4.0-rc > > > As per the email thread in cassandra-dev mailing list[1], remove windows > scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests. > 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.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] [Created] (CASSANDRA-16171) Remove Windows scripts
Yuki Morishita created CASSANDRA-16171: -- Summary: Remove Windows scripts Key: CASSANDRA-16171 URL: https://issues.apache.org/jira/browse/CASSANDRA-16171 Project: Cassandra Issue Type: Task Reporter: Yuki Morishita As per the email thread in cassandra-dev mailing list[1], remove windows scripts from Cassandra 4.0 onwards, due to the lack of maintenance and tests. 1: https://www.mail-archive.com/dev@cassandra.apache.org/msg15583.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-15586) 4.0 quality testing: Cluster Setup and Maintenance
[ https://issues.apache.org/jira/browse/CASSANDRA-15586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206241#comment-17206241 ] Yuki Morishita commented on CASSANDRA-15586: Hi Josh and Ekaterina, Yes, the plan is to open two tickets, one for removing Windows scripts and one for updating docs. I have patch for the former, so I will work on that right away. > 4.0 quality testing: Cluster Setup and Maintenance > -- > > Key: CASSANDRA-15586 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15586 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Josh McKenzie >Assignee: Ekaterina Dimitrova >Priority: Normal > Labels: 4.0-QA > Fix For: 4.0-beta, 4.0-triage > > > We want 4.0 to be easy for users to setup out of the box and just work. This > means having low friction when users download the Cassandra package and start > running it. For example, users should be able to easily configure and start > new 4.0 clusters and have tokens distributed evenly. Another example is > packaging, it should be easy to install Cassandra on all supported platforms > (e.g. packaging) and have Cassandra use standard platform integrations. -- 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-14608) Confirm correctness of windows scripts post-9608
[ https://issues.apache.org/jira/browse/CASSANDRA-14608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-14608: --- Fix Version/s: 4.0-rc > Confirm correctness of windows scripts post-9608 > > > Key: CASSANDRA-14608 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14608 > Project: Cassandra > Issue Type: Task > Environment: Windows >Reporter: Jason Brown >Priority: Urgent > Fix For: 4.0-rc > > > In CASSANDRA-9608, we chose to defer making all the changes to Windows > scripts. This ticket is to ensure that we do that work. -- 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-14608) Confirm correctness of windows scripts post-9608
[ https://issues.apache.org/jira/browse/CASSANDRA-14608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-14608: --- Authors: Yuki Morishita Test and Documentation Plan: The patch needs Windows environment with JDK8/JDK11 for review. There is no windows CI environments at the moment. Status: Patch Available (was: Open) [https://github.com/apache/cassandra/pull/701] Patch to read corresponding jvm-*.options based on java version. Also removed Sigar lib since it does not work for JDK11 and the recent JDK8. > Confirm correctness of windows scripts post-9608 > > > Key: CASSANDRA-14608 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14608 > Project: Cassandra > Issue Type: Task > Environment: Windows >Reporter: Jason Brown >Priority: Urgent > > In CASSANDRA-9608, we chose to defer making all the changes to Windows > scripts. This ticket is to ensure that we do that work. -- 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-15572) `object of type 'NoneType' has no len()` error in cqlsh with python 3
[
https://issues.apache.org/jira/browse/CASSANDRA-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-15572:
---
Status: Triage Needed (was: Awaiting Feedback)
> `object of type 'NoneType' has no len()` error in cqlsh with python 3
> -
>
> Key: CASSANDRA-15572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15572
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tool/cqlsh
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Normal
>
> Looks like in Python 3, webbrowser._tryorder can be NoneType and throw error
> like below:
> {code}
> Traceback (most recent call last):
> File ".\bin\cqlsh.py", line 99, in
> if len(webbrowser._tryorder) == 0:
> TypeError: object of type 'NoneType' has no len()
> {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] [Commented] (CASSANDRA-15572) `object of type 'NoneType' has no len()` error in cqlsh with python 3
[
https://issues.apache.org/jira/browse/CASSANDRA-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076048#comment-17076048
]
Yuki Morishita commented on CASSANDRA-15572:
I think we can just commit the patch and see if we can progress further to
explore python 3.7+.
If we need to patch cqlsh.bat, I will create the separate ticket.
> `object of type 'NoneType' has no len()` error in cqlsh with python 3
> -
>
> Key: CASSANDRA-15572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15572
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tool/cqlsh
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Normal
>
> Looks like in Python 3, webbrowser._tryorder can be NoneType and throw error
> like below:
> {code}
> Traceback (most recent call last):
> File ".\bin\cqlsh.py", line 99, in
> if len(webbrowser._tryorder) == 0:
> TypeError: object of type 'NoneType' has no len()
> {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] [Updated] (CASSANDRA-15662) cqlsh tests won't run on jdk1.8 (regression from CASSANDRA-10190)
[
https://issues.apache.org/jira/browse/CASSANDRA-15662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-15662:
---
Status: Ready to Commit (was: Review In Progress)
The scope of the ticket is to cqlsh tests, and confirmed it is running on CI.
+1.
> cqlsh tests won't run on jdk1.8 (regression from CASSANDRA-10190)
> --
>
> Key: CASSANDRA-15662
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15662
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Running the cqlsh tests on jdk1.8 no longer work.
> The commit {{bf9a1d487b}} for CASSANDRA-10190 broke this, by defaulting
> {{CASSANDRA_USE_JDK11}} to true. See
> https://github.com/apache/cassandra/commit/bf9a1d487b9ba469e8d740cf7d1cd419535a7e79#diff-90e40e02845884b66e9006b25250ea5cR36-R38
> The following three work…
> {code}
> jenv shell 1.8
> export CASSANDRA_USE_JDK11=false
> ./pylib/cassandra-cqlsh-tests.sh `pwd`
> {code}
> {code}
> jenv shell 11.0
> export CASSANDRA_USE_JDK11=true
> ./pylib/cassandra-cqlsh-tests.sh `pwd`
> {code}
> {code}
> jenv shell 1.8
> unset CASSANDRA_USE_JDK11
> ./pylib/cassandra-cqlsh-tests.sh `pwd`
> {code}
> The following does not…
> {code}
> jenv shell 1.8
> ./pylib/cassandra-cqlsh-tests.sh `pwd`
> {code}
> {noformat}
> BUILD FAILED
> /Users/mick/src/apache/casSANDRA/build.xml:292: -Duse.jdk11=true or
> $CASSANDRA_USE_JDK11=true cannot be set when building from java 8
> {noformat}
> JDK 1.8 is expected to be the default. With {{CASSANDRA_USE_JDK11}} being
> defined if/when JDK 11 is used.
--
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-15662) cqlsh tests won't run on jdk1.8 (regression from CASSANDRA-10190)
[
https://issues.apache.org/jira/browse/CASSANDRA-15662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-15662:
---
Reviewers: Yuki Morishita, Yuki Morishita (was: Yuki Morishita)
Yuki Morishita, Yuki Morishita
Status: Review In Progress (was: Patch Available)
> cqlsh tests won't run on jdk1.8 (regression from CASSANDRA-10190)
> --
>
> Key: CASSANDRA-15662
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15662
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Running the cqlsh tests on jdk1.8 no longer work.
> The commit {{bf9a1d487b}} for CASSANDRA-10190 broke this, by defaulting
> {{CASSANDRA_USE_JDK11}} to true. See
> https://github.com/apache/cassandra/commit/bf9a1d487b9ba469e8d740cf7d1cd419535a7e79#diff-90e40e02845884b66e9006b25250ea5cR36-R38
> The following three work…
> {code}
> jenv shell 1.8
> export CASSANDRA_USE_JDK11=false
> ./pylib/cassandra-cqlsh-tests.sh `pwd`
> {code}
> {code}
> jenv shell 11.0
> export CASSANDRA_USE_JDK11=true
> ./pylib/cassandra-cqlsh-tests.sh `pwd`
> {code}
> {code}
> jenv shell 1.8
> unset CASSANDRA_USE_JDK11
> ./pylib/cassandra-cqlsh-tests.sh `pwd`
> {code}
> The following does not…
> {code}
> jenv shell 1.8
> ./pylib/cassandra-cqlsh-tests.sh `pwd`
> {code}
> {noformat}
> BUILD FAILED
> /Users/mick/src/apache/casSANDRA/build.xml:292: -Duse.jdk11=true or
> $CASSANDRA_USE_JDK11=true cannot be set when building from java 8
> {noformat}
> JDK 1.8 is expected to be the default. With {{CASSANDRA_USE_JDK11}} being
> defined if/when JDK 11 is used.
--
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] [Assigned] (CASSANDRA-15573) Python 3.8 fails to execute cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-15573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita reassigned CASSANDRA-15573:
--
Assignee: Yuki Morishita
> Python 3.8 fails to execute cqlsh
> -
>
> Key: CASSANDRA-15573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15573
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tool/cqlsh
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Normal
>
> Python 3.8 renamed sre_parse.Pattern to sre_parse.State (see
> https://bugs.python.org/issue34681 and corresponding pull request
> https://github.com/python/cpython/pull/9310)
> So when executing cqlsh with Python 3.8, it throws error:
> {code}
> Traceback (most recent call last):
> File ".\bin\cqlsh.py", line 175, in
> from cqlshlib import cql3handling, cqlhandling, pylexotron, sslhandling,
> cqlshhandling
> File "C:\Users\Yuki
> Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\cql3handling.py", line 19,
> in
> from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint
> File "C:\Users\Yuki
> Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\cqlhandling.py", line 23,
> in
> from cqlshlib import pylexotron, util
> File "C:\Users\Yuki
> Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\pylexotron.py", line 342,
> in
> class ParsingRuleSet:
> File "C:\Users\Yuki
> Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\pylexotron.py", line 343,
> in ParsingRuleSet
> RuleSpecScanner = SaferScanner([
> File "C:\Users\Yuki
> Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\saferscanner.py", line 74,
> in __init__
> s = re.sre_parse.Pattern()
> AttributeError: module 'sre_parse' has no attribute 'Pattern'
> {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] [Updated] (CASSANDRA-15572) `object of type 'NoneType' has no len()` error in cqlsh with python 3
[
https://issues.apache.org/jira/browse/CASSANDRA-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-15572:
---
Parent: CASSANDRA-15659
Workflow: Cassandra Default Workflow (was: Cassandra Bug Workflow)
Issue Type: Sub-task (was: Bug)
> `object of type 'NoneType' has no len()` error in cqlsh with python 3
> -
>
> Key: CASSANDRA-15572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15572
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tool/cqlsh
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Normal
>
> Looks like in Python 3, webbrowser._tryorder can be NoneType and throw error
> like below:
> {code}
> Traceback (most recent call last):
> File ".\bin\cqlsh.py", line 99, in
> if len(webbrowser._tryorder) == 0:
> TypeError: object of type 'NoneType' has no len()
> {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] [Updated] (CASSANDRA-15573) Python 3.8 fails to execute cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-15573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-15573:
---
Parent: CASSANDRA-15659
Workflow: Cassandra Default Workflow (was: Cassandra Bug Workflow)
Issue Type: Sub-task (was: Bug)
> Python 3.8 fails to execute cqlsh
> -
>
> Key: CASSANDRA-15573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15573
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tool/cqlsh
>Reporter: Yuki Morishita
>Priority: Normal
>
> Python 3.8 renamed sre_parse.Pattern to sre_parse.State (see
> https://bugs.python.org/issue34681 and corresponding pull request
> https://github.com/python/cpython/pull/9310)
> So when executing cqlsh with Python 3.8, it throws error:
> {code}
> Traceback (most recent call last):
> File ".\bin\cqlsh.py", line 175, in
> from cqlshlib import cql3handling, cqlhandling, pylexotron, sslhandling,
> cqlshhandling
> File "C:\Users\Yuki
> Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\cql3handling.py", line 19,
> in
> from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint
> File "C:\Users\Yuki
> Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\cqlhandling.py", line 23,
> in
> from cqlshlib import pylexotron, util
> File "C:\Users\Yuki
> Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\pylexotron.py", line 342,
> in
> class ParsingRuleSet:
> File "C:\Users\Yuki
> Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\pylexotron.py", line 343,
> in ParsingRuleSet
> RuleSpecScanner = SaferScanner([
> File "C:\Users\Yuki
> Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\saferscanner.py", line 74,
> in __init__
> s = re.sre_parse.Pattern()
> AttributeError: module 'sre_parse' has no attribute 'Pattern'
> {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] [Commented] (CASSANDRA-15659) Better support of Python 3 for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-15659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17068341#comment-17068341 ] Yuki Morishita commented on CASSANDRA-15659: Hi, I filed a few python 3 related tickets, and I'd like to work to improve supports for more recent version of python 3. My suggestion is to make this ticket as an umbrella for all the improvements we will make for better support of python 3. I will link to the tickets as a starter. > Better support of Python 3 for cqlsh > > > Key: CASSANDRA-15659 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15659 > Project: Cassandra > Issue Type: Task > Components: Tool/cqlsh >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-alpha > > > From mailing list: > [https://lists.apache.org/thread.html/r377099b632c62b641e4feef5b738084fc5369b0c7157fae867853597%40%3Cdev.cassandra.apache.org%3E] > > As of today (24/3/2020) and current trunk, there is Python 3.6 supported (1) > but there is not any 3.6 version ootb in Debian for example. E.g. Buster has > Python 3.7 and other (recent) releases have version 2.7. This means that if > one wants to use Python 3 in Debian, he has to use 3.6 but it is not in the > repository so he has to download / compile / install it on his own. > There should be some sane Python 3 version supported which is as well present > in Debian repository (or requirement to run with 3.6 should be relaxed) . > (1) > [https://github.com/apache/cassandra/blob/bf9a1d487b9ba469e8d740cf7d1cd419535a7e79/bin/cqlsh#L57-L65] -- 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-15625) Nodetool toppartitions error
[ https://issues.apache.org/jira/browse/CASSANDRA-15625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17058434#comment-17058434 ] Yuki Morishita commented on CASSANDRA-15625: I've seen this error before for C* 3.0. The cause of the error was CASSANDRA-9241, which is only fixed for 3.x. I suggest you to upgrade to the latest 3.11.x if possible. > Nodetool toppartitions error > > > Key: CASSANDRA-15625 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15625 > Project: Cassandra > Issue Type: Bug >Reporter: Antonio >Assignee: Sam Tunnicliffe >Priority: Normal > > c* version :3.0.15 > here's my test table： > CREATE TABLE app300.test ( > a bigint PRIMARY KEY, > b text, > c text > ) > INSERT INTO app300.test(a ,b, c ) VALUES (50, 'test1', 'test1'); > when i use topartition ：nodetool toppartitions app300 test 50，get error > error: Expected 8 or 0 byte long (1048576) > -- StackTrace -- > org.apache.cassandra.serializers.MarshalException: Expected 8 or 0 byte long > (1048576) > at > org.apache.cassandra.serializers.LongSerializer.validate(LongSerializer.java:42) > at > org.apache.cassandra.db.marshal.AbstractType.getString(AbstractType.java:128) > at > org.apache.cassandra.db.ColumnFamilyStore.finishLocalSampling(ColumnFamilyStore.java:1579) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > but when i flush this table， topartition can work > -- 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-15573) Python 3.8 fails to execute cqlsh
Yuki Morishita created CASSANDRA-15573:
--
Summary: Python 3.8 fails to execute cqlsh
Key: CASSANDRA-15573
URL: https://issues.apache.org/jira/browse/CASSANDRA-15573
Project: Cassandra
Issue Type: Bug
Components: Tool/cqlsh
Reporter: Yuki Morishita
Python 3.8 renamed sre_parse.Pattern to sre_parse.State (see
https://bugs.python.org/issue34681 and corresponding pull request
https://github.com/python/cpython/pull/9310)
So when executing cqlsh with Python 3.8, it throws error:
{code}
Traceback (most recent call last):
File ".\bin\cqlsh.py", line 175, in
from cqlshlib import cql3handling, cqlhandling, pylexotron, sslhandling,
cqlshhandling
File "C:\Users\Yuki
Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\cql3handling.py", line 19,
in
from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint
File "C:\Users\Yuki
Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\cqlhandling.py", line 23, in
from cqlshlib import pylexotron, util
File "C:\Users\Yuki
Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\pylexotron.py", line 342, in
class ParsingRuleSet:
File "C:\Users\Yuki
Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\pylexotron.py", line 343, in
ParsingRuleSet
RuleSpecScanner = SaferScanner([
File "C:\Users\Yuki
Morishita\Projects\cassandra\bin\..\pylib\cqlshlib\saferscanner.py", line 74,
in __init__
s = re.sre_parse.Pattern()
AttributeError: module 'sre_parse' has no attribute 'Pattern'
{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] [Commented] (CASSANDRA-15572) `object of type 'NoneType' has no len()` error in cqlsh with python 3
[
https://issues.apache.org/jira/browse/CASSANDRA-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038000#comment-17038000
]
Yuki Morishita commented on CASSANDRA-15572:
Pull request here: https://github.com/apache/cassandra/pull/448
> `object of type 'NoneType' has no len()` error in cqlsh with python 3
> -
>
> Key: CASSANDRA-15572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15572
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Normal
>
> Looks like in Python 3, webbrowser._tryorder can be NoneType and throw error
> like below:
> {code}
> Traceback (most recent call last):
> File ".\bin\cqlsh.py", line 99, in
> if len(webbrowser._tryorder) == 0:
> TypeError: object of type 'NoneType' has no len()
> {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] [Assigned] (CASSANDRA-15572) `object of type 'NoneType' has no len()` error in cqlsh with python 3
[
https://issues.apache.org/jira/browse/CASSANDRA-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita reassigned CASSANDRA-15572:
--
Assignee: Yuki Morishita
> `object of type 'NoneType' has no len()` error in cqlsh with python 3
> -
>
> Key: CASSANDRA-15572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15572
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Normal
>
> Looks like in Python 3, webbrowser._tryorder can be NoneType and throw error
> like below:
> {code}
> Traceback (most recent call last):
> File ".\bin\cqlsh.py", line 99, in
> if len(webbrowser._tryorder) == 0:
> TypeError: object of type 'NoneType' has no len()
> {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] [Created] (CASSANDRA-15572) `object of type 'NoneType' has no len()` error in cqlsh with python 3
Yuki Morishita created CASSANDRA-15572:
--
Summary: `object of type 'NoneType' has no len()` error in cqlsh
with python 3
Key: CASSANDRA-15572
URL: https://issues.apache.org/jira/browse/CASSANDRA-15572
Project: Cassandra
Issue Type: Bug
Components: Tool/cqlsh
Reporter: Yuki Morishita
Looks like in Python 3, webbrowser._tryorder can be NoneType and throw error
like below:
{code}
Traceback (most recent call last):
File ".\bin\cqlsh.py", line 99, in
if len(webbrowser._tryorder) == 0:
TypeError: object of type 'NoneType' has no len()
{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] [Updated] (CASSANDRA-15300) 4.0 rpmbuild spec file is missing auditlogviewer and fqltool
[
https://issues.apache.org/jira/browse/CASSANDRA-15300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-15300:
---
Status: Open (was: Patch Available)
> 4.0 rpmbuild spec file is missing auditlogviewer and fqltool
>
>
> Key: CASSANDRA-15300
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15300
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Yuko Sakanaka
>Assignee: Yuko Sakanaka
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0
>
> Attachments: 15300-4.0.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The spec file on the current trunk branch (cassandra 4.0) is missing
> auditlogviewer and fqltool.
> I tried rpmbuild on trunk brunch, but it failed with unpacked files error.
> RPM build errors:
> Installed (but unpackaged) file(s) found:
> /usr/bin/auditlogviewer
> /usr/bin/fqltool
> I guess the committers will modify this file in the future because they are
> new features but I suggest that the following lines be added into the spec
> file.
>
> %attr(755,root,root) %\{_bindir}/auditlogviewer
> %attr(755,root,root) %\{_bindir}/fqltool
>
> thanks.
>
> [PATCH] Add auditlogviewer and fqltool into rpmbuild spec file. patch
> by ysakanaka; for CASSANDRA-15300
>
> —
> redhat/cassandra.spec | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/redhat/cassandra.spec b/redhat/cassandra.spec
> index eaf7565..0aedbd7 100644
> — a/redhat/cassandra.spec
> +++ b/redhat/cassandra.spec
> @@ -173,6 +173,8 @@ This package contains extra tools for working with
> Cassandra clusters.
> %attr(755,root,root) %\{_bindir}/sstableofflinerelevel
> %attr(755,root,root) %\{_bindir}/sstablerepairedset
> %attr(755,root,root) %\{_bindir}/sstablesplit
> +%attr(755,root,root) %\{_bindir}/auditlogviewer
> +%attr(755,root,root) %\{_bindir}/fqltool
>
>
> %changelog
> --
> 1.8.3.1
>
--
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-15300) 4.0 rpmbuild spec file is missing auditlogviewer and fqltool
[
https://issues.apache.org/jira/browse/CASSANDRA-15300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-15300:
---
Resolution: Fixed
Status: Resolved (was: Open)
Closing as fixed.
> 4.0 rpmbuild spec file is missing auditlogviewer and fqltool
>
>
> Key: CASSANDRA-15300
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15300
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Yuko Sakanaka
>Assignee: Yuko Sakanaka
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0
>
> Attachments: 15300-4.0.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The spec file on the current trunk branch (cassandra 4.0) is missing
> auditlogviewer and fqltool.
> I tried rpmbuild on trunk brunch, but it failed with unpacked files error.
> RPM build errors:
> Installed (but unpackaged) file(s) found:
> /usr/bin/auditlogviewer
> /usr/bin/fqltool
> I guess the committers will modify this file in the future because they are
> new features but I suggest that the following lines be added into the spec
> file.
>
> %attr(755,root,root) %\{_bindir}/auditlogviewer
> %attr(755,root,root) %\{_bindir}/fqltool
>
> thanks.
>
> [PATCH] Add auditlogviewer and fqltool into rpmbuild spec file. patch
> by ysakanaka; for CASSANDRA-15300
>
> —
> redhat/cassandra.spec | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/redhat/cassandra.spec b/redhat/cassandra.spec
> index eaf7565..0aedbd7 100644
> — a/redhat/cassandra.spec
> +++ b/redhat/cassandra.spec
> @@ -173,6 +173,8 @@ This package contains extra tools for working with
> Cassandra clusters.
> %attr(755,root,root) %\{_bindir}/sstableofflinerelevel
> %attr(755,root,root) %\{_bindir}/sstablerepairedset
> %attr(755,root,root) %\{_bindir}/sstablesplit
> +%attr(755,root,root) %\{_bindir}/auditlogviewer
> +%attr(755,root,root) %\{_bindir}/fqltool
>
>
> %changelog
> --
> 1.8.3.1
>
--
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-15300) 4.0 rpmbuild spec file is missing auditlogviewer and fqltool
[
https://issues.apache.org/jira/browse/CASSANDRA-15300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-15300:
---
Status: Patch Available (was: Review In Progress)
> 4.0 rpmbuild spec file is missing auditlogviewer and fqltool
>
>
> Key: CASSANDRA-15300
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15300
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Yuko Sakanaka
>Assignee: Yuko Sakanaka
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0
>
> Attachments: 15300-4.0.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The spec file on the current trunk branch (cassandra 4.0) is missing
> auditlogviewer and fqltool.
> I tried rpmbuild on trunk brunch, but it failed with unpacked files error.
> RPM build errors:
> Installed (but unpackaged) file(s) found:
> /usr/bin/auditlogviewer
> /usr/bin/fqltool
> I guess the committers will modify this file in the future because they are
> new features but I suggest that the following lines be added into the spec
> file.
>
> %attr(755,root,root) %\{_bindir}/auditlogviewer
> %attr(755,root,root) %\{_bindir}/fqltool
>
> thanks.
>
> [PATCH] Add auditlogviewer and fqltool into rpmbuild spec file. patch
> by ysakanaka; for CASSANDRA-15300
>
> —
> redhat/cassandra.spec | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/redhat/cassandra.spec b/redhat/cassandra.spec
> index eaf7565..0aedbd7 100644
> — a/redhat/cassandra.spec
> +++ b/redhat/cassandra.spec
> @@ -173,6 +173,8 @@ This package contains extra tools for working with
> Cassandra clusters.
> %attr(755,root,root) %\{_bindir}/sstableofflinerelevel
> %attr(755,root,root) %\{_bindir}/sstablerepairedset
> %attr(755,root,root) %\{_bindir}/sstablesplit
> +%attr(755,root,root) %\{_bindir}/auditlogviewer
> +%attr(755,root,root) %\{_bindir}/fqltool
>
>
> %changelog
> --
> 1.8.3.1
>
--
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-15300) 4.0 rpmbuild spec file is missing auditlogviewer and fqltool
[
https://issues.apache.org/jira/browse/CASSANDRA-15300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17036722#comment-17036722
]
Yuki Morishita commented on CASSANDRA-15300:
Looks like the fix for this is already committed in
[fc4381ca89ab39a82c9018e5171975285cc3bfe7|https://github.com/apache/cassandra/commit/fc4381ca89ab39a82c9018e5171975285cc3bfe7].
This can be closed.
> 4.0 rpmbuild spec file is missing auditlogviewer and fqltool
>
>
> Key: CASSANDRA-15300
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15300
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Yuko Sakanaka
>Assignee: Yuko Sakanaka
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0
>
> Attachments: 15300-4.0.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The spec file on the current trunk branch (cassandra 4.0) is missing
> auditlogviewer and fqltool.
> I tried rpmbuild on trunk brunch, but it failed with unpacked files error.
> RPM build errors:
> Installed (but unpackaged) file(s) found:
> /usr/bin/auditlogviewer
> /usr/bin/fqltool
> I guess the committers will modify this file in the future because they are
> new features but I suggest that the following lines be added into the spec
> file.
>
> %attr(755,root,root) %\{_bindir}/auditlogviewer
> %attr(755,root,root) %\{_bindir}/fqltool
>
> thanks.
>
> [PATCH] Add auditlogviewer and fqltool into rpmbuild spec file. patch
> by ysakanaka; for CASSANDRA-15300
>
> —
> redhat/cassandra.spec | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/redhat/cassandra.spec b/redhat/cassandra.spec
> index eaf7565..0aedbd7 100644
> — a/redhat/cassandra.spec
> +++ b/redhat/cassandra.spec
> @@ -173,6 +173,8 @@ This package contains extra tools for working with
> Cassandra clusters.
> %attr(755,root,root) %\{_bindir}/sstableofflinerelevel
> %attr(755,root,root) %\{_bindir}/sstablerepairedset
> %attr(755,root,root) %\{_bindir}/sstablesplit
> +%attr(755,root,root) %\{_bindir}/auditlogviewer
> +%attr(755,root,root) %\{_bindir}/fqltool
>
>
> %changelog
> --
> 1.8.3.1
>
--
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-15300) 4.0 rpmbuild spec file is missing auditlogviewer and fqltool
[
https://issues.apache.org/jira/browse/CASSANDRA-15300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-15300:
---
Reviewers: Yuki Morishita, Yuki Morishita (was: Yuki Morishita)
Yuki Morishita, Yuki Morishita
Status: Review In Progress (was: Patch Available)
> 4.0 rpmbuild spec file is missing auditlogviewer and fqltool
>
>
> Key: CASSANDRA-15300
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15300
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Yuko Sakanaka
>Assignee: Yuko Sakanaka
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0
>
> Attachments: 15300-4.0.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The spec file on the current trunk branch (cassandra 4.0) is missing
> auditlogviewer and fqltool.
> I tried rpmbuild on trunk brunch, but it failed with unpacked files error.
> RPM build errors:
> Installed (but unpackaged) file(s) found:
> /usr/bin/auditlogviewer
> /usr/bin/fqltool
> I guess the committers will modify this file in the future because they are
> new features but I suggest that the following lines be added into the spec
> file.
>
> %attr(755,root,root) %\{_bindir}/auditlogviewer
> %attr(755,root,root) %\{_bindir}/fqltool
>
> thanks.
>
> [PATCH] Add auditlogviewer and fqltool into rpmbuild spec file. patch
> by ysakanaka; for CASSANDRA-15300
>
> —
> redhat/cassandra.spec | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/redhat/cassandra.spec b/redhat/cassandra.spec
> index eaf7565..0aedbd7 100644
> — a/redhat/cassandra.spec
> +++ b/redhat/cassandra.spec
> @@ -173,6 +173,8 @@ This package contains extra tools for working with
> Cassandra clusters.
> %attr(755,root,root) %\{_bindir}/sstableofflinerelevel
> %attr(755,root,root) %\{_bindir}/sstablerepairedset
> %attr(755,root,root) %\{_bindir}/sstablesplit
> +%attr(755,root,root) %\{_bindir}/auditlogviewer
> +%attr(755,root,root) %\{_bindir}/fqltool
>
>
> %changelog
> --
> 1.8.3.1
>
--
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-15258) Cassandra Windows JDK11 not working
[ https://issues.apache.org/jira/browse/CASSANDRA-15258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-15258: --- Resolution: Duplicate Status: Resolved (was: Triage Needed) I close this one as a dupe for CASSANDRA-14608. I will work on fixing windows script there instead. > Cassandra Windows JDK11 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 >Assignee: Yuki Morishita >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-14608) Confirm correctness of windows scripts post-9608
[
https://issues.apache.org/jira/browse/CASSANDRA-14608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17035582#comment-17035582
]
Yuki Morishita commented on CASSANDRA-14608:
I don't think shipping broken script is a good idea, so I go ahead and updated
windows script:
[https://github.com/yukim/cassandra/tree/14608]
Patch contains:
* Java 8 / Java 11 support with new jvm properties files.
* Powershell 6+ support
I didn't test:
* "legacy" mode in cmd
* Install as windows service
I only updated powershell part, so I don't think running is not tested.
Note that I got the following error from sigar only when I'm using Java11 (java
8 runs fine with Sigar):
{code:java}
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x10014ed4, pid=27028,
tid=32152
#
# JRE version: OpenJDK Runtime Environment (11.0.2+9) (build 11.0.2+9)
# Java VM: OpenJDK 64-Bit Server VM (11.0.2+9, mixed mode, tiered, compressed
oops, concurrent mark sweep gc, windows-amd64)
# Problematic frame:
# C [sigar-amd64-winnt.dll+0x14ed4]
#
# No core dump will be written. Minidumps are not enabled by default on client
versions of Windows
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
# {code}
I'm not sure if this is my environment only or not, but if I remove sigar then
it works fine.
I don't mind supporting Windows for dev only because I know some orgs do not
allow running VM or docker on their machine, and running Cassandra directly on
windows helps in that situation.
> Confirm correctness of windows scripts post-9608
>
>
> Key: CASSANDRA-14608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14608
> Project: Cassandra
> Issue Type: Task
> Components: Packaging
> Environment: Windows
>Reporter: Jason Brown
>Priority: Urgent
> Labels: Java11, Windows
> Fix For: 4.0
>
>
> In CASSANDRA-9608, we chose to defer making all the changes to Windows
> scripts. This ticket is to ensure that we do that work.
--
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] [Assigned] (CASSANDRA-14608) Confirm correctness of windows scripts post-9608
[ https://issues.apache.org/jira/browse/CASSANDRA-14608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita reassigned CASSANDRA-14608: -- Assignee: Yuki Morishita > Confirm correctness of windows scripts post-9608 > > > Key: CASSANDRA-14608 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14608 > Project: Cassandra > Issue Type: Task > Components: Packaging > Environment: Windows >Reporter: Jason Brown >Assignee: Yuki Morishita >Priority: Urgent > Labels: Java11, Windows > Fix For: 4.0 > > > In CASSANDRA-9608, we chose to defer making all the changes to Windows > scripts. This ticket is to ensure that we do that work. -- 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-15258) Cassandra Windows JDK11 not working
[ https://issues.apache.org/jira/browse/CASSANDRA-15258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17026577#comment-17026577 ] Yuki Morishita commented on CASSANDRA-15258: jvm.options is now split into several files (jvm-server.options, jvm-client.options, etc) for 4.0 so cassandra.ps1 file needs to be updated in order to support running 4.0 on Windows. Let me work on patch for that. [~gus] the original description of this issue is for Windows start up script, so I will only fix that part. You should open another ticket if not done. > Cassandra Windows JDK11 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 >Assignee: Yuki Morishita >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] [Assigned] (CASSANDRA-15258) Cassandra Windows JDK11 not working
[ https://issues.apache.org/jira/browse/CASSANDRA-15258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita reassigned CASSANDRA-15258: -- Assignee: Yuki Morishita > Cassandra Windows JDK11 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 >Assignee: Yuki Morishita >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-15182) cqlsh utf_8.py, line 16, in decode return codecs.utf_8_decode(input, errors, True):1:'ascii' codec can't encode character u'\u9ed1' in position 60: ordi
[
https://issues.apache.org/jira/browse/CASSANDRA-15182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16873753#comment-16873753
]
Yuki Morishita commented on CASSANDRA-15182:
Hi [~gloCalHelp.com],
cqlsh is complaining when it is trying to output an error, since your original
CQL syntax is wrong (you have to provide some values for columns not like
',,,'.)
'Short' cql did not contain syntax error so it went through.
> cqlsh utf_8.py, line 16, in decode return codecs.utf_8_decode(input,
> errors, True):1:'ascii' codec can't encode character u'\u9ed1' in
> position 60: ordinal not in range(128)
>
>
> Key: CASSANDRA-15182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15182
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: gloCalHelp.com
>Priority: Normal
>
> I use cqlsh 5.0.1 with cassandra 3.11.3 with python2.7.13 in Centos 6.9.
> when I run this cql command: bin/cqlsh hadoop4 -u dba -p ** --debug
> -e "INSERT INTO HYGL_JCSJ.hyjg_ods_yy_gps_novar3
> (clcph,dwsj,bc,blbs,cjbzh,ckryid,clid,clmc,ddfx,ddrq,fwj,gd,gdjd,gdwd,jsdlc,jszjl,jxzjl,sjid,sjsfzh,sjxm,sssd,xlmc)
> VALUES
> ('黑A00888D','2019-06-2509:57:19',0,,'',,,'379-7038',1434,'2019-06-25',275,0,126723690,45726990
> ,796.0,2205,746,'null','null','null',0,'379');"
> I get the error message as below:
> Using CQL driver: '/home/cassandra/cas3.11.3/bin/../lib/cassandra-driver-internal-only-3.11.0-bb96859b.zip/cassandra-driver-3.11.0-bb96859b/cassandra/__init__.py'>
> Using connect timeout: 5 seconds
> Using 'utf-8' encoding
> Using ssl: False
> Traceback (most recent call last):
> File "/home/cassandra/cas3.11.3/bin/cqlsh.py", line 926, in onecmd
> self.handle_statement(st, statementtext)
> File "/home/cassandra/cas3.11.3/bin/cqlsh.py", line 966, in handle_statement
> return self.perform_statement(cqlruleset.cql_extract_orig(tokens, srcstr))
> File "/home/cassandra/cas3.11.3/bin/cqlsh.py", line 1000, in
> perform_statement
> success, future = self.perform_simple_statement(stmt)
> File "/home/cassandra/cas3.11.3/bin/cqlsh.py", line 1053, in
> perform_simple_statement
> self.printerr(unicode(err.__class__.__name__) + u": " +
> err.message.decode(encoding='utf-8'))
> File "/usr/local/python27/lib/python2.7/encodings/utf_8.py", line 16, in
> decode
> return codecs.utf_8_decode(input, errors, True)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u9ed1' in
> position 60: ordinal not in range(128)
>
> this issue seems different with the select command issue on
> https://issues.apache.org/jira/browse/CASSANDRA-10875
> and other method to add "-*- coding: utf-8 -*- " in the head of cqlsh.py ,
> can anyone hurry up to teach me?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14917) Nodetool netstats displays incorrect information on streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-14917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16706575#comment-16706575
]
Yuki Morishita commented on CASSANDRA-14917:
Are you using secondary indexes? Streaming is considered done after rebuilding
index.
So you will see no progress in netstats even if you have 100% sent files.
I think we can improve this somehow.
> Nodetool netstats displays incorrect information on streaming
> -
>
> Key: CASSANDRA-14917
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14917
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Igor Zubchenok
>Assignee: Dinesh Joshi
>Priority: Minor
>
> nodetool netstats command displays 'Sending 0 files' and non-zero 'bytes
> total' during node decommission.
> {code:java}
> Sending 0 files, 198933290919 bytes total. Already sent 0 files, 0 bytes total
> {code}
> Complete notetool netstats response
> {code:java}
> # nodetool netstats | grep -v 100%
> Mode: LEAVING
> Unbootstrap 67096090-f604-11e8--03532290668f
> /X.X.X.X
> Sending 8039 files, 174905861575 bytes total. Already sent 3147
> files, 39883605552 bytes total
>
> /var/lib/cassandra/data/app_tracks/tracks-bfd4a21086b711e7b6cbfd84ea9f1f78/mc-100884-big-Data.db
> 1866267759/8275615307 bytes(22%) sent to idx:0/5.9.54.111
> /X.X.X.X
> Sending 5475 files, 167399940563 bytes total. Already sent 2416
> files, 49417386715 bytes total
>
> /var/lib/cassandra/data/app_tracks/tracks-bd8310f086b711e7b6cbfd84ea9f1f78/mc-459374-big-Data.db
> 10192112/17529144 bytes(58%) sent to idx:0/5.9.59.101
> /X.X.X.X
> Sending 5843 files, 181124719187 bytes total. Already sent 2613
> files, 57001466824 bytes total
>
> /var/lib/cassandra/data/app_tracks/tracks-bd8310f086b711e7b6cbfd84ea9f1f78/mc-461873-big-Data.db
> 1439600/93308008 bytes(1%) sent to idx:0/46.4.31.97
> /X.X.X.X
> Sending 7303 files, 213976795121 bytes total. Already sent 1811
> files, 28956350780 bytes total
>
> /var/lib/cassandra/data/app_tracks/tracks-bfd4a21086b711e7b6cbfd84ea9f1f78/mc-100465-big-Data.db
> 3719051/37149976 bytes(10%) sent to idx:0/144.76.85.237
> /X.X.X.X
> Sending 7893 files, 204271020294 bytes total. Already sent 2397
> files, 36086600359 bytes total
>
> /var/lib/cassandra/data/app_tracks/tracks-bfd4a21086b711e7b6cbfd84ea9f1f78/mc-100197-big-Data.db
> 646314/8291439 bytes(7%) sent to idx:0/144.76.29.39
> /X.X.X.X
> Sending 0 files, 198933290919 bytes total. Already sent 0 files, 0
> bytes total
> /X.X.X.X
> Sending 6159 files, 187102577561 bytes total. Already sent 1526
> files, 26019708822 bytes total
>
> /var/lib/cassandra/data/app_tracks/tracks-bfd4a21086b711e7b6cbfd84ea9f1f78/mc-100685-big-Data.db
> 52211410/67213497 bytes(77%) sent to idx:0/144.76.85.182
> /X.X.X.X
> Sending 6534 files, 193239644509 bytes total. Already sent 2367
> files, 48105187871 bytes total
>
> /var/lib/cassandra/data/app_tracks/tracks-bfd4a21086b711e7b6cbfd84ea9f1f78/mc-100884-big-Data.db
> 5907583715/10068538729 bytes(58%) sent to idx:0/5.9.48.222
> /X.X.X.X
> Sending 5923 files, 213438389441 bytes total. Already sent 1663
> files, 32469866925 bytes total
> Read Repair Statistics:
> Attempted: 3537331
> Mismatch (Blocking): 2193
> Mismatch (Background): 4326
> Pool NameActive Pending Completed Dropped
> Large messages n/a18 87460 746
> Small messages n/a 8 9837560424 12410
> Gossip messages n/a 87666199 84717
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-14868) 安装出错
[ https://issues.apache.org/jira/browse/CASSANDRA-14868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita resolved CASSANDRA-14868. Resolution: Invalid The issue tracker here is for developing Apache Cassandra. You should report your issue to [https://github.com/Symantec/ambari-cassandra-service] (guessing from the stack trace). > 安装出错 > > > Key: CASSANDRA-14868 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14868 > Project: Cassandra > Issue Type: Bug > Environment: HDP 2.5 >Reporter: znn >Priority: Major > > Traceback (most recent call last): > File > "/var/lib/ambari-agent/cache/stacks/HDP/2.5/services/CASSANDRA/package/scripts/cassandra_master.py", > line 60, in > Cassandra_Master().execute() > File > "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py", > line 280, in execute > method(env) > File > "/var/lib/ambari-agent/cache/stacks/HDP/2.5/services/CASSANDRA/package/scripts/cassandra_master.py", > line 27, in install > import params > File > "/var/lib/ambari-agent/cache/stacks/HDP/2.5/services/CASSANDRA/package/scripts/params.py", > line 16, in > from resource_management.libraries.functions.version import > format_hdp_stack_version, compare_versions > ImportError: cannot import name format_hdp_stack_version -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12757) NPE if allocate_tokens_for_keyspace is typo/doesn't exist.
[
https://issues.apache.org/jira/browse/CASSANDRA-12757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16547483#comment-16547483
]
Yuki Morishita commented on CASSANDRA-12757:
Hi Damien,
Thanks for the patch.
My concern to your change is that it changes {{Keyspace.open}} method's
behavior. Right now it throws {{AssertionError}} stating that given keyspace
does not exist (if assertion is enabled which is default in Cassandra). It is
not perfect, but I prefer it stays the same than returning null resulting
{{NullPointerException}} without detail ({{Keyspace.open}} is used everywhere
without checking its returned value being null).
I think the original error happens if assertion is disabled. So, why don't we
check keyspace existence for this specific case?
> NPE if allocate_tokens_for_keyspace is typo/doesn't exist.
> --
>
> Key: CASSANDRA-12757
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12757
> Project: Cassandra
> Issue Type: Bug
> Components: Configuration
>Reporter: Jeremiah Jordan
>Assignee: Damien Stevenson
>Priority: Major
> Labels: lhf
> Fix For: 3.0.x, 3.11.x
>
>
> If the keyspace specified in allocate_tokens_for_keyspace does not exist you
> get an NPE. Should probably have a better error here letting people know
> what the issue was.
> {code}
> INFO 21:07:22,582 StorageService.java:1152 - JOINING: getting bootstrap
> token
> Exception (java.lang.NullPointerException) encountered during startup: null
> ERROR 21:07:22,590 CassandraDaemon.java:709 - Exception encountered during
> startup
> java.lang.NullPointerException: null
>at
> org.apache.cassandra.db.Keyspace.createReplicationStrategy(Keyspace.java:325)
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at org.apache.cassandra.db.Keyspace.(Keyspace.java:298)
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:201)
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:173)
> ~[cassandra-all-3.0.8:3.0.8]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12757) NPE if allocate_tokens_for_keyspace is typo/doesn't exist.
[
https://issues.apache.org/jira/browse/CASSANDRA-12757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-12757:
---
Reviewer: Yuki Morishita
> NPE if allocate_tokens_for_keyspace is typo/doesn't exist.
> --
>
> Key: CASSANDRA-12757
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12757
> Project: Cassandra
> Issue Type: Bug
> Components: Configuration
>Reporter: Jeremiah Jordan
>Assignee: Damien Stevenson
>Priority: Major
> Labels: lhf
> Fix For: 3.0.x, 3.11.x
>
>
> If the keyspace specified in allocate_tokens_for_keyspace does not exist you
> get an NPE. Should probably have a better error here letting people know
> what the issue was.
> {code}
> INFO 21:07:22,582 StorageService.java:1152 - JOINING: getting bootstrap
> token
> Exception (java.lang.NullPointerException) encountered during startup: null
> ERROR 21:07:22,590 CassandraDaemon.java:709 - Exception encountered during
> startup
> java.lang.NullPointerException: null
>at
> org.apache.cassandra.db.Keyspace.createReplicationStrategy(Keyspace.java:325)
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at org.apache.cassandra.db.Keyspace.(Keyspace.java:298)
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:201)
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:173)
> ~[cassandra-all-3.0.8:3.0.8]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14460) ERROR : java.lang.AssertionError: null
[
https://issues.apache.org/jira/browse/CASSANDRA-14460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16483554#comment-16483554
]
Yuki Morishita commented on CASSANDRA-14460:
This looks like CASSANDRA-12928, fixed by updating netty version in
CASSANDRA-13114.
You can try upgrading Cassandra to the latest 3.11.2.
> ERROR : java.lang.AssertionError: null
> --
>
> Key: CASSANDRA-14460
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14460
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Mutharasan Anbarasan
>Priority: Major
> Fix For: 3.10
>
>
> When I tried to ADD column to a existing table, I am getting below error.
> {code}
> WARN [MutationStage-48] 2018-02-15 09:42:27,696
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[MutationStage-48,5,main]: {}
> java.lang.AssertionError: null
> at io.netty.util.Recycler$WeakOrderQueue.(Recycler.java:225)
> ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
> at io.netty.util.Recycler$DefaultHandle.recycle(Recycler.java:180)
> ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
> at io.netty.util.Recycler.recycle(Recycler.java:141)
> ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
> at org.apache.cassandra.utils.btree.BTree$Builder.recycle(BTree.java:839)
> ~[apache-cassandra-3.10.jar:3.10]
> at org.apache.cassandra.utils.btree.BTree$Builder.build(BTree.java:1092)
> ~[apache-cassandra-3.10.jar:3.10]
> at
> org.apache.cassandra.db.partitions.PartitionUpdate.build(PartitionUpdate.java:587)
> ~[apache-cassandra-3.10.jar:3.10]
> at
> org.apache.cassandra.db.partitions.PartitionUpdate.maybeBuild(PartitionUpdate.java:577)
> ~[apache-cassandra-3.10.jar:3.10]
> at
> org.apache.cassandra.db.partitions.PartitionUpdate.holder(PartitionUpdate.java:388)
> ~[apache-cassandra-3.10.jar:3.10]
> at
> org.apache.cassandra.db.partitions.AbstractBTreePartition.unfilteredIterator(AbstractBTreePartition.java:177)
> ~[apache-cassandra-3.10.jar:3.10]
> at
> org.apache.cassandra.db.partitions.AbstractBTreePartition.unfilteredIterator(AbstractBTreePartition.java:172)
> ~[apache-cassandra-3.10.jar:3.10]
> at
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.serialize(PartitionUpdate.java:779)
> ~[apache-cassandra-3.10.jar:3.10]
> at
> org.apache.cassandra.db.Mutation$MutationSerializer.serialize(Mutation.java:393)
> ~[apache-cassandra-3.10.jar:3.10]
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:249)
> ~[apache-cassandra-3.10.jar:3.10]
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:585)
> ~[apache-cassandra-3.10.jar:3.10]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:462)
> ~[apache-cassandra-3.10.jar:3.10]
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:227)
> ~[apache-cassandra-3.10.jar:3.10]
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:232)
> ~[apache-cassandra-3.10.jar:3.10]
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:241)
> ~[apache-cassandra-3.10.jar:3.10]
> at
> org.apache.cassandra.service.StorageProxy$8.runMayThrow(StorageProxy.java:1416)
> ~[apache-cassandra-3.10.jar:3.10]
> at
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2640)
> ~[apache-cassandra-3.10.jar:3.10]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_121]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> ~[apache-cassandra-3.10.jar:3.10]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [apache-cassandra-3.10.jar:3.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109)
> [apache-cassandra-3.10.jar:3.10]
> at java.lang.Thread.run(Thread.java:745)
> [na:1.8.0_121]
> {code}
> How to fix this issue? Why does this issue popped up? Any pointers / work
> around solution is appreciated!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-8735) Batch log replication is not randomized when there are only 2 racks
[ https://issues.apache.org/jira/browse/CASSANDRA-8735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16116013#comment-16116013 ] Yuki Morishita commented on CASSANDRA-8735: --- Pinging [~blambov] and [~iamaleksey]. As Daniel pointed above, CASSANDRA-7237 removed randomizing part in 3.0+ (https://github.com/apache/cassandra/commit/762db474273f764b189d3613fce33943cd64701b#diff-642bb5d5ca328b50d59f2a550c94e5edR533). I cannot tell it was intentional or not, so can you take a look and see if it still need to be patched by this? Thanks. > Batch log replication is not randomized when there are only 2 racks > --- > > Key: CASSANDRA-8735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8735 > Project: Cassandra > Issue Type: Bug >Reporter: Yuki Morishita >Assignee: Mihai Suteu >Priority: Minor > Fix For: 2.1.9, 2.2.1, 3.0 alpha 1 > > Attachments: 8735-v2.patch, CASSANDRA-8735.patch > > > Batch log replication is not randomized and the same 2 nodes can be picked up > when there are only 2 racks in the cluster. > https://github.com/apache/cassandra/blob/cassandra-2.0.11/src/java/org/apache/cassandra/service/BatchlogEndpointSelector.java#L72-73 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-8076) Expose an mbean method to poll for repair job status
[
https://issues.apache.org/jira/browse/CASSANDRA-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita resolved CASSANDRA-8076.
---
Resolution: Duplicate
Yes, new JMX API:
{code}
/**
* Get the status of a given parent repair session.
* @param cmd the int reference returned when issuing the repair
* @return status of parent repair from enum {@link
org.apache.cassandra.repair.RepairRunnable.Status}
* followed by final message or messages of the session
*/
@Nullable
public List getParentRepairStatus(int cmd);
{code}
can be used in the use case described here. Closing as duplicate.
> Expose an mbean method to poll for repair job status
>
>
> Key: CASSANDRA-8076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8076
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Philip S Doctor
>Assignee: Yuki Morishita
> Attachments: 8076-2.0.txt
>
>
> Given the int reply-id from forceRepairAsync, allow a client to request the
> status of this ID via jmx.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13272) "nodetool bootstrap resume" does not exit
[
https://issues.apache.org/jira/browse/CASSANDRA-13272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16077675#comment-16077675
]
Yuki Morishita commented on CASSANDRA-13272:
I think at the time I thought {{Throwable e}} is usually {{ExecutionException}}
so I wanted to get what caused that execution error.
I'm not sure what's causing its cause to be null, but it looks it can happen.
I think we need proper null handling there.
> "nodetool bootstrap resume" does not exit
> -
>
> Key: CASSANDRA-13272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13272
> Project: Cassandra
> Issue Type: Bug
> Components: Lifecycle, Streaming and Messaging
>Reporter: Tom van der Woerdt
>Assignee: Tim Lamballais
> Labels: lhf
>
> I have a script that calls "nodetool bootstrap resume" after a failed join
> (in my environment some streams sometimes fail due to mis-tuning of stream
> bandwidth settings). However, if the streams fail again, nodetool won't exit.
> Last lines before it just hangs forever :
> {noformat}
> [2017-02-26 07:02:42,287] received file
> /var/lib/cassandra/data/keyspace/table-63d5d42009fa11e5879ebd9463bffdac/mc-12670-big-Data.db
> (progress: 1112%)
> [2017-02-26 07:02:42,287] received file
> /var/lib/cassandra/data/keyspace/table-63d5d42009fa11e5879ebd9463bffdac/mc-12670-big-Data.db
> (progress: 1112%)
> [2017-02-26 07:02:59,843] received file
> /var/lib/cassandra/data/keyspace/table-63d5d42009fa11e5879ebd9463bffdac/mc-12671-big-Data.db
> (progress: 1112%)
> [2017-02-26 09:25:51,000] session with /10.x.y.z complete (progress: 1112%)
> [2017-02-26 09:33:45,017] session with /10.x.y.z complete (progress: 1112%)
> [2017-02-26 09:39:27,216] session with /10.x.y.z complete (progress: 1112%)
> [2017-02-26 09:53:33,084] session with /10.x.y.z complete (progress: 1112%)
> [2017-02-26 09:55:07,115] session with /10.x.y.z complete (progress: 1112%)
> [2017-02-26 10:06:49,557] session with /10.x.y.z complete (progress: 1112%)
> [2017-02-26 10:40:55,880] session with /10.x.y.z complete (progress: 1112%)
> [2017-02-26 11:09:21,025] session with /10.x.y.z complete (progress: 1112%)
> [2017-02-26 12:44:35,755] session with /10.x.y.z complete (progress: 1112%)
> [2017-02-26 12:49:18,867] session with /10.x.y.z complete (progress: 1112%)
> [2017-02-26 13:23:50,611] session with /10.x.y.z complete (progress: 1112%)
> [2017-02-26 13:23:50,612] Stream failed
> {noformat}
> At that point ("Stream failed") I would expect nodetool to exit with a
> non-zero exit code. Instead, it just wants me to ^C it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13605) threads created during classload-static sections open commitlog handles
[
https://issues.apache.org/jira/browse/CASSANDRA-13605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049783#comment-16049783
]
Yuki Morishita commented on CASSANDRA-13605:
You are right, and it's been a problem for awhile.
FYI, right now we (try to) avoid this by checking if the process is running in
Cassandra daemon or tool(CASSANDRA-8616), but it is a temporary fix and does
not prevent from future code change.
> threads created during classload-static sections open commitlog handles
> ---
>
> Key: CASSANDRA-13605
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13605
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Tools
>Reporter: Nathan Jackels
>Priority: Minor
> Fix For: 3.0.x
>
>
> Some classes, such as org.apache.cassandra.db.commitlog.CommitLog create
> threads in static blocks. Some of these threads then open file-descriptors
> for the commitlog (and possibly sstables).
> {noformat}
> ...
> public static final CommitLog instance = CommitLog.construct();
> ...
> private static CommitLog construct()
> {
> CommitLog log = new CommitLog(DatabaseDescriptor.getCommitLogLocation(),
> CommitLogArchiver.construct());
>
> return log.start();
> }
> ...
> {noformat}
> If this occurs in a non-daemon process such as nodetool, or any of the other
> sstable tools it could prevent a CassandraDaemon from deleting commitlog
> files.
> These threads should only open files automatically if the process is a
> CassandraDaemon, not if it's a utility.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13518) sstableloader doesn't support non default storage_port and ssl_storage_port.
[
https://issues.apache.org/jira/browse/CASSANDRA-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-13518:
---
Resolution: Fixed
Fix Version/s: (was: 3.0.x)
3.11.0
3.0.14
Status: Resolved (was: Ready to Commit)
Committed as {{95635f3123d4ba84465fb57df837074b2121176c}}, thanks!
> sstableloader doesn't support non default storage_port and ssl_storage_port.
> -
>
> Key: CASSANDRA-13518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13518
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Zhiyan Shao
>Assignee: Zhiyan Shao
>Priority: Minor
> Fix For: 3.0.14, 3.11.0
>
> Attachments: 13518-3.0-1.txt, 13518-3.0-2.txt
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Currently these 2 ports are using hardcoded default ports:
> https://github.com/apache/cassandra/blob/8b3a60b9a7dbefeecc06bace617279612ec7092d/src/java/org/apache/cassandra/config/Config.java#L128-L129
> The proposed fix is to add command line option for these two ports like what
> NATIVE_PORT_OPTION currently does
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13518) sstableloader doesn't support non default storage_port and ssl_storage_port.
[ https://issues.apache.org/jira/browse/CASSANDRA-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16007356#comment-16007356 ] Yuki Morishita commented on CASSANDRA-13518: Thanks for the patch! Patch looks good to me. I can merge it to trunk when committing. > sstableloader doesn't support non default storage_port and ssl_storage_port. > - > > Key: CASSANDRA-13518 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13518 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Zhiyan Shao >Assignee: Zhiyan Shao >Priority: Minor > Fix For: 3.0.x > > Attachments: 13518-3.0-1.txt, 13518-3.0-2.txt > > Original Estimate: 1h > Remaining Estimate: 1h > > Currently these 2 ports are using hardcoded default ports: > https://github.com/apache/cassandra/blob/8b3a60b9a7dbefeecc06bace617279612ec7092d/src/java/org/apache/cassandra/config/Config.java#L128-L129 > The proposed fix is to add command line option for these two ports like what > NATIVE_PORT_OPTION currently does -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13518) sstableloader doesn't support non default storage_port and ssl_storage_port.
[ https://issues.apache.org/jira/browse/CASSANDRA-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-13518: --- Status: Ready to Commit (was: Patch Available) > sstableloader doesn't support non default storage_port and ssl_storage_port. > - > > Key: CASSANDRA-13518 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13518 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Zhiyan Shao >Assignee: Zhiyan Shao >Priority: Minor > Fix For: 3.0.x > > Attachments: 13518-3.0-1.txt, 13518-3.0-2.txt > > Original Estimate: 1h > Remaining Estimate: 1h > > Currently these 2 ports are using hardcoded default ports: > https://github.com/apache/cassandra/blob/8b3a60b9a7dbefeecc06bace617279612ec7092d/src/java/org/apache/cassandra/config/Config.java#L128-L129 > The proposed fix is to add command line option for these two ports like what > NATIVE_PORT_OPTION currently does -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13188) compaction-stress AssertionError from getMemtableFor()
[
https://issues.apache.org/jira/browse/CASSANDRA-13188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15960363#comment-15960363
]
Yuki Morishita commented on CASSANDRA-13188:
It is not initialized because Memtable is tied to commit log, so it creates
commit log in commit log directory (CASSANDRA-8616).
Option here is to do daemonInitialization in tool.
> compaction-stress AssertionError from getMemtableFor()
> --
>
> Key: CASSANDRA-13188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13188
> Project: Cassandra
> Issue Type: Bug
> Components: Testing, Tools
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>
> Exception:
> {noformat}
> ./compaction-stress compact -d /tmp/compaction -p
> https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml
> -t 4
> WARN 18:45:04,854 JNA link failure, one or more native method will be
> unavailable.
> java.lang.AssertionError: []
> at
> org.apache.cassandra.db.lifecycle.Tracker.getMemtableFor(Tracker.java:312)
> at
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1315)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:618)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:462)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:227)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:232)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:241)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeInternalWithoutCondition(ModificationStatement.java:570)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:564)
> at
> org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:356)
> at
> org.apache.cassandra.schema.SchemaKeyspace.saveSystemKeyspacesSchema(SchemaKeyspace.java:265)
> at
> org.apache.cassandra.db.SystemKeyspace.finishStartup(SystemKeyspace.java:495)
> at
> org.apache.cassandra.stress.CompactionStress$Compaction.run(CompactionStress.java:209)
> at
> org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:349)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-12929) Fix version check to enable streaming keep-alive
[
https://issues.apache.org/jira/browse/CASSANDRA-12929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15954750#comment-15954750
]
Yuki Morishita commented on CASSANDRA-12929:
My bad, I should have checked more closely.
I pushed fix and submitted test build.
||branch||testall||dtest||
|[12929-fix|https://github.com/yukim/cassandra/tree/12929-fix]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-12929-fix-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-12929-fix-dtest/lastCompletedBuild/testReport/]|
> Fix version check to enable streaming keep-alive
>
>
> Key: CASSANDRA-12929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12929
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Shuler
>Assignee: Paulo Motta
> Labels: dtest, test-failure
> Fix For: 4.0
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/494/testReport/bootstrap_test/TestBootstrap/simple_bootstrap_test_small_keepalive_period
> {noformat}
> Error Message
> Expected [['COMPLETED']] from SELECT bootstrapped FROM system.local WHERE
> key='local', but got [[u'IN_PROGRESS']]
> >> begin captured logging <<
> dtest: DEBUG: cluster ccm directory: /tmp/dtest-YmnyEI
> dtest: DEBUG: Done setting configuration options:
> { 'num_tokens': None, 'phi_convict_threshold': 5, 'start_rpc': 'true'}
> cassandra.cluster: INFO: New Cassandra host
> discovered
> - >> end captured logging << -
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/tools/decorators.py", line 46, in
> wrapped
> f(obj)
> File "/home/automaton/cassandra-dtest/bootstrap_test.py", line 163, in
> simple_bootstrap_test_small_keepalive_period
> assert_bootstrap_state(self, node2, 'COMPLETED')
> File "/home/automaton/cassandra-dtest/tools/assertions.py", line 297, in
> assert_bootstrap_state
> assert_one(session, "SELECT bootstrapped FROM system.local WHERE
> key='local'", [expected_bootstrap_state])
> File "/home/automaton/cassandra-dtest/tools/assertions.py", line 130, in
> assert_one
> assert list_res == [expected], "Expected {} from {}, but got
> {}".format([expected], query, list_res)
> "Expected [['COMPLETED']] from SELECT bootstrapped FROM system.local WHERE
> key='local', but got [[u'IN_PROGRESS']]\n >> begin
> captured logging << \ndtest: DEBUG: cluster ccm
> directory: /tmp/dtest-YmnyEI\ndtest: DEBUG: Done setting configuration
> options:\n{ 'num_tokens': None, 'phi_convict_threshold': 5, 'start_rpc':
> 'true'}\ncassandra.cluster: INFO: New Cassandra host datacenter1> discovered\n- >> end captured logging <<
> -"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-12825) testall failure in org.apache.cassandra.db.compaction.CompactionsCQLTest.testTriggerMinorCompactionDTCS-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15952950#comment-15952950
]
Yuki Morishita commented on CASSANDRA-12825:
Patches look good to me, + 1.
> testall failure in
> org.apache.cassandra.db.compaction.CompactionsCQLTest.testTriggerMinorCompactionDTCS-compression
> ---
>
> Key: CASSANDRA-12825
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12825
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Marcus Eriksson
> Labels: test-failure
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_testall/1243/testReport/org.apache.cassandra.db.compaction/CompactionsCQLTest/testTriggerMinorCompactionDTCS_compression/
> {code}
> Error Message
> No minor compaction triggered in 5000ms
> {code}{code}
> Stacktrace
> junit.framework.AssertionFailedError: No minor compaction triggered in 5000ms
> at
> org.apache.cassandra.db.compaction.CompactionsCQLTest.waitForMinor(CompactionsCQLTest.java:247)
> at
> org.apache.cassandra.db.compaction.CompactionsCQLTest.testTriggerMinorCompactionDTCS(CompactionsCQLTest.java:72)
> {code}
> Related failure:
> http://cassci.datastax.com/job/cassandra-3.X_testall/47/testReport/org.apache.cassandra.db.compaction/CompactionsCQLTest/testTriggerMinorCompactionDTCS/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CASSANDRA-11530) Remove deprecated repair method in 4.0
[
https://issues.apache.org/jira/browse/CASSANDRA-11530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-11530:
---
Resolution: Fixed
Fix Version/s: (was: 4.x)
4.0
Status: Resolved (was: Ready to Commit)
Thanks, committed as {{cc26c8304b4d4312213a0175dcd5f1531e7934ad}} to trunk.
> Remove deprecated repair method in 4.0
> --
>
> Key: CASSANDRA-11530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11530
> Project: Cassandra
> Issue Type: Task
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Minor
> Fix For: 4.0
>
>
> Once we hit 4.0, we should remove all deprecated repair JMX API.
> (nodetool has been using only new API since it is introduced.)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CASSANDRA-12929) dtest failure in bootstrap_test.TestBootstrap.simple_bootstrap_test_small_keepalive_period
[
https://issues.apache.org/jira/browse/CASSANDRA-12929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-12929:
---
Status: Ready to Commit (was: Patch Available)
> dtest failure in
> bootstrap_test.TestBootstrap.simple_bootstrap_test_small_keepalive_period
> --
>
> Key: CASSANDRA-12929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12929
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Shuler
>Assignee: Paulo Motta
> Labels: dtest, test-failure
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/494/testReport/bootstrap_test/TestBootstrap/simple_bootstrap_test_small_keepalive_period
> {noformat}
> Error Message
> Expected [['COMPLETED']] from SELECT bootstrapped FROM system.local WHERE
> key='local', but got [[u'IN_PROGRESS']]
> >> begin captured logging <<
> dtest: DEBUG: cluster ccm directory: /tmp/dtest-YmnyEI
> dtest: DEBUG: Done setting configuration options:
> { 'num_tokens': None, 'phi_convict_threshold': 5, 'start_rpc': 'true'}
> cassandra.cluster: INFO: New Cassandra host
> discovered
> - >> end captured logging << -
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/tools/decorators.py", line 46, in
> wrapped
> f(obj)
> File "/home/automaton/cassandra-dtest/bootstrap_test.py", line 163, in
> simple_bootstrap_test_small_keepalive_period
> assert_bootstrap_state(self, node2, 'COMPLETED')
> File "/home/automaton/cassandra-dtest/tools/assertions.py", line 297, in
> assert_bootstrap_state
> assert_one(session, "SELECT bootstrapped FROM system.local WHERE
> key='local'", [expected_bootstrap_state])
> File "/home/automaton/cassandra-dtest/tools/assertions.py", line 130, in
> assert_one
> assert list_res == [expected], "Expected {} from {}, but got
> {}".format([expected], query, list_res)
> "Expected [['COMPLETED']] from SELECT bootstrapped FROM system.local WHERE
> key='local', but got [[u'IN_PROGRESS']]\n >> begin
> captured logging << \ndtest: DEBUG: cluster ccm
> directory: /tmp/dtest-YmnyEI\ndtest: DEBUG: Done setting configuration
> options:\n{ 'num_tokens': None, 'phi_convict_threshold': 5, 'start_rpc':
> 'true'}\ncassandra.cluster: INFO: New Cassandra host datacenter1> discovered\n- >> end captured logging <<
> -"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-12929) dtest failure in bootstrap_test.TestBootstrap.simple_bootstrap_test_small_keepalive_period
[
https://issues.apache.org/jira/browse/CASSANDRA-12929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15950206#comment-15950206
]
Yuki Morishita commented on CASSANDRA-12929:
Nice catch. +1.
> dtest failure in
> bootstrap_test.TestBootstrap.simple_bootstrap_test_small_keepalive_period
> --
>
> Key: CASSANDRA-12929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12929
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Shuler
>Assignee: Paulo Motta
> Labels: dtest, test-failure
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/494/testReport/bootstrap_test/TestBootstrap/simple_bootstrap_test_small_keepalive_period
> {noformat}
> Error Message
> Expected [['COMPLETED']] from SELECT bootstrapped FROM system.local WHERE
> key='local', but got [[u'IN_PROGRESS']]
> >> begin captured logging <<
> dtest: DEBUG: cluster ccm directory: /tmp/dtest-YmnyEI
> dtest: DEBUG: Done setting configuration options:
> { 'num_tokens': None, 'phi_convict_threshold': 5, 'start_rpc': 'true'}
> cassandra.cluster: INFO: New Cassandra host
> discovered
> - >> end captured logging << -
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/tools/decorators.py", line 46, in
> wrapped
> f(obj)
> File "/home/automaton/cassandra-dtest/bootstrap_test.py", line 163, in
> simple_bootstrap_test_small_keepalive_period
> assert_bootstrap_state(self, node2, 'COMPLETED')
> File "/home/automaton/cassandra-dtest/tools/assertions.py", line 297, in
> assert_bootstrap_state
> assert_one(session, "SELECT bootstrapped FROM system.local WHERE
> key='local'", [expected_bootstrap_state])
> File "/home/automaton/cassandra-dtest/tools/assertions.py", line 130, in
> assert_one
> assert list_res == [expected], "Expected {} from {}, but got
> {}".format([expected], query, list_res)
> "Expected [['COMPLETED']] from SELECT bootstrapped FROM system.local WHERE
> key='local', but got [[u'IN_PROGRESS']]\n >> begin
> captured logging << \ndtest: DEBUG: cluster ccm
> directory: /tmp/dtest-YmnyEI\ndtest: DEBUG: Done setting configuration
> options:\n{ 'num_tokens': None, 'phi_convict_threshold': 5, 'start_rpc':
> 'true'}\ncassandra.cluster: INFO: New Cassandra host datacenter1> discovered\n- >> end captured logging <<
> -"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CASSANDRA-12929) dtest failure in bootstrap_test.TestBootstrap.simple_bootstrap_test_small_keepalive_period
[
https://issues.apache.org/jira/browse/CASSANDRA-12929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-12929:
---
Reviewer: Yuki Morishita
> dtest failure in
> bootstrap_test.TestBootstrap.simple_bootstrap_test_small_keepalive_period
> --
>
> Key: CASSANDRA-12929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12929
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Shuler
>Assignee: Paulo Motta
> Labels: dtest, test-failure
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/494/testReport/bootstrap_test/TestBootstrap/simple_bootstrap_test_small_keepalive_period
> {noformat}
> Error Message
> Expected [['COMPLETED']] from SELECT bootstrapped FROM system.local WHERE
> key='local', but got [[u'IN_PROGRESS']]
> >> begin captured logging <<
> dtest: DEBUG: cluster ccm directory: /tmp/dtest-YmnyEI
> dtest: DEBUG: Done setting configuration options:
> { 'num_tokens': None, 'phi_convict_threshold': 5, 'start_rpc': 'true'}
> cassandra.cluster: INFO: New Cassandra host
> discovered
> - >> end captured logging << -
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/tools/decorators.py", line 46, in
> wrapped
> f(obj)
> File "/home/automaton/cassandra-dtest/bootstrap_test.py", line 163, in
> simple_bootstrap_test_small_keepalive_period
> assert_bootstrap_state(self, node2, 'COMPLETED')
> File "/home/automaton/cassandra-dtest/tools/assertions.py", line 297, in
> assert_bootstrap_state
> assert_one(session, "SELECT bootstrapped FROM system.local WHERE
> key='local'", [expected_bootstrap_state])
> File "/home/automaton/cassandra-dtest/tools/assertions.py", line 130, in
> assert_one
> assert list_res == [expected], "Expected {} from {}, but got
> {}".format([expected], query, list_res)
> "Expected [['COMPLETED']] from SELECT bootstrapped FROM system.local WHERE
> key='local', but got [[u'IN_PROGRESS']]\n >> begin
> captured logging << \ndtest: DEBUG: cluster ccm
> directory: /tmp/dtest-YmnyEI\ndtest: DEBUG: Done setting configuration
> options:\n{ 'num_tokens': None, 'phi_convict_threshold': 5, 'start_rpc':
> 'true'}\ncassandra.cluster: INFO: New Cassandra host datacenter1> discovered\n- >> end captured logging <<
> -"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13390) Nodetool repair fails with snapshot error message
[
https://issues.apache.org/jira/browse/CASSANDRA-13390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15948179#comment-15948179
]
Yuki Morishita commented on CASSANDRA-13390:
bq. Could not create snapshot at /10.22.150.204
Did you look at log in /10.22.150.204? There should be something there.
> Nodetool repair fails with snapshot error message
> -
>
> Key: CASSANDRA-13390
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13390
> Project: Cassandra
> Issue Type: Bug
> Environment: * CentOS 7 : 4.4.21-1.el7.elrepo.x86_64
> * Cassandra 3.10 (setup from vanilla tar.gz)
>Reporter: Barthelemy Vessemont
>
> I'm trying to run a repair with following options :
> {{nodetool repair -seq -full -pr some_keyspace some_table1 some_table2
> some_other_table ...}}
> `some_keyspace` definition :
> {quote}
> CREATE KEYSPACE some_keyspace WITH replication = <'class':
> 'NetworkTopologyStrategy', 'AMST': '3'> AND durable_writes = true;
> {quote}
> Tables can be both of DTCS and LCS
> Cluster :
> {quote}
> Datacenter: AMST
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens OwnsHost ID
>Rack
> UN 10.22.150.236 205.22 GiB 256 ? B04
> UN 10.22.150.204 200.87 GiB 256 ? B05
> UN 10.22.140.77 203.12 GiB 256 ? D22
> {quote}
> Repair starts well but seems to fails at creating remote snapshots on nodes
> holding replicas:
> *info* : no other repair have been started on others nodes during this time,
> snapshots were also cleaned before.
> {quote}
> # nodetool repair -seq -full -pr some_keyspace some_table1 some_table2
> some_other_table ...
> 11:42:03 [2017-03-29 09:42:03,399] Starting repair command #10
> (f6dac620-1463-11e7-aa9f-01f10058e068), repairing keyspace some_keyspace with
> repair options (parallelism: sequential, primary range: true, incremental:
> false, job threads: 1, ColumnFamilies: [some_keyspace, some_table1,
> some_table2, some_other_table], dataCenters: [], hosts: [], # of ranges: 256,
> pull repair: false)
> 11:47:43 [2017-03-29 09:47:43,578] Repair session
> f6e74940-1463-11e7-aa9f-01f10058e068 for range
> [(4978050141600810389,4982072488404840895],
> (-1340498249852980466,-1311689893502261125],
> (-5302264476874517513,-5291739032085711936],
> (-5981241605827420506,-5966850479287809973],
> (1857121221013279321,1899365815561615863],
> (942740326159033054,946603639333506869],
> (382316032181285431,397235785699549982],
> [...]
> (-6731897432582288959,-6728305970724193972],
> (-3193765198824884162,-3152653432337268817],
> (6879878057460360708,6898924573938960263],
> (7238964282930318864,7282255874655871690],
> (-4737709921934606628,-4734841018997895217]] failed with error Could not
> create snapshot at /10.22.150.204 (progress: 1%)
> 11:47:43 [2017-03-29 09:47:43,579] Parent repair session with id =
> f6dac620-1463-11e7-aa9f-01f10058e068 has failed.
> 11:47:43 [2017-03-29 09:47:43,580] Repair command #10 finished in 5
> minutes 40 seconds
> {quote}
> errors logs on replica side :
> {quote}
> ERROR [AntiEntropyStage:1] 2017-03-29 09:47:43,577
> RepairMessageVerbHandler.java:168 - Got error, removing parent repair session
> ERROR [AntiEntropyStage:1] 2017-03-29 09:47:43,578 CassandraDaemon.java:229 -
> Exception in thread Thread[AntiEntropyStage:1,5,main]
> java.lang.RuntimeException: Parent repair session with id =
> f6dac620-1463-11e7-aa9f-01f10058e068 has failed.
> at
> org.apache.cassandra.service.ActiveRepairService.getParentRepairSession(ActiveRepairService.java:400)
> ~[apache-cassandra-3.10.jar:3.10]
> at
> org.apache.cassandra.service.ActiveRepairService.removeParentRepairSession(ActiveRepairService.java:416)
> ~[apache-cassandra-3.10.jar:3.10]
> at
> org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:170)
> ~[apache-cassandra-3.10.jar:3.10]
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66)
> ~[apache-cassandra-3.10.jar:3.10]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_91]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_91]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_91]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_91]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
> [apache-cassandra-3.10.jar:3.10]
> at java.lang.Thread.run(Thread.java:745) ~[na:1
[jira] [Commented] (CASSANDRA-13257) Add repair streaming preview
[
https://issues.apache.org/jira/browse/CASSANDRA-13257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15946527#comment-15946527
]
Yuki Morishita commented on CASSANDRA-13257:
Sorry for delay.
I think about {{PreviewKind}} again, and I'd like to keep that in repair.
The reason is that there is and will be a filtering logic that only gets
executed when "previewing", which sound weird to me since the logic never get
called when not previewing. Right now the only case is to validate repair. And
for that, there is no need to preview streaming.
I think even so streaming preview covers both full and incremental repair case,
and other streaming usage.
My patch to move {{PreviewKind}} is here:
https://github.com/yukim/cassandra/commit/55c3db065867c402bc4b1fc38ac0460854db6af6
For repair validation, {{SyncTask}} returns without invoking streaming preview.
I think we should add more info to {{SyncStat}}, as you left the note in TODO
comment to give more information for repair validation.
I also renamed {{PreviewKind}} to match repair options. as it gets displayed in
repair command output. Maybe implementing {{toString()}} is better though.
Other than that, I think overall well implemented. Thanks!
> Add repair streaming preview
>
>
> Key: CASSANDRA-13257
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13257
> Project: Cassandra
> Issue Type: New Feature
> Components: Streaming and Messaging
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
> Fix For: 4.0
>
>
> It would be useful to be able to estimate the amount of repair streaming that
> needs to be done, without actually doing any streaming. Our main motivation
> for this having something this is validating CASSANDRA-9143 in production,
> but I’d imagine it could also be a useful tool in troubleshooting.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-11530) Remove deprecated repair method in 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-11530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15933913#comment-15933913 ] Yuki Morishita commented on CASSANDRA-11530: Yes, this only removes deprecated methods. > Remove deprecated repair method in 4.0 > -- > > Key: CASSANDRA-11530 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11530 > Project: Cassandra > Issue Type: Task >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Minor > Fix For: 4.x > > > Once we hit 4.0, we should remove all deprecated repair JMX API. > (nodetool has been using only new API since it is introduced.) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13351) CASSANDRA-11345 why not fix on 2.1.x?
[
https://issues.apache.org/jira/browse/CASSANDRA-13351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932198#comment-15932198
]
Yuki Morishita commented on CASSANDRA-13351:
2.1 is only maintained for critical fixes only. It even states so in download
page of Apache Cassandra. (But apparently it's not it seems...)
You can work around by setting {{streaming_socket_timeout_in_ms}} high.
> CASSANDRA-11345 why not fix on 2.1.x?
> -
>
> Key: CASSANDRA-13351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13351
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
> Environment: cassandra 2.1.15
> jdk 1.8
>Reporter: zhaoyan
>
> I found same problem on cassandra 2.1.15
> the problem was reproduced In 2.1.13
> I don't know why not fix it on 2.1.x ?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CASSANDRA-11530) Remove deprecated repair method in 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-11530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-11530: --- Status: Patch Available (was: Open) > Remove deprecated repair method in 4.0 > -- > > Key: CASSANDRA-11530 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11530 > Project: Cassandra > Issue Type: Task >Reporter: Yuki Morishita >Priority: Minor > Fix For: 4.x > > > Once we hit 4.0, we should remove all deprecated repair JMX API. > (nodetool has been using only new API since it is introduced.) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (CASSANDRA-11530) Remove deprecated repair method in 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-11530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita reassigned CASSANDRA-11530: -- Assignee: Yuki Morishita > Remove deprecated repair method in 4.0 > -- > > Key: CASSANDRA-11530 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11530 > Project: Cassandra > Issue Type: Task >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Minor > Fix For: 4.x > > > Once we hit 4.0, we should remove all deprecated repair JMX API. > (nodetool has been using only new API since it is introduced.) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-11530) Remove deprecated repair method in 4.0
[
https://issues.apache.org/jira/browse/CASSANDRA-11530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932179#comment-15932179
]
Yuki Morishita commented on CASSANDRA-11530:
Trivial patch to remove deprecated repair methods and
{{LegacyJMXProgressSupport}}.
{{deprecated_repair_test}} fails since deprecated methods are removed. PR to
add {{max_version}} to those tests is here:
https://github.com/riptano/cassandra-dtest/pull/1453
||branch||testall||dtest||
|[11530|https://github.com/yukim/cassandra/tree/11530]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-11530-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-11530-dtest/lastCompletedBuild/testReport/]|
> Remove deprecated repair method in 4.0
> --
>
> Key: CASSANDRA-11530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11530
> Project: Cassandra
> Issue Type: Task
>Reporter: Yuki Morishita
>Priority: Minor
> Fix For: 4.x
>
>
> Once we hit 4.0, we should remove all deprecated repair JMX API.
> (nodetool has been using only new API since it is introduced.)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13257) Add repair streaming preview
[
https://issues.apache.org/jira/browse/CASSANDRA-13257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15927830#comment-15927830
]
Yuki Morishita commented on CASSANDRA-13257:
bq. validate that repaired data is in sync
I'm not sure this should go to {{nodetool repair}} command. If we have
subcommand, then {{nodetool repair validate}} would be the right command.
Does this need to "preview" streaming as well? Seems validating repaired
SSTables is enough.
About {{PreviewKind}} in streaming, it is how SSTables are selected and I'm
fine with it for now until we have more cleaner way to decouple from streaming
itself.
bq. We’d only ever be able to preview the full repair case.
Would it be so? I will look up CASSANDRA-13328 as well.
> Add repair streaming preview
>
>
> Key: CASSANDRA-13257
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13257
> Project: Cassandra
> Issue Type: New Feature
> Components: Streaming and Messaging
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
> Fix For: 4.0
>
>
> It would be useful to be able to estimate the amount of repair streaming that
> needs to be done, without actually doing any streaming. Our main motivation
> for this having something this is validating CASSANDRA-9143 in production,
> but I’d imagine it could also be a useful tool in troubleshooting.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13257) Add repair streaming preview
[
https://issues.apache.org/jira/browse/CASSANDRA-13257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15925864#comment-15925864
]
Yuki Morishita commented on CASSANDRA-13257:
I wonder what is the usage of "Perform preview on repaired
data"/{{PreviewKind.REPAIRED}}.
I kind of want to separate context of "preview streaming" and "preview repair".
So I'd like to keep {{PreviewKind}} in repair package, and have boolean
{{isPreview}} in streaming. It seems to me that the reason we have
{{PreviewKind}} in streaming right now is to add above functionality.
> Add repair streaming preview
>
>
> Key: CASSANDRA-13257
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13257
> Project: Cassandra
> Issue Type: New Feature
> Components: Streaming and Messaging
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
> Fix For: 4.0
>
>
> It would be useful to be able to estimate the amount of repair streaming that
> needs to be done, without actually doing any streaming. Our main motivation
> for this having something this is validating CASSANDRA-9143 in production,
> but I’d imagine it could also be a useful tool in troubleshooting.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CASSANDRA-13257) Add repair streaming preview
[ https://issues.apache.org/jira/browse/CASSANDRA-13257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-13257: --- Reviewer: Yuki Morishita Fix Version/s: 4.0 Component/s: Streaming and Messaging > Add repair streaming preview > > > Key: CASSANDRA-13257 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13257 > Project: Cassandra > Issue Type: New Feature > Components: Streaming and Messaging >Reporter: Blake Eggleston >Assignee: Blake Eggleston > Fix For: 4.0 > > > It would be useful to be able to estimate the amount of repair streaming that > needs to be done, without actually doing any streaming. Our main motivation > for this having something this is validating CASSANDRA-9143 in production, > but I’d imagine it could also be a useful tool in troubleshooting. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13300) Upgrade the jna version to 4.3.0
[ https://issues.apache.org/jira/browse/CASSANDRA-13300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15896870#comment-15896870 ] Yuki Morishita commented on CASSANDRA-13300: I don't have ppc64le machine so I cannot reproduce it, but ifrom their change log, it looks like jna added support for ppc64le since v4.2, and I guess that is the reason for this update request. > Upgrade the jna version to 4.3.0 > > > Key: CASSANDRA-13300 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13300 > Project: Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Amitkumar Ghatwal > > Could you please upgrade the jna version present in the github cassandra > location : https://github.com/apache/cassandra/blob/trunk/lib/jna-4.0.0.jar > to below latest version - 4.3.0 - > http://repo1.maven.org/maven2/net/java/dev/jna/jna/4.3.0/jna-4.3.0-javadoc.jar -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13257) Add repair streaming preview
[
https://issues.apache.org/jira/browse/CASSANDRA-13257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15885005#comment-15885005
]
Yuki Morishita commented on CASSANDRA-13257:
Is it possible to add "dry-run" feature to stremaing instead of TreeDifference?
That way, we can use the feature to preview other streaming operations.
For example:
{code}
StreamPlan newPlan = new StreamPlan(dryRun=true);
newPlan.addTransferRanges(range);
StreamResultFuture future = newPlan.execute();
// if dryRun, only run streaming until PREPARE phase so that exactly send and
*receive* size are known, and return calculated StreamState based on those.
StreamState dryRunResult = future.get();
{code}
Or, when streaming is only for out going (like decommission) we may be able to
return without exchanging messages.
WDYT?
> Add repair streaming preview
>
>
> Key: CASSANDRA-13257
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13257
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>
> It would be useful to be able to estimate the amount of repair streaming that
> needs to be done, without actually doing any streaming. Our main motivation
> for this having something this is validating CASSANDRA-9143 in production,
> but I’d imagine it could also be a useful tool in troubleshooting.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CASSANDRA-12202) LongLeveledCompactionStrategyTest flapping in 2.1, 2.2, 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-12202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-12202:
---
Resolution: Fixed
Fix Version/s: (was: 3.11.x)
(was: 3.0.x)
(was: 2.2.x)
(was: 2.1.x)
3.11.0
3.0.12
2.2.10
Status: Resolved (was: Ready to Commit)
Committed to 2.2+ as {{6ffd5cc5d28658b4d058de79a9bea9c10a82c8d4}}.
> LongLeveledCompactionStrategyTest flapping in 2.1, 2.2, 3.0
> ---
>
> Key: CASSANDRA-12202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12202
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 2.2.10, 3.0.12, 3.11.0
>
>
> We actually fixed this for 3.7+ in CASSANDRA-11657, need to backport that fix
> to 2.1+
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CASSANDRA-12886) Streaming failed due to SSL Socket connection reset
[
https://issues.apache.org/jira/browse/CASSANDRA-12886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-12886:
---
Status: Ready to Commit (was: Patch Available)
> Streaming failed due to SSL Socket connection reset
> ---
>
> Key: CASSANDRA-12886
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12886
> Project: Cassandra
> Issue Type: Bug
>Reporter: Bing Wu
>Assignee: Paulo Motta
> Attachments: debug.log.2016-11-10_2319.gz
>
>
> While running "nodetool repair", I see many instances of
> "javax.net.ssl.SSLException: java.net.SocketException: Connection reset" in
> system.logs on some nodes in the cluster. Timestamps correspond to streaming
> source/initiator's error messages of "sync failed between ..."
> Setup:
> - Cassandra 3.7.01
> - CentOS 6.7 in AWS (multi-region)
> - JDK version: {noformat}
> java version "1.8.0_102"
> Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
> {noformat}
> - cassandra.yaml:
> {noformat}
> server_encryption_options:
> internode_encryption: all
> keystore: [path]
> keystore_password: [password]
> truststore: [path]
> truststore_password: [password]
> # More advanced defaults below:
> # protocol: TLS
> # algorithm: SunX509
> # store_type: JKS
> # cipher_suites:
> [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
> require_client_auth: false
> {noformat}
> Error messages in system.log on the target host:
> {noformat}
> ERROR [STREAM-OUT-/54.247.111.232:7001] 2016-11-07 07:30:56,475
> StreamSession.java:529 - [Stream #e14abcb0-a4bb-11e6-9758-55b9ac38b78e]
> Streaming error occurred on session with peer 54.247.111.232
> javax.net.ssl.SSLException: Connection has been shutdown:
> javax.net.ssl.SSLException: java.net.SocketException: Connection reset
> at sun.security.ssl.SSLSocketImpl.checkEOF(SSLSocketImpl.java:1541)
> ~[na:1.8.0_102]
> at sun.security.ssl.SSLSocketImpl.checkWrite(SSLSocketImpl.java:1553)
> ~[na:1.8.0_102]
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:71)
> ~[na:1.8.0_102]
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> ~[na:1.8.0_102]
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> ~[na:1.8.0_102]
> at
> org.apache.cassandra.io.util.WrappedDataOutputStreamPlus.flush(WrappedDataOutputStreamPlus.java:66)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.sendMessage(ConnectionHandler.java:371)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.run(ConnectionHandler.java:342)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_102]
> Caused by: javax.net.ssl.SSLException: java.net.SocketException: Connection
> reset
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-12886) Streaming failed due to SSL Socket connection reset
[
https://issues.apache.org/jira/browse/CASSANDRA-12886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15879647#comment-15879647
]
Yuki Morishita commented on CASSANDRA-12886:
+1. (looks like 2 failed unit tests were due to some env issue.)
So this goes to 3.0 also, right?
> Streaming failed due to SSL Socket connection reset
> ---
>
> Key: CASSANDRA-12886
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12886
> Project: Cassandra
> Issue Type: Bug
>Reporter: Bing Wu
>Assignee: Paulo Motta
> Attachments: debug.log.2016-11-10_2319.gz
>
>
> While running "nodetool repair", I see many instances of
> "javax.net.ssl.SSLException: java.net.SocketException: Connection reset" in
> system.logs on some nodes in the cluster. Timestamps correspond to streaming
> source/initiator's error messages of "sync failed between ..."
> Setup:
> - Cassandra 3.7.01
> - CentOS 6.7 in AWS (multi-region)
> - JDK version: {noformat}
> java version "1.8.0_102"
> Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
> {noformat}
> - cassandra.yaml:
> {noformat}
> server_encryption_options:
> internode_encryption: all
> keystore: [path]
> keystore_password: [password]
> truststore: [path]
> truststore_password: [password]
> # More advanced defaults below:
> # protocol: TLS
> # algorithm: SunX509
> # store_type: JKS
> # cipher_suites:
> [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
> require_client_auth: false
> {noformat}
> Error messages in system.log on the target host:
> {noformat}
> ERROR [STREAM-OUT-/54.247.111.232:7001] 2016-11-07 07:30:56,475
> StreamSession.java:529 - [Stream #e14abcb0-a4bb-11e6-9758-55b9ac38b78e]
> Streaming error occurred on session with peer 54.247.111.232
> javax.net.ssl.SSLException: Connection has been shutdown:
> javax.net.ssl.SSLException: java.net.SocketException: Connection reset
> at sun.security.ssl.SSLSocketImpl.checkEOF(SSLSocketImpl.java:1541)
> ~[na:1.8.0_102]
> at sun.security.ssl.SSLSocketImpl.checkWrite(SSLSocketImpl.java:1553)
> ~[na:1.8.0_102]
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:71)
> ~[na:1.8.0_102]
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> ~[na:1.8.0_102]
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> ~[na:1.8.0_102]
> at
> org.apache.cassandra.io.util.WrappedDataOutputStreamPlus.flush(WrappedDataOutputStreamPlus.java:66)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.sendMessage(ConnectionHandler.java:371)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.run(ConnectionHandler.java:342)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_102]
> Caused by: javax.net.ssl.SSLException: java.net.SocketException: Connection
> reset
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CASSANDRA-13070) unittest antiCompactionSizeTest is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-13070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-13070:
---
Resolution: Fixed
Fix Version/s: (was: 3.0.x)
3.11.0
3.0.12
Status: Resolved (was: Patch Available)
Thanks, committed as {{51796ea63420f8daa49c9d491588ba9740c6b0d1}}.
> unittest antiCompactionSizeTest is flaky
>
>
> Key: CASSANDRA-13070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13070
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
> Fix For: 3.0.12, 3.11.0
>
> Attachments: 13070-3.0.txt, 13070-update-3.0.txt
>
>
> Unittest
> {{org.apache.cassandra.db.compaction.AntiCompactionTest.antiCompactionSizeTest}}
> is failing from time to time on branch 3.0
> ([13e9396|https://github.com/apache/cassandra/commit/13e939624d21eaf6e16d60b28636125e817ab286]):
> {code}
> [junit] Testcase:
> antiCompactionSizeTest(org.apache.cassandra.db.compaction.AntiCompactionTest):
> FAILED
> [junit] expected:<1.29786604E8> but was:<1.13623354E8>
> [junit] junit.framework.AssertionFailedError: expected:<1.29786604E8> but
> was:<1.13623354E8>
> [junit] at
> org.apache.cassandra.db.compaction.AntiCompactionTest.antiCompactionSizeTest(AntiCompactionTest.java:164)
> {code}
> Run the single test 21 times:
> {code}
> for i in {0..20}; do echo ==$i; ant testsome
> -Dtest.name=org.apache.cassandra.db.compaction.AntiCompactionTest
> -Dtest.methods=antiCompactionSizeTest; echo $i $? >> ~/testresult; done
> {code}
> On mac, it passed for 5 times, on linux it passed for 6 times.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13070) unittest antiCompactionSizeTest is unstable
[
https://issues.apache.org/jira/browse/CASSANDRA-13070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15877106#comment-15877106
]
Yuki Morishita commented on CASSANDRA-13070:
I couldn't reproduce this on my machine, nor cassci has not failed this test
(http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_testall/lastCompletedBuild/testReport/org.apache.cassandra.db.compaction/AntiCompactionTest/antiCompactionSizeTest/history/)
I wonder if this assertion is valid anymore. Once the delta value was 1,
then raised to 1600.
I *think* the original intention was to test anti compacted SSTables' size
should be close to the original size, but it was adjusted for SSTable format
change. I suggest removing this assertion since assertion doen't comply the
original intention after format change.
> unittest antiCompactionSizeTest is unstable
> ---
>
> Key: CASSANDRA-13070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13070
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
> Fix For: 3.0.x
>
> Attachments: 13070-3.0.txt
>
>
> Unittest
> {{org.apache.cassandra.db.compaction.AntiCompactionTest.antiCompactionSizeTest}}
> is failing from time to time on branch 3.0
> ([13e9396|https://github.com/apache/cassandra/commit/13e939624d21eaf6e16d60b28636125e817ab286]):
> {code}
> [junit] Testcase:
> antiCompactionSizeTest(org.apache.cassandra.db.compaction.AntiCompactionTest):
> FAILED
> [junit] expected:<1.29786604E8> but was:<1.13623354E8>
> [junit] junit.framework.AssertionFailedError: expected:<1.29786604E8> but
> was:<1.13623354E8>
> [junit] at
> org.apache.cassandra.db.compaction.AntiCompactionTest.antiCompactionSizeTest(AntiCompactionTest.java:164)
> {code}
> Run the single test 21 times:
> {code}
> for i in {0..20}; do echo ==$i; ant testsome
> -Dtest.name=org.apache.cassandra.db.compaction.AntiCompactionTest
> -Dtest.methods=antiCompactionSizeTest; echo $i $? >> ~/testresult; done
> {code}
> On mac, it passed for 5 times, on linux it passed for 6 times.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-12886) Streaming failed due to SSL Socket connection reset
[
https://issues.apache.org/jira/browse/CASSANDRA-12886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874062#comment-15874062
]
Yuki Morishita commented on CASSANDRA-12886:
Patch looks good to me. +1.
Unfortunately, test pages were missing at the moment, so I was not able to
check the result.
Can you run once again just in case?
> Streaming failed due to SSL Socket connection reset
> ---
>
> Key: CASSANDRA-12886
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12886
> Project: Cassandra
> Issue Type: Bug
>Reporter: Bing Wu
>Assignee: Paulo Motta
> Attachments: debug.log.2016-11-10_2319.gz
>
>
> While running "nodetool repair", I see many instances of
> "javax.net.ssl.SSLException: java.net.SocketException: Connection reset" in
> system.logs on some nodes in the cluster. Timestamps correspond to streaming
> source/initiator's error messages of "sync failed between ..."
> Setup:
> - Cassandra 3.7.01
> - CentOS 6.7 in AWS (multi-region)
> - JDK version: {noformat}
> java version "1.8.0_102"
> Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
> {noformat}
> - cassandra.yaml:
> {noformat}
> server_encryption_options:
> internode_encryption: all
> keystore: [path]
> keystore_password: [password]
> truststore: [path]
> truststore_password: [password]
> # More advanced defaults below:
> # protocol: TLS
> # algorithm: SunX509
> # store_type: JKS
> # cipher_suites:
> [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
> require_client_auth: false
> {noformat}
> Error messages in system.log on the target host:
> {noformat}
> ERROR [STREAM-OUT-/54.247.111.232:7001] 2016-11-07 07:30:56,475
> StreamSession.java:529 - [Stream #e14abcb0-a4bb-11e6-9758-55b9ac38b78e]
> Streaming error occurred on session with peer 54.247.111.232
> javax.net.ssl.SSLException: Connection has been shutdown:
> javax.net.ssl.SSLException: java.net.SocketException: Connection reset
> at sun.security.ssl.SSLSocketImpl.checkEOF(SSLSocketImpl.java:1541)
> ~[na:1.8.0_102]
> at sun.security.ssl.SSLSocketImpl.checkWrite(SSLSocketImpl.java:1553)
> ~[na:1.8.0_102]
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:71)
> ~[na:1.8.0_102]
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> ~[na:1.8.0_102]
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> ~[na:1.8.0_102]
> at
> org.apache.cassandra.io.util.WrappedDataOutputStreamPlus.flush(WrappedDataOutputStreamPlus.java:66)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.sendMessage(ConnectionHandler.java:371)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.run(ConnectionHandler.java:342)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_102]
> Caused by: javax.net.ssl.SSLException: java.net.SocketException: Connection
> reset
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CASSANDRA-13173) Reloading logback.xml does not work
[
https://issues.apache.org/jira/browse/CASSANDRA-13173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-13173:
---
Status: Ready to Commit (was: Patch Available)
> Reloading logback.xml does not work
> ---
>
> Key: CASSANDRA-13173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.0.x
>
>
> Regression of CASSANDRA-12535
> Reloading of logback.xml is broken by CASSANDRA-12535 because the delegate
> {{ReconfigureOnChangeFilter}} is not properly initialized.
> (Broken in 3.0.11 + 3.10)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13173) Reloading logback.xml does not work
[
https://issues.apache.org/jira/browse/CASSANDRA-13173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858425#comment-15858425
]
Yuki Morishita commented on CASSANDRA-13173:
Patch and tests look good to me. +1.
> Reloading logback.xml does not work
> ---
>
> Key: CASSANDRA-13173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.0.x
>
>
> Regression of CASSANDRA-12535
> Reloading of logback.xml is broken by CASSANDRA-12535 because the delegate
> {{ReconfigureOnChangeFilter}} is not properly initialized.
> (Broken in 3.0.11 + 3.10)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13177) sstabledump doesn't handle non-empty partitions with a partition-level deletion correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-13177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15850720#comment-15850720 ] Yuki Morishita commented on CASSANDRA-13177: +1 > sstabledump doesn't handle non-empty partitions with a partition-level > deletion correctly > - > > Key: CASSANDRA-13177 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13177 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Tyler Hobbs >Assignee: Tyler Hobbs > Fix For: 3.0.x, 3.x > > > If a partition has a partition-level deletion, but still contains rows (with > timestamps higher than the deletion), sstabledump will only show the deletion > and not the rows. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CASSANDRA-13177) sstabledump doesn't handle non-empty partitions with a partition-level deletion correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-13177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-13177: --- Status: Ready to Commit (was: Patch Available) > sstabledump doesn't handle non-empty partitions with a partition-level > deletion correctly > - > > Key: CASSANDRA-13177 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13177 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Tyler Hobbs >Assignee: Tyler Hobbs > Fix For: 3.0.x, 3.x > > > If a partition has a partition-level deletion, but still contains rows (with > timestamps higher than the deletion), sstabledump will only show the deletion > and not the rows. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13178) Cassandra crash if a table is dropped while joining
[
https://issues.apache.org/jira/browse/CASSANDRA-13178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15850711#comment-15850711
]
Yuki Morishita commented on CASSANDRA-13178:
After CASSANDRA-8838 (v2.2+), when bootstrap streaming failed, the node should
keep running (but not joinning to the cluster) and user can manually resume
bootstrap streaming (nodetool bootstrap resume).
I'm afraid we are not backporting this feature to 2.1.
> Cassandra crash if a table is dropped while joining
> ---
>
> Key: CASSANDRA-13178
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13178
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
> Environment: Cassandra-2.1.9
>Reporter: Brian Gallew
>
> I just had three different nodes crash while joining a cluster. They've been
> streaming data for 2 days now, and each one exited with this error:
> {code}
> ERROR [STREAM-IN-/XX.XX.144.63] 2017-02-02 20:42:45,275
> StreamSession.java:505 - [Stream #b4279df0-e7de-11e6-aa5a-452e7f2ad12b]
> Streaming error occurred
> java.io.IOException: CF 8280bcb0-cdf7-11e6-b227-b97a72c7aa0d was dropped
> during streaming
> at
> org.apache.cassandra.streaming.compress.CompressedStreamReader.read(CompressedStreamReader.java:71)
> ~[apache-cassandra-2.1.9.jar:2.1.9-SNAPSHOT]
> at
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:48)
> ~[apache-cassandra-2.1.9.jar:2.1.9-SNAPSHOT]
> at
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:38)
> ~[apache-cassandra-2.1.9.jar:2.1.9-SNAPSHOT]
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:56)
> ~[apache-cassandra-2.1.9.jar:2.1.9-SNAPSHOT]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:250)
> ~[apache-cassandra-2.1.9.jar:2.1.9-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> INFO [STREAM-IN-/XX.XX.144.63] 2017-02-02 20:42:45,275
> StreamResultFuture.java:180 - [Stream #b4279df0-e7de-11e6-aa5a-452e7f2ad12b]
> Session with /XX.XX.144.63 is complete
> WARN [STREAM-IN-/XX.XX.144.63] 2017-02-02 20:42:45,277
> StreamResultFuture.java:207 - [Stream #b4279df0-e7de-11e6-aa5a-452e7f2ad12b]
> Stream failed
> ERROR [main] 2017-02-02 20:42:45,278 CassandraDaemon.java:579 - Exception
> encountered during startup
> java.lang.RuntimeException: Error during boostrap: Stream failed
> at
> org.apache.cassandra.dht.BootStrapper.bootstrap(BootStrapper.java:86)
> ~[apache-cassandra-2.1.9.jar:2.1.9-SNAPSHOT]
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1148)
> ~[apache-cassandra-2.1.9.jar:2.1.9-SNAPSHOT]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:938)
> ~[apache-cassandra-2.1.9.jar:2.1.9-SNAPSHOT]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:734)
> ~[apache-cassandra-2.1.9.jar:2.1.9-SNAPSHOT]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:611)
> ~[apache-cassandra-2.1.9.jar:2.1.9-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:387)
> [apache-cassandra-2.1.9.jar:2.1.9-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:562)
> [apache-cassandra-2.1.9.jar:2.1.9-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:651)
> [apache-cassandra-2.1.9.jar:2.1.9-SNAPSHOT]
> Caused by: org.apache.cassandra.streaming.StreamException: Stream failed
> at
> org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:85)
> ~[apache-cassandra-2.1.9.jar:2.1.9-SNAPSHOT]
> at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172)
> ~[guava-16.0.jar:na]
> at
> com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
> ~[guava-16.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> ~[guava-16.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> ~[guava-16.0.jar:na]
> at
> com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:202)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:208)
> ~[apache-cassandra-2.1.9.jar:2.1.9-SNAPSHOT]
> at
> org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:184)
> ~[apache
[jira] [Commented] (CASSANDRA-10908) bad report: client_encryption seems to prevent startup in 2.2.4 and 3.1
[
https://issues.apache.org/jira/browse/CASSANDRA-10908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848640#comment-15848640
]
Yuki Morishita commented on CASSANDRA-10908:
Do you mean you get the same exception as below:
{noformat}
Caused by: java.lang.IllegalArgumentException: Cannot support
TLS_RSA_WITH_AES_256_CBC_SHA with currently installed providers
{noformat}
You need to install JCE.
https://support.datastax.com/hc/en-us/articles/204226129-Receiving-error-Caused-by-java-lang-IllegalArgumentException-Cannot-support-TLS-RSA-WITH-AES-256-CBC-SHA-with-currently-installed-providers-on-DSE-startup-after-setting-up-client-to-node-encryption
> bad report: client_encryption seems to prevent startup in 2.2.4 and 3.1
> ---
>
> Key: CASSANDRA-10908
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10908
> Project: Cassandra
> Issue Type: Bug
> Environment: Amazon Linux 2015.09
>Reporter: Will Hayworth
> Attachments: 2.2.4-client-log-trace.log, client_encryption.log
>
>
> Hi there! I'm a total Cassandra novice, so please forgive me if this report
> is lacking or malformed. I've been setting up a new cluster and trying to use
> 3.1 but I've noticed that so much as *enabling* client-to-node encryption
> causes the node to shut down after determining there's no gossip backlog.
> Notably, I set up node-to-node encryption beforehand and that was working
> just fine. I thought they might be interfering with each other, but that
> seems not to be the case. Logs attached. (Please let me know how I can be of
> further help!)
> Thanks for looking at this,
> Will
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13135) Forced termination of repair session leaves repair jobs running
[ https://issues.apache.org/jira/browse/CASSANDRA-13135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15836964#comment-15836964 ] Yuki Morishita commented on CASSANDRA-13135: Patch to remove queued repair jobs at the end of session: ||branch||testall||dtest|| |[13135-2.2|https://github.com/yukim/cassandra/tree/13135-2.2]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-13135-2.2-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-13135-2.2-dtest/lastCompletedBuild/testReport/]| |[13135-3.0|https://github.com/yukim/cassandra/tree/13135-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-13135-3.0-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-13135-3.0-dtest/lastCompletedBuild/testReport/]| |[13135-3.11|https://github.com/yukim/cassandra/tree/13135-3.11]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-13135-3.11-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-13135-3.11-dtest/lastCompletedBuild/testReport/]| |[13135-trunk|https://github.com/yukim/cassandra/tree/13135-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-13135-trunk-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-13135-trunk-dtest/lastCompletedBuild/testReport/]| > Forced termination of repair session leaves repair jobs running > --- > > Key: CASSANDRA-13135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13135 > Project: Cassandra > Issue Type: Bug >Reporter: Yuki Morishita >Assignee: Yuki Morishita > Fix For: 2.2.x, 3.0.x, 3.x > > > Forced termination of repair session (by failure detector or jmx) keeps > repair jobs running that the session created after session is terminated. > This can cause increase in repair time by those unnecessary works left in > repair job queue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-13135) Forced termination of repair session leaves repair jobs running
[ https://issues.apache.org/jira/browse/CASSANDRA-13135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-13135: --- Status: Patch Available (was: Open) > Forced termination of repair session leaves repair jobs running > --- > > Key: CASSANDRA-13135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13135 > Project: Cassandra > Issue Type: Bug >Reporter: Yuki Morishita >Assignee: Yuki Morishita > Fix For: 2.2.x, 3.0.x, 3.x > > > Forced termination of repair session (by failure detector or jmx) keeps > repair jobs running that the session created after session is terminated. > This can cause increase in repair time by those unnecessary works left in > repair job queue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
