[jira] [Updated] (CASSANDRA-15303) drop column statement should not initialize timestamp because of statement cache
[
https://issues.apache.org/jira/browse/CASSANDRA-15303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-15303:
-
Fix Version/s: 4.0.x
> drop column statement should not initialize timestamp because of statement
> cache
>
>
> Key: CASSANDRA-15303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15303
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0.x
>
>
> When executing drop-column query without timestamp,
> {{AlterTableStatement#Raw}} initializes a default timestamp and then the
> prepared statement is cached. The same timestamp will be reused for the same
> drop-column query. (related to CASSANDRA-13426)
>
> The fix is to use NULL timestamp to indicate: using statement execution time
> instead.
>
> patch:
> [https://github.com/jasonstack/cassandra/commits/fix-drop-column-timestamp]
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15303) drop column statement should not initialize timestamp because of statement cache
[
https://issues.apache.org/jira/browse/CASSANDRA-15303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923899#comment-16923899
]
ZhaoYang commented on CASSANDRA-15303:
--
cc [~iamaleksey]
> drop column statement should not initialize timestamp because of statement
> cache
>
>
> Key: CASSANDRA-15303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15303
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
>
> When executing drop-column query without timestamp,
> {{AlterTableStatement#Raw}} initializes a default timestamp and then the
> prepared statement is cached. The same timestamp will be reused for the same
> drop-column query. (related to CASSANDRA-13426)
>
> The fix is to use NULL to indicate: using statement execution time instead.
>
> patch:
> [https://github.com/jasonstack/cassandra/tree/fix-drop-column-timestamp]
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15303) drop column statement should not initialize timestamp because of statement cache
[
https://issues.apache.org/jira/browse/CASSANDRA-15303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-15303:
-
Description:
When executing drop-column query without timestamp, {{AlterTableStatement#Raw}}
initializes a default timestamp and then the prepared statement is cached. The
same timestamp will be reused for the same drop-column query. (related to
CASSANDRA-13426)
The fix is to use NULL timestamp to indicate: using statement execution time
instead.
patch: [https://github.com/jasonstack/cassandra/tree/fix-drop-column-timestamp]
was:
When executing drop-column query without timestamp, {{AlterTableStatement#Raw}}
initializes a default timestamp and then the prepared statement is cached. The
same timestamp will be reused for the same drop-column query. (related to
CASSANDRA-13426)
The fix is to use NULL to indicate: using statement execution time instead.
patch: [https://github.com/jasonstack/cassandra/tree/fix-drop-column-timestamp]
> drop column statement should not initialize timestamp because of statement
> cache
>
>
> Key: CASSANDRA-15303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15303
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
>
> When executing drop-column query without timestamp,
> {{AlterTableStatement#Raw}} initializes a default timestamp and then the
> prepared statement is cached. The same timestamp will be reused for the same
> drop-column query. (related to CASSANDRA-13426)
>
> The fix is to use NULL timestamp to indicate: using statement execution time
> instead.
>
> patch:
> [https://github.com/jasonstack/cassandra/tree/fix-drop-column-timestamp]
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15303) drop column statement should not initialize timestamp because of statement cache
[
https://issues.apache.org/jira/browse/CASSANDRA-15303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-15303:
-
Description:
When executing drop-column query without timestamp, {{AlterTableStatement#Raw}}
initializes a default timestamp and then the prepared statement is cached. The
same timestamp will be reused for the same drop-column query. (related to
CASSANDRA-13426)
The fix is to use NULL timestamp to indicate: using statement execution time
instead.
patch:
[https://github.com/jasonstack/cassandra/commits/fix-drop-column-timestamp]
was:
When executing drop-column query without timestamp, {{AlterTableStatement#Raw}}
initializes a default timestamp and then the prepared statement is cached. The
same timestamp will be reused for the same drop-column query. (related to
CASSANDRA-13426)
The fix is to use NULL timestamp to indicate: using statement execution time
instead.
patch: [https://github.com/jasonstack/cassandra/tree/fix-drop-column-timestamp]
> drop column statement should not initialize timestamp because of statement
> cache
>
>
> Key: CASSANDRA-15303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15303
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
>
> When executing drop-column query without timestamp,
> {{AlterTableStatement#Raw}} initializes a default timestamp and then the
> prepared statement is cached. The same timestamp will be reused for the same
> drop-column query. (related to CASSANDRA-13426)
>
> The fix is to use NULL timestamp to indicate: using statement execution time
> instead.
>
> patch:
> [https://github.com/jasonstack/cassandra/commits/fix-drop-column-timestamp]
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15303) drop column statement should not initialize timestamp because of statement cache
ZhaoYang created CASSANDRA-15303:
Summary: drop column statement should not initialize timestamp
because of statement cache
Key: CASSANDRA-15303
URL: https://issues.apache.org/jira/browse/CASSANDRA-15303
Project: Cassandra
Issue Type: Bug
Components: CQL/Interpreter
Reporter: ZhaoYang
Assignee: ZhaoYang
When executing drop-column query without timestamp, {{AlterTableStatement#Raw}}
initializes a default timestamp and then the prepared statement is cached. The
same timestamp will be reused for the same drop-column query. (related to
CASSANDRA-13426)
The fix is to use NULL to indicate: using statement execution time instead.
patch: [https://github.com/jasonstack/cassandra/tree/fix-drop-column-timestamp]
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923898#comment-16923898 ] maxwellguo commented on CASSANDRA-15297: [~cnlwsu] hi, i just modify the message and some space issue. For my local environment got some problem ,so i just made a new PR. url : https://github.com/apache/cassandra/pull/352 > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Attachments: after-fix.jpg, image.png, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > Time Spent: 0.5h > Remaining Estimate: 0h > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923865#comment-16923865 ] maxwellguo commented on CASSANDRA-15297: Thank you for your advice, i will modify it . > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Attachments: after-fix.jpg, image.png, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > Time Spent: 10m > Remaining Estimate: 0h > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[
https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923863#comment-16923863
]
Chris Lohfink commented on CASSANDRA-15297:
---
Nitpicking there an extra trailing on string and since its just
{{File.separator}} can probably just say in message {code}"Snapshot name cannot
contain " + File.separator{code}
With that it looks good to me.
> nodetool can not create snapshot with snapshot name that have special
> character
> ---
>
> Key: CASSANDRA-15297
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15297
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: maxwellguo
>Assignee: maxwellguo
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.x
>
> Attachments: after-fix.jpg, image.png, listsnapshots-p-s.jpg,
> snapshot-listsnapshot-.jpg, snapshot-p-s.jpg
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> we make snapshot through "nodetool snapshot -t snapshotname " , when
> snapshotname contains special characters like "/", the make snapshot process
> successfully , but the result
> can be different ,when we check the data file directory or use "nodetool
> listsnapshots".
> here is some case :
> 1. nodetool snapshot -t "p/s"
> the listsnapshot resturns snapshot p for all table but actually the snapshot
> name is "p/s";
> also the data directory is like the format :
> datapath/snapshots/p/s/snapshot-datafile-link
> !snapshot-p-s.jpg!
> !listsnapshots-p-s.jpg!
> 2. nodetool snapshot -t "/"
> the listsnapshot resturns "there is not snapshot"; but the make snapshot
> process return successfully and the data directory is like the format :
> datapath/snapshots/snapshot-datafile-link
> !snapshot-listsnapshot-.jpg!
> the Attachements are the result under our environment.
> so for me , we suggest that the snapshot name should not contains special
> character. just throw exception and told the user not to use special
> character.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15297: -- Status: Changes Suggested (was: Review In Progress) > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Attachments: after-fix.jpg, image.png, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > Time Spent: 10m > Remaining Estimate: 0h > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15297: -- Reviewers: Chris Lohfink, Chris Lohfink (was: Chris Lohfink) Chris Lohfink, Chris Lohfink Status: Review In Progress (was: Patch Available) > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Attachments: after-fix.jpg, image.png, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > Time Spent: 10m > Remaining Estimate: 0h > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15297: -- Attachment: image.png > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Attachments: after-fix.jpg, image.png, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > Time Spent: 10m > Remaining Estimate: 0h > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15295) Running into deadlock when do CommitLog initialization
[
https://issues.apache.org/jira/browse/CASSANDRA-15295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923858#comment-16923858
]
Jordan West commented on CASSANDRA-15295:
-
Thanks for the report [~gzh1992n]. I was able to easily reproduce the exact
stack trace by introducing an artificial exception into the try block in
{{runMayThrow}}. This is clearly an issue with using the class from another
thread during initialization. I will take a look at your patch.
> Running into deadlock when do CommitLog initialization
> --
>
> Key: CASSANDRA-15295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15295
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
>Reporter: Zephyr Guo
>Assignee: Zephyr Guo
>Priority: Normal
> Attachments: jstack.log, pstack.log, screenshot-1.png,
> screenshot-2.png, screenshot-3.png
>
>
> Recently, I found a cassandra(3.11.4) node stuck in STARTING status for a
> long time.
> I used jstack to saw what happened. The main thread stuck in
> *AbstractCommitLogSegmentManager.awaitAvailableSegment*
> !screenshot-1.png!
> The strange thing is COMMIT-LOG-ALLOCATOR thread state was runnable but it
> was not actually running.
> !screenshot-2.png!
> And then I used pstack to troubleshoot. I found COMMIT-LOG-ALLOCATOR block on
> java class initialization.
> !screenshot-3.png!
> This is a deadlock obviously. CommitLog waits for a CommitLogSegment when
> initializing. In this moment, the CommitLog class is not initialized and the
> main thread holds the class lock. After that, COMMIT-LOG-ALLOCATOR creates a
> CommitLogSegment with exception and call *CommitLog.handleCommitError*(static
> method). COMMIT-LOG-ALLOCATOR will block on this line because CommitLog
> class is still initializing.
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15295) Running into deadlock when do CommitLog initialization
[ https://issues.apache.org/jira/browse/CASSANDRA-15295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-15295: Reviewers: Jordan West, Jordan West (was: Jordan West) Jordan West, Jordan West Status: Review In Progress (was: Patch Available) > Running into deadlock when do CommitLog initialization > -- > > Key: CASSANDRA-15295 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15295 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Zephyr Guo >Assignee: Zephyr Guo >Priority: Normal > Attachments: jstack.log, pstack.log, screenshot-1.png, > screenshot-2.png, screenshot-3.png > > > Recently, I found a cassandra(3.11.4) node stuck in STARTING status for a > long time. > I used jstack to saw what happened. The main thread stuck in > *AbstractCommitLogSegmentManager.awaitAvailableSegment* > !screenshot-1.png! > The strange thing is COMMIT-LOG-ALLOCATOR thread state was runnable but it > was not actually running. > !screenshot-2.png! > And then I used pstack to troubleshoot. I found COMMIT-LOG-ALLOCATOR block on > java class initialization. > !screenshot-3.png! > This is a deadlock obviously. CommitLog waits for a CommitLogSegment when > initializing. In this moment, the CommitLog class is not initialized and the > main thread holds the class lock. After that, COMMIT-LOG-ALLOCATOR creates a > CommitLogSegment with exception and call *CommitLog.handleCommitError*(static > method). COMMIT-LOG-ALLOCATOR will block on this line because CommitLog > class is still initializing. > > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch master updated: Fix NEWS.txt link in prepare template and use full urls in finish
This is an automated email from the ASF dual-hosted git repository.
mshuler pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git
The following commit(s) were added to refs/heads/master by this push:
new b143547 Fix NEWS.txt link in prepare template and use full urls in
finish
b143547 is described below
commit b1435471bf97cd4b19f246ea55d88277556ec973
Author: Michael Shuler
AuthorDate: Thu Sep 5 16:19:14 2019 -0700
Fix NEWS.txt link in prepare template and use full urls in finish
---
cassandra-release/finish_release.sh | 10 --
cassandra-release/prepare_release.sh | 2 +-
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/cassandra-release/finish_release.sh
b/cassandra-release/finish_release.sh
index 290e4ac..c18bacf 100755
--- a/cassandra-release/finish_release.sh
+++ b/cassandra-release/finish_release.sh
@@ -199,8 +199,8 @@ echo "This version is a bug fix release[1] on the $series
series. As always, ple
echo "" >> $mail_file
echo "Enjoy!" >> $mail_file
echo "" >> $mail_file
-echo "[1]: (CHANGES.txt)" >> $mail_file
-echo "[2]: (NEWS.txt)" >> $mail_file
+echo "[1]: CHANGES.txt
$asf_git_repo?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-$release"
>> $mail_file
+echo "[2]: NEWS.txt
$asf_git_repo?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-$release"
>> $mail_file
echo "[3]: https://issues.apache.org/jira/browse/CASSANDRA; >> $mail_file
@@ -212,10 +212,8 @@ echo " 3) upload debian repo to bintray:
./upload_bintray.sh ${artifacts_svn_dir
echo " 4) update the website (~/Git/hyde/hyde.py -g -s src/ -d publish/)" #
TODO - this is old info and needs updating..
echo " 5) update CQL doc if appropriate"
echo " 6) update wikipedia page if appropriate"
-echo " 7) send announcement email: draft in $mail_dir/mail_release_$release,
misses short links for"
-echo "> CHANGES.txt:
$asf_git_repo?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-$release"
-echo "> NEWS.txt:
$asf_git_repo?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-$release"
-echo " 8) update #cassandra topic on irc (/msg chanserv op #cassandra)"
+echo " 7) send announcement email: draft in $mail_dir/mail_release_$release"
+echo " 8) update #cassandra topic on slack"
echo " 9) tweet from @cassandra"
echo " 10) release version in JIRA"
echo " 11) remove old version from people.apache.org (in
/www/www.apache.org/dist/cassandra and debian)"
diff --git a/cassandra-release/prepare_release.sh
b/cassandra-release/prepare_release.sh
index 710006c..9a2a7ff 100755
--- a/cassandra-release/prepare_release.sh
+++ b/cassandra-release/prepare_release.sh
@@ -222,6 +222,6 @@ echo "" >> $mail_file
echo "The vote will be open for 72 hours (longer if needed)." >> $mail_file
echo "" >> $mail_file
echo "[1]: CHANGES.txt:
$asf_git_repo?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/$release-tentative"
>> $mail_file
-echo "[2]: NEWS.txt:
$asf_git_repo?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/$release-tentative"
>> $mail_file
+echo "[2]: NEWS.txt:
$asf_git_repo?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/$release-tentative"
>> $mail_file
echo "Mail written to $mail_file"
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] tag 4.0-alpha1-tentative created (now fc4381c)
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a change to tag 4.0-alpha1-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git. at fc4381c (commit) No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] tag 4.0-alpha1-tentative deleted (was 4cb90db)
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a change to tag 4.0-alpha1-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git. *** WARNING: tag 4.0-alpha1-tentative was deleted! *** was 4cb90db Use `rm -f` in rpm spec to prevent failure on missing file The revisions that were on this tag are still contained in other references; therefore, this change does not discard any commits from the repository. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Add auditlogviewer and fqltool to rpm spec
This is an automated email from the ASF dual-hosted git repository.
mshuler pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new fc4381c Add auditlogviewer and fqltool to rpm spec
fc4381c is described below
commit fc4381ca89ab39a82c9018e5171975285cc3bfe7
Author: Michael Shuler
AuthorDate: Thu Sep 5 15:07:01 2019 -0700
Add auditlogviewer and fqltool to rpm spec
---
redhat/cassandra.spec | 2 ++
1 file changed, 2 insertions(+)
diff --git a/redhat/cassandra.spec b/redhat/cassandra.spec
index 5bc77e5..ca5d38e 100644
--- a/redhat/cassandra.spec
+++ b/redhat/cassandra.spec
@@ -120,10 +120,12 @@ exit 0
%files
%defattr(0644,root,root,0755)
%doc CHANGES.txt LICENSE.txt README.asc NEWS.txt NOTICE.txt CASSANDRA-14092.txt
+%attr(755,root,root) %{_bindir}/auditlogviewer
%attr(755,root,root) %{_bindir}/cassandra-stress
%attr(755,root,root) %{_bindir}/cqlsh
%attr(755,root,root) %{_bindir}/cqlsh.py
%attr(755,root,root) %{_bindir}/debug-cql
+%attr(755,root,root) %{_bindir}/fqltool
%attr(755,root,root) %{_bindir}/nodetool
%attr(755,root,root) %{_bindir}/sstableloader
%attr(755,root,root) %{_bindir}/sstablescrub
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch master updated: We need to pull after fetch, if we're working on trunk
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git The following commit(s) were added to refs/heads/master by this push: new 00696ac We need to pull after fetch, if we're working on trunk 00696ac is described below commit 00696ac76dfb578ff5999f6679be112a757d3630 Author: Michael Shuler AuthorDate: Thu Sep 5 14:55:20 2019 -0700 We need to pull after fetch, if we're working on trunk --- docker/build-rpms.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/docker/build-rpms.sh b/docker/build-rpms.sh index 06ba980..80a94e0 100755 --- a/docker/build-rpms.sh +++ b/docker/build-rpms.sh @@ -10,6 +10,7 @@ CASSANDRA_BRANCH=$1 cd $CASSANDRA_DIR git fetch +git pull # clear and refetch tags to account for re-tagging a new sha git tag -d $(git tag) > /dev/null git fetch --tags > /dev/null 2>&1 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Define upstream_version in rpm spec to deal with s/~/-/
This is an automated email from the ASF dual-hosted git repository.
mshuler pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 13e43a0 Define upstream_version in rpm spec to deal with s/~/-/
13e43a0 is described below
commit 13e43a03086dd623b32a733c72f74993c823ce75
Author: Michael Shuler
AuthorDate: Thu Sep 5 14:49:16 2019 -0700
Define upstream_version in rpm spec to deal with s/~/-/
---
redhat/cassandra.spec | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/redhat/cassandra.spec b/redhat/cassandra.spec
index d843f4d..5bc77e5 100644
--- a/redhat/cassandra.spec
+++ b/redhat/cassandra.spec
@@ -8,7 +8,9 @@
%global username cassandra
-%define relname apache-cassandra-%{version}
+# input of ~alphaN, ~betaN, ~rcN package versions need to retain upstream
'-alphaN, etc' version for sources
+%define upstream_version %(echo %{version} | sed -r 's/~/-/g')
+%define relname apache-cassandra-%{upstream_version}
Name: cassandra
Version: %{version}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14825) Expose table schema for drivers
[ https://issues.apache.org/jira/browse/CASSANDRA-14825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923751#comment-16923751 ] Chris Lohfink commented on CASSANDRA-14825: --- I'll start a thread on mailing list. Everyone is right and there is no consensus in sight so we just need a definitive one or other we can proceed with review. > Expose table schema for drivers > --- > > Key: CASSANDRA-14825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14825 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently the drivers recreate the CQL for the tables by putting together the > system table values. This is very difficult to keep up to date and buggy > enough that its only even supported in Java and Python drivers. Cassandra > already has some limited output available for snapshots that we could provide > in a virtual table or new query that the drivers can fetch. This can greatly > reduce the complexity of drivers while also reducing bugs like > CASSANDRA-14822 as the underlying schema and properties change. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14825) Expose table schema for drivers
[ https://issues.apache.org/jira/browse/CASSANDRA-14825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923747#comment-16923747 ] Benedict edited comment on CASSANDRA-14825 at 9/5/19 9:34 PM: -- Perhaps we should break this deadlock with a non-binding vote? Possibly on the mailing list? Since there's no obvious consensus, except that we should pick one of the two, it looks set to go round in circles if we don't just pick one and go with it. was (Author: benedict): Perhaps we should break this deadlock with a non-binding vote? Possibly on the mailing list? Since nobody feels strongly, it looks set to go round in circles if we don't just pick an approach and go with it. > Expose table schema for drivers > --- > > Key: CASSANDRA-14825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14825 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently the drivers recreate the CQL for the tables by putting together the > system table values. This is very difficult to keep up to date and buggy > enough that its only even supported in Java and Python drivers. Cassandra > already has some limited output available for snapshots that we could provide > in a virtual table or new query that the drivers can fetch. This can greatly > reduce the complexity of drivers while also reducing bugs like > CASSANDRA-14822 as the underlying schema and properties change. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14825) Expose table schema for drivers
[ https://issues.apache.org/jira/browse/CASSANDRA-14825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923747#comment-16923747 ] Benedict commented on CASSANDRA-14825: -- Perhaps we should break this deadlock with a non-binding vote? Possibly on the mailing list? Since nobody feels strongly, it looks set to go round in circles if we don't just pick an approach and go with it. > Expose table schema for drivers > --- > > Key: CASSANDRA-14825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14825 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently the drivers recreate the CQL for the tables by putting together the > system table values. This is very difficult to keep up to date and buggy > enough that its only even supported in Java and Python drivers. Cassandra > already has some limited output available for snapshots that we could provide > in a virtual table or new query that the drivers can fetch. This can greatly > reduce the complexity of drivers while also reducing bugs like > CASSANDRA-14822 as the underlying schema and properties change. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch master updated: Match -alpha1, -beta1, -rc1 release versions
This is an automated email from the ASF dual-hosted git repository.
mshuler pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git
The following commit(s) were added to refs/heads/master by this push:
new b85ba12 Match -alpha1, -beta1, -rc1 release versions
b85ba12 is described below
commit b85ba129017da486aa064d615759dd3a581588d9
Author: Michael Shuler
AuthorDate: Thu Sep 5 14:17:01 2019 -0700
Match -alpha1, -beta1, -rc1 release versions
---
docker/build-rpms.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docker/build-rpms.sh b/docker/build-rpms.sh
index d2d7c17..06ba980 100755
--- a/docker/build-rpms.sh
+++ b/docker/build-rpms.sh
@@ -35,9 +35,9 @@ fi
if [ "$tag" ]; then
is_tag=true
# Official release
- regx_tag="cassandra-([0-9.]+)$"
+ regx_tag="cassandra-([0-9.].*)$"
# Tentative release
- regx_tag_tentative="([0-9.]+)-tentative$"
+ regx_tag_tentative="([0-9.].*)-tentative$"
if [[ $tag =~ $regx_tag ]] || [[ $tag =~ $regx_tag_tentative ]]; then
git_version=${BASH_REMATCH[1]}
else
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14825) Expose table schema for drivers
[
https://issues.apache.org/jira/browse/CASSANDRA-14825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923720#comment-16923720
]
Andy Tolbert edited comment on CASSANDRA-14825 at 9/5/19 8:48 PM:
--
{quote}
I think you misunderstood Robert Stupp's comment above. He's not saying we
should stick to cqlsh-based DESCRIBE, he's mentioning the alternative to the
virtual table approach of having DESCRIBE being a genuine CQL (server-side)
command, one that would return result sets (and that I describe in a number of
comments above).
{quote}
I understand what he's referencing in context of the discussion of providing
server-side {{DESCRIBE}}, that is, not cqlsh {{DESCRIBE}} support. The virtual
table approach is something that there is an available patch for that works
perfectly fine and will meet a lot of use cases, whereas server-side
{{DESCRIBE}} does not yet exist and may require more discussion. Given that
and that the virtual table implementation is rather concise(300 lines), I felt
it pragmatic to consider doing both.
was (Author: andrew.tolbert):
{quote}
I think you misunderstood Robert Stupp's comment above. He's not saying we
should stick to cqlsh-based DESCRIBE, he's mentioning the alternative to the
virtual table approach of having DESCRIBE being a genuine CQL (server-side)
command, one that would return result sets (and that I describe in a number of
comments above).
{quote}
I understand what he's referencing in context of the discussion of providing
server-side {{DESCRIBE}}, that is, not cqlsh {{DESCRIBE}}) support. The
virtual table approach is something that there is an available patch for that
works perfectly fine and will meet a lot of use cases, whereas server-side
{{DESCRIBE}} does not yet exist and may require more discussion. Given that
and that the virtual table implementation is rather concise(300 lines), I felt
it pragmatic to consider doing both.
> Expose table schema for drivers
> ---
>
> Key: CASSANDRA-14825
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14825
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently the drivers recreate the CQL for the tables by putting together the
> system table values. This is very difficult to keep up to date and buggy
> enough that its only even supported in Java and Python drivers. Cassandra
> already has some limited output available for snapshots that we could provide
> in a virtual table or new query that the drivers can fetch. This can greatly
> reduce the complexity of drivers while also reducing bugs like
> CASSANDRA-14822 as the underlying schema and properties change.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14825) Expose table schema for drivers
[
https://issues.apache.org/jira/browse/CASSANDRA-14825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923720#comment-16923720
]
Andy Tolbert commented on CASSANDRA-14825:
--
{quote}
I think you misunderstood Robert Stupp's comment above. He's not saying we
should stick to cqlsh-based DESCRIBE, he's mentioning the alternative to the
virtual table approach of having DESCRIBE being a genuine CQL (server-side)
command, one that would return result sets (and that I describe in a number of
comments above).
{quote}
I understand what he's referencing in context of the discussion of providing
server-side {{DESCRIBE}}, that is, not cqlsh {{DESCRIBE}}) support. The
virtual table approach is something that there is an available patch for that
works perfectly fine and will meet a lot of use cases, whereas server-side
{{DESCRIBE}} does not yet exist and may require more discussion. Given that
and that the virtual table implementation is rather concise(300 lines), I felt
it pragmatic to consider doing both.
> Expose table schema for drivers
> ---
>
> Key: CASSANDRA-14825
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14825
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently the drivers recreate the CQL for the tables by putting together the
> system table values. This is very difficult to keep up to date and buggy
> enough that its only even supported in Java and Python drivers. Cassandra
> already has some limited output available for snapshots that we could provide
> in a virtual table or new query that the drivers can fetch. This can greatly
> reduce the complexity of drivers while also reducing bugs like
> CASSANDRA-14822 as the underlying schema and properties change.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch master updated: Replace '-' with '~' for CASSANDRA_VERSION in rpm build
This is an automated email from the ASF dual-hosted git repository.
mshuler pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git
The following commit(s) were added to refs/heads/master by this push:
new 46764e5 Replace '-' with '~' for CASSANDRA_VERSION in rpm build
46764e5 is described below
commit 46764e56777f85a486877efb2ccc76550923a89a
Author: Michael Shuler
AuthorDate: Thu Sep 5 13:45:11 2019 -0700
Replace '-' with '~' for CASSANDRA_VERSION in rpm build
---
docker/build-rpms.sh | 4
1 file changed, 4 insertions(+)
diff --git a/docker/build-rpms.sh b/docker/build-rpms.sh
index 15a2249..d2d7c17 100755
--- a/docker/build-rpms.sh
+++ b/docker/build-rpms.sh
@@ -69,5 +69,9 @@ mkdir -p ./build/javadoc
# Artifact will only be used internally for build process and won't be found
with snapshot suffix
ant artifacts -Drelease=true
cp ./build/apache-cassandra-*-src.tar.gz ${RPM_BUILD_DIR}/SOURCES/
+
+# if CASSANDRA_VERSION is -alphaN, -betaN, -rcN, then rpmbuild fails on the
'-' char; replace with '~'
+CASSANDRA_VERSION=${CASSANDRA_VERSION/-/\~}
+
rpmbuild --define="version ${CASSANDRA_VERSION}" --define="revision
${CASSANDRA_REVISION}" -ba ./redhat/cassandra.spec
cp $RPM_BUILD_DIR/SRPMS/*.rpm $RPM_BUILD_DIR/RPMS/noarch/*.rpm $RPM_DIST_DIR
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] tag 4.0-alpha1-tentative created (now 4cb90db)
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a change to tag 4.0-alpha1-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git. at 4cb90db (commit) No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] tag 4.0-alpha1-tentative deleted (was 145f6d6)
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a change to tag 4.0-alpha1-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git. *** WARNING: tag 4.0-alpha1-tentative was deleted! *** was 145f6d6 Set base.version and changelog to 4.0-alpha1 The revisions that were on this tag are still contained in other references; therefore, this change does not discard any commits from the repository. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14825) Expose table schema for drivers
[
https://issues.apache.org/jira/browse/CASSANDRA-14825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923709#comment-16923709
]
Sylvain Lebresne commented on CASSANDRA-14825:
--
bq. but is there any reason why we can't also offer a virtual table solution?
That would mean supporting 2 different ways to do the exact same things. That's
usually not considered ideal.
bq. as it allows users to access schema via any driver, and doesn't depend on
the drivers to build schema
I think you misunderstood [~snazy]'s comment above. He's not saying we should
stick to cqlsh-based {{DESCRIBE}}, he's mentioning the alternative to the
virtual table approach of having {{DESCRIBE}} being a genuine CQL (server-side)
command, one that would return result sets (and that I describe in a number of
comments above).
This would still give users access to the schema via any driver (without any
driver change) and would not depend on the drivers to build schema.
And fwiw, I so far continue to believe that this server-side {{DESCRIBE}}
approach is, as objectively as I can put it, better than a virtual-table one.
As I've mentioned before, users already know {{DESCRIBE}} and as {{DESCRIBE}}
is not going away cqlsh-side, the virtual table approach kind of creates 2
separate ways to "describe" schema for users, which again don't feel ideal to
me.
Additionally, and that's the point [~snazy] mentioned, using a specific command
(instead of basically reusing {{SELECT}}) gives us flexibility for schema
specific stuffs much more easily. As Robert says, there is subtleties when it
comes to schema, in particular some things that are kind of "internal" (dropped
columns record, table ID, ...), but can be necessary when needing to recreate
the schema identically. So there is a (genuine afaict) need for both getting
the schema with and without those internal info (something we currently support
badly, but it's not a reason to continue doing so).
With the {{DESCRIBE}} approach, this is simple, just support some {{WITH
INTERNALS}} to decide if those "internals" are returned or not. With the
virtual table approach, not so much. Adding syntax to {{SELECT}} that is only
ever useful when querying a handful of system views is ugly.
As for the argument that virtual tables give you the "full power of SELECT", I
think it's more theoretical than anything when you look into the details. It's
not like SELECT is _that_ flexible in the first place, it's somewhat limited by
what schema we pick for the system view. And the {{DESCRIBE}} syntax already
provides 1) full schema, 2) schema of one keyspace and 3) schema of one
"object" for all our schema objects (table, types, ...). What more do we need
in practice?
> Expose table schema for drivers
> ---
>
> Key: CASSANDRA-14825
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14825
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently the drivers recreate the CQL for the tables by putting together the
> system table values. This is very difficult to keep up to date and buggy
> enough that its only even supported in Java and Python drivers. Cassandra
> already has some limited output available for snapshots that we could provide
> in a virtual table or new query that the drivers can fetch. This can greatly
> reduce the complexity of drivers while also reducing bugs like
> CASSANDRA-14822 as the underlying schema and properties change.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15146) Transitional TLS server configuration options are overly complex
[
https://issues.apache.org/jira/browse/CASSANDRA-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
M Carlise reassigned CASSANDRA-15146:
-
Assignee: M Carlise (was: Joseph Lynch)
> Transitional TLS server configuration options are overly complex
>
>
> Key: CASSANDRA-15146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15146
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption, Local/Config
>Reporter: Joseph Lynch
>Assignee: M Carlise
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
>
> It appears as part of the port from transitional client TLS to transitional
> server TLS in CASSANDRA-10404 (the ability to switch a cluster to using
> {{internode_encryption}} without listening on two ports and without downtime)
> we carried the {{enabled}} setting over from the client implementation. I
> believe that the {{enabled}} option is redundant to {{internode_encryption}}
> and {{optional}} and it should therefore be removed prior to the 4.0 release
> where we will have to start respecting that interface.
> Current trunk yaml:
> {noformat}
> server_encryption_options:
>
> # set to true for allowing secure incoming connections
>
> enabled: false
>
> # If enabled and optional are both set to true, encrypted and unencrypted
> connections are handled on the storage_port
> optional: false
>
>
>
>
> # if enabled, will open up an encrypted listening socket on
> ssl_storage_port. Should be used
> # during upgrade to 4.0; otherwise, set to false.
>
> enable_legacy_ssl_storage_port: false
>
> # on outbound connections, determine which type of peers to securely
> connect to. 'enabled' must be set to true.
> internode_encryption: none
>
> keystore: conf/.keystore
>
> keystore_password: cassandra
>
> truststore: conf/.truststore
>
> truststore_password: cassandra
> {noformat}
> I propose we eliminate {{enabled}} and just use {{optional}} and
> {{internode_encryption}} to determine the listener setup. I also propose we
> change the default of {{optional}} to true. We could also re-name
> {{optional}} since it's a new option but I think it's good to stay consistent
> with the client and use {{optional}}.
> ||optional||internode_encryption||description||
> |true|none|(default) No encryption is used but if a server reaches out with
> it we'll use it|
> |false|dc|Encryption is required for inter-dc communication, but not intra-dc|
> |false|all|Encryption is required for all communication|
> |false|none|We only listen for unencrypted connections|
> |true|dc|Encryption is used for inter-dc communication but is not required|
> |true|all|Encryption is used for all communication but is not required|
> From these states it is clear when we should be accepting TLS connections
> (all except for false and none) as well as when we must enforce it.
> To transition without downtime from an un-encrypted cluster to an encrypted
> cluster the user would do the following:
> 1. After adding valid truststores, change {{internode_encryption}} to the
> desired level of encryption (recommended {{all}}) and restart Cassandra
> 2. Change {{optional=false}} and restart Cassandra to enforce #1
> If {{optional}} defaulted to {{false}} as it does right now we'd need a third
> restart to first change {{optional}} to {{true}}, which given my
> understanding of the OptionalSslHandler isn't really relevant.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Use `rm -f` in rpm spec to prevent failure on missing file
This is an automated email from the ASF dual-hosted git repository.
mshuler pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 4cb90db Use `rm -f` in rpm spec to prevent failure on missing file
4cb90db is described below
commit 4cb90dbbd081a0b6bd5c504404badd6e0d4b3a1c
Author: Michael Shuler
AuthorDate: Thu Sep 5 13:01:53 2019 -0700
Use `rm -f` in rpm spec to prevent failure on missing file
---
redhat/cassandra.spec | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/redhat/cassandra.spec b/redhat/cassandra.spec
index eaf7565..d843f4d 100644
--- a/redhat/cassandra.spec
+++ b/redhat/cassandra.spec
@@ -74,14 +74,14 @@ patch -p1 < debian/patches/cassandra_logdir_fix.diff
sed -i 's/^# hints_directory:/hints_directory:/' conf/cassandra.yaml
# remove batch, powershell, and other files not being installed
-rm conf/*.ps1
-rm bin/*.bat
-rm bin/*.orig
-rm bin/*.ps1
-rm bin/cassandra.in.sh
-rm lib/sigar-bin/*winnt* # strip segfaults on dll..
-rm tools/bin/*.bat
-rm tools/bin/cassandra.in.sh
+rm -f conf/*.ps1
+rm -f bin/*.bat
+rm -f bin/*.orig
+rm -f bin/*.ps1
+rm -f bin/cassandra.in.sh
+rm -f lib/sigar-bin/*winnt* # strip segfaults on dll..
+rm -f tools/bin/*.bat
+rm -f tools/bin/cassandra.in.sh
# copy default configs
cp -pr conf/* %{buildroot}/%{_sysconfdir}/%{username}/default.conf/
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch master updated: Clear and refetch tags to account for re-tagging a new sha
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git The following commit(s) were added to refs/heads/master by this push: new 627a246 Clear and refetch tags to account for re-tagging a new sha 627a246 is described below commit 627a24684092fce1dcc556758d795fb250ef45e3 Author: Michael Shuler AuthorDate: Thu Sep 5 12:37:45 2019 -0700 Clear and refetch tags to account for re-tagging a new sha --- docker/build-rpms.sh | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docker/build-rpms.sh b/docker/build-rpms.sh index 8b083c9..15a2249 100755 --- a/docker/build-rpms.sh +++ b/docker/build-rpms.sh @@ -10,6 +10,9 @@ CASSANDRA_BRANCH=$1 cd $CASSANDRA_DIR git fetch +# clear and refetch tags to account for re-tagging a new sha +git tag -d $(git tag) > /dev/null +git fetch --tags > /dev/null 2>&1 git checkout $CASSANDRA_BRANCH || exit 1 # Used version for build will always depend on the git referenced used for checkout above - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] tag 4.0-alpha1-tentative created (now 145f6d6)
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a change to tag 4.0-alpha1-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git. at 145f6d6 (commit) No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] tag 4.0-alpha1-tentative deleted (was d4054e0)
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a change to tag 4.0-alpha1-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git. *** WARNING: tag 4.0-alpha1-tentative was deleted! *** was d4054e0 ninja: Fix "No newline at end of file" in c*.yaml The revisions that were on this tag are still contained in other references; therefore, this change does not discard any commits from the repository. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Set base.version and changelog to 4.0-alpha1
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new 145f6d6 Set base.version and changelog to 4.0-alpha1 145f6d6 is described below commit 145f6d6dc445276467ebe456668930f41fbf9127 Author: Michael Shuler AuthorDate: Thu Sep 5 12:06:43 2019 -0700 Set base.version and changelog to 4.0-alpha1 --- CHANGES.txt | 2 +- build.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index d6bb701..6425b1f 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,4 @@ -4.0 +4.0-alpha1 * Inaccurate exception message with nodetool snapshot (CASSANDRA-15287) * Fix InternodeOutboundMetrics overloaded bytes/count mixup (CASSANDRA-15186) * Enhance & reenable RepairTest with compression=off and compression=on (CASSANDRA-15272) diff --git a/build.xml b/build.xml index 40d2bf5..0478338 100644 --- a/build.xml +++ b/build.xml @@ -25,7 +25,7 @@ - + https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=tree"/> - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch master updated: Fix yum error with curl update
This is an automated email from the ASF dual-hosted git repository. mshuler pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git The following commit(s) were added to refs/heads/master by this push: new f6d63bb Fix yum error with curl update f6d63bb is described below commit f6d63bbe7d82f50ceda5ebb43b6e5f9edbe5e4c9 Author: Michael Shuler AuthorDate: Thu Sep 5 11:57:01 2019 -0700 Fix yum error with curl update --- docker/centos7-image.docker | 5 + 1 file changed, 5 insertions(+) diff --git a/docker/centos7-image.docker b/docker/centos7-image.docker index 1d80216..47a7e87 100644 --- a/docker/centos7-image.docker +++ b/docker/centos7-image.docker @@ -22,6 +22,11 @@ RUN yum -y install \ rpm-build \ sudo +# fix yum error after installing epel-release: +# Cannot retrieve metalink for repository: epel/x86_64. Please verify its path and try again +# https://stackoverflow.com/questions/48320850/installing-epel-repository-on-centos-7-breaks-yum-functionality +RUN yum -y update curl --disablerepo=epel + # via epel-releases RUN yum -y install python2-pip - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15302) Pool is busy (no available connection and the queue has reached its max size 256)))
debasis maity created CASSANDRA-15302: - Summary: Pool is busy (no available connection and the queue has reached its max size 256))) Key: CASSANDRA-15302 URL: https://issues.apache.org/jira/browse/CASSANDRA-15302 Project: Cassandra Issue Type: Bug Components: Cluster/Schema Reporter: debasis maity com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (tried: 192.168.11.16/192.168.11.16:9042 (com.datastax.driver.core.exceptions.BusyPoolException: [192.168.11.16/192.168.11.16] Pool is busy (no available connection and the queue has reached its max size 256))) at com.datastax.driver.core.exceptions.NoHostAvailableException.copy(NoHostAvailableException.java:83) at com.datastax.driver.core.exceptions.NoHostAvailableException.copy(NoHostAvailableException.java:37) at com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:35) at com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:293) com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (no host was tried) at com.datastax.driver.core.exceptions.NoHostAvailableException.copy(NoHostAvailableException.java:83) at com.datastax.driver.core.exceptions.NoHostAvailableException.copy(NoHostAvailableException.java:37) at com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:35) at com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:293) . We believe this has caused the caching structures in Consolidator to fall out of sync with newly provisioned devices/types, so the above error was provoked. After clearing the cache by restarting memory cache bundles, the input is WORKING CORRECTLY now. However, there are still problems related to Cassandra server, as sometimes the output doesn't work (reporting the errors like NoAvailableConnections above) etc. Please check the status of Cassandra cluster (note that the other components are also using it). nodetool status is showing fine. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14825) Expose table schema for drivers
[
https://issues.apache.org/jira/browse/CASSANDRA-14825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923580#comment-16923580
]
Andy Tolbert commented on CASSANDRA-14825:
--
I do see how {{DESCRIBE}} can have value, but is there any reason why we can't
also offer a virtual table solution? Server providing schema via a select is a
big improvement over what currently exists as it allows users to access schema
via any driver, and doesn't depend on the drivers to build schema which has had
its share of bugs. In addition, the maintenance overhead of the virtual tables
seems pretty low as the code for that is approximately 300 lines. It will
definitely have value until a {{DESCRIBE}}-like implementation is available,
and will still be useful if/when there is something like {{DESCRIBE}}. The PR
also fixes some issues in {{TableCQLHelper}} as well.
> Expose table schema for drivers
> ---
>
> Key: CASSANDRA-14825
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14825
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently the drivers recreate the CQL for the tables by putting together the
> system table values. This is very difficult to keep up to date and buggy
> enough that its only even supported in Java and Python drivers. Cassandra
> already has some limited output available for snapshots that we could provide
> in a virtual table or new query that the drivers can fetch. This can greatly
> reduce the complexity of drivers while also reducing bugs like
> CASSANDRA-14822 as the underlying schema and properties change.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14825) Expose table schema for drivers
[
https://issues.apache.org/jira/browse/CASSANDRA-14825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923531#comment-16923531
]
Robert Stupp commented on CASSANDRA-14825:
--
Sorry for being very late to the ticket here.
The benefit of {{DESCRIBE}} over {{SELECT}} is that {{DESCRIBE}} can/could emit
a complete DDL script - e.g. a script like one that lands as the {{schema.cql}}
file in a snapshot, with all the dropped-columns. This is particularly
important, when you want to get the _really compatible_ schema for a table or
keyspace in backup/restore use cases or if you intend to move some sstables to
another cluster. User could for example issue a {{DESCRIBE
SCHEMA/KEYSPACE/TABLE foobar WITH INTERNALS}} and would get a complete script
that not just contains the keyspace + table definitions including the dropped
columns but also UDTs, UDFs, UDAs.
> Expose table schema for drivers
> ---
>
> Key: CASSANDRA-14825
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14825
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently the drivers recreate the CQL for the tables by putting together the
> system table values. This is very difficult to keep up to date and buggy
> enough that its only even supported in Java and Python drivers. Cassandra
> already has some limited output available for snapshots that we could provide
> in a virtual table or new query that the drivers can fetch. This can greatly
> reduce the complexity of drivers while also reducing bugs like
> CASSANDRA-14822 as the underlying schema and properties change.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15274) Multiple Corrupt datafiles across entire environment
[
https://issues.apache.org/jira/browse/CASSANDRA-15274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920810#comment-16920810
]
Phil O Conduin edited comment on CASSANDRA-15274 at 9/5/19 2:18 PM:
Hi,
We managed to remove the CRC check from the code and build. When we do a
sstable2json on a corrupt file we are not seeing an issue with CRC.
This time it is not CRC check, but exception during an attempt to decompress
the chunk, so I think we got the answer to our question - it is not just CRC
check problem.
Another area of investigation of this issue, we decided to create a script that
generated MD5 checksums against all sstable files. This script runs from cron
twice per day and logs checksums of all sstable files.
We capture the md5 and then compare it over the lifetime fo the file. We have
proved that the md5 checksum number is not changing. This would indicate a
possible bug in Cassandra at time of compacting/writing the file.
Taking the latest file for example:
First reported in cassandra log Sep 01 08:39:48
{{Sep 01 08:39:48 hostname cassandra[16223]: ERROR 07:39:48 Failed creating a
merkle tree for repair #fb265fa0-cc8a-11e9-9296-5b5fb0093f98 on
KeyspaceMetadata/CF, (-2320162195562336336,-2318312110429971422], /x.x.x.x (see
log for details)}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: INFO 07:39:48 repair
#fb265fa0-cc8a-11e9-9296-5b5fb0093f98 Received merkle tree for CF from
/x.x.x.x}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: WARN 07:39:48 repair
#fb265fa0-cc8a-11e9-9296-5b5fb0093f98 CF sync failed}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: INFO 07:39:48 repair
#fb265fa0-cc8a-11e9-9296-5b5fb0093f98 Requesting merkle trees for
CF_RecentIndex (to [/x.x.x.x, /1x.x.x.x, /x.x.x.x, /x.x.x.x, /x.x.x.x,
/x.x.x.x])}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: ERROR 07:39:48 Exception in
thread Thread[RepairJobTask:24,5,main]}}
{{ Sep 01 08:39:48 hostname cassandra[16223]:
org.apache.cassandra.exceptions.RepairException: repair
#fb265fa0-cc8a-11e9-9296-5b5fb0093f98 on KeyspaceMetadata/CF,
(-2320162195562336336,-2318312110429971422] Validation failed in /x.x.x.x}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: at
org.apache.cassandra.repair.ValidationTask.treeReceived(ValidationTask.java:64)
~[apache-cassandra-2.2.13.jar:2.2.13]}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: at
org.apache.cassandra.repair.RepairSession.validationComplete(RepairSession.java:178)
~[apache-cassandra-2.2.13.jar:2.2.13]}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: at
org.apache.cassandra.service.ActiveRepairService.handleMessage(ActiveRepairService.java:478)
~[apache-cassandra-2.2.13.jar:2.2.13]}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: at
org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:174)
~[apache-cassandra-2.2.13.jar:2.2.13]}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:67)
~[apache-cassandra-2.2.13.jar:2.2.13]}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_172]}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: at
java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_172]}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
~[na:1.8.0_172]}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[na:1.8.0_172]}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: at
java.lang.Thread.run(Thread.java:748) [na:1.8.0_172]}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: ERROR 07:39:48 Exception in
thread Thread[ValidationExecutor:53,1,main]}}
{{ Sep 01 08:39:48 hostname cassandra[16223]:
org.apache.cassandra.io.FSReadError:
org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
/data/ssd2/data/KeyspaceMetadata/CF-1e77be609c7911e8ac12255de1fb512a/lb-26352-big-Data.db}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: at
org.apache.cassandra.io.util.RandomAccessReader.readBytes(RandomAccessReader.java:365)
~[apache-cassandra-2.2.13.jar:2.2.13]}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: at
org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:361)
~[apache-cassandra-2.2.13.jar:2.2.13]}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: at
org.apache.cassandra.utils.ByteBufferUtil.readWithLength(ByteBufferUtil.java:324)
~[apache-cassandra-2.2.13.jar:2.2.13]}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: at
org.apache.cassandra.db.ColumnSerializer.deserializeColumnBody(ColumnSerializer.java:132)
~[apache-cassandra-2.2.13.jar:2.2.13]}}
{{ Sep 01 08:39:48 hostname cassandra[16223]: at
[jira] [Comment Edited] (CASSANDRA-15274) Multiple Corrupt datafiles across entire environment
[ https://issues.apache.org/jira/browse/CASSANDRA-15274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920810#comment-16920810 ] Phil O Conduin edited comment on CASSANDRA-15274 at 9/5/19 2:17 PM: Hi, We managed to remove the CRC check from the code and build. When we do a sstable2json on a corrupt file we are not seeing an issue with CRC. This time it is not CRC check, but exception during an attempt to decompress the chunk, so I think we got the answer to our question - it is not just CRC check problem. Another area of investigation of this issue, we decided to create a script that generated MD5 checksums against all sstable files. This script runs from cron twice per day and logs checksums of all sstable files. We capture the md5 and then compare it over the lifetime fo the file. We have proved that the md5 checksum number is not changing. This would indicate a possible bug in Cassandra at time of compacting/writing the file. Taking the latest file for example: First reported in cassandra log Sep 01 08:39:48 Sep 01 08:39:48 hostname cassandra[16223]: ERROR 07:39:48 Failed creating a merkle tree for repair #fb265fa0-cc8a-11e9-9296-5b5fb0093f98 on KeyspaceMetadata/CF, (-2320162195562336336,-2318312110429971422], /x.x.x.x (see log for details) Sep 01 08:39:48 hostname cassandra[16223]: INFO 07:39:48 repair #fb265fa0-cc8a-11e9-9296-5b5fb0093f98 Received merkle tree for CF from /x.x.x.x Sep 01 08:39:48 hostname cassandra[16223]: WARN 07:39:48 repair #fb265fa0-cc8a-11e9-9296-5b5fb0093f98 CF sync failed Sep 01 08:39:48 hostname cassandra[16223]: INFO 07:39:48 repair #fb265fa0-cc8a-11e9-9296-5b5fb0093f98 Requesting merkle trees for CF_RecentIndex (to [/x.x.x.x, /1x.x.x.x, /x.x.x.x, /x.x.x.x, /x.x.x.x, /x.x.x.x]) Sep 01 08:39:48 hostname cassandra[16223]: ERROR 07:39:48 Exception in thread Thread[RepairJobTask:24,5,main] Sep 01 08:39:48 hostname cassandra[16223]: org.apache.cassandra.exceptions.RepairException: repair #fb265fa0-cc8a-11e9-9296-5b5fb0093f98 on KeyspaceMetadata/CF, (-2320162195562336336,-2318312110429971422] Validation failed in /x.x.x.x Sep 01 08:39:48 hostname cassandra[16223]: at org.apache.cassandra.repair.ValidationTask.treeReceived(ValidationTask.java:64) ~[apache-cassandra-2.2.13.jar:2.2.13] Sep 01 08:39:48 hostname cassandra[16223]: at org.apache.cassandra.repair.RepairSession.validationComplete(RepairSession.java:178) ~[apache-cassandra-2.2.13.jar:2.2.13] Sep 01 08:39:48 hostname cassandra[16223]: at org.apache.cassandra.service.ActiveRepairService.handleMessage(ActiveRepairService.java:478) ~[apache-cassandra-2.2.13.jar:2.2.13] Sep 01 08:39:48 hostname cassandra[16223]: at org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:174) ~[apache-cassandra-2.2.13.jar:2.2.13] Sep 01 08:39:48 hostname cassandra[16223]: at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:67) ~[apache-cassandra-2.2.13.jar:2.2.13] Sep 01 08:39:48 hostname cassandra[16223]: at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[na:1.8.0_172] Sep 01 08:39:48 hostname cassandra[16223]: at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_172] Sep 01 08:39:48 hostname cassandra[16223]: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[na:1.8.0_172] Sep 01 08:39:48 hostname cassandra[16223]: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_172] Sep 01 08:39:48 hostname cassandra[16223]: at java.lang.Thread.run(Thread.java:748) [na:1.8.0_172] Sep 01 08:39:48 hostname cassandra[16223]: ERROR 07:39:48 Exception in thread Thread[ValidationExecutor:53,1,main] Sep 01 08:39:48 hostname cassandra[16223]: org.apache.cassandra.io.FSReadError: org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted: /data/ssd2/data/KeyspaceMetadata/CF-1e77be609c7911e8ac12255de1fb512a/lb-26352-big-Data.db Sep 01 08:39:48 hostname cassandra[16223]: at org.apache.cassandra.io.util.RandomAccessReader.readBytes(RandomAccessReader.java:365) ~[apache-cassandra-2.2.13.jar:2.2.13] Sep 01 08:39:48 hostname cassandra[16223]: at org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:361) ~[apache-cassandra-2.2.13.jar:2.2.13] Sep 01 08:39:48 hostname cassandra[16223]: at org.apache.cassandra.utils.ByteBufferUtil.readWithLength(ByteBufferUtil.java:324) ~[apache-cassandra-2.2.13.jar:2.2.13] Sep 01 08:39:48 hostname cassandra[16223]: at org.apache.cassandra.db.ColumnSerializer.deserializeColumnBody(ColumnSerializer.java:132) ~[apache-cassandra-2.2.13.jar:2.2.13] Sep 01 08:39:48 hostname cassandra[16223]: at org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:92) ~[apache-cassandra-2.2.13.jar:2.2.13] Sep 01 08:39:48 hostname cassandra[16223]: at
[jira] [Updated] (CASSANDRA-14973) Bring v5 driver out of beta, introduce v6 before 4.0 release is cut
[ https://issues.apache.org/jira/browse/CASSANDRA-14973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated CASSANDRA-14973: -- Labels: client-impacting protocolv5 (was: ) > Bring v5 driver out of beta, introduce v6 before 4.0 release is cut > --- > > Key: CASSANDRA-14973 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14973 > Project: Cassandra > Issue Type: Task >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Urgent > Labels: client-impacting, protocolv5 > Fix For: 4.0, 4.0-rc > > > In http://issues.apache.org/jira/browse/CASSANDRA-12142, we’ve introduced > Beta flag for v5 protocol. However, up till now, v5 is in beta both in > [Cassandra|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/ProtocolVersion.java#L46] > and in > [java-driver|https://github.com/datastax/java-driver/blob/3.x/driver-core/src/main/java/com/datastax/driver/core/ProtocolVersion.java#L35]. > > Before the final 4.0 release is cut, we need to bring v5 out of beta and > finalise native protocol spec, and start bringing all new changes to v6 > protocol, which will be in beta. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay updated CASSANDRA-15299:
--
Labels: client-impacting protocolv5 (was: )
> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Labels: client-impacting, protocolv5
> Fix For: 4.0-beta
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it
> introduced checksumming/CRC32 to request and response bodies. It’s an
> important step forward, but it doesn’t cover the entire stream. In
> parcicular, the message header is not covered by a checksum or a crc, which
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of
> computing the CRC32 on the bytes written on the wire - losing the properties
> of the CRC32. In some cases, due to this sequencing, attempting to decompress
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order,
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression
> operate on individual message bodies rather than frames of multiple complete
> messages. In reality, this has several important additional downsides. To
> name a couple:
> # For compression, we are getting poor compression ratios for smaller
> messages - when operating on tiny sequences of bytes. In reality, for most
> small requests and responses we are discarding the compressed value as it’d
> be smaller than the uncompressed one - incurring both redundant allocations
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages.
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
> should switch to a framing protocol with multiple messages in a single frame.
> I suggest we reuse the framing protocol recently implemented for internode
> messaging in CASSANDRA-15066 to the extent that its logic can be borrowed,
> and that we do it before native protocol v5 graduates from beta. See
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
> and
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14688) Update protocol spec and class level doc with protocol checksumming details
[
https://issues.apache.org/jira/browse/CASSANDRA-14688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge Bay updated CASSANDRA-14688:
--
Labels: protocolv5 (was: )
> Update protocol spec and class level doc with protocol checksumming details
> ---
>
> Key: CASSANDRA-14688
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14688
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Documentation and Website
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0, 4.0-beta
>
>
> CASSANDRA-13304 provides an option to add checksumming to the frame body of
> native protocol messages. The native protocol spec needs to be updated to
> reflect this ASAP. We should also verify that the javadoc comments describing
> the on-wire format in
> {{o.a.c.transport.frame.checksum.ChecksummingTransformer}} are up to date.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch master updated (b084797 -> 893d422)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git. from b084797 Use version number we passed in as argument add 893d422 Configure so emails are sent when a build fails, becomes unstable or returns to stable, to the builds@ ML and the authors of the breakage. No new revisions were added by this update. Summary of changes: jenkins-dsl/cassandra_job_dsl_seed.groovy | 21 + 1 file changed, 21 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14825) Expose table schema for drivers
[
https://issues.apache.org/jira/browse/CASSANDRA-14825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923085#comment-16923085
]
Andy Tolbert commented on CASSANDRA-14825:
--
+1. I tried this out again and left some review comments on the [pull
request|https://github.com/apache/cassandra/pull/284]. The only non-trivial
suggestion I have is to make the topic a clustering column (i.e. {{table_name}}
in {{system_views.describe_table}} should be a clustering column) so you can
make a query such as 'show me all tables in this keyspace'. On the other hand
I can see 'give me the entire schema for this keyspace' and 'give me the schema
for this particular thing' as more valuable usecases, this would be more of a
'nice to have'.
> Expose table schema for drivers
> ---
>
> Key: CASSANDRA-14825
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14825
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently the drivers recreate the CQL for the tables by putting together the
> system table values. This is very difficult to keep up to date and buggy
> enough that its only even supported in Java and Python drivers. Cassandra
> already has some limited output available for snapshots that we could provide
> in a virtual table or new query that the drivers can fetch. This can greatly
> reduce the complexity of drivers while also reducing bugs like
> CASSANDRA-14822 as the underlying schema and properties change.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
