[jira] [Commented] (CASSANDRA-14468) "Unable to parse targets for index" on upgrade to Cassandra 3.0.10-3.0.16
[
https://issues.apache.org/jira/browse/CASSANDRA-14468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497633#comment-16497633
]
Jordan West commented on CASSANDRA-14468:
-
Can take a look next week
> "Unable to parse targets for index" on upgrade to Cassandra 3.0.10-3.0.16
> -
>
> Key: CASSANDRA-14468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14468
> Project: Cassandra
> Issue Type: Bug
>Reporter: Wade Simmons
>Priority: Major
>
> I am attempting to upgrade from Cassandra 2.2.10 to 3.0.16. I am getting this
> error:
> {code}
> org.apache.cassandra.exceptions.ConfigurationException: Unable to parse
> targets for index idx_foo ("666f6f")
> at
> org.apache.cassandra.index.internal.CassandraIndex.parseTarget(CassandraIndex.java:800)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.index.internal.CassandraIndex.indexCfsMetadata(CassandraIndex.java:747)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.db.ColumnFamilyStore.scrubDataDirectories(ColumnFamilyStore.java:645)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:251)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> [apache-cassandra-3.0.16.jar:3.0.16]
> {code}
> It looks like this might be related to CASSANDRA-14104 that was just added to
> 3.0.16
--
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-14464) stop-server.bat -p ../pid.txt -f command not working on windows 2016
[ https://issues.apache.org/jira/browse/CASSANDRA-14464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497751#comment-16497751 ] Shyam Phirke commented on CASSANDRA-14464: -- [~jasobrown], [~djoshi3], [~JoshuaMcKenzie] Can anybody look into this issue? This can be observed on Win 2012 machines as well. > stop-server.bat -p ../pid.txt -f command not working on windows 2016 > > > Key: CASSANDRA-14464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14464 > Project: Cassandra > Issue Type: Bug >Reporter: Shyam Phirke >Priority: Critical > > Steps to reproduce: > 1. Copy and extract cassandra binaries on windows 2016 machine > 2. Start cassandra in non-legacy mode > 3. Check pid of cassandra in task manager and compare it with in pid.txt > 4. Now stop cassandra using command stop-server.bat -p ../pid.txt -f > Expected: > After executing \bin:\> stop-server.bat -p > ../pid.txt -f > cassandra process as in pid.txt should get killed. > > Actual: > After executing above stop command, the cassandra process as in pid.txt gets > killed but a new process gets created with new pid. Also the pid.txt not > updated with new pid. > This new process should not get created. > > Please comment on this issue if more details required. > I am using cassandra 3.11.2. > > This issue impacting me much since because of this new process getting > created my application uninstallation getting impacted. > -- 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] [Comment Edited] (CASSANDRA-14451) Infinity ms Commit Log Sync
[
https://issues.apache.org/jira/browse/CASSANDRA-14451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498619#comment-16498619
]
Jason Brown edited comment on CASSANDRA-14451 at 6/1/18 9:57 PM:
-
Below are branches that resolve the problem
||3.0||3.11||trunk||
|[branch|https://github.com/jasobrown/cassandra/tree/14451-3.0]|[branch|https://github.com/jasobrown/cassandra/tree/14451-3.11]|[branch|https://github.com/jasobrown/cassandra/tree/14451-trunk]|
|[utests &
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14451-3.0]|[utests
&
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14451-3.11]|[utests
&
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14451-trunk]|
The bug was using {{markerIntervalNanos}} in the {{wakeUpAt}} variable as basis
for determining if we've lagged in the actual flush to disk. The code should
use {{syncIntervalNanos}} for that determination. Once again, the only problem
here is around determining if we should log about the commitlog flushing
falling behind, not that the commitlog is actually falling behind (it ins't, at
least as far as the overlogging here is concerned).
Most of the change was moving the logging code out of the primary
{{AbstractCommitLogService.SyncRunnable#sync()}} and into a subroutine. This
allowed me to add unit tests, as well as clean up/clarify the {{sync()}} method.
was (Author: jasobrown):
Below are branches that resolve the problem
||3.0||3.11||trunk||
|[branch|https://github.com/jasobrown/cassandra/tree/14451-3.0]|[branch|https://github.com/jasobrown/cassandra/tree/14451-3.11]|[branch|https://github.com/jasobrown/cassandra/tree/14451-trunk]|
|[utests
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14451-3.0]|[utests
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14451-3.11]|[utests
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14451-trunk]|
||
The bug was using {{markerIntervalNanos}} in the {{wakeUpAt}} variable as basis
for determining if we've lagged in the actual flush to disk. The code should
use {{syncIntervalNanos}} for that determination.
Most of the change was moving the logging code out of the primary
{{AbstractCommitLogService.SyncRunnable#sync()}} and into a subroutine. This
allowed me to add unit tests, as well as clean up/clarify the {{sync()}} method.
> Infinity ms Commit Log Sync
> ---
>
> Key: CASSANDRA-14451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14451
> Project: Cassandra
> Issue Type: Bug
> Environment: 3.11.2 - 2 DC
>Reporter: Harry Hough
>Assignee: Jason Brown
>Priority: Minor
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> Its giving commit log sync warnings where there were apparently zero syncs
> and therefore gives "Infinityms" as the average duration
> {code:java}
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:11:14,294
> NoSpamLogger.java:94 - Out of 0 commit log syncs over the past 0.00s with
> average duration of Infinityms, 1 have exceeded the configured commit
> interval by an average of 74.40ms
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:16:57,844
> NoSpamLogger.java:94 - Out of 0 commit log syncs over the past 0.00s with
> average duration of Infinityms, 1 have exceeded the configured commit
> interval by an average of 198.69ms
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:24:46,325
> NoSpamLogger.java:94 - Out of 0 commit log syncs over the past 0.00s with
> average duration of Infinityms, 1 have exceeded the configured commit
> interval by an average of 264.11ms
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:29:46,393
> NoSpamLogger.java:94 - Out of 32 commit log syncs over the past 268.84s with,
> average duration of 17.56ms, 1 have exceeded the configured commit interval
> by an average of 173.66ms{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-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498851#comment-16498851 ] Patrick Bannister commented on CASSANDRA-10190: --- [~jolynch], thanks! Help figuring out the testing infrastructure would be much appreciated, I don't have any experience with tox yet. Right now I'm testing on AWS EC2 instances, I haven't made the jump to CI systems yet. I'll add some subtasks to this ticket to address our testing gaps - authentication, Windows, displaying CJK languages, describe statements, and use of commas for thousands separators and decimal separators are the concrete items I think are urgent. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement >Reporter: Andrew Pennebaker >Priority: Major > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- 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-14466) Enable Direct I/O
[ https://issues.apache.org/jira/browse/CASSANDRA-14466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498703#comment-16498703 ] Mulugeta Mammo commented on CASSANDRA-14466: [~aweisberg] Thanks for the feedback. Yes, we are well aware of the traditional recommendation of not mixing O_DIRECT with buffered I/O as described in detail in the Linux manual pages here: [http://man7.org/linux/man-pages/man2/open.2.html]. However, our understanding is that latest kernel versions do a pretty good job of managing any possible page-cache coherence. We have confirmed this by running multiple experiments and by running Cassandra stress test with a mix read/write workload that uses O_DIRECT for read and buffered I/O for write. Regarding the general question on the performance benefit of O_DIRECT over buffered I/O: * O_DIRECT reduces the overhead of a file system cache pollution. Our experiments show that, when running a pure read workload under heavy load the system's performance is overwhelmed by the kernel resources that are needed to manage memory. For example, we see a very high kernel CPU utilization that is close to 50%, vmstat shows a high memory paging activity and the perf profile shows try_to_unmap_one as one of the hottest kernel functions. This bottleneck is reproducible on various server systems with multiple high bandwidth flash storage devices (i.e. NVMe devices). * O_DIRECT avoids the double caching problem, to better utilize the Cassandra specific caching options. * O_DIRECT offers a more predictable latency independent of other processes using file system cache. *Details:* Cassandra does not have a way to disable the OS file system caching on Linux. The option to bypass the file system cache in the JDK was first introduced in Java on JDK 10 with the introduction of Direct IO support. We modified Cassandra to incorporate Direct IO support in the read and write IO path.The Write IO path did not provide performance improvements, hence to simplify the patch only the read IO path is being proposed here. This Direct IO patch produces the following relative performance improvements over baseline Cassandra: * Kernel CPU utilization is reduced by 90%. * Cassandra Ops/sec throughput increases up to 80% * Mean, 95th, 99th latencies are reduced by 40-50% General Hardware Configuration: * high core count servers (40+ cores) * 128GB+ DRAM * Dataset:DRAM ratio of 8:1 or greater * multiple NVMe devices General Software Configuration: * Cassandra versions: Cassandra 3.x and trunk 4.0 versions * Cassandra process running: one * Schema compression settings: default LZ4 64KB chunk size * Schema: cqlstress-insanity-example.yaml * Benchmark: Cassandra-Stress * Runtime: 5 minutes or more depending on how long DRAM takes to reach steady state * Workload: 100% read * Heavily loaded system (number of client threads >200) * Kernel: version 4.0 and above * Other settings: Datastax production settings ([https://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/config/configRecommendedSettings.html] Thanks, Mulugeta > Enable Direct I/O > -- > > Key: CASSANDRA-14466 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14466 > Project: Cassandra > Issue Type: New Feature > Components: Local Write-Read Paths >Reporter: Mulugeta Mammo >Priority: Major > Attachments: direct_io.patch > > > Hi, > JDK 10 introduced a new API for Direct IO that enables applications to bypass > the file system cache and potentially improve performance. Details of this > feature can be found at [https://bugs.openjdk.java.net/browse/JDK-8164900]. > This patch uses the JDK 10 API to enable Direct IO for the Cassandra read > path. By default, we have disabled this feature; but it can be enabled using > a new configuration parameter, enable_direct_io_for_read_path. We have > conducted a Cassandra read-only stress test and measured a throughput gain of > up to 60% on flash drives. > The patch requires JDK 10 Cassandra Support - > https://issues.apache.org/jira/browse/CASSANDRA-9608 > Please review the patch and let us know your feedback. > Thanks, > [^direct_io.patch] > -- 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] [Issue Comment Deleted] (CASSANDRA-10876) Alter behavior of batch WARN and fail on single partition batches
[
https://issues.apache.org/jira/browse/CASSANDRA-10876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tania S Engel updated CASSANDRA-10876:
--
Comment: was deleted
(was: In 3.11.1 we still see these warnings even when we are inserting into
multiple tables with the same partition key. The comment above from Patrick
seems to indicate a partition key is for one keyspace.table. But I thought a
partition key was a value that hashed to the same value. Is it still a burden
on the coordinator worthy of a warning if we do a batch insert to 4 tables with
the same partition key ({color:#33}Day{color})? For example if we do a
batch insert into these 2 tables, is that considered a single partition insert
and if so why is there a warning?
CREATE TABLE Log_User (Day timestamp, LogTime timeuuid,
{color:#33}UserID{color} int) PRIMARY KEY ({color:#33}Day {color},
UserID, LogTime)
CREATE TABLE Log_Event( Day timestamp, LogTime timeuuid, EventID int)
{color:#33}PRIMARY KEY ({color}{color:#33}Day {color}{color:#33},
EventID , LogTime){color})
> Alter behavior of batch WARN and fail on single partition batches
> -
>
> Key: CASSANDRA-10876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10876
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Patrick McFadin
>Assignee: Sylvain Lebresne
>Priority: Minor
> Labels: lhf
> Fix For: 3.6
>
> Attachments: 10876.txt
>
>
> In an attempt to give operator insight into potentially harmful batch usage,
> Jiras were created to log WARN or fail on certain batch sizes. This ignores
> the single partition batch, which doesn't create the same issues as a
> multi-partition batch.
> The proposal is to ignore size on single partition batch statements.
> Reference:
> [CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487]
> [CASSANDRA-8011|https://issues.apache.org/jira/browse/CASSANDRA-8011]
--
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-14487) Unset GREP_OPTIONS
[
https://issues.apache.org/jira/browse/CASSANDRA-14487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498720#comment-16498720
]
ASF GitHub Bot commented on CASSANDRA-14487:
GitHub user joaquincasares opened a pull request:
https://github.com/apache/cassandra/pull/229
CASSANDRA-14487 unset GREP_OPTIONS
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/joaquincasares/cassandra CASSANDRA-14487
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cassandra/pull/229.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #229
commit ab86727f3eb91736bc74b92befd576b7e0213462
Author: Joaquin Casares
Date: 2018-06-01T23:47:32Z
CASSANDRA-14487 unset GREP_OPTIONS
> Unset GREP_OPTIONS
> --
>
> Key: CASSANDRA-14487
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14487
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joaquin Casares
>Assignee: Joaquin Casares
>Priority: Major
>
> I have always had GREP_OPTIONS set to \{{–color=always}}.
> Recently, on OS X, this bit me here:
> *
> [https://github.com/apache/cassandra/blob/069e383f57e3106bbe2e6ddcebeae77da1ea53e1/conf/cassandra-env.sh#L132]
> Because GREP_OPTIONS is also deprecated, it's suggested you use the following
> format instead:
> {NOFORMAT}
> alias grep="grep --color=always"
> {NOFORMAT}
> We have two paths forward:
> * {{unset GREP_OPTIONS}}
> * Force the affected line to be {{grep --color=never}}
--
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-14487) Unset GREP_OPTIONS
[
https://issues.apache.org/jira/browse/CASSANDRA-14487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joaquin Casares updated CASSANDRA-14487:
Status: Patch Available (was: Open)
https://github.com/apache/cassandra/pull/229
> Unset GREP_OPTIONS
> --
>
> Key: CASSANDRA-14487
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14487
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joaquin Casares
>Assignee: Joaquin Casares
>Priority: Major
>
> I have always had GREP_OPTIONS set to \{{–color=always}}.
> Recently, on OS X, this bit me here:
> *
> [https://github.com/apache/cassandra/blob/069e383f57e3106bbe2e6ddcebeae77da1ea53e1/conf/cassandra-env.sh#L132]
> Because GREP_OPTIONS is also deprecated, it's suggested you use the following
> format instead:
> {NOFORMAT}
> alias grep="grep --color=always"
> {NOFORMAT}
> We have two paths forward:
> * {{unset GREP_OPTIONS}}
> * Force the affected line to be {{grep --color=never}}
--
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-14487) Unset GREP_OPTIONS
[
https://issues.apache.org/jira/browse/CASSANDRA-14487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joaquin Casares updated CASSANDRA-14487:
Description:
I have always had GREP_OPTIONS set to \{{–color=always}}.
Recently, on OS X, this bit me here:
*
[https://github.com/apache/cassandra/blob/069e383f57e3106bbe2e6ddcebeae77da1ea53e1/conf/cassandra-env.sh#L132]
Because GREP_OPTIONS is also deprecated, it's suggested you use the following
format instead:
{NOFORMAT}
alias grep="grep --color=always"
{NOFORMAT}
We have two paths forward:
* \{{unset GREP_OPTIONS}}
* Force the affected line to be \{{grep --color=never}}
was:
I have always had GREP_OPTIONS set to \{{–color=always}}.
Recently, on OS X, this bit me here:
*
[https://github.com/apache/cassandra/blob/069e383f57e3106bbe2e6ddcebeae77da1ea53e1/conf/cassandra-env.sh#L132]
Because GREP_OPTIONS is also deprecated, it's suggested you use the following
format instead:
{NOFORMAT}
alias grep="grep --color=always"
{NOFORMAT}
We have two paths forward:
* \{{unset GREP_OPTIONS}}
* Force the affected line to be \{{grep --color=never}}
> Unset GREP_OPTIONS
> --
>
> Key: CASSANDRA-14487
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14487
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joaquin Casares
>Assignee: Joaquin Casares
>Priority: Major
>
> I have always had GREP_OPTIONS set to \{{–color=always}}.
> Recently, on OS X, this bit me here:
> *
> [https://github.com/apache/cassandra/blob/069e383f57e3106bbe2e6ddcebeae77da1ea53e1/conf/cassandra-env.sh#L132]
> Because GREP_OPTIONS is also deprecated, it's suggested you use the following
> format instead:
> {NOFORMAT}
> alias grep="grep --color=always"
> {NOFORMAT}
> We have two paths forward:
> * \{{unset GREP_OPTIONS}}
> * Force the affected line to be \{{grep --color=never}}
--
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-14487) Unset GREP_OPTIONS
[
https://issues.apache.org/jira/browse/CASSANDRA-14487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joaquin Casares updated CASSANDRA-14487:
Description:
I have always had GREP_OPTIONS set to \{{–color=always}}.
Recently, on OS X, this bit me here:
*
[https://github.com/apache/cassandra/blob/069e383f57e3106bbe2e6ddcebeae77da1ea53e1/conf/cassandra-env.sh#L132]
Because GREP_OPTIONS is also deprecated, it's suggested you use the following
format instead:
{NOFORMAT}
alias grep="grep --color=always"
{NOFORMAT}
We have two paths forward:
* {{unset GREP_OPTIONS}}
* Force the affected line to be {{grep --color=never}}
was:
I have always had GREP_OPTIONS set to \{{–color=always}}.
Recently, on OS X, this bit me here:
*
[https://github.com/apache/cassandra/blob/069e383f57e3106bbe2e6ddcebeae77da1ea53e1/conf/cassandra-env.sh#L132]
Because GREP_OPTIONS is also deprecated, it's suggested you use the following
format instead:
{NOFORMAT}
alias grep="grep --color=always"
{NOFORMAT}
We have two paths forward:
* \{{unset GREP_OPTIONS}}
* Force the affected line to be \{{grep --color=never}}
> Unset GREP_OPTIONS
> --
>
> Key: CASSANDRA-14487
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14487
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joaquin Casares
>Assignee: Joaquin Casares
>Priority: Major
>
> I have always had GREP_OPTIONS set to \{{–color=always}}.
> Recently, on OS X, this bit me here:
> *
> [https://github.com/apache/cassandra/blob/069e383f57e3106bbe2e6ddcebeae77da1ea53e1/conf/cassandra-env.sh#L132]
> Because GREP_OPTIONS is also deprecated, it's suggested you use the following
> format instead:
> {NOFORMAT}
> alias grep="grep --color=always"
> {NOFORMAT}
> We have two paths forward:
> * {{unset GREP_OPTIONS}}
> * Force the affected line to be {{grep --color=never}}
--
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-10876) Alter behavior of batch WARN and fail on single partition batches
[
https://issues.apache.org/jira/browse/CASSANDRA-10876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498508#comment-16498508
]
Tania S Engel commented on CASSANDRA-10876:
---
In 3.11.1 we still see these warnings even when we are inserting into multiple
tables with the same partition key. The comment above from Patrick seems to
indicate a partition key is for one keyspace.table. But I thought a partition
key was a value that hashed to the same value. Is it still a burden on the
coordinator worthy of a warning if we do a batch insert to 4 tables with the
same partition key ({color:#33}Day{color})? For example if we do a batch
insert into these 2 tables, is that considered a single partition insert and if
so why is there a warning?
CREATE TABLE Log_User (Day timestamp, LogTime timeuuid,
{color:#33}UserID{color} int) PRIMARY KEY ({color:#33}Day {color},
UserID, LogTime)
CREATE TABLE Log_Event( Day timestamp, LogTime timeuuid, EventID int)
{color:#33}PRIMARY KEY ({color}{color:#33}Day {color}{color:#33},
EventID , LogTime){color}
> Alter behavior of batch WARN and fail on single partition batches
> -
>
> Key: CASSANDRA-10876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10876
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Patrick McFadin
>Assignee: Sylvain Lebresne
>Priority: Minor
> Labels: lhf
> Fix For: 3.6
>
> Attachments: 10876.txt
>
>
> In an attempt to give operator insight into potentially harmful batch usage,
> Jiras were created to log WARN or fail on certain batch sizes. This ignores
> the single partition batch, which doesn't create the same issues as a
> multi-partition batch.
> The proposal is to ignore size on single partition batch statements.
> Reference:
> [CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487]
> [CASSANDRA-8011|https://issues.apache.org/jira/browse/CASSANDRA-8011]
--
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-14451) Infinity ms Commit Log Sync
[
https://issues.apache.org/jira/browse/CASSANDRA-14451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498619#comment-16498619
]
Jason Brown commented on CASSANDRA-14451:
-
Below are branches that resolve the problem
||3.0||3.11||trunk||
|[branch|https://github.com/jasobrown/cassandra/tree/14451-3.0]|[branch|https://github.com/jasobrown/cassandra/tree/14451-3.11]|[branch|https://github.com/jasobrown/cassandra/tree/14451-trunk]|
|[utests
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14451-3.0]|[utests
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14451-3.11]|[utests
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14451-trunk]|
||
The bug was using {{markerIntervalNanos}} in the {{wakeUpAt}} variable as basis
for determining if we've lagged in the actual flush to disk. The code should
use {{syncIntervalNanos}} for that determination.
Most of the change was moving the logging code out of the primary
{{AbstractCommitLogService.SyncRunnable#sync()}} and into a subroutine. This
allowed me to add unit tests, as well as clean up/clarify the {{sync()}} method.
> Infinity ms Commit Log Sync
> ---
>
> Key: CASSANDRA-14451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14451
> Project: Cassandra
> Issue Type: Bug
> Environment: 3.11.2 - 2 DC
>Reporter: Harry Hough
>Assignee: Jason Brown
>Priority: Minor
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> Its giving commit log sync warnings where there were apparently zero syncs
> and therefore gives "Infinityms" as the average duration
> {code:java}
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:11:14,294
> NoSpamLogger.java:94 - Out of 0 commit log syncs over the past 0.00s with
> average duration of Infinityms, 1 have exceeded the configured commit
> interval by an average of 74.40ms
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:16:57,844
> NoSpamLogger.java:94 - Out of 0 commit log syncs over the past 0.00s with
> average duration of Infinityms, 1 have exceeded the configured commit
> interval by an average of 198.69ms
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:24:46,325
> NoSpamLogger.java:94 - Out of 0 commit log syncs over the past 0.00s with
> average duration of Infinityms, 1 have exceeded the configured commit
> interval by an average of 264.11ms
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:29:46,393
> NoSpamLogger.java:94 - Out of 32 commit log syncs over the past 268.84s with,
> average duration of 17.56ms, 1 have exceeded the configured commit interval
> by an average of 173.66ms{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-14451) Infinity ms Commit Log Sync
[
https://issues.apache.org/jira/browse/CASSANDRA-14451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Brown updated CASSANDRA-14451:
Fix Version/s: 4.0.x
3.11.x
3.0.x
Status: Patch Available (was: Open)
> Infinity ms Commit Log Sync
> ---
>
> Key: CASSANDRA-14451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14451
> Project: Cassandra
> Issue Type: Bug
> Environment: 3.11.2 - 2 DC
>Reporter: Harry Hough
>Assignee: Jason Brown
>Priority: Minor
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> Its giving commit log sync warnings where there were apparently zero syncs
> and therefore gives "Infinityms" as the average duration
> {code:java}
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:11:14,294
> NoSpamLogger.java:94 - Out of 0 commit log syncs over the past 0.00s with
> average duration of Infinityms, 1 have exceeded the configured commit
> interval by an average of 74.40ms
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:16:57,844
> NoSpamLogger.java:94 - Out of 0 commit log syncs over the past 0.00s with
> average duration of Infinityms, 1 have exceeded the configured commit
> interval by an average of 198.69ms
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:24:46,325
> NoSpamLogger.java:94 - Out of 0 commit log syncs over the past 0.00s with
> average duration of Infinityms, 1 have exceeded the configured commit
> interval by an average of 264.11ms
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:29:46,393
> NoSpamLogger.java:94 - Out of 32 commit log syncs over the past 268.84s with,
> average duration of 17.56ms, 1 have exceeded the configured commit interval
> by an average of 173.66ms{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] [Created] (CASSANDRA-14487) Unset GREP_OPTIONS
Joaquin Casares created CASSANDRA-14487:
---
Summary: Unset GREP_OPTIONS
Key: CASSANDRA-14487
URL: https://issues.apache.org/jira/browse/CASSANDRA-14487
Project: Cassandra
Issue Type: Bug
Reporter: Joaquin Casares
Assignee: Joaquin Casares
I have always had GREP_OPTIONS set to \{{–color=always}}.
Recently, on OS X, this bit me here:
*
[https://github.com/apache/cassandra/blob/069e383f57e3106bbe2e6ddcebeae77da1ea53e1/conf/cassandra-env.sh#L132]
Because GREP_OPTIONS is also deprecated, it's suggested you use the following
format instead:
{NOFORMAT}
alias grep="grep --color=always"
{NOFORMAT}
We have two paths forward:
* \{{unset GREP_OPTIONS}}
* Force the affected line to be \{{grep --color=never}}
--
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-14464) stop-server.bat -p ../pid.txt -f command not working on windows 2016
[ https://issues.apache.org/jira/browse/CASSANDRA-14464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497827#comment-16497827 ] Jason Brown commented on CASSANDRA-14464: - [~sphirke] I do not have access to a Windows machine. nor have I actually used one within the last decade. The only other folks on the git blame for various Windows files are [~blerer] or [~pauloricardomg]. > stop-server.bat -p ../pid.txt -f command not working on windows 2016 > > > Key: CASSANDRA-14464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14464 > Project: Cassandra > Issue Type: Bug >Reporter: Shyam Phirke >Priority: Critical > > Steps to reproduce: > 1. Copy and extract cassandra binaries on windows 2016 machine > 2. Start cassandra in non-legacy mode > 3. Check pid of cassandra in task manager and compare it with in pid.txt > 4. Now stop cassandra using command stop-server.bat -p ../pid.txt -f > Expected: > After executing \bin:\> stop-server.bat -p > ../pid.txt -f > cassandra process as in pid.txt should get killed. > > Actual: > After executing above stop command, the cassandra process as in pid.txt gets > killed but a new process gets created with new pid. Also the pid.txt not > updated with new pid. > This new process should not get created. > > Please comment on this issue if more details required. > I am using cassandra 3.11.2. > > This issue impacting me much since because of this new process getting > created my application uninstallation getting impacted. > -- 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-14451) Infinity ms Commit Log Sync
[
https://issues.apache.org/jira/browse/CASSANDRA-14451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497916#comment-16497916
]
Jason Brown commented on CASSANDRA-14451:
-
As I suspected, this is just a bug with logging (due to CASSANDRA-14108), and
no real behavior or correctness is impacted. I have a patch for 3.11, but need
to port to 3.0 and trunk.
> Infinity ms Commit Log Sync
> ---
>
> Key: CASSANDRA-14451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14451
> Project: Cassandra
> Issue Type: Bug
> Environment: 3.11.2 - 2 DC
>Reporter: Harry Hough
>Assignee: Jason Brown
>Priority: Minor
>
> Its giving commit log sync warnings where there were apparently zero syncs
> and therefore gives "Infinityms" as the average duration
> {code:java}
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:11:14,294
> NoSpamLogger.java:94 - Out of 0 commit log syncs over the past 0.00s with
> average duration of Infinityms, 1 have exceeded the configured commit
> interval by an average of 74.40ms
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:16:57,844
> NoSpamLogger.java:94 - Out of 0 commit log syncs over the past 0.00s with
> average duration of Infinityms, 1 have exceeded the configured commit
> interval by an average of 198.69ms
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:24:46,325
> NoSpamLogger.java:94 - Out of 0 commit log syncs over the past 0.00s with
> average duration of Infinityms, 1 have exceeded the configured commit
> interval by an average of 264.11ms
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:29:46,393
> NoSpamLogger.java:94 - Out of 32 commit log syncs over the past 268.84s with,
> average duration of 17.56ms, 1 have exceeded the configured commit interval
> by an average of 173.66ms{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-14468) "Unable to parse targets for index" on upgrade to Cassandra 3.0.10-3.0.16
[
https://issues.apache.org/jira/browse/CASSANDRA-14468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wade Simmons updated CASSANDRA-14468:
-
Attachment: data.tar.gz
> "Unable to parse targets for index" on upgrade to Cassandra 3.0.10-3.0.16
> -
>
> Key: CASSANDRA-14468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14468
> Project: Cassandra
> Issue Type: Bug
>Reporter: Wade Simmons
>Priority: Major
> Attachments: data.tar.gz
>
>
> I am attempting to upgrade from Cassandra 2.2.10 to 3.0.16. I am getting this
> error:
> {code}
> org.apache.cassandra.exceptions.ConfigurationException: Unable to parse
> targets for index idx_foo ("666f6f")
> at
> org.apache.cassandra.index.internal.CassandraIndex.parseTarget(CassandraIndex.java:800)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.index.internal.CassandraIndex.indexCfsMetadata(CassandraIndex.java:747)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.db.ColumnFamilyStore.scrubDataDirectories(ColumnFamilyStore.java:645)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:251)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> [apache-cassandra-3.0.16.jar:3.0.16]
> {code}
> It looks like this might be related to CASSANDRA-14104 that was just added to
> 3.0.16
--
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-14467) Add option to sanity check tombstones on reads/compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-14467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497918#comment-16497918 ] Marcus Eriksson commented on CASSANDRA-14467: - bq. why is this not just an assertion? It seems very assertion like? Agree, was debating this a bit, but biggest reason I went this way was to have a way of just logging any validation failures. Also, doing this validation is not very expensive, but it is not free, so you might not want to disable all assertions to just disable this check. Push a few new commits addressing the latest round of comments > Add option to sanity check tombstones on reads/compaction > - > > Key: CASSANDRA-14467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14467 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Minor > Fix For: 4.x > > > We should add an option to do a quick sanity check of tombstones on reads + > compaction. It should either log the error or throw an exception. -- 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-14468) "Unable to parse targets for index" on upgrade to Cassandra 3.0.10-3.0.16
[
https://issues.apache.org/jira/browse/CASSANDRA-14468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497917#comment-16497917
]
Wade Simmons commented on CASSANDRA-14468:
--
I think the issue is that {{type}} on this line is the type for the value of
the column, and not the type for the name of the column:
https://github.com/apache/cassandra/blob/cassandra-3.0.16/src/java/org/apache/cassandra/schema/SchemaKeyspace.java#L1063
> "Unable to parse targets for index" on upgrade to Cassandra 3.0.10-3.0.16
> -
>
> Key: CASSANDRA-14468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14468
> Project: Cassandra
> Issue Type: Bug
>Reporter: Wade Simmons
>Priority: Major
>
> I am attempting to upgrade from Cassandra 2.2.10 to 3.0.16. I am getting this
> error:
> {code}
> org.apache.cassandra.exceptions.ConfigurationException: Unable to parse
> targets for index idx_foo ("666f6f")
> at
> org.apache.cassandra.index.internal.CassandraIndex.parseTarget(CassandraIndex.java:800)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.index.internal.CassandraIndex.indexCfsMetadata(CassandraIndex.java:747)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.db.ColumnFamilyStore.scrubDataDirectories(ColumnFamilyStore.java:645)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:251)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> [apache-cassandra-3.0.16.jar:3.0.16]
> {code}
> It looks like this might be related to CASSANDRA-14104 that was just added to
> 3.0.16
--
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-14468) "Unable to parse targets for index" on upgrade to Cassandra 3.0.10-3.0.16
[
https://issues.apache.org/jira/browse/CASSANDRA-14468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497925#comment-16497925
]
Wade Simmons commented on CASSANDRA-14468:
--
I was able to reproduce by creating two column families. Each with a column
named "foo", one with comparator type BytesType and one with UTF8Type.
I will attach the Cassandra 2.2.10 data directory from this reproduction. If
you start up Cassandra 3.0.10+ with this data it will reproduce the error.
> "Unable to parse targets for index" on upgrade to Cassandra 3.0.10-3.0.16
> -
>
> Key: CASSANDRA-14468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14468
> Project: Cassandra
> Issue Type: Bug
>Reporter: Wade Simmons
>Priority: Major
>
> I am attempting to upgrade from Cassandra 2.2.10 to 3.0.16. I am getting this
> error:
> {code}
> org.apache.cassandra.exceptions.ConfigurationException: Unable to parse
> targets for index idx_foo ("666f6f")
> at
> org.apache.cassandra.index.internal.CassandraIndex.parseTarget(CassandraIndex.java:800)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.index.internal.CassandraIndex.indexCfsMetadata(CassandraIndex.java:747)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.db.ColumnFamilyStore.scrubDataDirectories(ColumnFamilyStore.java:645)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:251)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> [apache-cassandra-3.0.16.jar:3.0.16]
> {code}
> It looks like this might be related to CASSANDRA-14104 that was just added to
> 3.0.16
--
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-14468) "Unable to parse targets for index" on upgrade to Cassandra 3.0.10-3.0.16
[
https://issues.apache.org/jira/browse/CASSANDRA-14468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497909#comment-16497909
]
Wade Simmons commented on CASSANDRA-14468:
--
Interestingly, it looks like the ticket that caused this issue was trying to
solve a very similar issue! CASSANDRA-12516
The problem is that the type is listed as "UTF8Type" for both calls to
getInterned. I'm guessing when its being called with hex bytes it should not be
UTF8Type and this is the bug.
> "Unable to parse targets for index" on upgrade to Cassandra 3.0.10-3.0.16
> -
>
> Key: CASSANDRA-14468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14468
> Project: Cassandra
> Issue Type: Bug
>Reporter: Wade Simmons
>Priority: Major
>
> I am attempting to upgrade from Cassandra 2.2.10 to 3.0.16. I am getting this
> error:
> {code}
> org.apache.cassandra.exceptions.ConfigurationException: Unable to parse
> targets for index idx_foo ("666f6f")
> at
> org.apache.cassandra.index.internal.CassandraIndex.parseTarget(CassandraIndex.java:800)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.index.internal.CassandraIndex.indexCfsMetadata(CassandraIndex.java:747)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.db.ColumnFamilyStore.scrubDataDirectories(ColumnFamilyStore.java:645)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:251)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> [apache-cassandra-3.0.16.jar:3.0.16]
> {code}
> It looks like this might be related to CASSANDRA-14104 that was just added to
> 3.0.16
--
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-12516) Interned column identifiers can be overridden incorrectly
[
https://issues.apache.org/jira/browse/CASSANDRA-12516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497926#comment-16497926
]
Wade Simmons commented on CASSANDRA-12516:
--
It looks like this patch introduced a new error: CASSANDRA-14468
> Interned column identifiers can be overridden incorrectly
> -
>
> Key: CASSANDRA-12516
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12516
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Aleksey Yeschenko
>Assignee: Stefania
>Priority: Major
> Fix For: 3.0.10, 3.10
>
>
> As discovered by [~Stefania] in CASSANDRA-12423, our use of
> {{ColumnIdentifier.internedInstances}} to map byte buffer column names to
> column identifiers is incorrect. It's possible for two non-equal
> {{ColumnIdentifier}} instances to have the same {{ByteBuffer}} as raw name,
> and yet different text representations, due to different column name types,
> leading to hard to debug correctness issues.
> Should either amend the map to have the type as part of the key, or limit the
> use of that map.
--
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-14442) Let nodetool import take a list of directories
[ https://issues.apache.org/jira/browse/CASSANDRA-14442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497964#comment-16497964 ] Marcus Eriksson commented on CASSANDRA-14442: - bq. is it ok that callers of importNewSSTables can now run concurrently good point, re-added the synchronized on that method to be sure, we shouldn't be running nodetool import concurrently anyway bq. Consider moving SSTableImporter#moveAndOpenSSTable to be a static method on SSTable, maybe renameAndOpen (it may be useful for future uses/tests and isn’t specific to SSTableImporter) fixed, and added a sanity check that we are not moving live sstables and a few tests bq. Should they be marked since 4.0? ah yes, nice catch > Let nodetool import take a list of directories > -- > > Key: CASSANDRA-14442 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14442 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Major > Fix For: 4.x > > > It should be possible to load sstables from several input directories when > running nodetool import. Directories that failed to import should be output. -- 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-14468) "Unable to parse targets for index" on upgrade to Cassandra 3.0.10-3.0.16
[
https://issues.apache.org/jira/browse/CASSANDRA-14468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497902#comment-16497902
]
Wade Simmons commented on CASSANDRA-14468:
--
Ok I've dug a bit further and found out my simplified schema will not reproduce
it. After running a debugger, it appears that the issue somehow related to
ColumnIdentifier.internedInstances. For some reason, some entries in this map
have their "text" set to the actual name of the column (like "foo") and some
have their text set to the hex bytes of the name (like "666f6f"). I think the
issue is that the InternedKey only matches on the bytes of the column name, so
both lookups with "foo" and "666f6f" will pull the same interned entry from the
map. The stacktrace happens when the schema has the hex byte version of the
name, but the internedmap has the ascii version.
My current guess is there are similar column names in other tables and they are
getting interned incorrectly. I'll see if I can dig into this more.
> "Unable to parse targets for index" on upgrade to Cassandra 3.0.10-3.0.16
> -
>
> Key: CASSANDRA-14468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14468
> Project: Cassandra
> Issue Type: Bug
>Reporter: Wade Simmons
>Priority: Major
>
> I am attempting to upgrade from Cassandra 2.2.10 to 3.0.16. I am getting this
> error:
> {code}
> org.apache.cassandra.exceptions.ConfigurationException: Unable to parse
> targets for index idx_foo ("666f6f")
> at
> org.apache.cassandra.index.internal.CassandraIndex.parseTarget(CassandraIndex.java:800)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.index.internal.CassandraIndex.indexCfsMetadata(CassandraIndex.java:747)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.db.ColumnFamilyStore.scrubDataDirectories(ColumnFamilyStore.java:645)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:251)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> [apache-cassandra-3.0.16.jar:3.0.16]
> {code}
> It looks like this might be related to CASSANDRA-14104 that was just added to
> 3.0.16
--
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-14467) Add option to sanity check tombstones on reads/compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-14467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498155#comment-16498155 ] Ariel Weisberg commented on CASSANDRA-14467: Only remaining nit is that when you reset the setting in the unit tests it's not exception safe so if the test fails it will remain disabled. Otherwise +1. > Add option to sanity check tombstones on reads/compaction > - > > Key: CASSANDRA-14467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14467 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Minor > Fix For: 4.x > > > We should add an option to do a quick sanity check of tombstones on reads + > compaction. It should either log the error or throw an exception. -- 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-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498303#comment-16498303 ] Joseph Lynch commented on CASSANDRA-10190: -- [~ptbannister] testing against both python2 and python3 is reasonably easy using tox and it sounds like supporting both is going to be the easiest path forwards until distros drop py27. If you want help testing or reviewing let me know, happy to take a look or contribute test cases, just let me know where I can help. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement >Reporter: Andrew Pennebaker >Priority: Major > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- 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-14442) Let nodetool import take a list of directories
[
https://issues.apache.org/jira/browse/CASSANDRA-14442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498265#comment-16498265
]
Jordan West commented on CASSANDRA-14442:
-
LGTM. I'm +1 as is but one minor suggestion if you feel like including it:
The live SSTable check could be replaced by the following. Its a little more
succinct and less work (since we do the "contains" check in the iteration
instead of afterwards):
{code:java}
boolean isLive = cfs.getLiveSSTables().stream().filter(r ->
r.descriptor.equals(newDescriptor) ||
r.descriptor.equals(oldDescriptor)).findAny().isPresent();
if (isLive)
{
String message = String.format("Can't move and open a file that is already
in use in the table %s -> %s", oldDescriptor, newDescriptor);
logger.error(message);
throw new RuntimeException(message);
}
{code}
> Let nodetool import take a list of directories
> --
>
> Key: CASSANDRA-14442
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14442
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 4.x
>
>
> It should be possible to load sstables from several input directories when
> running nodetool import. Directories that failed to import should be output.
--
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-14409) Transient Replication: Support ring changes when transient replication is in use (add/remove node, change RF, add/remove DC)
[ https://issues.apache.org/jira/browse/CASSANDRA-14409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-14409: --- Description: The additional state transitions that transient replication introduces require streaming and nodetool cleanup to behave differently. We already have code that does the streaming, but in some cases we shouldn't stream any data and in others when we stream to receive data we have to make sure we stream from a full replica and not a transient replica. Transitioning from not replicated to transiently replicated means that a node must stay pending until the next incremental repair completes at which point the data for that range is known to be available at full replicas. Transitioning from transiently replicated to fully replicated requires streaming from a full replica and is identical to how we stream from not replicated to replicated. The transition must be managed so the transient replica is not read from as a full replica until streaming completes. It can be used immediately for a write quorum. Transitioning from fully replicated to transiently replicated requires cleanup to remove repaired data from the transiently replicated range to reclaim space. It can be used immediately for a write quorum. Transitioning from transiently replicated to not replicated requires cleanup to be run to remove the formerly transiently replicated data. nodetool move, removenode, cleanup, decommission, and rebuild need to handle these issues as does bootstrap. Update web site, documentation, NEWS.txt with a description of the steps for doing common operations. Add/remove DC, Add/remove node(s), replace node, change RF. was: The additional state transitions that transient replication introduces require streaming and nodetool cleanup to behave differently. We already have code that does the streaming, but in some cases we shouldn't stream any data and in others when we stream to receive data we have to make sure we stream from a full replica and not a transient replica. Transitioning from not replicated to transiently replicated means that a node must stay pending until the next incremental repair completes at which point the data for that range is known to be available at full replicas. Transitioning from transiently replicated to fully replicated requires streaming from a full replica and is identical to how we stream from not replicated to replicated. The transition must be managed so the transient replica is not read from as a full replica until streaming completes. It can be used immediately for a write quorum. Transitioning from fully replicated to transiently replicated requires cleanup to remove repaired data from the transiently replicated range to reclaim space. It can be used immediately for a write quorum. Transitioning from transiently replicated to not replicated requires cleanup to be run to remove the formerly transiently replicated data. nodetool move, removenode, cleanup, decommission, and rebuild need to handle these issues as does bootstrap. Update web site, documentation, NEWS.txt with a description of the steps for doing common operations. Add/remove DC, Add/remove node(s), replace node, change RF. Some of the rules I have observed WRT to streaming and ring changes. * Who you stream data to is based on "their" transient status (for code that initiates streaming as a push) while who you initiate streaming from is based on "your" transient status * Full replicas should always fetch from transient replicas in case one of them is being given the boot * Transient replicas should never stream from full replicas because it will load them up with data they don't want * Full replicas may need to stream from both the transient replica getting the boot and another full replica. * Don't boot a transient replica without streaming it's data * When streaming to a full replica you can always omit repaired data, the corollary > Transient Replication: Support ring changes when transient replication is in > use (add/remove node, change RF, add/remove DC) > > > Key: CASSANDRA-14409 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14409 > Project: Cassandra > Issue Type: Sub-task > Components: Coordination, Core, Documentation and Website >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Major > Fix For: 4.0 > > > The additional state transitions that transient replication introduces > require streaming and nodetool cleanup to behave differently. We already have > code that does the streaming, but in some cases we shouldn't stream any data > and in others when we stream to receive
[jira] [Updated] (CASSANDRA-14436) Add sampler for query time and expose with nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-14436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-14436:
-
Reviewer: Dinesh Joshi
> Add sampler for query time and expose with nodetool
> ---
>
> Key: CASSANDRA-14436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14436
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Major
>
> Create a new {{nodetool profileload}} that functions just like toppartitions
> but with more data, returning the slowest local reads and writes on the host
> during a given duration and highest frequency touched partitions (same as
> {{nodetool toppartitions}}). Refactor included to extend use of the sampler
> for uses outside of top frequency (max instead of total sample values).
> Future work to this is to include top cpu and allocations by query and
> possibly tasks/cpu/allocations by stage during time window.
--
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
