[jira] [Updated] (CASSANDRA-18579) No link to source packages
[ https://issues.apache.org/jira/browse/CASSANDRA-18579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-18579: --- Labels: policy (was: ) > No link to source packages > -- > > Key: CASSANDRA-18579 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18579 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Sebb >Priority: Normal > Labels: policy > > I could not find a link to download source releases. > They should be provided alongside the binary releases. -- 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-18035) Add "Hello World" docker-based quick start development guide
[
https://issues.apache.org/jira/browse/CASSANDRA-18035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632422#comment-17632422
]
Michael Shuler commented on CASSANDRA-18035:
^ adding to the site docs was also why I came to comment.
+1 for current patch, it worked as expected for me, and I believe this will be
useful for my own occasional needs.
+10 for current patch + including site doc.
> Add "Hello World" docker-based quick start development guide
>
>
> Key: CASSANDRA-18035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18035
> Project: Cassandra
> Issue Type: Task
>Reporter: Paulo Motta
>Priority: Normal
>
> I propose adding a new {{QUICKSTART.md}} guide that provides instructions to
> beginner contributors on how to:
> a) Setup a development environment and IDE from scratch on WSL/Ubuntu/Debian
> environments
> b) Run a simple unit test from the IDE
> c) Create a simple patch that prints "Hello World" during Cassandra
> initialization
> d) Test the patch on a local docker instance
> A new {{docker/}} directory is added along with the guide with the following
> utilities:
> a) Dockerfile: unoptimized vanilla docker image manifest suitable only for
> local dev testing.
> b) build.sh: build a cassandra artifact and cassandra-test image.
> c) start.sh: start local cassandra-test container.
> d) stop.sh: stop local-cassandra test container.
> A couple of follow-up improvements that come to mind:
> - Add ant targets to build/start/stop cassandra-test container.
> - Add OSX instructions.
> - More IDE setup instructions (ie. Eclipse/VScode).
> - A more involved Hello World example, perhaps creating a dummy VirtualTable
> with unit/dtests.
> - Update Dockerfile to point to build/ instead of creating an artifact.
> A DEV mailing list message was sent to gather community feedback on this
> proposal: https://lists.apache.org/thread/gmb0q5yb2bzbs0cjw7mlcz1vwk2l23g2
--
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-8675) COPY TO/FROM broken for newline characters
[
https://issues.apache.org/jira/browse/CASSANDRA-8675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17628350#comment-17628350
]
Michael Shuler commented on CASSANDRA-8675:
---
Hi Vincenzo, would you be so kind as to verify the bug still affects trunk/4.x?
If the behavior does indeed still present itself, edit the bug and adjust the
fixver from 3.0.x to also include: 3.11., 4.x, 5.x. If it is important to you,
as it sounds that it is, please bring this up on the cassandra-dev mailing list
and see if you can find an active committer to review and offer feedback. (I
would suggest that a patch that also includes test(s) would be an improvement
to the current patch.)
As it sits, this bug likely won't be seen by other devs outside of the few
ticket "watchers", which is how I was notified. The squeaky wheel is going to
get noticed.
> COPY TO/FROM broken for newline characters
> --
>
> Key: CASSANDRA-8675
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8675
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Tools
> Environment: [cqlsh 5.0.1 | Cassandra 2.1.2 | CQL spec 3.2.0 | Native
> protocol v3]
> Ubuntu 14.04 64-bit
>Reporter: Lex Lythius
>Priority: Normal
> Labels: cqlsh, remove-reopen
> Fix For: 3.0.x
>
> Attachments: CASSANDRA-8675.patch, copytest.csv
>
>
> Exporting/importing does not preserve contents when texts containing newline
> (and possibly other) characters are involved:
> {code:sql}
> cqlsh:test> create table if not exists copytest (id int primary key, t text);
> cqlsh:test> insert into copytest (id, t) values (1, 'This has a newline
> ... character');
> cqlsh:test> insert into copytest (id, t) values (2, 'This has a quote "
> character');
> cqlsh:test> insert into copytest (id, t) values (3, 'This has a fake tab \t
> character (typed backslash, t)');
> cqlsh:test> select * from copytest;
> id | t
> +-
> 1 | This has a newline\ncharacter
> 2 |This has a quote " character
> 3 | This has a fake tab \t character (entered slash-t text)
> (3 rows)
> cqlsh:test> copy copytest to '/tmp/copytest.csv';
> 3 rows exported in 0.034 seconds.
> cqlsh:test> copy copytest from '/tmp/copytest.csv';
> 3 rows imported in 0.005 seconds.
> cqlsh:test> select * from copytest;
> id | t
> +---
> 1 | This has a newlinencharacter
> 2 | This has a quote " character
> 3 | This has a fake tab \t character (typed backslash, t)
> (3 rows)
> {code}
> I tried replacing \n in the CSV file with \\n, which just expands to \n in
> the table; and with an actual newline character, which fails with error since
> it prematurely terminates the record.
> It seems backslashes are only used to take the following character as a
> literal
> Until this is fixed, what would be the best way to refactor an old table with
> a new, incompatible structure maintaining its content and name, since we
> can't rename tables?
--
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-14227) Extend maximum expiration date
[
https://issues.apache.org/jira/browse/CASSANDRA-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520768#comment-17520768
]
Michael Shuler commented on CASSANDRA-14227:
Removed assignee. I only found a few random state changes by the user in Jira,
so this assignment also looked random. If this was incorrect, please reassign!
> Extend maximum expiration date
> --
>
> Key: CASSANDRA-14227
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14227
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Paulo Motta (Deprecated)
>Priority: Urgent
> Fix For: 4.x
>
>
> The maximum expiration timestamp that can be represented by the storage
> engine is
> 2038-01-19T03:14:06+00:00 due to the encoding of {{localExpirationTime}} as
> an int32.
> On CASSANDRA-14092 we added an overflow policy which rejects requests with
> expiration above the maximum date as a temporary measure, but we should
> remove this limitation by updating the storage engine to support at least the
> maximum allowed TTL of 20 years.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14227) Extend maximum expiration date
[
https://issues.apache.org/jira/browse/CASSANDRA-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler reassigned CASSANDRA-14227:
--
Assignee: (was: Mohammad Aburadeh)
> Extend maximum expiration date
> --
>
> Key: CASSANDRA-14227
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14227
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Paulo Motta (Deprecated)
>Priority: Urgent
> Fix For: 4.x
>
>
> The maximum expiration timestamp that can be represented by the storage
> engine is
> 2038-01-19T03:14:06+00:00 due to the encoding of {{localExpirationTime}} as
> an int32.
> On CASSANDRA-14092 we added an overflow policy which rejects requests with
> expiration above the maximum date as a temporary measure, but we should
> remove this limitation by updating the storage engine to support at least the
> maximum allowed TTL of 20 years.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14227) Extend maximum expiration date
[
https://issues.apache.org/jira/browse/CASSANDRA-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-14227:
---
Complexity: Challenging
Severity: Critical (was: Normal)
Set this Jira to Severity = Critical and Complexity = Challenging to reflect
the state of this problem, as time goes on, as well as the nature of the fix.
> Extend maximum expiration date
> --
>
> Key: CASSANDRA-14227
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14227
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Paulo Motta
>Priority: Urgent
>
> The maximum expiration timestamp that can be represented by the storage
> engine is
> 2038-01-19T03:14:06+00:00 due to the encoding of {{localExpirationTime}} as
> an int32.
> On CASSANDRA-14092 we added an overflow policy which rejects requests with
> expiration above the maximum date as a temporary measure, but we should
> remove this limitation by updating the storage engine to support at least the
> maximum allowed TTL of 20 years.
--
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-13701) Lower default num_tokens
[
https://issues.apache.org/jira/browse/CASSANDRA-13701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17075235#comment-17075235
]
Michael Shuler commented on CASSANDRA-13701:
Also found these in the {{cassandra}} repo - one for pytest and circleci has a
bunch:
{{(trunk)mshuler@hana:~/git/cassandra$ git grep NUM_TOKENS=}}
{{pylib/cassandra-cqlsh-tests.sh:export NUM_TOKENS="32"}}
{{(trunk)mshuler@hana:~/git/cassandra$ git grep num-tokens= .circleci/ | wc -l}}
{{24}}
> Lower default num_tokens
>
>
> Key: CASSANDRA-13701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13701
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Chris Lohfink
>Assignee: Jeremy Hanna
>Priority: Low
>
> For reasons highlighted in CASSANDRA-7032, the high number of vnodes is not
> necessary. It is very expensive for operations processes and scanning. Its
> come up a lot and its pretty standard and known now to always reduce the
> num_tokens within the community. We should just lower the defaults.
--
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-13701) Lower default num_tokens
[
https://issues.apache.org/jira/browse/CASSANDRA-13701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17075197#comment-17075197
]
Michael Shuler commented on CASSANDRA-13701:
This is set here in the {{cassandra-builds}} repo:
{{(master)mshuler@hana:~/git/cassandra-builds$ git grep NUM_TOKENS}}
{{build-scripts/cassandra-dtest-pytest.sh:export NUM_TOKENS="32"}}
{{build-scripts/cassandra-dtest.sh:export NUM_TOKENS="32"}}
> Lower default num_tokens
>
>
> Key: CASSANDRA-13701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13701
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Chris Lohfink
>Assignee: Jeremy Hanna
>Priority: Low
>
> For reasons highlighted in CASSANDRA-7032, the high number of vnodes is not
> necessary. It is very expensive for operations processes and scanning. Its
> come up a lot and its pretty standard and known now to always reduce the
> num_tokens within the community. We should just lower the defaults.
--
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-15652) add ifesdjeen's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15652: --- Status: Ready to Commit (was: Review In Progress) > add ifesdjeen's gpg key to project's KEYS file > -- > > Key: CASSANDRA-15652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15652 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Alex Petrov >Assignee: Michael Shuler >Priority: Normal > Attachments: keys.patch > > > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > References: > - https://www.apache.org/dev/release-signing#keys-policy > - http://www.apache.org/legal/release-policy.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-15652) add ifesdjeen's gpg key to project's KEYS file
[
https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-15652:
---
Reviewers: Michael Shuler, Michael Shuler (was: Michael Shuler)
Michael Shuler, Michael Shuler
Status: Review In Progress (was: Patch Available)
Alex sent his key to the SKS pool and we verified on slack.
Before:
{{$ gpg --verbose --search-keys --keyserver
hkps://hkps.pool.sks-keyservers.net 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C}}
{{ gpg: data source: [https://192.146.137.140:443|https://192.146.137.140/]}}
{{ gpg: key "9E66CEC6106D578D0B1EB9BFF1000962B7F6840C" not found on keyserver}}
{{ gpg: keyserver search failed: Not found}}
Now:
{{$ gpg --verbose --search-keys --keyserver
hkps://hkps.pool.sks-keyservers.net 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C}}
{{ gpg: data source: [https://192.146.137.140:443|https://192.146.137.140/]}}
{{ (1) Alex Petrov }}
{{ 4096 bit RSA key F1000962B7F6840C, created: 2020-03-21}}
{{ Keys 1-1 of 1 for "9E66CEC6106D578D0B1EB9BFF1000962B7F6840C". Enter
number(s), N)ext, or Q)uit > 1}}
{{ gpg: data source: [https://192.146.137.140:443|https://192.146.137.140/]}}
{{ gpg: armor header: Version: SKS 1.1.6}}
{{ gpg: armor header: Comment: Hostname: pgpkeys.uk}}
{{ gpg: pub rsa4096/F1000962B7F6840C 2020-03-21 Alex Petrov
}}
{{ gpg: key F1000962B7F6840C: "Alex Petrov " not
changed}}
{{ gpg: Total number processed: 1}}
{{ gpg: unchanged: 1}}
> add ifesdjeen's gpg key to project's KEYS file
> --
>
> Key: CASSANDRA-15652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15652
> Project: Cassandra
> Issue Type: Task
> Components: Packaging
>Reporter: Alex Petrov
>Assignee: Michael Shuler
>Priority: Normal
> Attachments: keys.patch
>
>
> The patch adds my gpg public key to the project's KEYS file found at
> https://dist.apache.org/repos/dist/release/cassandra/KEYS
> My gpg public key here has the fingerprint
> 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C
> References:
> - https://www.apache.org/dev/release-signing#keys-policy
> - http://www.apache.org/legal/release-policy.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-15652) add ifesdjeen's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15652: --- Authors: Alex Petrov (was: Michael Shuler) Test and Documentation Plan: Merge, import KEYS file, check sig. Status: Patch Available (was: Open) > add ifesdjeen's gpg key to project's KEYS file > -- > > Key: CASSANDRA-15652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15652 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Alex Petrov >Assignee: Michael Shuler >Priority: Normal > Attachments: keys.patch > > > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > References: > - https://www.apache.org/dev/release-signing#keys-policy > - http://www.apache.org/legal/release-policy.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-15652) add ifesdjeen's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15652: --- Change Category: Operability Complexity: Normal Component/s: Packaging Status: Open (was: Triage Needed) > add ifesdjeen's gpg key to project's KEYS file > -- > > Key: CASSANDRA-15652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15652 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Alex Petrov >Assignee: Michael Shuler >Priority: Normal > Attachments: keys.patch > > > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > References: > - https://www.apache.org/dev/release-signing#keys-policy > - http://www.apache.org/legal/release-policy.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-15652) add ifesdjeen's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler reassigned CASSANDRA-15652: -- Assignee: Michael Shuler > add ifesdjeen's gpg key to project's KEYS file > -- > > Key: CASSANDRA-15652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15652 > Project: Cassandra > Issue Type: Task >Reporter: Alex Petrov >Assignee: Michael Shuler >Priority: Normal > Attachments: keys.patch > > > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > References: > - https://www.apache.org/dev/release-signing#keys-policy > - http://www.apache.org/legal/release-policy.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] [Comment Edited] (CASSANDRA-15652) add ifesdjeen's gpg key to project's KEYS file
[
https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067823#comment-17067823
]
Michael Shuler edited comment on CASSANDRA-15652 at 3/26/20, 4:41 PM:
--
Yep! A couple of us cross-signed keys a few years back at a Cassandra Summit,
this is a good idea and I'd be happy to sign.
[~ifesdjeen], I've never used a web thing to upload keys. I can search your key
on the Ubuntu keyserver, but from a little reading, it appears that sync of
that keyserver to other keyservers is super latent. I still cannot search your
key on SKS, MIT, or Surfnet. If you could do the following in a shell, it
should be be searchable from the main SKS keyserver pool, which is the usual
default for any gpg install:
{{gpg --verbose --send-keys --keyserver hkps://hkps.pool.sks-keyservers.net
9E66CEC6106D578D0B1EB9BFF1000962B7F6840C}}
That should hit 98% of gpg users and all the plugins like Enigmail.
+1 to merge when the public key can be found :)
To test (example is my key fingerprint):
{{mshuler@hana:~$ gpg --verbose --search-keys --keyserver
hkps://hkps.pool.sks-keyservers.net A26E528B271F19B9E5D8E19EA278B781FE4B2BDA}}
{{gpg: data source: https://162.213.33.9:443}}
{{(1) Michael Shuler }}
{{ Michael Shuler }}
{{ 4096 bit RSA key A278B781FE4B2BDA, created: 2009-07-15}}
{{Keys 1-1 of 1 for "A26E528B271F19B9E5D8E19EA278B781FE4B2BDA". Enter
number(s), N)ext, or Q)uit > 1}}
{{gpg: data source: https://162.213.33.9:443}}
{{gpg: key A278B781FE4B2BDA: number of dropped non-self-signatures: 33}}
{{gpg: pub rsa4096/A278B781FE4B2BDA 2009-07-15 Michael Shuler
}}
{{gpg: key A278B781FE4B2BDA: "Michael Shuler " not
changed}}
{{gpg: Total number processed: 1}}
{{gpg: unchanged: 1}}
was (Author: mshuler):
Yep! A couple of us cross-signed keys a few years back at a Cassandra Summit,
this is a good idea and I'd be happy to sign.
[~ifesdjeen], I've never used a web thing to upload keys. I can search your key
on the Ubuntu keyserver, but from a little reading, it appears that sync of
that keyserver to other keyservers is super latent. I still cannot search your
key on SKS, MIT, or Surfnet. If you could do the following in a shell, it
should be be searchable from the main SKS keyserver pool, which is the usual
default for any gpg install:
{{gpg --verbose --send-keys --keyserver hkps://hkps.pool.sks-keyservers.net
9E66CEC6106D578D0B1EB9BFF1000962B7F6840C}}
That should hit 98% of gpg users and all the plugins like Enigmail.
+1 to merge when the public key can be found :)
To test (example is my key fingerprint):
{{mshuler@hana:~$ gpg --verbose --search-keys --keyserver --keyserver
hkps://hkps.pool.sks-keyservers.net A26E528B271F19B9E5D8E19EA278B781FE4B2BDA}}
{{gpg: data source: https://162.213.33.9:443}}
{{(1) Michael Shuler }}
{{ Michael Shuler }}
{{ 4096 bit RSA key A278B781FE4B2BDA, created: 2009-07-15}}
{{Keys 1-1 of 1 for "A26E528B271F19B9E5D8E19EA278B781FE4B2BDA". Enter
number(s), N)ext, or Q)uit > 1}}
{{gpg: data source: https://162.213.33.9:443}}
{{gpg: key A278B781FE4B2BDA: number of dropped non-self-signatures: 33}}
{{gpg: pub rsa4096/A278B781FE4B2BDA 2009-07-15 Michael Shuler
}}
{{gpg: key A278B781FE4B2BDA: "Michael Shuler " not
changed}}
{{gpg: Total number processed: 1}}
{{gpg: unchanged: 1}}
> add ifesdjeen's gpg key to project's KEYS file
> --
>
> Key: CASSANDRA-15652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15652
> Project: Cassandra
> Issue Type: Task
>Reporter: Alex Petrov
>Priority: Normal
> Attachments: keys.patch
>
>
> The patch adds my gpg public key to the project's KEYS file found at
> https://dist.apache.org/repos/dist/release/cassandra/KEYS
> My gpg public key here has the fingerprint
> 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C
> References:
> - https://www.apache.org/dev/release-signing#keys-policy
> - http://www.apache.org/legal/release-policy.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-15652) add ifesdjeen's gpg key to project's KEYS file
[
https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067823#comment-17067823
]
Michael Shuler commented on CASSANDRA-15652:
Yep! A couple of us cross-signed keys a few years back at a Cassandra Summit,
this is a good idea and I'd be happy to sign.
[~ifesdjeen], I've never used a web thing to upload keys. I can search your key
on the Ubuntu keyserver, but from a little reading, it appears that sync of
that keyserver to other keyservers is super latent. I still cannot search your
key on SKS, MIT, or Surfnet. If you could do the following in a shell, it
should be be searchable from the main SKS keyserver pool, which is the usual
default for any gpg install:
{{gpg --verbose --send-keys --keyserver hkps://hkps.pool.sks-keyservers.net
9E66CEC6106D578D0B1EB9BFF1000962B7F6840C}}
That should hit 98% of gpg users and all the plugins like Enigmail.
+1 to merge when the public key can be found :)
To test (example is my key fingerprint):
{{mshuler@hana:~$ gpg --verbose --search-keys --keyserver --keyserver
hkps://hkps.pool.sks-keyservers.net A26E528B271F19B9E5D8E19EA278B781FE4B2BDA}}
{{gpg: data source: https://162.213.33.9:443}}
{{(1) Michael Shuler }}
{{ Michael Shuler }}
{{ 4096 bit RSA key A278B781FE4B2BDA, created: 2009-07-15}}
{{Keys 1-1 of 1 for "A26E528B271F19B9E5D8E19EA278B781FE4B2BDA". Enter
number(s), N)ext, or Q)uit > 1}}
{{gpg: data source: https://162.213.33.9:443}}
{{gpg: key A278B781FE4B2BDA: number of dropped non-self-signatures: 33}}
{{gpg: pub rsa4096/A278B781FE4B2BDA 2009-07-15 Michael Shuler
}}
{{gpg: key A278B781FE4B2BDA: "Michael Shuler " not
changed}}
{{gpg: Total number processed: 1}}
{{gpg: unchanged: 1}}
> add ifesdjeen's gpg key to project's KEYS file
> --
>
> Key: CASSANDRA-15652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15652
> Project: Cassandra
> Issue Type: Task
>Reporter: Alex Petrov
>Priority: Normal
> Attachments: keys.patch
>
>
> The patch adds my gpg public key to the project's KEYS file found at
> https://dist.apache.org/repos/dist/release/cassandra/KEYS
> My gpg public key here has the fingerprint
> 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C
> References:
> - https://www.apache.org/dev/release-signing#keys-policy
> - http://www.apache.org/legal/release-policy.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-15652) add ifesdjeen's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17065059#comment-17065059 ] Michael Shuler commented on CASSANDRA-15652: While reading through a keybase issue requesting functionality as a real keyserver, I noticed a referenced (then many more references) issue on the security problems with keybase suggesting upload of user's secret key to them. Please, tell me you did not upload your secret key, as I understand is the default.. > add ifesdjeen's gpg key to project's KEYS file > -- > > Key: CASSANDRA-15652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15652 > Project: Cassandra > Issue Type: Task >Reporter: Alex Petrov >Priority: Normal > Attachments: keys.patch > > > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > References: > - https://www.apache.org/dev/release-signing#keys-policy > - http://www.apache.org/legal/release-policy.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-15652) add ifesdjeen's gpg key to project's KEYS file
[
https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17065049#comment-17065049
]
Michael Shuler commented on CASSANDRA-15652:
keybase.io is not a pgp keyserver - it's a social_media_id <-> gpg_key_id
voluntary registry (plus $otherthings).
{{$ gpg --verbose --recv-keys --keyserver hkps://hkps.pool.sks-keyservers.net
9E66CEC6106D578D0B1EB9BFF1000962B7F6840C}}
{{gpg: data source: https://192.146.137.140:443}}
{{gpg: keyserver receive failed: No data}}
The ASF docs on this:
[https://www.apache.org/dev/release-signing#keyserver]
Once published to a public keyserver, you should be able to search your keyid
at [https://pgp.surfnet.nl/] (or any public keyserver, since they are a shared
distributed database).
> add ifesdjeen's gpg key to project's KEYS file
> --
>
> Key: CASSANDRA-15652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15652
> Project: Cassandra
> Issue Type: Task
>Reporter: Alex Petrov
>Priority: Normal
> Attachments: keys.patch
>
>
> The patch adds my gpg public key to the project's KEYS file found at
> https://dist.apache.org/repos/dist/release/cassandra/KEYS
> My gpg public key here has the fingerprint
> 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C
> References:
> - https://www.apache.org/dev/release-signing#keys-policy
> - http://www.apache.org/legal/release-policy.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-15652) add ifesdjeen's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17064001#comment-17064001 ] Michael Shuler commented on CASSANDRA-15652: Also, this is a brand new unsigned (by others) key. Is this your very first use of GPG? Generally, it's recommended to have a key in the "strong set", but just wondering, there are others that aren't. > add ifesdjeen's gpg key to project's KEYS file > -- > > Key: CASSANDRA-15652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15652 > Project: Cassandra > Issue Type: Task >Reporter: Alex Petrov >Priority: Normal > Attachments: key.patch > > > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > References: > - https://www.apache.org/dev/release-signing#keys-policy > - http://www.apache.org/legal/release-policy.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-15652) add ifesdjeen's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17064000#comment-17064000 ] Michael Shuler commented on CASSANDRA-15652: Your patch has some funky lack of line breaks, first line is append to the last key block and lack of a trailing newline. > add ifesdjeen's gpg key to project's KEYS file > -- > > Key: CASSANDRA-15652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15652 > Project: Cassandra > Issue Type: Task >Reporter: Alex Petrov >Priority: Normal > Attachments: key.patch > > > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C > References: > - https://www.apache.org/dev/release-signing#keys-policy > - http://www.apache.org/legal/release-policy.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=17063561#comment-17063561 ] Michael Shuler commented on CASSANDRA-15586: As I mentioned on Slack, I used to have access to a large CI infrastructure with some release test automation, but do not have access any longer. The last releases I built, I manually tested the basic install/start/query/stop worked as expected on a couple virtualbox instances, Ubuntu 18.04 and CentOS 7.6. I did not do any manual verification of package upgrades from previous versions, which would be a good thing to test. CI systems at ASF: old, shared (moving to new): https://builds.apache.org/view/A-D/view/Cassandra/ new, dedicated: https://ci-cassandra.apache.org/ > 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 >Reporter: Josh McKenzie >Assignee: Ekaterina Dimitrova >Priority: Normal > Labels: 4.0-QA > Fix For: 4.0-rc > > > 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] [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=17062113#comment-17062113 ] Michael Shuler commented on CASSANDRA-15586: There are zero automated release artifact functionality tests. After build, do the packages work as expected, along the lines of: - fetch tar/deb/rpm - extract / install (checking that with a default OS install, the deps are pulled in correctly for deb/rpm) - start / status / stop / restart - basic cql query or two returns expected data As release manager, these are the basic steps I am doing manually after release builds, prior to voting. > 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 >Reporter: Josh McKenzie >Assignee: Ekaterina Dimitrova >Priority: Normal > Labels: 4.0-QA > Fix For: 4.0-rc > > > 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-15426) Cassandra 3.11.5 fails to start on Windows
[ https://issues.apache.org/jira/browse/CASSANDRA-15426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15426: --- Fix Version/s: (was: 3.11.x) (was: 3.0.x) 3.0.20 3.11.6 > Cassandra 3.11.5 fails to start on Windows > --- > > Key: CASSANDRA-15426 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15426 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Hints >Reporter: Ashish Singh >Assignee: Jeff Jirsa >Priority: Normal > Fix For: 3.0.20, 3.11.6, 4.0 > > > Cassandra 3.11.5 fails to start on Windows server 2012 R2. with following > error trace. > Cassandra 3.11.4 doesn't fail on Windows 2012 R2. > > org.apache.cassandra.io.FSReadError: java.io.IOException: Invalid folder > descriptor trying to create log replica > C:\Users\Administrator\Downloads\apache-cassandra-3.11.5-bin.tar\apache-cassandra-3.11.5-bin\apache-cassandra-3.11.5\data\data\system\local-7ad54392bcdd35a684174e047860b377 > at org.apache.cassandra.db.lifecycle.LogReplica.create(LogReplica.java:58) > ~[apache-cassandra-3.11.5.jar:3.11.5] > at > org.apache.cassandra.db.lifecycle.LogReplicaSet.maybeCreateReplica(LogReplicaSet.java:86) > ~[apache-cassandra-3.11.5.jar:3.11.5] > at org.apache.cassandra.db.lifecycle.LogFile.makeRecord(LogFile.java:311) > [apache-cassandra-3.11.5.jar:3.11.5] > at org.apache.cassandra.db.lifecycle.LogFile.add(LogFile.java:283) > [apache-cassandra-3.11.5.jar:3.11.5] > at > org.apache.cassandra.db.lifecycle.LogTransaction.trackNew(LogTransaction.java:139) > [apache-cassandra-3.11.5.jar:3.11.5] > at > org.apache.cassandra.db.lifecycle.LifecycleTransaction.trackNew(LifecycleTransaction.java:528) > [apache-cassandra-3.11.5.jar:3.11.5] > at > org.apache.cassandra.io.sstable.format.big.BigTableWriter.(BigTableWriter.java:81) > [apache-cassandra-3.11.5.jar:3.11.5] > at > org.apache.cassandra.io.sstable.format.big.BigFormat$WriterFactory.open(BigFormat.java:92) > [apache-cassandra-3.11.5.jar:3.11.5] > at > org.apache.cassandra.io.sstable.format.SSTableWriter.create(SSTableWriter.java:102) > [apache-cassandra-3.11.5.jar:3.11.5] > at > org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.create(SimpleSSTableMultiWriter.java:119) > [apache-cassandra-3.11.5.jar:3.11.5] > at > org.apache.cassandra.db.compaction.AbstractCompactionStrategy.createSSTableMultiWriter(AbstractCompactionStrategy.java:588) > [apache-cassandra-3.11.5.jar:3.11.5] > at > org.apache.cassandra.db.compaction.CompactionStrategyManager.createSSTableMultiWriter(CompactionStrategyManager.java:1027) > [apache-cassandra-3.11.5.jar:3.11.5] > at > org.apache.cassandra.db.ColumnFamilyStore.createSSTableMultiWriter(ColumnFamilyStore.java:532) > [apache-cassandra-3.11.5.jar:3.11.5] > at > org.apache.cassandra.db.Memtable$FlushRunnable.createFlushWriter(Memtable.java:504) > [apache-cassandra-3.11.5.jar:3.11.5] > at org.apache.cassandra.db.Memtable$FlushRunnable.(Memtable.java:443) > [apache-cassandra-3.11.5.jar:3.11.5] > at org.apache.cassandra.db.Memtable$FlushRunnable.(Memtable.java:420) > [apache-cassandra-3.11.5.jar:3.11.5] > at org.apache.cassandra.db.Memtable.createFlushRunnables(Memtable.java:307) > [apache-cassandra-3.11.5.jar:3.11.5] > at org.apache.cassandra.db.Memtable.flushRunnables(Memtable.java:298) > [apache-cassandra-3.11.5.jar:3.11.5] > at > org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1153) > [apache-cassandra-3.11.5.jar:3.11.5] > at > org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1118) > [apache-cassandra-3.11.5.jar:3.11.5] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > [na:1.8.0_161] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > [na:1.8.0_161] > at > org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84) > [apache-cassandra-3.11.5.jar:3.11.5] > at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_161] > Caused by: java.io.IOException: Invalid folder descriptor trying to -- 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-13649) Uncaught exceptions in Netty pipeline
[
https://issues.apache.org/jira/browse/CASSANDRA-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-13649:
---
Fix Version/s: (was: 3.11.1)
(was: 3.0.15)
(was: 2.2.11)
3.11.x
3.0.x
2.2.x
> Uncaught exceptions in Netty pipeline
> -
>
> Key: CASSANDRA-13649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13649
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging, Legacy/Testing
>Reporter: Stefan Podkowinski
>Assignee: Norman Maurer
>Priority: Normal
> Labels: patch
> Fix For: 4.0, 2.2.x, 3.0.x, 3.11.x
>
> Attachments:
> 0001-CASSANDRA-13649-Ensure-all-exceptions-are-correctly-.patch,
> test_stdout.txt
>
>
> I've noticed some netty related errors in trunk in [some of the dtest
> results|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/106/#showFailuresLink].
> Just want to make sure that we don't have to change anything related to the
> exception handling in our pipeline and that this isn't a netty issue.
> Actually if this causes flakiness but is otherwise harmless, we should do
> something about it, even if it's just on the dtest side.
> {noformat}
> WARN [epollEventLoopGroup-2-9] 2017-06-28 17:23:49,699 Slf4JLogger.java:151
> - An exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not handle
> the exception.
> io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed:
> Connection reset by peer
> at io.netty.channel.unix.FileDescriptor.readAddress(...)(Unknown
> Source) ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> {noformat}
> And again in another test:
> {noformat}
> WARN [epollEventLoopGroup-2-8] 2017-06-29 02:27:31,300 Slf4JLogger.java:151
> - An exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not handle
> the exception.
> io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed:
> Connection reset by peer
> at io.netty.channel.unix.FileDescriptor.readAddress(...)(Unknown
> Source) ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> {noformat}
> Edit:
> The {{io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)()
> failed}} error also causes tests to fail for 3.0 and 3.11.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14970: --- Fix Version/s: (was: 3.11.6) (was: 3.0.20) (was: 2.2.16) > New releases must supply SHA-256 and/or SHA-512 checksums > - > > Key: CASSANDRA-14970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14970 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Shuler >Assignee: Michael Semb Wever >Priority: Urgent > Fix For: 4.0-alpha > > Attachments: > 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, > 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, > ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png, > cassandra-2.1_14970_updated.patch > > > Release policy was updated around 9/2018 to state: > "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT > supply MD5 or SHA-1. Existing releases do not need to be changed." > build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. > cassandra-builds/cassandra-release scripts need to be updated to work with > the new checksum files. > http://www.apache.org/dev/release-distribution#sigs-and-sums -- 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-15549) Remove all recommendations to run Cassandra as root
[ https://issues.apache.org/jira/browse/CASSANDRA-15549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17034574#comment-17034574 ] Michael Shuler commented on CASSANDRA-15549: I don't know. Some specifics on the "several exceptions/logs in the code which recommend users to run Cassandra as root", which versions/branches, etc. from OP would help. I only did a quick grep in trunk to see what I could see. > Remove all recommendations to run Cassandra as root > --- > > Key: CASSANDRA-15549 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15549 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > > There are several exceptions/logs in the code which recommend users to run > Cassandra as root, should remove these since users really shouldn’t be > running Cassandra as root. -- 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-15563) Backport removal of OpenJDK warning log
[ https://issues.apache.org/jira/browse/CASSANDRA-15563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15563: --- Fix Version/s: 3.0.x 2.2.x > Backport removal of OpenJDK warning log > --- > > Key: CASSANDRA-15563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15563 > Project: Cassandra > Issue Type: Task >Reporter: Thomas Steinmaurer >Priority: Normal > Fix For: 2.2.x, 3.0.x > > > As requested on Slack, creating this ticket for a backport of > CASSANDRA-13916, potentially to 2.2 and 3.0. -- 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-15549) Remove all recommendations to run Cassandra as root
[ https://issues.apache.org/jira/browse/CASSANDRA-15549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17033635#comment-17033635 ] Michael Shuler commented on CASSANDRA-15549: `git grep root` returns a lot of hits, but I did see the linked CASSANDRA-8142 in NEWS/CHANGES. This shows fixed for 3.2, so should be in the 3.11 and trunk branches already, in order to prevent starting up as UID=0. > Remove all recommendations to run Cassandra as root > --- > > Key: CASSANDRA-15549 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15549 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > > There are several exceptions/logs in the code which recommend users to run > Cassandra as root, should remove these since users really shouldn’t be > running Cassandra as root. -- 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-13810) Overload because of hint pressure + MVs
[
https://issues.apache.org/jira/browse/CASSANDRA-13810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-13810:
---
Bug Category: Parent values: Availability(12983)Level 1 values:
Unavailable(12994)
Fix Version/s: 4.x
3.11.x
3.0.x
Severity: Critical (was: Normal)
> Overload because of hint pressure + MVs
> ---
>
> Key: CASSANDRA-13810
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13810
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Tom van der Woerdt
>Priority: Urgent
> Labels: materializedviews
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Cluster setup: 3 DCs, 20 Cassandra nodes each, all 3.0.14, with approx. 200GB
> data per machine. Many tables have MVs associated.
> During some maintenance we did a rolling restart of all nodes in the cluster.
> This caused a buildup of hints/batches, as expected. Most nodes came back
> just fine, except for two nodes.
> These two nodes came back with a loadavg of >100, and 'nodetool tpstats'
> showed a million (not exaggerating) MutationStage tasks per second(!). It was
> clear that these were mostly (all?) mutations coming from hints, as indicated
> by thousands of log entries per second in debug.log :
> {noformat}
> DEBUG [SharedPool-Worker-107] 2017-08-27 13:16:51,098 HintVerbHandler.java:95
> - Failed to apply hint
> java.util.concurrent.CompletionException:
> org.apache.cassandra.exceptions.WriteTimeoutException: Operation timed out -
> received only 0 responses.
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:292)
> ~[na:1.8.0_144]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:308)
> ~[na:1.8.0_144]
> at
> java.util.concurrent.CompletableFuture.uniAccept(CompletableFuture.java:647)
> ~[na:1.8.0_144]
> at
> java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:632)
> ~[na:1.8.0_144]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> ~[na:1.8.0_144]
> at
> java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:1977)
> ~[na:1.8.0_144]
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:481)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.db.Keyspace.lambda$applyInternal$0(Keyspace.java:495)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_144]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_144]
> Caused by: org.apache.cassandra.exceptions.WriteTimeoutException: Operation
> timed out - received only 0 responses.
> ... 6 common frames omitted
> {noformat}
> After reading the relevant code, it seems that a hint is considered
> droppable, and in the mutation path when the table contains a MV and the lock
> fails to acquire and the mutation is droppable, it throws a WTE without
> waiting until the timeout expires. This explains why Cassandra is able to
> process a million mutations per second without actually considering them
> 'dropped' in the 'nodetool tpstats' output.
> I managed to recover the two nodes by stopping handoffs on all nodes in the
> cluster and reenabling them one at a time. It's likely that the hint/batchlog
> settings were sub-optimal on this cluster, but I think that the retry
> behavior(?) of hints should be improved as it's hard to express hint
> throughput in kb/s when the mutations can involve MVs.
> More data available upon request -- I'm not sure which bits are relevant and
> which aren't.
--
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-15446) Per-thread stack size is too small on aarch64 CentOS
[ https://issues.apache.org/jira/browse/CASSANDRA-15446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15446: --- Fix Version/s: (was: 3.11.5) 3.11.x > Per-thread stack size is too small on aarch64 CentOS > > > Key: CASSANDRA-15446 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15446 > Project: Cassandra > Issue Type: Bug > Components: Local/Config, Local/Startup and Shutdown >Reporter: Heming Fu >Assignee: Heming Fu >Priority: Normal > Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x > > > Hi all, > I found an issue when I tried to start cassandra on my aarch64 CentOS7.6, > however no errors on Ubuntu. Of course I could increase -Xss in jvm.options > to fix it, but this issue also caused Cassandra's docker images from docker > hub could not run containers on this OS. > The information of my current environment and root cause of this issue were > shown below. > *Error* > The stack size specified is too small, Specify at least 328k > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > *Version* > Cassandra 2.1.21 2.2.15 3.0.19 3.11.5 > *Environment* > $ lscpu > Architecture: aarch64 > Byte Order: Little Endian > $ uname -m > aarch64 > $ java -version > openjdk version "1.8.0_181" > OpenJDK Runtime Environment (build 1.8.0_181-b13) > OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode) > [root@localhost apache-cassandra-3.11.5]# cat /etc/os-release > $ cat /etc/os-release > NAME="CentOS Linux" > VERSION="7 (AltArch)" > ID="centos" > ID_LIKE="rhel fedora" > VERSION_ID="7" > PRETTY_NAME="CentOS Linux 7 (AltArch)" > ANSI_COLOR="0;31" > CPE_NAME="cpe:/o:centos:centos:7" > HOME_URL="https://www.centos.org/; > BUG_REPORT_URL="https://bugs.centos.org/; > *Root Cause* > Checked openjdk-1.8.0 source code, the min stack size is calculated by > StackYellowPage, StackRedPage, StackShadowPage, OS page size. Among those > parameters, *default OS page size of aarch64 CentOS 7.6 is 64K, however > aarch64 Ubuntu 18.04 and X86 CentOS are both 4K.* > This difference causes JVM on aarch64 Ubuntu 18.04 needs 164K per-thread > stack size, but 328K required on aarch64 CentOS 7.6. > The formula is > os::Linux::min_stack_allowed = MAX2(os::Linux::min_stack_allowed, > (size_t)(StackYellowPages+StackRedPages+StackShadowPages) * > Linux::page_size() + > (2*BytesPerWord COMPILER2_PRESENT(+1)) * Linux::vm_default_page_size()); > *Parameters on aarch64 CentOS7.6* > intx StackRedPages = 1 > intx StackShadowPages = 1 > intx StackYellowPages = 1 > pageSize 64K > BytesPerWord 8 > vm_default_page_size 8K > As a result, we have min_stack_allowed = (1 + 1 + 1) * 64K + (2 * 8 + 1) * 8K > = 328K > > I could see some similar issues asked for specified achitecture, but no root > cause analyzed. I hope this could help you decide proper stack size for all > common OS. > If you have any suggestion, pls let me know. > -- 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-15137) Switch http to https URLs in build.xml
[ https://issues.apache.org/jira/browse/CASSANDRA-15137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029172#comment-17029172 ] Michael Shuler commented on CASSANDRA-15137: Committed to 2.1 and merged up. https://github.com/apache/cassandra/commit/b26927d863d5fc5d3251c4ce2aa0cdef9046dd3e > Switch http to https URLs in build.xml > -- > > Key: CASSANDRA-15137 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15137 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies >Reporter: Michael Shuler >Assignee: Michael Shuler >Priority: Normal > Fix For: 2.2.15, 3.0.19, 3.11.5, 4.0 > > Attachments: 0001-Switch-http-to-https-URLs-in-build.xml.patch, > 2.1_backport_Switch-http-to-https-URLs-in-build.xml.patch > > > Switch to using https URLs wherever possible in build.xml. -- 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-15534) add mick's second (RSA) gpg key to the project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15534: --- Fix Version/s: 4.0 Source Control Link: https://dist.apache.org/repos/dist/release/cassandra/ Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed revision 37800. Thanks, Mick. > add mick's second (RSA) gpg key to the project's KEYS file > -- > > Key: CASSANDRA-15534 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15534 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Michael Semb Wever >Assignee: Michael Shuler >Priority: Normal > Fix For: 4.0 > > Attachments: 15534.patch > > > Following on from CASSANDRA-15360... > The signing RPMs with `rpmsign` during the release process requires a RSA > key. So my existing DSA key from 15360 does not work with `rpmsign` > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > A4C4 65FE A0C5 5256 1A39 2A61 E913 35D7 7E3E 87CB -- 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-15534) add mick's second (RSA) gpg key to the project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15534: --- Status: Ready to Commit (was: Review In Progress) > add mick's second (RSA) gpg key to the project's KEYS file > -- > > Key: CASSANDRA-15534 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15534 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Michael Semb Wever >Assignee: Michael Shuler >Priority: Normal > Attachments: 15534.patch > > > Following on from CASSANDRA-15360... > The signing RPMs with `rpmsign` during the release process requires a RSA > key. So my existing DSA key from 15360 does not work with `rpmsign` > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > A4C4 65FE A0C5 5256 1A39 2A61 E913 35D7 7E3E 87CB -- 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-15534) add mick's second (RSA) gpg key to the project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler reassigned CASSANDRA-15534: -- Assignee: Michael Shuler > add mick's second (RSA) gpg key to the project's KEYS file > -- > > Key: CASSANDRA-15534 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15534 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Michael Semb Wever >Assignee: Michael Shuler >Priority: Normal > Attachments: 15534.patch > > > Following on from CASSANDRA-15360... > The signing RPMs with `rpmsign` during the release process requires a RSA > key. So my existing DSA key from 15360 does not work with `rpmsign` > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > A4C4 65FE A0C5 5256 1A39 2A61 E913 35D7 7E3E 87CB -- 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-15534) add mick's second (RSA) gpg key to the project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15534: --- Reviewers: Michael Shuler, Michael Shuler (was: Michael Shuler) Michael Shuler, Michael Shuler Status: Review In Progress (was: Patch Available) > add mick's second (RSA) gpg key to the project's KEYS file > -- > > Key: CASSANDRA-15534 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15534 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Michael Semb Wever >Assignee: Michael Shuler >Priority: Normal > Attachments: 15534.patch > > > Following on from CASSANDRA-15360... > The signing RPMs with `rpmsign` during the release process requires a RSA > key. So my existing DSA key from 15360 does not work with `rpmsign` > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > A4C4 65FE A0C5 5256 1A39 2A61 E913 35D7 7E3E 87CB -- 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-15534) add mick's second (RSA) gpg key to the project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-15534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17026738#comment-17026738 ] Michael Shuler commented on CASSANDRA-15534: Shouldn't the DSA key that was added to KEYS be removed? My understanding of the [Signing Releases|https://www.apache.org/dev/release-signing.html] doc suggests the DSA key should not have been added to the project KEYS file. > add mick's second (RSA) gpg key to the project's KEYS file > -- > > Key: CASSANDRA-15534 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15534 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Michael Semb Wever >Priority: Normal > Attachments: 15534.patch > > > Following on from CASSANDRA-15360... > The signing RPMs with `rpmsign` during the release process requires a RSA > key. So my existing DSA key from 15360 does not work with `rpmsign` > The patch adds my gpg public key to the project's KEYS file found at > https://dist.apache.org/repos/dist/release/cassandra/KEYS > My gpg public key here has the fingerprint > A4C4 65FE A0C5 5256 1A39 2A61 E913 35D7 7E3E 87CB -- 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-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[
https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024728#comment-17024728
]
Michael Shuler commented on CASSANDRA-14970:
Patches above for 2.2, 3.0, 3.11, and trunk look good to me on {{ant
artifacts}} tests for each branch.
I did also try to build 2.1 and the build currently fails, due to the old http
URLs in build.xml and build.properties.default now being disabled. There was
someone on slack with the same problem, so I added a 2.1 backport patch to
CASSANDRA-15137. With that patch applied to the {{cassandra-2.1}} branch and
the 2.1 patch above on top, I did not get the desired .sha256 & .sha512 files
created when building the artifacts for some reason. That can probably be
worked on later, if needed.
> New releases must supply SHA-256 and/or SHA-512 checksums
> -
>
> Key: CASSANDRA-14970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14970
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Michael Shuler
>Assignee: Michael Semb Wever
>Priority: Urgent
> Fix For: 2.2.16, 3.0.20, 3.11.6, 4.0
>
> Attachments:
> 0001-Update-downloads-for-sha256-sha512-checksum-files.patch,
> 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch,
> ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png,
> cassandra-2.1_14970_updated.patch
>
>
> Release policy was updated around 9/2018 to state:
> "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT
> supply MD5 or SHA-1. Existing releases do not need to be changed."
> build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both.
> cassandra-builds/cassandra-release scripts need to be updated to work with
> the new checksum files.
> http://www.apache.org/dev/release-distribution#sigs-and-sums
--
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-15137) Switch http to https URLs in build.xml
[ https://issues.apache.org/jira/browse/CASSANDRA-15137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024723#comment-17024723 ] Michael Shuler commented on CASSANDRA-15137: Adding 2.1 backport patch to ticket, since the build is broken after http URLs have been disabled. [^2.1_backport_Switch-http-to-https-URLs-in-build.xml.patch] > Switch http to https URLs in build.xml > -- > > Key: CASSANDRA-15137 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15137 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies >Reporter: Michael Shuler >Assignee: Michael Shuler >Priority: Normal > Fix For: 2.2.15, 3.0.19, 3.11.5, 4.0 > > Attachments: 0001-Switch-http-to-https-URLs-in-build.xml.patch, > 2.1_backport_Switch-http-to-https-URLs-in-build.xml.patch > > > Switch to using https URLs wherever possible in build.xml. -- 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-15137) Switch http to https URLs in build.xml
[ https://issues.apache.org/jira/browse/CASSANDRA-15137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15137: --- Attachment: 2.1_backport_Switch-http-to-https-URLs-in-build.xml.patch > Switch http to https URLs in build.xml > -- > > Key: CASSANDRA-15137 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15137 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies >Reporter: Michael Shuler >Assignee: Michael Shuler >Priority: Normal > Fix For: 2.2.15, 3.0.19, 3.11.5, 4.0 > > Attachments: 0001-Switch-http-to-https-URLs-in-build.xml.patch, > 2.1_backport_Switch-http-to-https-URLs-in-build.xml.patch > > > Switch to using https URLs wherever possible in build.xml. -- 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-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14970: --- Attachment: cassandra-2.1_14970_updated.patch > New releases must supply SHA-256 and/or SHA-512 checksums > - > > Key: CASSANDRA-14970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14970 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Shuler >Assignee: Michael Semb Wever >Priority: Urgent > Fix For: 2.2.16, 3.0.20, 3.11.6, 4.0 > > Attachments: > 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, > 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, > ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png, > cassandra-2.1_14970_updated.patch > > > Release policy was updated around 9/2018 to state: > "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT > supply MD5 or SHA-1. Existing releases do not need to be changed." > build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. > cassandra-builds/cassandra-release scripts need to be updated to work with > the new checksum files. > http://www.apache.org/dev/release-distribution#sigs-and-sums -- 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-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024669#comment-17024669 ] Michael Shuler commented on CASSANDRA-14970: Set myself as reviewer. First comment: there have been no commits since the cassandra-2.1.21 release (Feb 2019) and this is not a security/critical patch? I suppose if we have a release planned to fix something for 2.1, implement this patch at that time? > New releases must supply SHA-256 and/or SHA-512 checksums > - > > Key: CASSANDRA-14970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14970 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Shuler >Assignee: Michael Semb Wever >Priority: Urgent > Fix For: 2.2.16, 3.0.20, 3.11.6, 4.0 > > Attachments: > 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, > 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, > ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png > > > Release policy was updated around 9/2018 to state: > "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT > supply MD5 or SHA-1. Existing releases do not need to be changed." > build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. > cassandra-builds/cassandra-release scripts need to be updated to work with > the new checksum files. > http://www.apache.org/dev/release-distribution#sigs-and-sums -- 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-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14970: --- Reviewers: Michael Shuler > New releases must supply SHA-256 and/or SHA-512 checksums > - > > Key: CASSANDRA-14970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14970 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Shuler >Assignee: Michael Semb Wever >Priority: Urgent > Fix For: 2.2.16, 3.0.20, 3.11.6, 4.0 > > Attachments: > 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, > 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, > ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png > > > Release policy was updated around 9/2018 to state: > "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT > supply MD5 or SHA-1. Existing releases do not need to be changed." > build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. > cassandra-builds/cassandra-release scripts need to be updated to work with > the new checksum files. > http://www.apache.org/dev/release-distribution#sigs-and-sums -- 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-15218) NativeTransport allocates heap buffers for compression
[ https://issues.apache.org/jira/browse/CASSANDRA-15218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15218: --- Fix Version/s: (was: 4.0.x) 4.x > NativeTransport allocates heap buffers for compression > -- > > Key: CASSANDRA-15218 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15218 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Benedict Elliott Smith >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.x > > > This may once have been necessary, but it is now wasteful in that we maintain > extra headroom in our heap allocators to support this, since we have a fully > functioning DirectByteBuffer compliant variant -- 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-15217) IntervalLock uses currentTimeMillis; should use monotonic time source
[ https://issues.apache.org/jira/browse/CASSANDRA-15217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15217: --- Fix Version/s: (was: 4.0.x) 4.x > IntervalLock uses currentTimeMillis; should use monotonic time source > - > > Key: CASSANDRA-15217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15217 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Benedict Elliott Smith >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.x > > -- 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-15224) DynamicSnitch.applyConfigChanges can corrupt snitch state
[ https://issues.apache.org/jira/browse/CASSANDRA-15224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15224: --- Fix Version/s: (was: 4.0.x) 4.x > DynamicSnitch.applyConfigChanges can corrupt snitch state > - > > Key: CASSANDRA-15224 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15224 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Benedict Elliott Smith >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.x > > > This method is not synchronised, and doesn’t wait for the cancelled task to > complete (which could already be running), so we could have two updates in > flight simultaneously and corrupt the internal state of the collection -- 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-14883) Let Cassandra support the new JVM, Eclipse Openj9.
[ https://issues.apache.org/jira/browse/CASSANDRA-14883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14883: --- Fix Version/s: (was: 4.0.x) 4.x > Let Cassandra support the new JVM, Eclipse Openj9. > -- > > Key: CASSANDRA-14883 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14883 > Project: Cassandra > Issue Type: Improvement > Components: Packaging > Environment: jdk8u192-b12_openj9-0.11.0 > cassandra 4.0.0_beta_20181109_build >Reporter: Lee Sangboo >Priority: Normal > Fix For: 4.x > > Attachments: jamm-0.3.2.jar, jamm.zip > > > Cassandra does not currently support the new JVM, Eclipse Openj9. In internal > testing, Openj9 outperforms Hotspot. I have deployed a modified jamm library > that has a problem with the current startup, but when I started Cassandra, I > got a log message saying "Non-Oracle JVM detected." Some features, such as > unimported compact SSTables, may not work as intended "If there is no > problem, I would also like to delete the above message. -- 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-14769) Batchlog consistency proportional to live nodes, not DC size
[ https://issues.apache.org/jira/browse/CASSANDRA-14769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14769: --- Fix Version/s: (was: 4.0.x) 4.x > Batchlog consistency proportional to live nodes, not DC size > > > Key: CASSANDRA-14769 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14769 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Batch Log >Reporter: Benedict Elliott Smith >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.x > > > Batchlog tries to write to at least two nodes in the DC, if there are two or > more nodes in the DC. But if all other nodes are down, it will accept > writing with just CL.ONE. This doesn’t *seem* to be intentional, and I think > we should probably fail the batch log write in this scenario. > The prior discussion I could find on this topic was in CASSANDRA-9895, > wherein the following was stated: > bq. The idea was that the batchlog should give you the guarantee that you > won't lose atomicity unless you lose 3 machines during the request > (coordinator plus two others) > If this is the intended guarantee, depending on liveness to decide your > consistency seems busted. -- 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-15215) VIntCoding should read and write more efficiently
[ https://issues.apache.org/jira/browse/CASSANDRA-15215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15215: --- Fix Version/s: (was: 4.0.x) 4.x > VIntCoding should read and write more efficiently > - > > Key: CASSANDRA-15215 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15215 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction, Local/SSTable >Reporter: Benedict Elliott Smith >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.x > > > Most vints occupy significantly fewer than 8 bytes, and most buffers have >= > 8 bytes spare, in which case we can construct the relevant bytes in a > register and memcpy them to the correct position. Since we read and write a > lot of vints, this waste is probably measurable, particularly during > compaction and flush, and can probably be considered a performance bug. -- 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-14979) cqlsh_tests/cqlsh_copy_tests.py::TestCqlshCopy::test_unusual_dates is failing
[ https://issues.apache.org/jira/browse/CASSANDRA-14979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14979: --- Fix Version/s: (was: 4.0.x) 4.x > cqlsh_tests/cqlsh_copy_tests.py::TestCqlshCopy::test_unusual_dates is failing > - > > Key: CASSANDRA-14979 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14979 > Project: Cassandra > Issue Type: Bug > Components: Tool/cqlsh >Reporter: Ariel Weisberg >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.x > > > I think this may be due to a real bug. Looking at what happens I don't see > how the code can handle the out of range dates. -- 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-14669) Transient Replication: Confirm vnode support w/Transient Replication
[ https://issues.apache.org/jira/browse/CASSANDRA-14669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14669: --- Fix Version/s: (was: 4.0.x) 4.x > Transient Replication: Confirm vnode support w/Transient Replication > > > Key: CASSANDRA-14669 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14669 > Project: Cassandra > Issue Type: Sub-task > Components: Feature/Transient Replication >Reporter: Ariel Weisberg >Priority: Normal > Fix For: 4.x > > > Transient replication's implementation supports vnodes, but the test coverage > is insufficient to be confident there are no hidden issues. Once test > coverage is sufficient we should allow the creation of TR keyspaces with > vnodes. -- 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-14680) Built-in 2i implementation applies updates non-deterministically
[
https://issues.apache.org/jira/browse/CASSANDRA-14680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-14680:
---
Fix Version/s: (was: 4.0.x)
4.x
> Built-in 2i implementation applies updates non-deterministically
>
>
> Key: CASSANDRA-14680
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14680
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Chris Lohfink
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Spotted by [~cnlwsu] during CASSANDRA-14664 review, and confirmed by me and
> [~beobal] separately.
> {{Keyspace.applyInternal()}} generates {{nowInSeconds}} from local time at
> the time of mutation application - which can happen at quite a delay from
> that mutation creation (think streaming path, hints, batchlog replay). That
> {{nowInSeconds}} value is later used by {{CassandraIndex}} {{Indexer}} to
> determine liveness of cells and also used for some of generated tombstones.
> Depending on when {{Keyspace.applyInternal()}} call happens, you'll see
> varying results in the internal 2i table, which sounds problematic. The
> values should be derived from the cells and liveness info in the partition
> updates exclusively.
--
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-14709) Global configuration parameter to reject increment repair and allow full repair only
[ https://issues.apache.org/jira/browse/CASSANDRA-14709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14709: --- Fix Version/s: (was: 4.0.x) 4.x > Global configuration parameter to reject increment repair and allow full > repair only > > > Key: CASSANDRA-14709 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14709 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair, Local/Config >Reporter: Thomas Steinmaurer >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x > > > We are running Cassandra in AWS and On-Premise at customer sites, currently > 2.1 in production with 3.0/3.11 in pre-production stages including loadtest. > In a migration path from 2.1 to 3.11.x, I’m afraid that at some point in time > we end up in incremental repairs being enabled / ran a first time > unintentionally, cause: > a) A lot of online resources / examples do not use the _-full_ command-line > option available since 2.2 (?) > b) Our internal (support) tickets of course also state nodetool repair > command without the -full option, as these examples are for 2.1 > Especially for On-Premise customers (with less control than with our AWS > deployments), this asks a bit for getting out-of-control once we have 3.11 > out and nodetool repair being run without the -full command-line option. > With troubles incremental repair are introducing and incremental being the > default since 2.2 (?), what do you think about a JVM system property, > cassandra.yaml setting or whatever … to basically let the cluster > administrator chose if incremental repairs are allowed or not? I know, such a > flag still can be flipped then (by the customer), but as a first safety stage > possibly sufficient enough. -- 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-14732) Range queries do not always query local node
[ https://issues.apache.org/jira/browse/CASSANDRA-14732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14732: --- Fix Version/s: (was: 4.0.x) 4.x > Range queries do not always query local node > > > Key: CASSANDRA-14732 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14732 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Coordination >Reporter: Benedict Elliott Smith >Priority: Low > Fix For: 4.x > > > The logic for choosing to submit a local request is very peculiar, only doing > so if it is the only replica to be queried. Going through the NIC to query > oneself otherwise is fairly strange, and surely a bug. > I wonder if we should detect and warn messages sent from/to ourselves, as > this is surely always a bug. -- 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-14590) Size of fixed-width write values not verified from peers
[ https://issues.apache.org/jira/browse/CASSANDRA-14590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14590: --- Fix Version/s: (was: 4.0.x) 4.x > Size of fixed-width write values not verified from peers > - > > Key: CASSANDRA-14590 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14590 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Streaming and Messaging >Reporter: Benedict Elliott Smith >Priority: Low > Fix For: 3.0.x, 3.11.x, 4.x > > > There are any number of reasons data arriving on a node might be corrupt in a > manner that can ultimately pollute non-corrupt data. CASSANDRA-14568 is just > one example. In this bug’s case, invalid clusterings were sent to a legacy > version peer, which eventually sent them back to a latest version peer. In > either case, verification of the size of the values arriving would have > prevented the corruption spreading, or affecting whole-sstable operations > containing the values. > > I propose verifying the fixed-width types arriving from peers, and also on > serialization. The former permits rejecting the write with an exception, and > preventing the write being ACK’d, or polluting memtables (thus maintaining > update atomicity without affecting more records). The latter will be a > guarantee that this corruption cannot make it to an sstable via any other > route (e.g. a bug internal to the node) -- 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-14666) Race condition in AbstractReplicationStrategy.getNaturalReplicas
[ https://issues.apache.org/jira/browse/CASSANDRA-14666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14666: --- Fix Version/s: (was: 4.0.x) 4.x > Race condition in AbstractReplicationStrategy.getNaturalReplicas > > > Key: CASSANDRA-14666 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14666 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Distributed Metadata >Reporter: Benedict Elliott Smith >Priority: Low > Labels: correctness > Fix For: 3.0.x, 3.11.x, 4.x > > > There is a very narrow and infrequent race window, in which two ring updates > occur in a short space of time (or during an interval of no queries): > - thread A invalidates the cache after the first ring change, snapshots this > version of the ring, and begins to calculate its natural endpoints > - thread B sees the second ring change, and invalidates the cache before > thread A completes > - thread A writes its value to the cache, based on the old ring layout > Now, a stale view of the endpoints for this token will be persisted in > AbstractReplicationStrategy until the next ring change (which may feasibly > never occur) -- 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-14781) Log message when mutation passed to CommitLog#add(Mutation) is too large is not descriptive enough
[ https://issues.apache.org/jira/browse/CASSANDRA-14781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14781: --- Fix Version/s: (was: 4.0.x) 4.x > Log message when mutation passed to CommitLog#add(Mutation) is too large is > not descriptive enough > -- > > Key: CASSANDRA-14781 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14781 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Jordan West >Assignee: Tom Petracca >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.x > > Attachments: CASSANDRA-14781.patch, CASSANDRA-14781_3.0.patch, > CASSANDRA-14781_3.11.patch > > > When hitting > [https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/commitlog/CommitLog.java#L256-L257], > the log message produced does not help the operator track down what data is > being written. At a minimum the keyspace and cfIds involved would be useful > (and are available) – more detail might not be reasonable to include. -- 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-14795) Expose information about stored hints via JMX
[
https://issues.apache.org/jira/browse/CASSANDRA-14795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-14795:
---
Fix Version/s: (was: 4.0.x)
4.x
> Expose information about stored hints via JMX
> -
>
> Key: CASSANDRA-14795
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14795
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
> Fix For: 4.x
>
>
> Currently there is no way to determine what kind of hints a node has, apart
> from looking at the filenames (thus host-ids) on disk. Having a way to access
> this information would help with debugging hint creation/replay scenarios.
> In addition to the JMX method, there is a new nodetool command:
> {noformat}$ bin/nodetool -h 127.0.0.1 -p 7100 listendpointspendinghints
> Host ID Address Rack DC Status Total files Newest Oldest
> 5762b140-3fdf-4057-9ca7-05c070ccc9c3 127.0.0.2 rack1 datacenter1 DOWN 2
> 2018-09-18 14:05:18,835 2018-09-18 14:05:08,811
> {noformat}
--
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-15290) Avoid token cache invalidation for removing proxy node
[ https://issues.apache.org/jira/browse/CASSANDRA-15290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15290: --- Fix Version/s: (was: 4.0.x) 4.x > Avoid token cache invalidation for removing proxy node > -- > > Key: CASSANDRA-15290 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15290 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Membership >Reporter: Jay Zhuang >Assignee: Jay Zhuang >Priority: Low > Fix For: 4.x > > > As proxy node doesn't own token, adding/removing doesn't change token > ownership and no need to invalidate the token cache. -- 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-14975) cqlsh dtests are not running in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-14975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14975: --- Fix Version/s: (was: 4.0.x) 4.x > cqlsh dtests are not running in CircleCI > > > Key: CASSANDRA-14975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14975 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.x > > > Right now the dtests skip these tests because most don't pass. Originally > they weren't being collected because the test files end in_tests.py instead > of _test.py, but I fixed that by adding _tests.py to the list of recognized > patterns. > Get them all running in CircleCI. Nothing special they will be part of the > existing dtest jobs. -- 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-13720) Clean up repair code
[ https://issues.apache.org/jira/browse/CASSANDRA-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-13720: --- Fix Version/s: (was: 4.0.x) 4.x > Clean up repair code > > > Key: CASSANDRA-13720 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13720 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Simon Zhou >Assignee: Simon Zhou >Priority: Normal > Fix For: 4.x > > > Lots of unused 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-15222) BufferedDataOutputStreamPlus.write() should use FastByteOperations.copy()
[ https://issues.apache.org/jira/browse/CASSANDRA-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15222: --- Fix Version/s: (was: 4.0.x) 4.x > BufferedDataOutputStreamPlus.write() should use FastByteOperations.copy() > - > > Key: CASSANDRA-15222 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15222 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Local/SSTable, Messaging/Internode >Reporter: Benedict Elliott Smith >Assignee: Boris Tsirkin >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Time Spent: 0.5h > Remaining Estimate: 0h > -- 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-15373) validate value sizes in LegacyLayout
[ https://issues.apache.org/jira/browse/CASSANDRA-15373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15373: --- Fix Version/s: (was: 3.11.5) (was: 3.0.19) 3.11.6 3.0.20 > validate value sizes in LegacyLayout > > > Key: CASSANDRA-15373 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15373 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.0, 3.0.20, 3.11.6 > > > In 2.1, all values are serialized as variable length blobs, with a length > prefix, followed by the actual value, even with fixed width types like int32. > The 3.0 storage engine, on the other hand, omits the length prefix for fixed > width types. Since the length of fixed width types are not validated on the > 3.0 write path, writing data for a fixed width type from an incorrectly sized > byte buffer will over or underflow the space allocated for it, corrupting the > remainder of that partition or indexed region from being read. This is not > discovered until we attempt to read the corrupted value. This patch updates > LegacyLayout to throw a marshal exception if it encounters an unexpected > value size for fixed size columns. -- 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-15211) Remove BaseIterator.stopChild
[ https://issues.apache.org/jira/browse/CASSANDRA-15211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-15211: --- Fix Version/s: (was: 3.11.5) (was: 3.0.19) 3.11.x 3.0.x > Remove BaseIterator.stopChild > - > > Key: CASSANDRA-15211 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15211 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.0, 3.0.x, 3.11.x > > > This concept was introduced in CASSANDRA-13482, and while it logically > resolves the bug, the “more correct” solution is to attach the functions of > the extending iterator to the iterator they are being absorbed into. > CASSANDRA-13482 introduced a slight error in its evaluation of exit > conditions that cropped up in CASSANDRA-14812, that could be avoided with > this formulation. -- 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-15035) C* 3.0 sstables w/ UDTs are corrupted in 3.11 + 4.0
[
https://issues.apache.org/jira/browse/CASSANDRA-15035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-15035:
---
Fix Version/s: (was: 3.11.5)
3.11.6
> C* 3.0 sstables w/ UDTs are corrupted in 3.11 + 4.0
> ---
>
> Key: CASSANDRA-15035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15035
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDT, Local/SSTable
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Urgent
> Fix For: 4.0, 3.11.6
>
>
> OSS C* 3.0 writes incorrect type information for UDTs into the
> serialization-header of each sstable.
> In C* 3.0, both UDTs and tuple are always frozen. A frozen type must be
> enclosed in a {{frozen<...>}} via the {{CQL3Type}} hierarchy (resp
> {{org.apache.cassandra.db.marshal.FrozenType(...)}} via the {{AbstractType}}
> hierarchy) “bracket” in the schema and serialization-header.
> Since CASSANDRA-7423 (committed to C* 3.6) UDTs can also be non-frozen (=
> multi-cell).
> Unfortunately, C* 3.0 does not write the
> {{org.apache.cassandra.db.marshal.FrozenType(...)}} “bracket” for UDTs into
> the {{SerializationHeader.Component}} in the {{-Stats.db}} sstable component.
> The order in which columns of a row are serialized depends on the concrete
> {{AbstractType}}. Columns with variable length types (frozen types belong to
> this category) are serialized before columns with multi-cell types
> (non-frozen types belong to that category).
> If C* 3.6 (or any newer version) reads an sstable written by C* 3.0 (up to
> 3.5), it will read the type information “non-frozen UDT” from the
> serialization header, which is technically correct.
> This means, that upgrades from C* 3.0 to C* 3.11 and 4.0, using a schema that
> uses UDTs, result in inaccessible data in those sstables. Reads against 3.0
> sstables as well as attempts to scrub these sstables result in a wide variety
> of errors/exceptions ({{CorruptSSTableException}}, {{EOFExcepiton}},
> {{OutOfMemoryError}}, etc etc), as usual in such cases.
> Mitigation strategy in the proposed patch:
> * Fix the broken serialization-headers automatically when an upgrade from C*
> 3.0 is detected.
> * Enhance {{sstablescrub}} to verify the serialization-header against the
> schema and allow {{sstablescrub}} to fix the UDT types according to the
> information in the schema. This does not apply to "online scrub" (e.g.
> nodetool scrub). The behavior of {{sstablescrub}} has been changed to first
> inspect the serialization-header and verify the type information against the
> schema.
> Differences between the schema and the sstable serialization-headers cause
> {{sstablescrub}} to error out and stop - i.e. safety first (there’s a way to
> opt-out though).
> A new class {{SSTableHeaderFix}} can inspect the serialization-header
> ({{SerializationHeader.Component}}) in the the {{-Statistics.db}} component
> and fix the type information in those sstables for UDTs according to the
> schema information.
> This new class could be used during verify and before sstables are imported.
> But changes to “verify” and “import” are out of the scope of this ticket, as
> the patch is already bigger than I originally expected.
> Another issue not tackled by this ticket is that the wrong ‘kind’ is written
> to the type information in {{system_schema.dropped_columns}} when a
> non-frozen UDT column is dropped. When a UDT column is dropped, the type of
> the dropped column is converted from the UDT definition to its
> “corresponding” tuple type definition. But all versions currently write
> {{frozen>}}, but for non-frozen UDTs it should actually just be
> {{tuple<...>}}. Unfortunately, there is nothing that could be done in this
> ticket to fix (or even consider) the type information of a dropped column.
> But for correctness, the tuple type should be a multi-cell one (only
> accessible for dropped UDTs though - not as something that a user can create
> as a type).
--
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-15371) Incorrect messaging service version breaks in-JVM upgrade tests on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-15371:
---
Fix Version/s: (was: 3.11.x)
(was: 3.0.x)
(was: 2.2.x)
3.11.6
3.0.20
2.2.16
> Incorrect messaging service version breaks in-JVM upgrade tests on trunk
>
>
> Key: CASSANDRA-15371
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15371
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0, 2.2.16, 3.0.20, 3.11.6
>
>
> The in-JVM upgrade tests on trunk currently fail because the messaging
> version for internode messaging is selected as
> {{MessagingService.current_version}},
> a regression from the implementation in CASSANDRA-15078.
--
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-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14970: --- Fix Version/s: (was: 3.11.5) (was: 3.0.19) (was: 2.2.15) 3.11.6 3.0.20 2.2.16 > New releases must supply SHA-256 and/or SHA-512 checksums > - > > Key: CASSANDRA-14970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14970 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Shuler >Assignee: Michael Shuler >Priority: Urgent > Fix For: 4.0, 2.2.16, 3.0.20, 3.11.6 > > Attachments: > 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, > 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, > ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png > > > Release policy was updated around 9/2018 to state: > "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT > supply MD5 or SHA-1. Existing releases do not need to be changed." > build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. > cassandra-builds/cassandra-release scripts need to be updated to work with > the new checksum files. > http://www.apache.org/dev/release-distribution#sigs-and-sums -- 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-15333) The release process does not incremental the version, nor document the need to
[
https://issues.apache.org/jira/browse/CASSANDRA-15333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-15333:
---
Status: Ready to Commit (was: Review In Progress)
> The release process does not incremental the version, nor document the need to
> --
>
> Key: CASSANDRA-15333
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15333
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/Website
>Reporter: mck
>Assignee: mck
>Priority: Normal
>
> Incrementing the {{`base.version`}} in {{build.xml}} has remained a manual,
> and easily forgotten, part of the release process.
> This patch adds the how and when to perform that step into the existing
> release process documentation:
>
> https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15333
--
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-15333) The release process does not incremental the version, nor document the need to
[
https://issues.apache.org/jira/browse/CASSANDRA-15333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-15333:
---
Reviewers: Michael Shuler, Michael Shuler (was: Michael Shuler)
Michael Shuler, Michael Shuler
Status: Review In Progress (was: Patch Available)
Looks good, feel free to commit. Thanks!
> The release process does not incremental the version, nor document the need to
> --
>
> Key: CASSANDRA-15333
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15333
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/Website
>Reporter: mck
>Assignee: mck
>Priority: Normal
>
> Incrementing the {{`base.version`}} in {{build.xml}} has remained a manual,
> and easily forgotten, part of the release process.
> This patch adds the how and when to perform that step into the existing
> release process documentation:
>
> https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15333
--
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-10988) isInclusive and boundsAsComposites in Restriction take bounds in different order
[
https://issues.apache.org/jira/browse/CASSANDRA-10988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-10988:
---
Fix Version/s: (was: 2.2.x)
2.2.8
> isInclusive and boundsAsComposites in Restriction take bounds in different
> order
>
>
> Key: CASSANDRA-10988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10988
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Vassil Hristov
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 2.2.8
>
>
> After we've upgraded our cluster to version 2.1.11, we started getting the
> bellow exceptions for some of our queries. Issue seems to be very similar to
> CASSANDRA-7284.
> Code to reproduce:
> {code:java}
> createTable("CREATE TABLE %s (" +
> "a text," +
> "b int," +
> "PRIMARY KEY (a, b)" +
> ") WITH COMPACT STORAGE" +
> "AND CLUSTERING ORDER BY (b DESC)");
> execute("insert into %s (a, b) values ('a', 2)");
> execute("SELECT * FROM %s WHERE a = 'a' AND b > 0");
> {code}
> {code:java}
> java.lang.ClassCastException:
> org.apache.cassandra.db.composites.Composites$EmptyComposite cannot be cast
> to org.apache.cassandra.db.composites.CellName
> at
> org.apache.cassandra.db.composites.AbstractCellNameType.cellFromByteBuffer(AbstractCellNameType.java:188)
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at
> org.apache.cassandra.db.composites.AbstractSimpleCellNameType.makeCellName(AbstractSimpleCellNameType.java:125)
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at
> org.apache.cassandra.db.composites.AbstractCellNameType.makeCellName(AbstractCellNameType.java:254)
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.makeExclusiveSliceBound(SelectStatement.java:1197)
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.applySliceRestriction(SelectStatement.java:1205)
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.processColumnFamily(SelectStatement.java:1283)
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1250)
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:299)
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:276)
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:67)
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:238)
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:493)
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:138)
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
> [apache-cassandra-2.1.11.jar:2.1.11]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
> [apache-cassandra-2.1.11.jar:2.1.11]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_66]
> at
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
> [apache-cassandra-2.1.11.jar:2.1.11]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
>
[jira] [Updated] (CASSANDRA-10814) [patch] make json date formatter thread safe
[ https://issues.apache.org/jira/browse/CASSANDRA-10814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-10814: --- Fix Version/s: (was: 2.2.x) 2.2.5 > [patch] make json date formatter thread safe > > > Key: CASSANDRA-10814 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10814 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Dave Brosius >Assignee: Dave Brosius >Priority: Low > Fix For: 2.2.5 > > Attachments: 10814.txt > > > the TimestampSerializer.TO_JSON_FORMATTER (SimpleDateFormat) is shared across > thread which isn't thread safe. Switch to using ThreadLocal -- 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-10487) Regression in select count with limit
[
https://issues.apache.org/jira/browse/CASSANDRA-10487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-10487:
---
Fix Version/s: (was: 2.2.x)
2.2.3
> Regression in select count with limit
> -
>
> Key: CASSANDRA-10487
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10487
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 2.2.3
>
>
> After CASSANDRA-4914 the {{LIMIT}} clause should limit only the number of
> rows returned to the user not the number of rows used by the aggregates.
> That functionality is currently broken in 2.2.
--
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-10372) Adds smallint and tinyint to the CQL documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-10372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-10372:
---
Fix Version/s: (was: 2.2.x)
2.2.3
> Adds smallint and tinyint to the CQL documentation
> --
>
> Key: CASSANDRA-10372
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10372
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Low
> Fix For: 2.2.3
>
> Attachments: 10372-2.2.txt
>
>
> CASSANDRA-8951 added {{smallint}} and {{tinyint}} types but the CQL
> documentation was not updated.
--
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-10146) Deprecate v1 and v2 protocol in 2.2, drop support in 3.0
[ https://issues.apache.org/jira/browse/CASSANDRA-10146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-10146: --- Fix Version/s: (was: 2.2.x) 2.1.10 2.2.2 > Deprecate v1 and v2 protocol in 2.2, drop support in 3.0 > > > Key: CASSANDRA-10146 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10146 > Project: Cassandra > Issue Type: Task > Components: Legacy/CQL >Reporter: Tyler Hobbs >Assignee: Benjamin Lerer >Priority: Normal > Labels: client-impacting, doc-impacting > Fix For: 2.1.10, 2.2.2, 3.0.0 rc1 > > > In 3.0, we would like to use frozen collections in the system keyspaces, and > it seems likely that we will eventually want to use tuples or nested > collections as well. Drivers that only support protocol versions 1 and 2 > will not be able to read these system keyspaces because they cannot decode > those types. > I think this is a good time to start deprecating and dropping support for old > protocol versions. The v3 protocol was introduced in 2.1, so if we remove > support for v1 and v2 in 3.0, that gives users two major versions to upgrade > their drivers. Fortunately, upgrading drivers to a version that supports the > v3 protocol is generally straightforward. > The benefits of doing this are: > * We can use new types in the system keyspaces > * We can eliminate protocol-version-specific encoding and decoding of > collections within Cassandra > * Driver maintainers can eventually drop support for old protocol versions > once all C* versions that support them are EOL > To avoid a hard drop of v1 and v2 support in 3.0, I propose that we also > officially deprecate these in 2.2. Unfortunately, we don't have > protocol-level warnings until v4, so we can't use that to notify users of the > deprecation, but the combination of a NEWS.txt entry, warning logs, and > (potentially) driver-level warnings should suffice. -- 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-13847) test failure in cqlsh_tests.cqlsh_tests.CqlLoginTest.test_list_roles_after_login
[ https://issues.apache.org/jira/browse/CASSANDRA-13847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-13847: --- Fix Version/s: (was: 2.2.x) (was: 2.1.x) 2.2.11 > test failure in > cqlsh_tests.cqlsh_tests.CqlLoginTest.test_list_roles_after_login > > > Key: CASSANDRA-13847 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13847 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Testing, Legacy/Tools >Reporter: Joel Knighton >Assignee: Andrés de la Peña >Priority: Normal > Labels: test-failure > Fix For: 2.2.11 > > > example failure: > http://cassci.datastax.com/job/cassandra-2.1_dtest/546/testReport/cqlsh_tests.cqlsh_tests/CqlLoginTest/test_list_roles_after_login > This test was added for [CASSANDRA-13640]. The comments seem to indicated > this is only a problem on 3.0+, but the added test certainly seems to > reproduce the problem on 2.1 and 2.2. Even if the issue does affect 2.1/2.2, > it seems insufficiently critical for 2.1, so we need to limit the test to run > on 2.2+ at the very least, possibly 3.0+ if we don't fix the cause on 2.2. > Thoughts [~adelapena]? -- 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-11549) cqlsh: COPY FROM ignores NULL values in conversion
[
https://issues.apache.org/jira/browse/CASSANDRA-11549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-11549:
---
Fix Version/s: (was: 2.1.x)
2.1.15
> cqlsh: COPY FROM ignores NULL values in conversion
> --
>
> Key: CASSANDRA-11549
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11549
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Tools
>Reporter: Stefania
>Assignee: Stefania
>Priority: Normal
> Fix For: 2.1.15, 2.2.7, 3.0.6, 3.6
>
>
> COPY FROM fails to import empty values.
> For example:
> {code}
> $ cat test.csv
> a,10,20
> b,30,
> c,50,60
> $ cqlsh
> cqlsh> create keyspace if not exists test with replication = {'class':
> 'SimpleStrategy', 'replication_factor':1};
> cqlsh> create table if not exists test.test (t text primary key, i1 int, i2
> int);
> cqlsh> copy test.test (t,i1,i2) from 'test.csv';
> {code}
> Imports:
> {code}
> select * from test.test";
> t | i1 | i2
> ---++
> a | 10 | 20
> c | 50 | 60
> (2 rows)
> {code}
> and generates a {{ParseError - invalid literal for int() with base 10: '',
> given up without retries}} for the row with an empty value.
> It should import the empty value as a {{null}} and there should be no error:
> {code}
> cqlsh> select * from test.test";
> t | i1 | i2
> ---++--
> a | 10 | 20
> c | 50 | 60
> b | 30 | null
> (3 rows)
> {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-10764) Cassandra Daemon should print JVM arguments
[ https://issues.apache.org/jira/browse/CASSANDRA-10764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-10764: --- Fix Version/s: (was: 2.1.x) 2.1.13 > Cassandra Daemon should print JVM arguments > --- > > Key: CASSANDRA-10764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10764 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability, Local/Startup and Shutdown > Environment: PROD >Reporter: Anubhav Kale >Assignee: Robert Stupp >Priority: Low > Fix For: 2.1.13 > > Attachments: 10764.patch > > > While debugging, its useful to check if Cassandra indeed is picking up the > JVM args supplied to it. Therefore, we should print those on startup. > Patch is attached, and straightforward. -- 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-13614) Batchlog replay throttle should be dynamically configurable with jmx and possibly nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-13614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-13614:
---
Fix Version/s: (was: 4.x)
4.0
> Batchlog replay throttle should be dynamically configurable with jmx and
> possibly nodetool
> --
>
> Key: CASSANDRA-13614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13614
> Project: Cassandra
> Issue Type: Sub-task
> Components: Feature/Materialized Views, Local/Config
>Reporter: Andrés de la Peña
>Assignee: Andrés de la Peña
>Priority: Normal
> Fix For: 4.0
>
>
> As it is said in
> [CASSANDRA-13162|https://issues.apache.org/jira/browse/CASSANDRA-13162],
> batchlog replay can be excessively throttled with materialized views. The
> throttle is controlled by the property {{batchlog_replay_throttle_in_kb}},
> which is set by default to (only) 1024KB, and it can't be configured
> dynamically. It would be useful to be able of modifying it dynamically with
> JMX and possibly nodetool.
--
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-13584) Inclusion of cassandra-dtest project from code donation
[ https://issues.apache.org/jira/browse/CASSANDRA-13584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-13584: --- Fix Version/s: 2.1.19 2.2.11 3.0.15 3.11.1 4.0 > Inclusion of cassandra-dtest project from code donation > --- > > Key: CASSANDRA-13584 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13584 > Project: Cassandra > Issue Type: Task >Reporter: Nate McCall >Assignee: Nate McCall >Priority: Normal > Fix For: 2.1.19, 2.2.11, 3.0.15, 3.11.1, 4.0 > > Attachments: DataStax_software-grant.pdf > > > The issue is for tracking legal and incubator acceptance of cassandra-dtest. > IP clearance template is located here: > https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/cassandra-dtest.xml > The dtest project is located here: > https://github.com/riptano/cassandra-dtest > For convienience, vote thread is here: > https://lists.apache.org/thread.html/d9e694ba8eaac8e8c70cbfd3f6ee249d43f8c67279882ffc65e56cac@%3Cdev.cassandra.apache.org%3E > Software grant from DataStax is attached. -- 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-13584) Inclusion of cassandra-dtest project from code donation
[ https://issues.apache.org/jira/browse/CASSANDRA-13584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-13584: --- Fix Version/s: (was: 4.x) > Inclusion of cassandra-dtest project from code donation > --- > > Key: CASSANDRA-13584 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13584 > Project: Cassandra > Issue Type: Task >Reporter: Nate McCall >Assignee: Nate McCall >Priority: Normal > Attachments: DataStax_software-grant.pdf > > > The issue is for tracking legal and incubator acceptance of cassandra-dtest. > IP clearance template is located here: > https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/cassandra-dtest.xml > The dtest project is located here: > https://github.com/riptano/cassandra-dtest > For convienience, vote thread is here: > https://lists.apache.org/thread.html/d9e694ba8eaac8e8c70cbfd3f6ee249d43f8c67279882ffc65e56cac@%3Cdev.cassandra.apache.org%3E > Software grant from DataStax is attached. -- 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-14205) ReservedKeywords class is missing some reserved CQL keywords
[
https://issues.apache.org/jira/browse/CASSANDRA-14205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-14205:
---
Fix Version/s: (was: 3.11.x)
(was: 4.x)
3.11.2
4.0
> ReservedKeywords class is missing some reserved CQL keywords
>
>
> Key: CASSANDRA-14205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14205
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Andrés de la Peña
>Assignee: Andrés de la Peña
>Priority: Normal
> Fix For: 3.11.2, 4.0
>
>
> The CQL keywords {{DEFAULT}}, {{UNSET}}, {{MBEAN}} and {{MBEANS}} (introduced
> by CASSANDRA-11424 and CASSANDRA-10091) are neither considered [unreserved
> keywords|https://github.com/apache/cassandra/blob/trunk/src/antlr/Parser.g#L1788-L1846]
> by the ANTLR parser, nor included in the
> [{{ReservedKeywords}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/ReservedKeywords.java]
> class.
> The current parser behaviour is considering them as reserved keywords, in the
> sense that they can't be used as keyspace/table/column names, which seems
> right:
> {code:java}
> cassandra@cqlsh> CREATE KEYSPACE unset WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
> SyntaxException: line 1:16 no viable alternative at input 'unset' (CREATE
> KEYSPACE [unset]...)
> {code}
> I think we should keep considering these keywords as reserved and add them to
> {{ReservedKeywords}} class.
--
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-13963) SecondaryIndexManagerTest.indexWithfailedInitializationIsNotQueryableAfterPartialRebuild is flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-13963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-13963: --- Fix Version/s: (was: 4.x) 4.0 > SecondaryIndexManagerTest.indexWithfailedInitializationIsNotQueryableAfterPartialRebuild > is flaky > - > > Key: CASSANDRA-13963 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13963 > Project: Cassandra > Issue Type: Bug > Components: Feature/2i Index, Legacy/Testing >Reporter: Andrés de la Peña >Assignee: Andrés de la Peña >Priority: Low > Fix For: 4.0 > > > The unit test > [SecondaryIndexManagerTest.indexWithfailedInitializationIsNotQueryableAfterPartialRebuild|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/index/SecondaryIndexManagerTest.java#L460-L476] > is flaky. Apart from [the CI results showing a 3% > flakiness|http://cassci.datastax.com/view/All_Jobs/job/trunk_utest/2430/testReport/org.apache.cassandra.index/SecondaryIndexManagerTest/indexWithfailedInitializationIsNotQueryableAfterPartialRebuild/], > the test failure can be locally reproduced just running the test multiple > times. In my case, it fails 2-5 times for each 1000 executions. -- 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-13965) SecondaryIndexManagerTest.assert[Not]MarkedAsBuilt produces flaky tests
[
https://issues.apache.org/jira/browse/CASSANDRA-13965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-13965:
---
Fix Version/s: (was: 4.x)
4.0
> SecondaryIndexManagerTest.assert[Not]MarkedAsBuilt produces flaky tests
> ---
>
> Key: CASSANDRA-13965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13965
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index, Legacy/Testing
>Reporter: Andrés de la Peña
>Assignee: Andrés de la Peña
>Priority: Low
> Fix For: 4.0
>
>
> The methods
> [{{SecondaryIndexManagerTest.assertMarkedAsBuilt}}|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/index/SecondaryIndexManagerTest.java#L554-L557]
> and
> [{{SecondaryIndexManagerTest.assertNotMarkedAsBuilt}}|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/index/SecondaryIndexManagerTest.java#L559-L562]
> produce occasional test failures.
> These methods assume that there aren't any other indexes in the
> {{system.IndexInfo}} table than those created by the calling test. However,
> it is possible to find indexes built for other tests (not only
> {{SecondaryIndexManagerTest}}) that rely on {{CQLTester.afterTest}} to
> cleanup to drop their created indexes, because this method is asynchronous.
> So, it is possible to reach the
> {{SecondaryIndexManagerTest.assert(Not)MarkedAsBuilt}} calls before the
> indexes created by the previous test have been cleaned up.
--
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-13783) Updating the plugin url link
[ https://issues.apache.org/jira/browse/CASSANDRA-13783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-13783: --- Fix Version/s: (was: 4.x) > Updating the plugin url link > > > Key: CASSANDRA-13783 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13783 > Project: Cassandra > Issue Type: Task > Components: Legacy/Documentation and Website >Reporter: Amitkumar Ghatwal >Priority: Urgent > > Hi All, > > Updating index.rst with url of plugin > Moved the capi-row cache plugin github repository from an individual github > account to a more generic one. > Older plugin repo location : https://github.com/hhorii/capi-rowcache > New plugin repo location : https://github.com/ppc64le/capi-rowcache > PR link : > https://github.com/apache/cassandra/pull/139/commits/05851cdabc953ec17480b0bd325b1b5adb7b53bb > Reference : https://issues.apache.org/jira/browse/CASSANDRA-13581 -- 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-13703) Using min_compress_ratio <= 1 causes corruption
[
https://issues.apache.org/jira/browse/CASSANDRA-13703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-13703:
---
Fix Version/s: (was: 4.x)
4.0
> Using min_compress_ratio <= 1 causes corruption
> ---
>
> Key: CASSANDRA-13703
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13703
> Project: Cassandra
> Issue Type: Bug
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
>Priority: Urgent
> Fix For: 4.0
>
> Attachments: patch
>
>
> This is because chunks written uncompressed end up below the compressed size
> threshold. Demonstrated by applying the attached patch meant to improve the
> testing of the 10520 changes, and running
> {{CompressedSequentialWriterTest.testLZ4Writer}}.
> The default {{min_compress_ratio: 0}} is not affected as it never writes
> uncompressed.
--
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-13640) CQLSH error when using 'login' to switch users
[
https://issues.apache.org/jira/browse/CASSANDRA-13640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-13640:
---
Fix Version/s: (was: 3.11.x)
(was: 4.x)
(was: 3.0.x)
3.0.15
3.11.1
4.0
> CQLSH error when using 'login' to switch users
> --
>
> Key: CASSANDRA-13640
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13640
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Andrés de la Peña
>Assignee: Andrés de la Peña
>Priority: Low
> Fix For: 3.0.15, 3.11.1, 4.0
>
>
> Using {{PasswordAuthenticator}} and {{CassandraAuthorizer}}:
> {code}
> bin/cqlsh -u cassandra -p cassandra
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.0.14-SNAPSHOT | CQL spec 3.4.0 | Native protocol
> v4]
> Use HELP for help.
> cassandra@cqlsh> create role super with superuser = true and password = 'p'
> and login = true;
> cassandra@cqlsh> login super;
> Password:
> super@cqlsh> list roles;
> 'Row' object has no attribute 'values'
> {code}
> When we initialize the Shell, we configure certain settings on the session
> object such as
> {code}
> self.session.default_timeout = request_timeout
> self.session.row_factory = ordered_dict_factory
> self.session.default_consistency_level = cassandra.ConsistencyLevel.ONE
> {code}
> However, once we perform a LOGIN cmd, which calls do_login(..), we create a
> new cluster/session object but actually never set those settings on the new
> session.
> It isn't failing on 3.x.
> As a workaround, it is possible to logout and log back in and things work
> correctly.
--
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-13650) cql_tests:SlowQueryTester.local_query_test and cql_tests:SlowQueryTester.remote_query_test failed on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-13650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-13650:
---
Fix Version/s: (was: 4.x)
4.0
> cql_tests:SlowQueryTester.local_query_test and
> cql_tests:SlowQueryTester.remote_query_test failed on trunk
> --
>
> Key: CASSANDRA-13650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13650
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Distributed Metadata
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Low
> Fix For: 4.0
>
>
> cql_tests.py:SlowQueryTester.local_query_test failed on trunk
> cql_tests.py:SlowQueryTester.remote_query_test failed on trunk
> SHA: fe3cfe3d7df296f022c50c9c0d22f91a0fc0a217
> It's due to the dtest unable to find {{'SELECT \* FROM ks.test1'}} pattern
> from log.
> but in the log, following info is showed:
> {{MonitoringTask.java:173 - 1 operations were slow in the last 10 msecs:
> , time 102 msec - slow timeout 10 msec}}
> ColumnFilter.toString() should return {{*}}, but return normal column {{val}}
> instead
--
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-13622) Better config validation/documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-13622:
---
Fix Version/s: (was: 3.11.x)
(was: 4.x)
(was: 3.0.x)
3.0.15
3.11.1
4.0
> Better config validation/documentation
> --
>
> Key: CASSANDRA-13622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13622
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Kurt Greaves
>Assignee: ZhaoYang
>Priority: Low
> Labels: lhf
> Fix For: 3.0.15, 3.11.1, 4.0
>
>
> There are a number of properties in the yaml that are "in_mb", however
> resolve to bytes when calculated in {{DatabaseDescriptor.java}}, but are
> stored in int's. This means that their maximum values are 2047, as any higher
> when converted to bytes overflows the int.
> Where possible/reasonable we should convert these to be long's, and stored as
> long's. If there is no reason for the value to ever be >2047 we should at
> least document that as the max value, or better yet make it error if set
> higher than that. Noting that although it's bad practice to increase a lot of
> them to such high values, there may be cases where it is necessary and in
> which case we should handle it appropriately rather than overflowing and
> surprising the user. That is, causing it to break but not in the way the user
> expected it to :)
> Following are functions that currently could be at risk of the above:
> {code:java|title=DatabaseDescriptor.java}
> getThriftFramedTransportSize()
> getMaxValueSize()
> getCompactionLargePartitionWarningThreshold()
> getCommitLogSegmentSize()
> getNativeTransportMaxFrameSize()
> # These are in KB so max value of 2096128
> getBatchSizeWarnThreshold()
> getColumnIndexSize()
> getColumnIndexCacheSize()
> getMaxMutationSize()
> {code}
> Note we may not actually need to fix all of these, and there may be more.
> This was just from a rough scan over the 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-13617) Missing option from the cassandra-stress tool help
[ https://issues.apache.org/jira/browse/CASSANDRA-13617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-13617: --- Fix Version/s: (was: 4.x) > Missing option from the cassandra-stress tool help > -- > > Key: CASSANDRA-13617 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13617 > Project: Cassandra > Issue Type: Improvement > Components: Tool/stress >Reporter: Pedro Gordo >Priority: Low > > The "duration" option is missing from the cassandra-stress help. -- 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-13573) ColumnMetadata.cellValueType() doesn't return correct type for non-frozen collection
[
https://issues.apache.org/jira/browse/CASSANDRA-13573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-13573:
---
Fix Version/s: (was: 3.11.x)
(was: 4.x)
(was: 3.0.x)
3.0.15
3.11.1
4.0
> ColumnMetadata.cellValueType() doesn't return correct type for non-frozen
> collection
>
>
> Key: CASSANDRA-13573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13573
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views, Legacy/Core, Legacy/CQL,
> Legacy/Tools
>Reporter: Stefano Ortolani
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 3.0.15, 3.11.1, 4.0
>
>
> Schema and data"
> {noformat}
> CREATE TABLE ks.cf (
> hash blob,
> report_id timeuuid,
> subject_ids frozen>,
> PRIMARY KEY (hash, report_id)
> ) WITH CLUSTERING ORDER BY (report_id DESC);
> INSERT INTO ks.cf (hash, report_id, subject_ids) VALUES (0x1213, now(),
> {1,2,4,5});
> {noformat}
> sstabledump output is:
> {noformat}
> sstabledump mc-1-big-Data.db
> [
> {
> "partition" : {
> "key" : [ "1213" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 16,
> "clustering" : [ "ec01eed0-49d9-11e7-b39a-97a96f529c02" ],
> "liveness_info" : { "tstamp" : "2017-06-05T10:29:57.434856Z" },
> "cells" : [
> { "name" : "subject_ids", "value" : "" }
> ]
> }
> ]
> }
> ]
> {noformat}
> While the values are really there:
> {noformat}
> cqlsh:ks> select * from cf ;
> hash | report_id| subject_ids
> +--+-
> 0x1213 | 02bafff0-49d9-11e7-b39a-97a96f529c02 | {1, 2, 4}
> {noformat}
--
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-13370) unittest CipherFactoryTest failed on MacOS
[
https://issues.apache.org/jira/browse/CASSANDRA-13370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-13370:
---
Fix Version/s: (was: 3.11.x)
(was: 4.x)
3.11.0
4.0
> unittest CipherFactoryTest failed on MacOS
> --
>
> Key: CASSANDRA-13370
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13370
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Testing
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Low
> Fix For: 3.11.0, 4.0
>
> Attachments: 13370-trunk-update.txt, 13370-trunk.txt
>
>
> Seems like MacOS(El Capitan) doesn't allow writing to {{/dev/urandom}}:
> {code}
> $ echo 1 > /dev/urandom
> echo: write error: operation not permitted
> {code}
> Which is causing CipherFactoryTest failed:
> {code}
> $ ant test -Dtest.name=CipherFactoryTest
> ...
> [junit] Testsuite: org.apache.cassandra.security.CipherFactoryTest
> [junit] Testsuite: org.apache.cassandra.security.CipherFactoryTest Tests
> run: 7, Failures: 0, Errors: 7, Skipped: 0, Time elapsed: 2.184 sec
> [junit]
> [junit] Testcase:
> buildCipher_SameParams(org.apache.cassandra.security.CipherFactoryTest):
> Caused an ERROR
> [junit] setSeed() failed
> [junit] java.security.ProviderException: setSeed() failed
> [junit] at
> sun.security.provider.NativePRNG$RandomIO.implSetSeed(NativePRNG.java:472)
> [junit] at
> sun.security.provider.NativePRNG$RandomIO.access$300(NativePRNG.java:331)
> [junit] at
> sun.security.provider.NativePRNG.engineSetSeed(NativePRNG.java:214)
> [junit] at
> java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:209)
> [junit] at java.security.SecureRandom.(SecureRandom.java:190)
> [junit] at
> org.apache.cassandra.security.CipherFactoryTest.setup(CipherFactoryTest.java:50)
> [junit] Caused by: java.io.IOException: Operation not permitted
> [junit] at java.io.FileOutputStream.writeBytes(Native Method)
> [junit] at java.io.FileOutputStream.write(FileOutputStream.java:313)
> [junit] at
> sun.security.provider.NativePRNG$RandomIO.implSetSeed(NativePRNG.java:470)
> ...
> {code}
> I'm able to reproduce the issue on two Mac machines. But not sure if it's
> affecting all other developers.
> {{-Djava.security.egd=file:/dev/urandom}} was introduced in:
> CASSANDRA-9581
> I would suggest to revert the
> [change|https://github.com/apache/cassandra/commit/ae179e45327a133248c06019f87615c9cf69f643]
> as {{pig-test}} is removed ([pig is no longer
> supported|https://github.com/apache/cassandra/commit/56cfc6ea35d1410f2f5a8ae711ae33342f286d79]).
> Or adding a condition for MacOS in build.xml.
> [~aweisberg] [~jasobrown] any thoughts?
--
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-13216) testall failure in org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages
[
https://issues.apache.org/jira/browse/CASSANDRA-13216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-13216:
---
Fix Version/s: (was: 3.11.x)
(was: 4.x)
(was: 3.0.x)
3.0.14
3.11.0
4.0
> testall failure in
> org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages
>
>
> Key: CASSANDRA-13216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13216
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Testing
>Reporter: Sean McCarthy
>Assignee: Alex Petrov
>Priority: Normal
> Labels: test-failure, testall
> Fix For: 3.0.14, 3.11.0, 4.0
>
> Attachments: TEST-org.apache.cassandra.net.MessagingServiceTest.log,
> TEST-org.apache.cassandra.net.MessagingServiceTest.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.11_testall/81/testReport/org.apache.cassandra.net/MessagingServiceTest/testDroppedMessages
> {code}
> Error Message
> expected:<... dropped latency: 27[30 ms and Mean cross-node dropped latency:
> 2731] ms> but was:<... dropped latency: 27[28 ms and Mean cross-node dropped
> latency: 2730] ms>
> {code}{code}
> Stacktrace
> junit.framework.AssertionFailedError: expected:<... dropped latency: 27[30 ms
> and Mean cross-node dropped latency: 2731] ms> but was:<... dropped latency:
> 27[28 ms and Mean cross-node dropped latency: 2730] ms>
> at
> org.apache.cassandra.net.MessagingServiceTest.testDroppedMessages(MessagingServiceTest.java:83)
> {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-13174) Indexing is allowed on Duration type when it should not be
[
https://issues.apache.org/jira/browse/CASSANDRA-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-13174:
---
Fix Version/s: (was: 3.11.x)
(was: 4.x)
3.11.0
4.0
> Indexing is allowed on Duration type when it should not be
> --
>
> Key: CASSANDRA-13174
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13174
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
> Environment: C* 3.10
>Reporter: Kishan Karunaratne
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.11.0, 4.0
>
>
> Looks like secondary indexing is allowed on duration type columns. Since
> comparisons are not possible for the duration type, indexing on it also
> should be invalid.
> 1)
> {noformat}
> CREATE TABLE duration_table (k int PRIMARY KEY, d duration);
> INSERT INTO duration_table (k, d) VALUES (0, 1s);
> SELECT * from duration_table WHERE d=1s ALLOW FILTERING;
> {noformat}
> The above throws an error:
> {noformat}
> WARN [ReadStage-2] 2017-01-31 17:09:57,821
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-2,10,main]: {}
> java.lang.RuntimeException: java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2591)
> ~[main/:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_91]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> ~[main/:na]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [main/:na]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109)
> [main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> Caused by: java.lang.UnsupportedOperationException: null
> at
> org.apache.cassandra.db.marshal.AbstractType.compareCustom(AbstractType.java:174)
> ~[main/:na]
> at
> org.apache.cassandra.db.marshal.AbstractType.compare(AbstractType.java:160)
> ~[main/:na]
> at
> org.apache.cassandra.db.marshal.AbstractType.compareForCQL(AbstractType.java:204)
> ~[main/:na]
> at org.apache.cassandra.cql3.Operator.isSatisfiedBy(Operator.java:201)
> ~[main/:na]
> at
> org.apache.cassandra.db.filter.RowFilter$SimpleExpression.isSatisfiedBy(RowFilter.java:719)
> ~[main/:na]
> at
> org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToRow(RowFilter.java:324)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.BaseRows.applyOne(BaseRows.java:120)
> ~[main/:na]
> at org.apache.cassandra.db.transform.BaseRows.add(BaseRows.java:110)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.UnfilteredRows.add(UnfilteredRows.java:44)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.Transformation.add(Transformation.java:174)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.Transformation.apply(Transformation.java:140)
> ~[main/:na]
> at
> org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToPartition(RowFilter.java:307)
> ~[main/:na]
> at
> org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToPartition(RowFilter.java:292)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:96)
> ~[main/:na]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:310)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:145)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:138)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:134)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:333)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1884)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2587)
> ~[main/:na]
> ... 5 common frames omitted
> {noformat}
> 2)
> Similarly, if an index is created on the duration column:
> {noformat}
> CREATE INDEX d_index ON simplex.duration_table (d);
> SELECT * from duration_table WHERE d=1s;
> {noformat}
> results
[jira] [Updated] (CASSANDRA-13130) Strange result of several list updates in a single request
[
https://issues.apache.org/jira/browse/CASSANDRA-13130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-13130:
---
Fix Version/s: (was: 3.11.x)
(was: 4.x)
(was: 3.0.x)
(was: 2.2.x)
2.2.10
3.0.13
3.11.0
4.0
> Strange result of several list updates in a single request
> --
>
> Key: CASSANDRA-13130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13130
> Project: Cassandra
> Issue Type: Bug
>Reporter: Mikhail Krupitskiy
>Assignee: Benjamin Lerer
>Priority: Low
> Fix For: 2.2.10, 3.0.13, 3.11.0, 4.0
>
>
> Let's assume that we have a row with the 'listColumn' column and value
> \{1,2,3,4\}.
> For me it looks logical to expect that the following two pieces of code will
> ends up with the same result but it isn't so.
> Code1:
> {code}
> UPDATE t SET listColumn[2] = 7, listColumn[2] = 8 WHERE id = 1;
> {code}
> Expected result: listColumn=\{1,2,8,4\}
> Actual result: listColumn=\{1,2,7,8,4\}
> Code2:
> {code}
> UPDATE t SET listColumn[2] = 7 WHERE id = 1;
> UPDATE t SET listColumn[2] = 8 WHERE id = 1;
> {code}
> Expected result: listColumn=\{1,2,8,4\}
> Actual result: listColumn=\{1,2,8,4\}
> So the question is why Code1 and Code2 give different results?
> Looks like Code1 should give the same result as Code2.
--
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-12952) AlterTableStatement propagates base table and affected MV changes inconsistently
[
https://issues.apache.org/jira/browse/CASSANDRA-12952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-12952:
---
Fix Version/s: (was: 3.11.x)
(was: 4.x)
(was: 3.0.x)
3.0.15
3.11.1
4.0
> AlterTableStatement propagates base table and affected MV changes
> inconsistently
>
>
> Key: CASSANDRA-12952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12952
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views, Legacy/Distributed Metadata
>Reporter: Aleksey Yeschenko
>Assignee: Andrés de la Peña
>Priority: Normal
> Fix For: 3.0.15, 3.11.1, 4.0
>
>
> In {{AlterTableStatement}}, when renaming columns or changing their types, we
> also keep track of all affected MVs - ones that also need column renames or
> type changes. Then in the end we announce the migration for the table change,
> and afterwards, separately, one for each affected MV.
> This creates a window in which view definitions and base table definition are
> not in sync with each other. If a node fails in between receiving those
> pushes, it's likely to have startup issues.
> The fix is trivial: table change and affected MV change should be pushed as a
> single schema mutation.
--
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-10130) Node failure during 2i update after streaming can have incomplete 2i when restarted
[ https://issues.apache.org/jira/browse/CASSANDRA-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-10130: --- Fix Version/s: (was: 4.x) 4.0 > Node failure during 2i update after streaming can have incomplete 2i when > restarted > --- > > Key: CASSANDRA-10130 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10130 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Coordination >Reporter: Yuki Morishita >Assignee: Andrés de la Peña >Priority: Low > Fix For: 4.0 > > > Since MV/2i update happens after SSTables are received, node failure during > MV/2i update can leave received SSTables live when restarted while MV/2i are > partially up to date. > We can add some kind of tracking mechanism to automatically rebuild at the > startup, or at least warn user when the node restarts. -- 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-14214) Make it possible to change NEVER_PURGE_TOMBSTONES during runtime
[ https://issues.apache.org/jira/browse/CASSANDRA-14214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14214: --- Fix Version/s: (was: 4.x) 4.0 > Make it possible to change NEVER_PURGE_TOMBSTONES during runtime > > > Key: CASSANDRA-14214 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14214 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0 > > > If a node gets behind on compaction it could be good to be able to flip the > NEVER_PURGE_TOMBSTONES flag to speed up compactions during runtime. -- 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-14482) ZSTD Compressor support in Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-14482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14482: --- Fix Version/s: (was: 4.x) 4.0 > ZSTD Compressor support in Cassandra > > > Key: CASSANDRA-14482 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14482 > Project: Cassandra > Issue Type: New Feature > Components: Dependencies, Feature/Compression >Reporter: Sushma A Devendrappa >Assignee: Dinesh Joshi >Priority: Normal > Labels: performance, pull-request-available > Fix For: 4.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > ZStandard has a great speed and compression ratio tradeoff. > ZStandard is open source compression from Facebook. > More about ZSTD > [https://github.com/facebook/zstd] > https://code.facebook.com/posts/1658392934479273/smaller-and-faster-data-compression-with-zstandard/ > -- 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-14502) toDate() CQL function is instantiated for wrong argument type
[
https://issues.apache.org/jira/browse/CASSANDRA-14502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-14502:
---
Fix Version/s: (was: 4.x)
4.0
> toDate() CQL function is instantiated for wrong argument type
> -
>
> Key: CASSANDRA-14502
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14502
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Piotr Sarna
>Assignee: Benjamin Lerer
>Priority: Low
> Fix For: 4.0
>
> Attachments: CASSANDRA-14502.txt
>
>
> {{toDate()}} function is instantiated to work for {{timeuuid}} and {{date}}
> types passed as an argument, instead of {{timeuuid}} and {{timestamp}}, as
> stated in this documentation:
> [http://cassandra.apache.org/doc/latest/cql/functions.html#datetime-functions]
> As a result it's possible to convert a {{date}} into {{date}}, but not a
> {{timestamp}} into {{date}}, which is probably what was meant.
--
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-14619) Create fqltool compare command
[
https://issues.apache.org/jira/browse/CASSANDRA-14619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-14619:
---
Fix Version/s: (was: 4.x)
4.0
> Create fqltool compare command
> --
>
> Key: CASSANDRA-14619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14619
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Labels: fqltool
> Fix For: 4.0
>
>
> We need a {{fqltool compare}} command that can take the recorded runs from
> CASSANDRA-14618 and compares them, it should output any differences and
> potentially all queries against the mismatching partition up until the
> mismatch
--
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-14866) Issue a CQL native protocol warning if SASI indexes are enabled on a table
[ https://issues.apache.org/jira/browse/CASSANDRA-14866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14866: --- Fix Version/s: (was: 3.11.x) (was: 4.x) 3.11.5 > Issue a CQL native protocol warning if SASI indexes are enabled on a table > -- > > Key: CASSANDRA-14866 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14866 > Project: Cassandra > Issue Type: Bug > Components: Feature/SASI >Reporter: Andrés de la Peña >Assignee: Andrés de la Peña >Priority: Normal > Labels: pull-request-available > Fix For: 3.11.5, 4.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > If someone enables SASI indexes then we should return a native protocol > warning that will be printed by cqlsh saying that they are beta quality still > and you need to be careful with using them in production. > This is motivated not only by [the existing bugs and > limitations|https://issues.apache.org/jira/browse/CASSANDRA-12674?jql=project%20%3D%20CASSANDRA%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20sasi] > but for the fact that they haven't been extensively tested yet. -- 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-15007) Incorrect rf validation in SimpleStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-15007:
---
Fix Version/s: (was: 4.x)
4.0
> Incorrect rf validation in SimpleStrategy
> -
>
> Key: CASSANDRA-15007
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15007
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Michael
>Assignee: Dinesh Joshi
>Priority: Low
> Fix For: 4.0
>
> Attachments: 15007.patch
>
>
> Getting uninformative ConfigurationException when trying to create a keyspace
> with SimpleStrategy and no replication factor.
> {{cqlsh> create keyspace test with replication = \{'class':
> 'SimpleStrategy'};}}
> {{ConfigurationException:}}
--
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
