date:20210701



[ 
https://issues.apache.org/jira/browse/CASSANDRA-14496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17373074#comment-17373074
 ] 

Brandon Williams commented on CASSANDRA-14496:
--

Circle looks good, +1.

/cc [~marcuse]

> TWCS erroneously disabling tombstone compactions when 
> unchecked_tombstone_compaction=true
> -
>
> Key: CASSANDRA-14496
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14496
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction
>Reporter: Robert Tarrall
>Assignee: Alexander Ivakov
>Priority: Low
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> This code:
> {code:java}
> this.options = new TimeWindowCompactionStrategyOptions(options);
> if 
> (!options.containsKey(AbstractCompactionStrategy.TOMBSTONE_COMPACTION_INTERVAL_OPTION)
>  && 
> !options.containsKey(AbstractCompactionStrategy.TOMBSTONE_THRESHOLD_OPTION))
> {
> disableTombstoneCompactions = true;
> logger.debug("Disabling tombstone compactions for TWCS");
> }
> else
> logger.debug("Enabling tombstone compactions for TWCS");
> }
> {code}
> ... in TimeWindowCompactionStrategy.java disables tombstone compactions in 
> TWCS if you have not *explicitly* set either tombstone_compaction_interval or 
> tombstone_threshold.  Adding 'tombstone_compaction_interval': '86400' to the 
> compaction stanza in a table definition has the (to me unexpected) side 
> effect of enabling tombstone compactions. 
> This is surprising and does not appear to be mentioned in the docs.
> I would suggest that tombstone compactions should be run unless these options 
> are both set to 0.
> If the concern is that (as with DTCS in CASSANDRA-9234) we don't want to 
> waste time on tombstone compactions when we expect the tables to eventually 
> be expired away, perhaps we should also check unchecked_tombstone_compaction 
> and still enable tombstone compactions if that's set to true.
> May also make sense to set defaults for interval & threshold to 0 & disable 
> if they're nonzero so that setting non-default values, rather than setting 
> ANY value, is what determines whether tombstone compactions are enabled?



--
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-16781) Fix upgrade dtests (after cassandra-4.0 branch bumped to 4.0.1)



[ 
https://issues.apache.org/jira/browse/CASSANDRA-16781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17373066#comment-17373066
 ] 

Michael Semb Wever commented on CASSANDRA-16781:


{{upgrade_tests/upgrade_through_versions_test.py}} [broke a test in 
trunk|https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/396/label=cassandra-dtest,split=1/testReport/junit/dtest-upgrade.upgrade_tests.upgrade_through_versions_test/TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD/test_rolling_upgrade/].
 working on it…

> Fix upgrade dtests (after cassandra-4.0 branch bumped to 4.0.1)
> ---
>
> Key: CASSANDRA-16781
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16781
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> {noformat}
> Regression
> dtest-upgrade.upgrade_tests.paging_test.TestPagingDataNodes2RF1_Upgrade_current_4_0_x_To_indev_4_0_x.test_static_columns_paging
>  (from Cassandra dtests)
> Failing for the past 1 build (Since Unstable#116 )
> Took 46 sec.
>  Failed 1 times in the last 29 runs. Flakiness: 3%, Stability: 96%
> Error Message
> TypeError: '<' not supported between instances of 'str' and 'int'
> Stacktrace
> self =  object at 0x7f5ff1817c10>
> @since('2.0.6')
> def test_static_columns_paging(self):
> """
> Exercises paging with static columns to detect bugs
> @jira_ticket CASSANDRA-8502.
> """
> cursor = self.prepare(row_factory=named_tuple_factory)
> cursor.execute("CREATE TABLE test (a int, b int, c int, s1 int 
> static, s2 int static, PRIMARY KEY (a, b))")
> 
> for is_upgraded, cursor in self.do_upgrade(cursor, 
> row_factory=named_tuple_factory):
> >   min_version = min(self.get_node_versions())
> upgrade_tests/paging_test.py:661: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> /usr/lib/python3.8/distutils/version.py:52: in __lt__
> c = self._cmp(other)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> self = LooseVersion ('4.0-rc1'), other = LooseVersion ('4.0.1')
> def _cmp (self, other):
> if isinstance(other, str):
> other = LooseVersion(other)
> 
> if self.version == other.version:
> return 0
> >   if self.version < other.version:
> E   TypeError: '<' not supported between instances of 'str' and 'int'
> /usr/lib/python3.8/distutils/version.py:337: TypeError
> {noformat}
> from 
> https://ci-cassandra.apache.org/job/Cassandra-4.0/116/testReport/junit/dtest-upgrade.upgrade_tests.paging_test/TestPagingDataNodes2RF1_Upgrade_current_4_0_x_To_indev_4_0_x/test_static_columns_paging/
>  
> ref: https://the-asf.slack.com/archives/CK23JSY2K/p1625125464283300 



--
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-16762) Create content and UI components for new website



[ 
https://issues.apache.org/jira/browse/CASSANDRA-16762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17373063#comment-17373063
 ] 

Michael Semb Wever commented on CASSANDRA-16762:


> Will the src remain the same for both stage and prod?

That would be great if possible.

Currently you can see the differences…
https://cassandra.staged.apache.org/index.html
has
{code}
https://plausible.cassandra.apache.org/js/plausible.js";>
{code}
and
https://cassandra.apache.org/index.html
has
{code}
https://plausible.cassandra.apache.org/js/plausible.js";>
{code}


> Create content and UI components for new website
> 
>
> Key: CASSANDRA-16762
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16762
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: Anthony Grasso
>Assignee: Paul Au
>Priority: High
>
> We need create the content (asciidoc) and UI components to render the website 
> using Antora. This work can commence once the following has happened:
>  * Website and documentation proof of concept is done - CASSANDRA-16029
>  * Website design and concept is done - CASSANDRA-16115
>  * Website and document tooling is done - CASSANDRA-16066 
>  



--
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-16762) Create content and UI components for new website

2021-07-01 Thread Paul Au (Jira)



[ 
https://issues.apache.org/jira/browse/CASSANDRA-16762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17373061#comment-17373061
 ] 

Paul Au commented on CASSANDRA-16762:
-

I like going the javascript route.  Will the src remain the same for both stage 
and prod?

> Create content and UI components for new website
> 
>
> Key: CASSANDRA-16762
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16762
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: Anthony Grasso
>Assignee: Paul Au
>Priority: High
>
> We need create the content (asciidoc) and UI components to render the website 
> using Antora. This work can commence once the following has happened:
>  * Website and documentation proof of concept is done - CASSANDRA-16029
>  * Website design and concept is done - CASSANDRA-16115
>  * Website and document tooling is done - CASSANDRA-16066 
>  



--
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-14496) TWCS erroneously disabling tombstone compactions when unchecked_tombstone_compaction=true



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-14496:
-
Fix Version/s: 4.x

> TWCS erroneously disabling tombstone compactions when 
> unchecked_tombstone_compaction=true
> -
>
> Key: CASSANDRA-14496
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14496
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction
>Reporter: Robert Tarrall
>Assignee: Alexander Ivakov
>Priority: Low
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> This code:
> {code:java}
> this.options = new TimeWindowCompactionStrategyOptions(options);
> if 
> (!options.containsKey(AbstractCompactionStrategy.TOMBSTONE_COMPACTION_INTERVAL_OPTION)
>  && 
> !options.containsKey(AbstractCompactionStrategy.TOMBSTONE_THRESHOLD_OPTION))
> {
> disableTombstoneCompactions = true;
> logger.debug("Disabling tombstone compactions for TWCS");
> }
> else
> logger.debug("Enabling tombstone compactions for TWCS");
> }
> {code}
> ... in TimeWindowCompactionStrategy.java disables tombstone compactions in 
> TWCS if you have not *explicitly* set either tombstone_compaction_interval or 
> tombstone_threshold.  Adding 'tombstone_compaction_interval': '86400' to the 
> compaction stanza in a table definition has the (to me unexpected) side 
> effect of enabling tombstone compactions. 
> This is surprising and does not appear to be mentioned in the docs.
> I would suggest that tombstone compactions should be run unless these options 
> are both set to 0.
> If the concern is that (as with DTCS in CASSANDRA-9234) we don't want to 
> waste time on tombstone compactions when we expect the tables to eventually 
> be expired away, perhaps we should also check unchecked_tombstone_compaction 
> and still enable tombstone compactions if that's set to true.
> May also make sense to set defaults for interval & threshold to 0 & disable 
> if they're nonzero so that setting non-default values, rather than setting 
> ANY value, is what determines whether tombstone compactions are enabled?



--
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-14496) TWCS erroneously disabling tombstone compactions when unchecked_tombstone_compaction=true



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-14496:
-
Fix Version/s: 4.0.x
   3.11.x

> TWCS erroneously disabling tombstone compactions when 
> unchecked_tombstone_compaction=true
> -
>
> Key: CASSANDRA-14496
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14496
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction
>Reporter: Robert Tarrall
>Assignee: Alexander Ivakov
>Priority: Low
> Fix For: 3.11.x, 4.0.x
>
>
> This code:
> {code:java}
> this.options = new TimeWindowCompactionStrategyOptions(options);
> if 
> (!options.containsKey(AbstractCompactionStrategy.TOMBSTONE_COMPACTION_INTERVAL_OPTION)
>  && 
> !options.containsKey(AbstractCompactionStrategy.TOMBSTONE_THRESHOLD_OPTION))
> {
> disableTombstoneCompactions = true;
> logger.debug("Disabling tombstone compactions for TWCS");
> }
> else
> logger.debug("Enabling tombstone compactions for TWCS");
> }
> {code}
> ... in TimeWindowCompactionStrategy.java disables tombstone compactions in 
> TWCS if you have not *explicitly* set either tombstone_compaction_interval or 
> tombstone_threshold.  Adding 'tombstone_compaction_interval': '86400' to the 
> compaction stanza in a table definition has the (to me unexpected) side 
> effect of enabling tombstone compactions. 
> This is surprising and does not appear to be mentioned in the docs.
> I would suggest that tombstone compactions should be run unless these options 
> are both set to 0.
> If the concern is that (as with DTCS in CASSANDRA-9234) we don't want to 
> waste time on tombstone compactions when we expect the tables to eventually 
> be expired away, perhaps we should also check unchecked_tombstone_compaction 
> and still enable tombstone compactions if that's set to true.
> May also make sense to set defaults for interval & threshold to 0 & disable 
> if they're nonzero so that setting non-default values, rather than setting 
> ANY value, is what determines whether tombstone compactions are enabled?



--
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-14496) TWCS erroneously disabling tombstone compactions when unchecked_tombstone_compaction=true



[ 
https://issues.apache.org/jira/browse/CASSANDRA-14496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17373022#comment-17373022
 ] 

Brandon Williams commented on CASSANDRA-14496:
--

||Branch||CI||
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-14496]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-14496]|
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-14496-4.0]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-14496-4.0]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-14496-trunk]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-14496-trunk]|


> TWCS erroneously disabling tombstone compactions when 
> unchecked_tombstone_compaction=true
> -
>
> Key: CASSANDRA-14496
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14496
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction
>Reporter: Robert Tarrall
>Assignee: Alexander Ivakov
>Priority: Low
>
> This code:
> {code:java}
> this.options = new TimeWindowCompactionStrategyOptions(options);
> if 
> (!options.containsKey(AbstractCompactionStrategy.TOMBSTONE_COMPACTION_INTERVAL_OPTION)
>  && 
> !options.containsKey(AbstractCompactionStrategy.TOMBSTONE_THRESHOLD_OPTION))
> {
> disableTombstoneCompactions = true;
> logger.debug("Disabling tombstone compactions for TWCS");
> }
> else
> logger.debug("Enabling tombstone compactions for TWCS");
> }
> {code}
> ... in TimeWindowCompactionStrategy.java disables tombstone compactions in 
> TWCS if you have not *explicitly* set either tombstone_compaction_interval or 
> tombstone_threshold.  Adding 'tombstone_compaction_interval': '86400' to the 
> compaction stanza in a table definition has the (to me unexpected) side 
> effect of enabling tombstone compactions. 
> This is surprising and does not appear to be mentioned in the docs.
> I would suggest that tombstone compactions should be run unless these options 
> are both set to 0.
> If the concern is that (as with DTCS in CASSANDRA-9234) we don't want to 
> waste time on tombstone compactions when we expect the tables to eventually 
> be expired away, perhaps we should also check unchecked_tombstone_compaction 
> and still enable tombstone compactions if that's set to true.
> May also make sense to set defaults for interval & threshold to 0 & disable 
> if they're nonzero so that setting non-default values, rather than setting 
> ANY value, is what determines whether tombstone compactions are enabled?



--
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-14496) TWCS erroneously disabling tombstone compactions when unchecked_tombstone_compaction=true



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-14496:
-
Reviewers: Brandon Williams, Brandon Williams  (was: Brandon Williams)
   Brandon Williams, Brandon Williams
   Status: Review In Progress  (was: Patch Available)

> TWCS erroneously disabling tombstone compactions when 
> unchecked_tombstone_compaction=true
> -
>
> Key: CASSANDRA-14496
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14496
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction
>Reporter: Robert Tarrall
>Assignee: Alexander Ivakov
>Priority: Low
>
> This code:
> {code:java}
> this.options = new TimeWindowCompactionStrategyOptions(options);
> if 
> (!options.containsKey(AbstractCompactionStrategy.TOMBSTONE_COMPACTION_INTERVAL_OPTION)
>  && 
> !options.containsKey(AbstractCompactionStrategy.TOMBSTONE_THRESHOLD_OPTION))
> {
> disableTombstoneCompactions = true;
> logger.debug("Disabling tombstone compactions for TWCS");
> }
> else
> logger.debug("Enabling tombstone compactions for TWCS");
> }
> {code}
> ... in TimeWindowCompactionStrategy.java disables tombstone compactions in 
> TWCS if you have not *explicitly* set either tombstone_compaction_interval or 
> tombstone_threshold.  Adding 'tombstone_compaction_interval': '86400' to the 
> compaction stanza in a table definition has the (to me unexpected) side 
> effect of enabling tombstone compactions. 
> This is surprising and does not appear to be mentioned in the docs.
> I would suggest that tombstone compactions should be run unless these options 
> are both set to 0.
> If the concern is that (as with DTCS in CASSANDRA-9234) we don't want to 
> waste time on tombstone compactions when we expect the tables to eventually 
> be expired away, perhaps we should also check unchecked_tombstone_compaction 
> and still enable tombstone compactions if that's set to true.
> May also make sense to set defaults for interval & threshold to 0 & disable 
> if they're nonzero so that setting non-default values, rather than setting 
> ANY value, is what determines whether tombstone compactions are enabled?



--
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-14893) Backport CASSANDRA-10508 to 3.0 branch



[ 
https://issues.apache.org/jira/browse/CASSANDRA-14893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17373013#comment-17373013
 ] 

Brandon Williams commented on CASSANDRA-14893:
--

Actually this isn't a bugfix, so it needs approval on the ML to go into 3.0.

> Backport CASSANDRA-10508 to 3.0 branch
> --
>
> Key: CASSANDRA-14893
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14893
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Internode
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Normal
>
> With CASSANDRA-10508 we removed the hard coded SSL protocols and in favor of 
> the jvm default values in th 3.x branch. When reading through that jira it 
> looks like it was never considered to do the same change in the 3.0 branch 
> but the reasoning for the change seams just as valid for 3.0. And the issue 
> with CASSANDRA-14842 when upgrading 3.0.x->4.0 would not have happened.



--
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-14893) Backport CASSANDRA-10508 to 3.0 branch



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-14893:
-
Status: Patch Available  (was: Review In Progress)

> Backport CASSANDRA-10508 to 3.0 branch
> --
>
> Key: CASSANDRA-14893
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14893
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Internode
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Normal
>
> With CASSANDRA-10508 we removed the hard coded SSL protocols and in favor of 
> the jvm default values in th 3.x branch. When reading through that jira it 
> looks like it was never considered to do the same change in the 3.0 branch 
> but the reasoning for the change seams just as valid for 3.0. And the issue 
> with CASSANDRA-14842 when upgrading 3.0.x->4.0 would not have happened.



--
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-14893) Backport CASSANDRA-10508 to 3.0 branch



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-14893:
-
Status: Open  (was: Patch Available)

> Backport CASSANDRA-10508 to 3.0 branch
> --
>
> Key: CASSANDRA-14893
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14893
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Internode
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Normal
>
> With CASSANDRA-10508 we removed the hard coded SSL protocols and in favor of 
> the jvm default values in th 3.x branch. When reading through that jira it 
> looks like it was never considered to do the same change in the 3.0 branch 
> but the reasoning for the change seams just as valid for 3.0. And the issue 
> with CASSANDRA-14842 when upgrading 3.0.x->4.0 would not have happened.



--
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-15282) nodetool tablestats does not list bytes repaired/unrepaired



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-15282:
-
Reviewers: Brandon Williams, Marcus Eriksson  (was: Brandon Williams)

> nodetool tablestats does not list bytes repaired/unrepaired
> ---
>
> Key: CASSANDRA-15282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15282
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/nodetool
>Reporter: DeepakVohra
>Assignee: Josh Turner
>Priority: Normal
> Fix For: 4.0.1, 4.1
>
> Attachments: 15282.trunk
>
>
> According to _CASSANDRA-13774_
> _add bytes repaired/unrepaired in nodetool tablestats_
> But, only the percent is listed, and not the actual bytes with latest 4.0 
> build.
> {code:java}
> nodetool tablestats --sort local_read_count --top 3
> ...
> Percent repaired: 0.0
> ...{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-15282) nodetool tablestats does not list bytes repaired/unrepaired



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-15282:
-
  Fix Version/s: (was: 4.0.x)
 (was: 4.x)
 4.1
 4.0.1
  Since Version: 4.0-alpha1
Source Control Link: 
https://github.com/apache/cassandra/commit/d7270725a1a0807e99b1e23a2d02c38fe8ddd94a
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

CI is clean, committed.  Thank you!

> nodetool tablestats does not list bytes repaired/unrepaired
> ---
>
> Key: CASSANDRA-15282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15282
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/nodetool
>Reporter: DeepakVohra
>Assignee: Josh Turner
>Priority: Normal
> Fix For: 4.0.1, 4.1
>
> Attachments: 15282.trunk
>
>
> According to _CASSANDRA-13774_
> _add bytes repaired/unrepaired in nodetool tablestats_
> But, only the percent is listed, and not the actual bytes with latest 4.0 
> build.
> {code:java}
> nodetool tablestats --sort local_read_count --top 3
> ...
> Percent repaired: 0.0
> ...{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-15282) nodetool tablestats does not list bytes repaired/unrepaired



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-15282:
-
Status: Ready to Commit  (was: Review In Progress)

> nodetool tablestats does not list bytes repaired/unrepaired
> ---
>
> Key: CASSANDRA-15282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15282
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/nodetool
>Reporter: DeepakVohra
>Assignee: Josh Turner
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: 15282.trunk
>
>
> According to _CASSANDRA-13774_
> _add bytes repaired/unrepaired in nodetool tablestats_
> But, only the percent is listed, and not the actual bytes with latest 4.0 
> build.
> {code:java}
> nodetool tablestats --sort local_read_count --top 3
> ...
> Percent repaired: 0.0
> ...{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

[cassandra] branch trunk updated (dfc3dbc -> d5e8e81)

2021-07-01 Thread brandonwilliams

This is an automated email from the ASF dual-hosted git repository.

brandonwilliams pushed a change to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git.


from dfc3dbc  Merge branch cassandra-4.0 into trunk
 new d727072  Add repaired/unrepaired bytes back to nodetool
 new d5e8e81  Merge branch 'cassandra-4.0' into trunk

The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 CHANGES.txt|  1 +
 .../tools/nodetool/stats/TableStatsHolder.java | 14 ++
 .../tools/nodetool/stats/TableStatsPrinter.java|  6 ++
 .../tools/nodetool/stats/TableStatsPrinterTest.java| 18 ++
 4 files changed, 39 insertions(+)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] branch cassandra-4.0 updated: Add repaired/unrepaired bytes back to nodetool

2021-07-01 Thread brandonwilliams

This is an automated email from the ASF dual-hosted git repository.

brandonwilliams pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git


The following commit(s) were added to refs/heads/cassandra-4.0 by this push:
 new d727072  Add repaired/unrepaired bytes back to nodetool
d727072 is described below

commit d7270725a1a0807e99b1e23a2d02c38fe8ddd94a
Author: Josh Turner 
AuthorDate: Thu Jul 1 12:24:40 2021 -0500

Add repaired/unrepaired bytes back to nodetool

Patch by Josh Turner, reviewed by marcuse and brandonwilliams for
CASSANDRA-15282
---
 CHANGES.txt|  1 +
 .../tools/nodetool/stats/TableStatsHolder.java | 14 ++
 .../tools/nodetool/stats/TableStatsPrinter.java|  6 ++
 .../tools/nodetool/stats/TableStatsPrinterTest.java| 18 ++
 4 files changed, 39 insertions(+)

diff --git a/CHANGES.txt b/CHANGES.txt
index e976214..aa95028 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.0.1
+ * Add repaired/unrepaired bytes back to nodetool (CASSANDRA-15282)
  * Upgrade lz4-java to 1.8.0 to add RH6 support back (CASSANDRA-16753)
  * Improve DiagnosticEventService.publish(event) logging message of events 
(CASSANDRA-16749)
  * Cleanup dependency scopes (CASSANDRA-16704)
diff --git 
a/src/java/org/apache/cassandra/tools/nodetool/stats/TableStatsHolder.java 
b/src/java/org/apache/cassandra/tools/nodetool/stats/TableStatsHolder.java
index 8b9b722..b1685e6 100644
--- a/src/java/org/apache/cassandra/tools/nodetool/stats/TableStatsHolder.java
+++ b/src/java/org/apache/cassandra/tools/nodetool/stats/TableStatsHolder.java
@@ -136,6 +136,9 @@ public class TableStatsHolder implements StatsHolder
 mpTable.put("local_write_latency_ms", String.format("%01.3f", 
table.localWriteLatencyMs));
 mpTable.put("pending_flushes", table.pendingFlushes);
 mpTable.put("percent_repaired", table.percentRepaired);
+mpTable.put("bytes_repaired", table.bytesRepaired);
+mpTable.put("bytes_unrepaired", table.bytesUnrepaired);
+mpTable.put("bytes_pending_repair", table.bytesPendingRepair);
 mpTable.put("bloom_filter_false_positives", 
table.bloomFilterFalsePositives);
 mpTable.put("bloom_filter_false_ratio", String.format("%01.5f", 
table.bloomFilterFalseRatio));
 mpTable.put("bloom_filter_space_used", table.bloomFilterSpaceUsed);
@@ -241,6 +244,9 @@ public class TableStatsHolder implements StatsHolder
 Long compressionMetadataOffHeapSize = null;
 Long offHeapSize = null;
 Double percentRepaired = null;
+Long bytesRepaired = null;
+Long bytesUnrepaired = null;
+Long bytesPendingRepair = null;
 
 try
 {
@@ -250,6 +256,9 @@ public class TableStatsHolder implements StatsHolder
 compressionMetadataOffHeapSize = (Long) 
probe.getColumnFamilyMetric(keyspaceName, tableName, 
"CompressionMetadataOffHeapMemoryUsed");
 offHeapSize = memtableOffHeapSize + bloomFilterOffHeapSize 
+ indexSummaryOffHeapSize + compressionMetadataOffHeapSize;
 percentRepaired = (Double) 
probe.getColumnFamilyMetric(keyspaceName, tableName, "PercentRepaired");
+bytesRepaired = (Long) 
probe.getColumnFamilyMetric(keyspaceName, tableName, "BytesRepaired");
+bytesUnrepaired = (Long) 
probe.getColumnFamilyMetric(keyspaceName, tableName, "BytesUnrepaired");
+bytesPendingRepair = (Long) 
probe.getColumnFamilyMetric(keyspaceName, tableName, "BytesPendingRepair");
 }
 catch (RuntimeException e)
 {
@@ -271,6 +280,11 @@ public class TableStatsHolder implements StatsHolder
 {
 statsTable.percentRepaired = Math.round(100 * 
percentRepaired) / 100.0;
 }
+
+statsTable.bytesRepaired = bytesRepaired != null ? 
bytesRepaired : 0;
+statsTable.bytesUnrepaired = bytesUnrepaired != null ? 
bytesUnrepaired : 0;
+statsTable.bytesPendingRepair = bytesPendingRepair != null ? 
bytesPendingRepair : 0;
+
 statsTable.sstableCompressionRatio = 
probe.getColumnFamilyMetric(keyspaceName, tableName, "CompressionRatio");
 Object estimatedPartitionCount = 
probe.getColumnFamilyMetric(keyspaceName, tableName, "EstimatedPartitionCount");
 if (Long.valueOf(-1L).equals(estimatedPartitionCount))
diff --git 
a/src/java/org/apache/cassandra/tools/nodetool/stats/TableStatsPrinter.java 
b/src/java/org/apache/cassandra/tools/nodetool/stats/TableStatsPrinter.java
index 8c27e1e..f4188e4 100644
--- a/src/java/org/apache/cassandra/tools/nodetool/stats/TableStatsPrinter.java
+++

[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk

2021-07-01 Thread brandonwilliams

This is an automated email from the ASF dual-hosted git repository.

brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git

commit d5e8e81993311076b7c9759e864429fc500fe9c6
Merge: dfc3dbc d727072
Author: Brandon Williams 
AuthorDate: Thu Jul 1 14:27:34 2021 -0500

Merge branch 'cassandra-4.0' into trunk

 CHANGES.txt|  1 +
 .../tools/nodetool/stats/TableStatsHolder.java | 14 ++
 .../tools/nodetool/stats/TableStatsPrinter.java|  6 ++
 .../tools/nodetool/stats/TableStatsPrinterTest.java| 18 ++
 4 files changed, 39 insertions(+)

diff --cc CHANGES.txt
index bef29da,aa95028..dcfacb4
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,11 -1,7 +1,12 @@@
 -4.0.1
 +4.1
 + * Add isolated flush timer to CommitLogMetrics and ensure writes correspond 
to single WaitingOnCommit data points (CASSANDRA-16701)
 + * Add a system property to set hostId if not yet initialized 
(CASSANDRA-14582)
 + * GossiperTest.testHasVersion3Nodes didn't take into account trunk version 
changes, fixed to rely on latest version (CASSANDRA-16651)
 +Merged from 4.0:
+  * Add repaired/unrepaired bytes back to nodetool (CASSANDRA-15282)
   * Upgrade lz4-java to 1.8.0 to add RH6 support back (CASSANDRA-16753)
   * Improve DiagnosticEventService.publish(event) logging message of events 
(CASSANDRA-16749)
 + * Obfuscate passwords in statements in QueryEvents (CASSANDRA-16669)
   * Cleanup dependency scopes (CASSANDRA-16704)
   * Make JmxHistogram#getRecentValues() and JmxTimer#getRecentValues() 
thread-safe (CASSANDRA-16707)
  Merged from 3.11:

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-16666) Make SSLContext creation pluggable/extensible

2021-07-01 Thread Stefan Miklosovic (Jira)



[ 
https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17373008#comment-17373008
 ] 

Stefan Miklosovic commented on CASSANDRA-1:
---

I ve taken a look too. Added some comments to PR.

It would be awesome if we see some 3rd party implementation of this in action 
so we know it indeed works as intended. It is strange to just code up an 
interface by default logic for which it works but there isnt any (public) 
example how to do yet another impl.

> Make SSLContext creation pluggable/extensible
> -
>
> Key: CASSANDRA-1
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Internode
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.x
>
>
> Currently Cassandra creates the SSLContext via SSLFactory.java. SSLFactory is 
> a final class with static methods and not overridable. The SSLFactory loads 
> the keys and certs from the file based artifacts for the same. While this 
> works for many, in the industry where security is stricter and contextual, 
> this approach falls short. Many big organizations need flexibility to load 
> the SSL artifacts from a custom resource (like custom Key Management 
> Solution, HashiCorp Vault, Amazon KMS etc). While JSSE SecurityProvider 
> architecture allows us flexibility to build our custom mechanisms to validate 
> and process security artifacts, many times all we need is to build upon 
> Java's existing extensibility that Trust/Key Manager interfaces provide to 
> load keystores from various resources in the absence of any customized 
> requirements on the Keys/Certificate formats.
> My proposal here is to make the SSLContext creation pluggable/extensible and 
> have the current SSLFactory.java implement an extensible interface. 
> I contributed a similar change that is live now in Apache Kafka (2.6.0) - 
> https://issues.apache.org/jira/browse/KAFKA-8890 
> I can spare some time writing the pluggable interface and run by the required 
> reviewers.
>  
> Created [CEP-9: Make SSLContext creation 
> pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable]
>  
>  
> cc: [~dcapwell] [~djoshi]



--
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-13810) Overload because of hint pressure + MVs

2021-07-01 Thread Sean Fulton (Jira)

[
https://issues.apache.org/jira/browse/CASSANDRA-13810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17373006#comment-17373006
]

Sean Fulton edited comment on CASSANDRA-13810 at 7/1/21, 7:18 PM:
--

We had a similar situation and there's very little out there on how to
trouble-shoot so I wanted to append our findings here:

We have 1 cluster, 5 data centers and about 30 nodes. About a week ago, 1 node
in a 7-node DC went to a system load of 133+, and a day later 3 nodes of a
5-node DC went to a load of 133+. Only error was as above, a burst of failed to
apply hints, 0 nodes responded.

We several days on this using a variety of diagnostic tools. All we could
determine is that the load was not being generated by an application, and was
not hitting the disk. It was massive writes to the memtables that were simply
sucking up CPU resources.

Finally we took the step of shutting down hinted handoffs across the cluster,
while running htop in one of the impacted nodes. After five nodes had hints
turned off, the load on the impacted nodes all dropped to normal. Examination
of the five nodes that we had turned hints off on revealed that they had a huge
stockpile of old hints files, with an average of about 6,000 hints files per
machine.

We deleted the hints files older than 1 day and turned hinted handoff back on
(nodetool resumehandoff). Everything was fine. We turned hinted handoff back on
for all the nodes, and everything remained stable.-

Our theory is that this back-log of old hints files was being replayed onto
servers that either no longer had the data or did not need them. Also, it's
unclear whether this had anything to do with materialized views–there was a lot
of data to the MVs, but there was a lot of writing in general, so it is
difficult to tell whether the MV activity was a byproduct of the original
problem.

I will say that there was next to no diagnostic info available, even with the
logging level set to trace. The error (just like the one above), doesn't tell
anything about what hint file it was running, or even where the file originated.

I would recommend that there be debugging–at least in trace mode–that provides
the name of the hint file being processed, and where it comes from so that
users can trouble-shoot this kind of problem in the future. Had we known it was
file X coming from node Y, it would have been a simple matter to go to node Y
and realize that there were old hints files laying around that needed to be
cleaned out.

I hope this helps anyone else who runs into a problem like this.

Sean

was (Author: seantfulton):
We had a similar situation and there's very little out there on how to
trouble-shoot so I wanted to append our findings here:

Using find . -mtime +1 -print we deleted the hints files older than 1 day and
turned hinted handoff back on (nodetool resumehandoff). Everything was fine. We
turned hinted handoff back on for all the nodes, and everything remained
stable.--

[jira] [Commented] (CASSANDRA-13810) Overload because of hint pressure + MVs

2021-07-01 Thread Sean Fulton (Jira)



[ 
https://issues.apache.org/jira/browse/CASSANDRA-13810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17373006#comment-17373006
 ] 

Sean Fulton commented on CASSANDRA-13810:
-

We had a similar situation and there's very little out there on how to 
trouble-shoot so I wanted to append our findings here:

We have 1 cluster, 5 data centers and about 30 nodes. About a week ago, 1 node 
in a 7-node DC went to a system load of 133+, and a day later 3 nodes of a 
5-node DC went to a load of 133+. Only error was as above, a burst of failed to 
apply hints, 0 nodes responded.

We several days on this using a variety of diagnostic tools. All we could 
determine is that the load was not being generated by an application, and was 
not hitting the disk. It was massive writes to the memtables that were simply 
sucking up CPU resources.

Finally we took the step of shutting down hinted handoffs across the cluster, 
while running htop in one of the impacted nodes. After five nodes had hints 
turned off, the load on the impacted nodes all dropped to normal. Examination 
of the five nodes that we had turned hints off on revealed that they had a huge 
stockpile of old hints files, with an average of about 6,000 hints files per 
machine.

Using find . -mtime +1 -print  we deleted the hints files older than 1 day and 
turned hinted handoff back on (nodetool resumehandoff). Everything was fine. We 
turned hinted handoff back on for all the nodes, and everything remained 
stable.--

Our theory is that this back-log of old hints files was being replayed onto 
servers that either no longer had the data or did not need them. Also, it's 
unclear whether this had anything to do with materialized views–there was a lot 
of data to the MVs, but there was a lot of writing in general, so it is 
difficult to tell whether the MV activity was a byproduct of the original 
problem.

I will say that there was next to no diagnostic info available, even with the 
logging level set to trace. The error (just like the one above), doesn't tell 
anything about what hint file it was running, or even where the file originated.

I would recommend that there be debugging–at least in trace mode–that provides 
the name of the hint file being processed, and where it comes from so that 
users can trouble-shoot this kind of problem in the future. Had we known it was 
file X coming from node Y, it would have been a simple matter to go to node Y 
and realize that there were old hints files laying around that needed to be 
cleaned out.

 

> 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]

[jira] [Updated] (CASSANDRA-16782) Improve the way we pick sstables for STCS-in-L0 and in TWCS 'current' window



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-16782:

Fix Version/s: (was: 4.0.x)

> Improve the way we pick sstables for STCS-in-L0 and in TWCS 'current' window
> 
>
> Key: CASSANDRA-16782
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16782
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction/LCS, Local/Compaction/TWCS
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> The goal when being behind in L0 should always be to get the number of 
> sstables down to a reasonable level as soon as possible. Currently it is 
> common that we run compactions on the large sstables but leave thousands of 
> tiny sstables behind.



--
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-16779) Display bytes per level for LCS in tablestats



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-16779:

Fix Version/s: (was: 4.0.x)

> Display bytes per level for LCS in tablestats
> -
>
> Key: CASSANDRA-16779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16779
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction/LCS
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.x
>
>
> Tablestats should show the size of each level in bytes



--
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-16780) Log when writing many tombstones to a partition



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-16780:

Fix Version/s: (was: 4.0.x)

> Log when writing many tombstones to a partition
> ---
>
> Key: CASSANDRA-16780
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16780
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> Log when writing many tombstones to a partition like we do when writing a 
> large partition



--
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-16777) Flaky ViewTest

2021-07-01 Thread Jira



[ 
https://issues.apache.org/jira/browse/CASSANDRA-16777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372982#comment-17372982
 ] 

Andres de la Peña commented on CASSANDRA-16777:
---

+1 to splitting {{ViewTest}}. Perhaps we could either make the tests inherit 
from a common super class to avoid code duplication, more or less [this 
way|https://github.com/adelapena/cassandra/commit/68d7d1247a24671688e030d1275710c8f4efd84e],
 wdyt?

It seems that several MV tests can still find server-side timeouts:
 * 
[{{ViewPKTest.testPartitionKeyOnlyTable}}|https://app.circleci.com/pipelines/github/adelapena/cassandra/631/workflows/d40373e0-d85a-4a7e-b3e6-0d7aa0c599c7/jobs/6183]
 * 
[{{ViewRangesTest.testRangeTombstone}}|https://app.circleci.com/pipelines/github/adelapena/cassandra/632/workflows/82218abb-cdb8-4445-823f-70ea3762885d/jobs/6193]
 * 
[{{ViewRangesTest.testRangeTombstone}}|https://app.circleci.com/pipelines/github/adelapena/cassandra/632/workflows/82218abb-cdb8-4445-823f-70ea3762885d/jobs/6194]
 * 
[{{ViewTimesTest.ttlTest}}|https://app.circleci.com/pipelines/github/adelapena/cassandra/633/workflows/0fab87e7-26bc-457a-b742-517a04e6eca5/jobs/6198]

I think we can investigate those separately, if we are worried that they might 
be caused by something different than just an unusually slow CI run.
  

> Flaky ViewTest
> --
>
> Key: CASSANDRA-16777
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16777
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc3, 4.0, 4.0.x
>
>
> ViewTest has been 
> [failing|https://ci-cassandra.apache.org/job/Cassandra-4.0/113/testReport/junit/org.apache.cassandra.cql3/ViewTest/testFrozenCollectionsWithComplicatedInnerType/]
>  every now and then on the 4.0 line. Being so close to having 0 faky failures 
> I want to scratch that itch so I propose we split it like we did with 
> ViewComplexTest.



--
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-16780) Log when writing many tombstones to a partition



[ 
https://issues.apache.org/jira/browse/CASSANDRA-16780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372974#comment-17372974
 ] 

Brandon Williams commented on CASSANDRA-16780:
--

I don't think we can technically put this in 4.0.x unless it's considered a 
bug, unfortunately.

> Log when writing many tombstones to a partition
> ---
>
> Key: CASSANDRA-16780
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16780
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Log when writing many tombstones to a partition like we do when writing a 
> large partition



--
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-16783) Delay auth setup to after gossip has settled to avoid unavailables on startup



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-16783:

Fix Version/s: 4.0.x

> Delay auth setup to after gossip has settled to avoid unavailables on startup
> -
>
> Key: CASSANDRA-16783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16783
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> We should delay trying to do auth setup until after gossip has settled to 
> avoid getting unavailables from trying to read the auth tables before knowing 
> of any neighbours 



--
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-16780) Log when writing many tombstones to a partition



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-16780:

Fix Version/s: 4.0.x

> Log when writing many tombstones to a partition
> ---
>
> Key: CASSANDRA-16780
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16780
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Log when writing many tombstones to a partition like we do when writing a 
> large partition



--
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-16779) Display bytes per level for LCS in tablestats



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-16779:

Fix Version/s: 4.0.x

> Display bytes per level for LCS in tablestats
> -
>
> Key: CASSANDRA-16779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16779
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction/LCS
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.0.x, 4.x
>
>
> Tablestats should show the size of each level in bytes



--
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-16782) Improve the way we pick sstables for STCS-in-L0 and in TWCS 'current' window



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-16782:

Fix Version/s: 4.0.x

> Improve the way we pick sstables for STCS-in-L0 and in TWCS 'current' window
> 
>
> Key: CASSANDRA-16782
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16782
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction/LCS, Local/Compaction/TWCS
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> The goal when being behind in L0 should always be to get the number of 
> sstables down to a reasonable level as soon as possible. Currently it is 
> common that we run compactions on the large sstables but leave thousands of 
> tiny sstables behind.



--
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-15282) nodetool tablestats does not list bytes repaired/unrepaired



[ 
https://issues.apache.org/jira/browse/CASSANDRA-15282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372964#comment-17372964
 ] 

Marcus Eriksson commented on CASSANDRA-15282:
-

+1 assuming clean ci

> nodetool tablestats does not list bytes repaired/unrepaired
> ---
>
> Key: CASSANDRA-15282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15282
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/nodetool
>Reporter: DeepakVohra
>Assignee: Josh Turner
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: 15282.trunk
>
>
> According to _CASSANDRA-13774_
> _add bytes repaired/unrepaired in nodetool tablestats_
> But, only the percent is listed, and not the actual bytes with latest 4.0 
> build.
> {code:java}
> nodetool tablestats --sort local_read_count --top 3
> ...
> Percent repaired: 0.0
> ...{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-15282) nodetool tablestats does not list bytes repaired/unrepaired



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-15282:
-
Reviewers: Brandon Williams, Brandon Williams  (was: Brandon Williams)
   Brandon Williams, Brandon Williams
   Status: Review In Progress  (was: Patch Available)

> nodetool tablestats does not list bytes repaired/unrepaired
> ---
>
> Key: CASSANDRA-15282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15282
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/nodetool
>Reporter: DeepakVohra
>Assignee: Josh Turner
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: 15282.trunk
>
>
> According to _CASSANDRA-13774_
> _add bytes repaired/unrepaired in nodetool tablestats_
> But, only the percent is listed, and not the actual bytes with latest 4.0 
> build.
> {code:java}
> nodetool tablestats --sort local_read_count --top 3
> ...
> Percent repaired: 0.0
> ...{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-15282) nodetool tablestats does not list bytes repaired/unrepaired



[ 
https://issues.apache.org/jira/browse/CASSANDRA-15282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372961#comment-17372961
 ] 

Brandon Williams commented on CASSANDRA-15282:
--

||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-15282]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-15282]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-15282-trunk]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-15282-trunk]

Slightly rebased Josh's patch above.

> nodetool tablestats does not list bytes repaired/unrepaired
> ---
>
> Key: CASSANDRA-15282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15282
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/nodetool
>Reporter: DeepakVohra
>Assignee: Josh Turner
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: 15282.trunk
>
>
> According to _CASSANDRA-13774_
> _add bytes repaired/unrepaired in nodetool tablestats_
> But, only the percent is listed, and not the actual bytes with latest 4.0 
> build.
> {code:java}
> nodetool tablestats --sort local_read_count --top 3
> ...
> Percent repaired: 0.0
> ...{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-15282) nodetool tablestats does not list bytes repaired/unrepaired



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-15282:
-
Fix Version/s: 4.x
   4.0.x

> nodetool tablestats does not list bytes repaired/unrepaired
> ---
>
> Key: CASSANDRA-15282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15282
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/nodetool
>Reporter: DeepakVohra
>Assignee: Josh Turner
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: 15282.trunk
>
>
> According to _CASSANDRA-13774_
> _add bytes repaired/unrepaired in nodetool tablestats_
> But, only the percent is listed, and not the actual bytes with latest 4.0 
> build.
> {code:java}
> nodetool tablestats --sort local_read_count --top 3
> ...
> Percent repaired: 0.0
> ...{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-15098) Endpoints no longer owning tokens are not removed for vnode



[ 
https://issues.apache.org/jira/browse/CASSANDRA-15098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372950#comment-17372950
 ] 

Brandon Williams commented on CASSANDRA-15098:
--

Needs minor rebasing.

> Endpoints no longer owning tokens are not removed for vnode
> ---
>
> Key: CASSANDRA-15098
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15098
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Gossip
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> The logical here to remove endpoints no longer owning tokens is not working 
> for multiple tokens (vnode):
> https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/StorageService.java#L2505
> And it's very expensive to copy the tokenmetadata for every check.



--
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-15098) Endpoints no longer owning tokens are not removed for vnode



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-15098:
-
Fix Version/s: 4.x
   3.11.x
   3.0.x

> Endpoints no longer owning tokens are not removed for vnode
> ---
>
> Key: CASSANDRA-15098
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15098
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Gossip
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> The logical here to remove endpoints no longer owning tokens is not working 
> for multiple tokens (vnode):
> https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/StorageService.java#L2505
> And it's very expensive to copy the tokenmetadata for every check.



--
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-15098) Endpoints no longer owning tokens are not removed for vnode



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-15098:
-
Status: Open  (was: Patch Available)

> Endpoints no longer owning tokens are not removed for vnode
> ---
>
> Key: CASSANDRA-15098
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15098
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Gossip
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Normal
>
> The logical here to remove endpoints no longer owning tokens is not working 
> for multiple tokens (vnode):
> https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/service/StorageService.java#L2505
> And it's very expensive to copy the tokenmetadata for every check.



--
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-14218) Deprecate Throwables.propagate usage



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-14218:
-
Status: Open  (was: Patch Available)

> Deprecate Throwables.propagate usage
> 
>
> Key: CASSANDRA-14218
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14218
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Dependencies
>Reporter: Romain Hardouin
>Assignee: Kirk True
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: 14218-trunk.txt, 14218-trunk.txt
>
>
> Google decided to deprecate guava {{Throwables.propagate}} method:
>  * [Why we deprecated 
> Throwables.propagate|https://github.com/google/guava/wiki/Why-we-deprecated-Throwables.propagate]
>  * [Documentation 
> update|https://github.com/google/guava/wiki/ThrowablesExplained/_compare/92190ee7e37d334fa5fcdb6db8d0f43a2fdf02e1...226a3060445716d479981e606f589c99eee517ca]
> We have 35 occurences in the trunk:
> {code:java}
> $ rg -c 'Throwables.propagate' *
> src/java/org/apache/cassandra/streaming/StreamReader.java:1
> src/java/org/apache/cassandra/streaming/StreamTransferTask.java:1
> src/java/org/apache/cassandra/db/SnapshotDetailsTabularData.java:1
> src/java/org/apache/cassandra/db/Memtable.java:1
> src/java/org/apache/cassandra/db/ColumnFamilyStore.java:4
> src/java/org/apache/cassandra/cache/ChunkCache.java:2
> src/java/org/apache/cassandra/utils/WrappedRunnable.java:1
> src/java/org/apache/cassandra/hints/Hint.java:1
> src/java/org/apache/cassandra/tools/LoaderOptions.java:1
> src/java/org/apache/cassandra/tools/SSTableOfflineRelevel.java:1
> src/java/org/apache/cassandra/streaming/management/ProgressInfoCompositeData.java:3
> src/java/org/apache/cassandra/streaming/management/StreamStateCompositeData.java:2
> src/java/org/apache/cassandra/streaming/management/StreamSummaryCompositeData.java:2
> src/java/org/apache/cassandra/streaming/compress/CompressedStreamReader.java:1
> src/java/org/apache/cassandra/db/compaction/Scrubber.java:1
> src/java/org/apache/cassandra/db/compaction/Verifier.java:1
> src/java/org/apache/cassandra/db/compaction/CompactionHistoryTabularData.java:1
> src/java/org/apache/cassandra/db/compaction/Upgrader.java:1
> src/java/org/apache/cassandra/io/compress/CompressionMetadata.java:1
> src/java/org/apache/cassandra/streaming/management/SessionCompleteEventCompositeData.java:2
> src/java/org/apache/cassandra/io/sstable/SSTableSimpleWriter.java:1
> src/java/org/apache/cassandra/io/sstable/ISSTableScanner.java:1
> src/java/org/apache/cassandra/streaming/management/SessionInfoCompositeData.java:3
> src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java:1
> {code}
> I don't know if we want to remove all usages but we should at least check 
> author's intention for each usage and refactor if needed.



--
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-14218) Deprecate Throwables.propagate usage



[ 
https://issues.apache.org/jira/browse/CASSANDRA-14218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372946#comment-17372946
 ] 

Brandon Williams commented on CASSANDRA-14218:
--

Needs minimal rebasing now.

> Deprecate Throwables.propagate usage
> 
>
> Key: CASSANDRA-14218
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14218
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Dependencies
>Reporter: Romain Hardouin
>Assignee: Kirk True
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: 14218-trunk.txt, 14218-trunk.txt
>
>
> Google decided to deprecate guava {{Throwables.propagate}} method:
>  * [Why we deprecated 
> Throwables.propagate|https://github.com/google/guava/wiki/Why-we-deprecated-Throwables.propagate]
>  * [Documentation 
> update|https://github.com/google/guava/wiki/ThrowablesExplained/_compare/92190ee7e37d334fa5fcdb6db8d0f43a2fdf02e1...226a3060445716d479981e606f589c99eee517ca]
> We have 35 occurences in the trunk:
> {code:java}
> $ rg -c 'Throwables.propagate' *
> src/java/org/apache/cassandra/streaming/StreamReader.java:1
> src/java/org/apache/cassandra/streaming/StreamTransferTask.java:1
> src/java/org/apache/cassandra/db/SnapshotDetailsTabularData.java:1
> src/java/org/apache/cassandra/db/Memtable.java:1
> src/java/org/apache/cassandra/db/ColumnFamilyStore.java:4
> src/java/org/apache/cassandra/cache/ChunkCache.java:2
> src/java/org/apache/cassandra/utils/WrappedRunnable.java:1
> src/java/org/apache/cassandra/hints/Hint.java:1
> src/java/org/apache/cassandra/tools/LoaderOptions.java:1
> src/java/org/apache/cassandra/tools/SSTableOfflineRelevel.java:1
> src/java/org/apache/cassandra/streaming/management/ProgressInfoCompositeData.java:3
> src/java/org/apache/cassandra/streaming/management/StreamStateCompositeData.java:2
> src/java/org/apache/cassandra/streaming/management/StreamSummaryCompositeData.java:2
> src/java/org/apache/cassandra/streaming/compress/CompressedStreamReader.java:1
> src/java/org/apache/cassandra/db/compaction/Scrubber.java:1
> src/java/org/apache/cassandra/db/compaction/Verifier.java:1
> src/java/org/apache/cassandra/db/compaction/CompactionHistoryTabularData.java:1
> src/java/org/apache/cassandra/db/compaction/Upgrader.java:1
> src/java/org/apache/cassandra/io/compress/CompressionMetadata.java:1
> src/java/org/apache/cassandra/streaming/management/SessionCompleteEventCompositeData.java:2
> src/java/org/apache/cassandra/io/sstable/SSTableSimpleWriter.java:1
> src/java/org/apache/cassandra/io/sstable/ISSTableScanner.java:1
> src/java/org/apache/cassandra/streaming/management/SessionInfoCompositeData.java:3
> src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java:1
> {code}
> I don't know if we want to remove all usages but we should at least check 
> author's intention for each usage and refactor if needed.



--
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-13685) PartitionColumns.java:161: java.lang.AssertionError: null



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-13685:
-
Status: Open  (was: Patch Available)

> PartitionColumns.java:161: java.lang.AssertionError: null
> -
>
> Key: CASSANDRA-13685
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13685
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core, Legacy/Local Write-Read Paths
>Reporter: Jay Zhuang
>Assignee: Michael Burman
>Priority: Low
>  Labels: lhf
> Attachments: CASSANDRA-13685.patch
>
>
> Similar to CASSANDRA-8192, I guess the SSTable is corrupted:
> {noformat}
> ERROR [SSTableBatchOpen:1] 2017-07-10 21:28:09,325 CassandraDaemon.java:207 - 
> Exception in thread Thread[SSTableBatchOpen:1,5,main]
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.db.PartitionColumns$Builder.add(PartitionColumns.java:161)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:339)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:486)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:375)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader$4.run(SSTableReader.java:534)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_121]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_121]
> at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
>  [apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
> {noformat}
> Would be better to report {{CorruptSSTableException}} with SSTable path.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-12757) NPE if allocate_tokens_for_keyspace is typo/doesn't exist.



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-12757:
-
Status: Open  (was: Patch Available)

> NPE if allocate_tokens_for_keyspace is typo/doesn't exist.
> --
>
> Key: CASSANDRA-12757
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12757
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Jeremiah Jordan
>Assignee: Damien Stevenson
>Priority: Normal
>  Labels: lhf
> Fix For: 3.0.x, 3.11.x
>
>
> If the keyspace specified in allocate_tokens_for_keyspace does not exist you 
> get an NPE.  Should probably have a better error here letting people know 
> what the issue was.
> {code}
> INFO  21:07:22,582  StorageService.java:1152 - JOINING: getting bootstrap 
> token
> Exception (java.lang.NullPointerException) encountered during startup: null
> ERROR 21:07:22,590  CassandraDaemon.java:709 - Exception encountered during 
> startup
> java.lang.NullPointerException: null
>at 
> org.apache.cassandra.db.Keyspace.createReplicationStrategy(Keyspace.java:325) 
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at org.apache.cassandra.db.Keyspace.(Keyspace.java:298) 
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129) 
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106) 
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at 
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:201) 
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at 
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:173)
>  ~[cassandra-all-3.0.8:3.0.8]
> {code}



--
This message was sent by Atlassian Jira
(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-9452) Remove configuration of storage-conf from tools



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-9452:

Status: Open  (was: Patch Available)

> Remove configuration of storage-conf from tools
> ---
>
> Key: CASSANDRA-9452
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9452
> Project: Cassandra
>  Issue Type: Task
>  Components: Legacy/Testing, Legacy/Tools, Local/Config
>Reporter: Mike Adamson
>Assignee: Vinay Chella
>Priority: Low
>  Labels: 4.0-feature-freeze-review-requested, lhf
> Fix For: 4.x
>
> Attachments: CASSANDRA-14092-trunk_v1.txt, CASSANDRA-9452-trunk.txt
>
>
> The following files still making reference to storage-config and/or 
> storage-conf.xml
> * ./build.xml
> * ./bin/nodetool
> * ./bin/sstablekeys
> * ./test/resources/functions/configure_cassandra.sh
> * ./test/resources/functions/install_cassandra.sh
> * ./tools/bin/json2sstable
> * ./tools/bin/sstable2json
> * ./tools/bin/sstablelevelreset



--
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-12922) Bloom filter miss counts are not measured correctly



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-12922:
-
Status: Open  (was: Patch Available)

> Bloom filter miss counts are not measured correctly
> ---
>
> Key: CASSANDRA-12922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12922
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Local Write-Read Paths
>Reporter: Branimir Lambov
>Assignee: Sundar Srinivasan
>Priority: Normal
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: 12922-trunk.txt
>
>
> Bloom filter hits and misses are evaluated incorrectly in 
> {{BigTableReader.getPosition}}: we properly record hits, but not misses. In 
> particular, if we don't find a match for a key in the index, which is where 
> almost all non-matches will be rejected, [we don't record a bloom filter 
> false 
> positive|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/big/BigTableReader.java#L228].
> This leads to very misleading output from e.g. {{nodetool tablestats}}.



--
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-16785) Improvements to CircleCI CI/CD pipeline



[ 
https://issues.apache.org/jira/browse/CASSANDRA-16785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372929#comment-17372929
 ] 

Brandon Williams commented on CASSANDRA-16785:
--

Ping [~edimitrova]

> Improvements to CircleCI CI/CD pipeline
> ---
>
> Key: CASSANDRA-16785
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16785
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CI
>Reporter: Johanna Griffin
>Priority: Normal
> Attachments: DataStax Config Review & Combined Dynamic Config Setup 
> Workflows (2021) (2).pdf
>
>
> h1. About
> DataStax is the company [associated with Apache’s open-source 
> Cassandra|https://stackoverflow.com/questions/24564725/apache-cassandra-vs-datastax-cassandra]
>  project. 
>  
> The DataStax team requested a configuration review to do a more modern and 
> general revamp of their pipeline for the 2021 config prepared with the Setup 
> Workflows feature (setup).
>  
> GitHub Demo Repo for CircleCI Setup Workflows & Dynamic Configuration scripts 
> [here|https://github.com/CircleCI-Public/blog-dynamic-config-examples].
>  
> h1. Current Configuration & Workflow
>  
> The current state of their configuration can be found at the [Cassandra 
> open-source GitHub 
> repository|https://github.com/datastax/cassandra/tree/ds-trunk/.circleci].
>  
>  
> Because Cassandra works with users contributing to the repo who are not a 
> part of the organization, they expect these users to be able to run tests on 
> CircleCI. 
>  
> There are three tiers: Medium, Large and X-Large test tiers that users may 
> qualify to run. Right now, the process to create a valid CircleCI 
> configuration to run is complex in that it involves copying the right config 
> to the .circleci/config.yml file based on what you’re attempting to run. 
>  
> Now: config.yml.LOWRES is the default config. MIDRES and HIGHRES are custom 
> configs for those who have access to premium CircleCI resources.
> h1. Overview
> h2. Goals and Desired Outcome
> The team is looking for ways to modernize their workflow. Ideally, there is 
> one config.yml that will run various workflows based on the parameters 
> provided and contexts allowed to the team member. Updating the config master 
> should be done via GitHub and opening issues on the JIRA Board. 
>  
> Suggestions
>  # Currently the process is manual to trigger steps within the build. We'll 
> investigate the best ways to provide a more automotive experience to cut down 
> on developer time.
> Solution: setup workflows, dynamic configuration/conditional workflows and 
> [restricted 
> contexts|https://circleci.com/docs/2.0/contexts/#running-workflows-with-a-restricted-context]
>   
>  # Easy User Management: The ability for their team to add users through the 
> UI instead of needing to submit a support ticket. 
> Solution: DevOps Customer Engineering worked with the product team in 2020 to 
> add shared organization management functionality to the UI. On our roadmap 
> for 2021 is to add users via the UI. See 
>  # Tracking Test Results: Tracking test results across runs to get a 
> historical look at build times, flaky builds, etc.
> h2. Q Pause
>  # Using the LOWRES config as an example which then can be translated to the 
> other config tiers, jobs with environment variables that could be stored in 
> [Contexts as environment variables and restricted or unrestricted based on 
> user 
> team/tier|https://circleci.com/docs/2.0/contexts/#restrict-a-context-to-a-security-group-or-groups]
>  or passed as a pipeline parameters:
>  
>  * Java 8 JVM Upgrade Distributed Tests (j8_jvm_upgrade_dtests)
>  * - ANT_HOME: /usr/share/ant
>  * - JAVA11_HOME: /usr/lib/jvm/java-11-openjdk-amd64
>  * - JAVA8_HOME: /usr/lib/jvm/java-8-openjdk-amd64
>  * - LANG: en_US.UTF-8
>  * - KEEP_TEST_DIR: true
>  * - DEFAULT_DIR: /home/cassandra/cassandra-dtest
>  * - PYTHONIOENCODING: utf-8
>  * - PYTHONUNBUFFERED: true
>  * - CASS_DRIVER_NO_EXTENSIONS: true
>  * - CASS_DRIVER_NO_CYTHON: true
>  * - CASSANDRA_SKIP_SYNC: true
>  * - DTEST_REPO: git://github.com/apache/cassandra-dtest.git
>  * - DTEST_BRANCH: trunk
>  * - CCM_MAX_HEAP_SIZE: 1024M
>  * - CCM_HEAP_NEWSIZE: 256M
>  * - REPEATED_UTEST_TARGET: testsome
>  * - REPEATED_UTEST_CLASS: null
>  * - REPEATED_UTEST_METHODS: null
>  * - REPEATED_UTEST_COUNT: 100
>  * - REPEATED_UTEST_STOP_ON_FAILURE: false
>  * - REPEATED_DTEST_NAME: null
>  * - REPEATED_DTEST_VNODES: false
>  * - REPEATED_DTEST_COUNT: 100
>  * - REPEATED_DTEST_STOP_ON_FAILURE: false
>  * - JAVA_HOME: /usr/lib/jvm/java-8-openjdk-amd64
>  * - JDK_HOME: /usr/lib/jvm/java-8-openjdk-amd64
>  * Java 8 cqlsh Distributed Tests python 2 with VNodes 
>

[jira] [Updated] (CASSANDRA-10023) Emit a metric for number of local read and write calls



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-10023:
-
Status: Open  (was: Patch Available)

> Emit a metric for number of local read and write calls
> --
>
> Key: CASSANDRA-10023
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10023
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability/Metrics
>Reporter: Sankalp Kohli
>Assignee: Damien Stevenson
>Priority: Low
>  Labels: 4.0-feature-freeze-review-requested, lhf
> Fix For: 4.x
>
> Attachments: 10023-trunk-dtests.txt, 10023-trunk.txt, 
> CASSANDRA-10023.patch
>
>
> Many C* drivers have feature to be replica aware and chose the co-ordinator 
> which is a replica. We should add a metric which tells us whether all calls 
> to the co-ordinator are replica aware.
> We have seen issues where client thinks they are replica aware when they 
> forget to add routing key at various places in the 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-13855) URL Seed provider



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-13855:
-
Fix Version/s: 4.x

> URL Seed provider
> -
>
> Key: CASSANDRA-13855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13855
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Coordination, Legacy/Core
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: 0001-Add-URL-Seed-Provider-trunk.txt
>
>
> Seems like including a dead simple seed provider that can fetch from a URL, 1 
> line per seed, would be useful.



--
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-13855) URL Seed provider



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-13855:
-
Status: Open  (was: Patch Available)

> URL Seed provider
> -
>
> Key: CASSANDRA-13855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13855
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Coordination, Legacy/Core
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
>  Labels: lhf
> Attachments: 0001-Add-URL-Seed-Provider-trunk.txt
>
>
> Seems like including a dead simple seed provider that can fetch from a URL, 1 
> line per seed, would be useful.



--
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-16785) Improvements to CircleCI CI/CD pipeline

2021-07-01 Thread Johanna Griffin (Jira)



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Johanna Griffin updated CASSANDRA-16785:

Description: 
h1. About

DataStax is the company [associated with Apache’s open-source 
Cassandra|https://stackoverflow.com/questions/24564725/apache-cassandra-vs-datastax-cassandra]
 project. 

 

The DataStax team requested a configuration review to do a more modern and 
general revamp of their pipeline for the 2021 config prepared with the Setup 
Workflows feature (setup).

 

GitHub Demo Repo for CircleCI Setup Workflows & Dynamic Configuration scripts 
[here|https://github.com/CircleCI-Public/blog-dynamic-config-examples].

 
h1. Current Configuration & Workflow

 

The current state of their configuration can be found at the [Cassandra 
open-source GitHub 
repository|https://github.com/datastax/cassandra/tree/ds-trunk/.circleci].

 

 

Because Cassandra works with users contributing to the repo who are not a part 
of the organization, they expect these users to be able to run tests on 
CircleCI. 

 

There are three tiers: Medium, Large and X-Large test tiers that users may 
qualify to run. Right now, the process to create a valid CircleCI configuration 
to run is complex in that it involves copying the right config to the 
.circleci/config.yml file based on what you’re attempting to run. 

 

Now: config.yml.LOWRES is the default config. MIDRES and HIGHRES are custom 
configs for those who have access to premium CircleCI resources.
h1. Overview
h2. Goals and Desired Outcome

The team is looking for ways to modernize their workflow. Ideally, there is one 
config.yml that will run various workflows based on the parameters provided and 
contexts allowed to the team member. Updating the config master should be done 
via GitHub and opening issues on the JIRA Board. 

 

Suggestions
 # Currently the process is manual to trigger steps within the build. We'll 
investigate the best ways to provide a more automotive experience to cut down 
on developer time.

Solution: setup workflows, dynamic configuration/conditional workflows and 
[restricted 
contexts|https://circleci.com/docs/2.0/contexts/#running-workflows-with-a-restricted-context]
  
 # Easy User Management: The ability for their team to add users through the UI 
instead of needing to submit a support ticket. 

Solution: DevOps Customer Engineering worked with the product team in 2020 to 
add shared organization management functionality to the UI. On our roadmap for 
2021 is to add users via the UI. See 
 # Tracking Test Results: Tracking test results across runs to get a historical 
look at build times, flaky builds, etc.

h2. Q Pause
 # Using the LOWRES config as an example which then can be translated to the 
other config tiers, jobs with environment variables that could be stored in 
[Contexts as environment variables and restricted or unrestricted based on user 
team/tier|https://circleci.com/docs/2.0/contexts/#restrict-a-context-to-a-security-group-or-groups]
 or passed as a pipeline parameters:

 
 * Java 8 JVM Upgrade Distributed Tests (j8_jvm_upgrade_dtests)
 * - ANT_HOME: /usr/share/ant
 * - JAVA11_HOME: /usr/lib/jvm/java-11-openjdk-amd64
 * - JAVA8_HOME: /usr/lib/jvm/java-8-openjdk-amd64
 * - LANG: en_US.UTF-8
 * - KEEP_TEST_DIR: true
 * - DEFAULT_DIR: /home/cassandra/cassandra-dtest
 * - PYTHONIOENCODING: utf-8
 * - PYTHONUNBUFFERED: true
 * - CASS_DRIVER_NO_EXTENSIONS: true
 * - CASS_DRIVER_NO_CYTHON: true
 * - CASSANDRA_SKIP_SYNC: true
 * - DTEST_REPO: git://github.com/apache/cassandra-dtest.git
 * - DTEST_BRANCH: trunk
 * - CCM_MAX_HEAP_SIZE: 1024M
 * - CCM_HEAP_NEWSIZE: 256M
 * - REPEATED_UTEST_TARGET: testsome
 * - REPEATED_UTEST_CLASS: null
 * - REPEATED_UTEST_METHODS: null
 * - REPEATED_UTEST_COUNT: 100
 * - REPEATED_UTEST_STOP_ON_FAILURE: false
 * - REPEATED_DTEST_NAME: null
 * - REPEATED_DTEST_VNODES: false
 * - REPEATED_DTEST_COUNT: 100
 * - REPEATED_DTEST_STOP_ON_FAILURE: false
 * - JAVA_HOME: /usr/lib/jvm/java-8-openjdk-amd64
 * - JDK_HOME: /usr/lib/jvm/java-8-openjdk-amd64

 * Java 8 cqlsh Distributed Tests python 2 with VNodes 
[j8_cqlsh-dtests-py2-with-vnodes]
 * - ANT_HOME: /usr/share/ant
 * - JAVA11_HOME: /usr/lib/jvm/java-11-openjdk-amd64
 * - JAVA8_HOME: /usr/lib/jvm/java-8-openjdk-amd64
 * - LANG: en_US.UTF-8
 * - KEEP_TEST_DIR: true
 * - DEFAULT_DIR: /home/cassandra/cassandra-dtest
 * - PYTHONIOENCODING: utf-8
 * - PYTHONUNBUFFERED: true
 * - CASS_DRIVER_NO_EXTENSIONS: true
 * - CASS_DRIVER_NO_CYTHON: true
 * - CASSANDRA_SKIP_SYNC: true
 * - DTEST_REPO: git://github.com/apache/cassandra-dtest.git
 * - DTEST_BRANCH: trunk
 * - CCM_MAX_HEAP_SIZE: 1024M
 * - CCM_HEAP_NEWSIZE: 256M
 * - REPEATED_UTEST_TARGET: testsome
 * -

[jira] [Updated] (CASSANDRA-11990) Address rows rather than partitions in SASI



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-11990:
-
Status: Open  (was: Patch Available)

> Address rows rather than partitions in SASI
> ---
>
> Key: CASSANDRA-11990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11990
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/SASI, Legacy/CQL
>Reporter: Alex Petrov
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.x
>
> Attachments: perf.pdf, size_comparison.png
>
>
> Currently, the lookup in SASI index would return the key position of the 
> partition. After the partition lookup, the rows are iterated and the 
> operators are applied in order to filter out ones that do not match.
> bq. TokenTree which accepts variable size keys (such would enable different 
> partitioners, collections support, primary key indexing etc.), 



--
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-16760) JMXTimer exposes attributes in inconsistent time units

2021-07-01 Thread Caleb Rackliffe (Jira)



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Caleb Rackliffe updated CASSANDRA-16760:

Reviewers: Caleb Rackliffe

> JMXTimer exposes attributes in inconsistent time units
> --
>
> Key: CASSANDRA-16760
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16760
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Observability
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> JMXTimer objects are constructed with a duration time unit, which is fixed to 
> MICROSECONDS in the codebase. According to that, we should expect the time 
> values returned from the JXMTimer are in micros.
> However, the time unit is inconsistent among the JMXTimer attributes. 
> Most of the attributes such as percentiles and mean values returned are in 
> micros, except Values and RecentValues. 
> Those 2 attributes expose the raw histogram values of the underlying Timer 
> (CodaHale) and the values are fixed to be based on nanos. 
> The inconsistency leads to confusion and mis-interpretation of the values, if 
> the end user is not familiar with the implementation details. One may 
> consider the Values and RecentValues are also in micros.
> Besides the confusion, given the intention is to record the time values in 
> the micros resolution, we do not need to allocate 165 buckets in the 
> DecayingEstimatedHistogramReservoir. 165 buckets is necessary for nanos, but 
> not for micros. We can only allocate 90 buckets and it should reduce ~50% 
> memory footprint used by the Timers. 
> I'd like to propose an approach to scale the values being recorded in the 
> reservoirs used by Timers and reduce the allocation.



--
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-12106) Add ability to blacklist a CQL partition so all requests are ignored



[ 
https://issues.apache.org/jira/browse/CASSANDRA-12106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372921#comment-17372921
 ] 

Brandon Williams commented on CASSANDRA-12106:
--

Needs a rebase.  Also terms like 'blacklist' should be substituted to match 
CASSANDRA-15862.

> Add ability to blacklist a CQL partition so all requests are ignored
> 
>
> Key: CASSANDRA-12106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12106
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Legacy/Local Write-Read Paths, Local/Config
>Reporter: Geoffrey Yu
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Fix For: 4.x
>
> Attachments: 12106-trunk.txt
>
>
> Sometimes reads/writes to a given partition may cause problems due to the 
> data present. It would be useful to have a manual way to blacklist such 
> partitions so all read and write requests to them are rejected.



--
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-12106) Add ability to blacklist a CQL partition so all requests are ignored



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-12106:
-
Status: Open  (was: Patch Available)

> Add ability to blacklist a CQL partition so all requests are ignored
> 
>
> Key: CASSANDRA-12106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12106
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Legacy/Local Write-Read Paths, Local/Config
>Reporter: Geoffrey Yu
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Fix For: 4.x
>
> Attachments: 12106-trunk.txt
>
>
> Sometimes reads/writes to a given partition may cause problems due to the 
> data present. It would be useful to have a manual way to blacklist such 
> partitions so all read and write requests to them are rejected.



--
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-12766) Determine SSL for nodetool based on cassandra-env.sh



[ 
https://issues.apache.org/jira/browse/CASSANDRA-12766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372919#comment-17372919
 ] 

Brandon Williams commented on CASSANDRA-12766:
--

3.11 and 4.0 are bugfix only, moving to 4.x.  Needs to be rebased at least.

> Determine SSL for nodetool based on cassandra-env.sh
> 
>
> Key: CASSANDRA-12766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12766
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
> Environment: Linux
>Reporter: Simon Fontana Oscarsson
>Priority: Low
> Fix For: 4.x
>
> Attachments: Nodetool-read-ssl-argument-from-cassandra-env.patch
>
>
> Instead of specifying SSL with the --ssl flag we could enable SSL always when 
>  com.sun.management.jmxremote.ssl=true in cassandra-env.sh. A --no-ssl flag 
> could be useful when you don't want ssl enabled. 



--
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-12766) Determine SSL for nodetool based on cassandra-env.sh



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-12766:
-
Status: Open  (was: Patch Available)

> Determine SSL for nodetool based on cassandra-env.sh
> 
>
> Key: CASSANDRA-12766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12766
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
> Environment: Linux
>Reporter: Simon Fontana Oscarsson
>Priority: Low
> Fix For: 4.x
>
> Attachments: Nodetool-read-ssl-argument-from-cassandra-env.patch
>
>
> Instead of specifying SSL with the --ssl flag we could enable SSL always when 
>  com.sun.management.jmxremote.ssl=true in cassandra-env.sh. A --no-ssl flag 
> could be useful when you don't want ssl enabled. 



--
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-12766) Determine SSL for nodetool based on cassandra-env.sh



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-12766:
-
Fix Version/s: (was: 3.11.x)
   4.x

> Determine SSL for nodetool based on cassandra-env.sh
> 
>
> Key: CASSANDRA-12766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12766
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
> Environment: Linux
>Reporter: Simon Fontana Oscarsson
>Priority: Low
> Fix For: 4.x
>
> Attachments: Nodetool-read-ssl-argument-from-cassandra-env.patch
>
>
> Instead of specifying SSL with the --ssl flag we could enable SSL always when 
>  com.sun.management.jmxremote.ssl=true in cassandra-env.sh. A --no-ssl flag 
> could be useful when you don't want ssl enabled. 



--
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-12349) Adding some new features to cqlsh



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-12349:
-
Resolution: Won't Fix
Status: Resolved  (was: Open)

This no longer applies, so I'm closing based on Jeff's comment which I agree 
with.  If you wish to pursue this please rebase and add tests for 
consideration, and disable by default since we aren't going to change the 
default behavior this late in the game, nor rewrite all the existing cqlsh 
tests that test the restricted items.

> Adding some new features to cqlsh
> -
>
> Key: CASSANDRA-12349
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12349
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Legacy/Tools
> Environment: All
>Reporter: vin01
>Priority: Low
>  Labels: cqlsh
>
> I will like to have following features in in cqlsh, I have made a patch to 
> enable them as well.
> 1. Aliases.
> 2. Safe mode (prompt on delete,update,truncate,drop if safe_mode is true).
> 3. Press q to exit.
> Its also shared here -> 
> https://github.com/vineet01/cassandra/blob/trunk/new_features.txt
> Example for aliases :-
> cassandra@cqlsh> show 
>  ;  ALIASES  HOST SESSION  VERSION  
> cassandra@cqlsh> show ALIASES ;
> Aliases :> {'dk': 'desc keyspaces;', 'sl': 'select * from'}
> now if you type dk and press  it will auto complete it to "desc 
> keyspace".
> Adding an alias from shell :-
> cassandra@cqlsh> alias slu=select * from login.user ;
> Alias added successfully - sle:select * login.user ;
> cassandra@cqlsh> show ALIASES ;
> Aliases :> {'slu': 'select * from login.user ;', 'dk': 'desc keyspaces;', 
> 'sl': 'select * from'}
> cassandra@cqlsh> sle
> Expanded alias to> select * from login.user ;
>  username | blacklisted | lastlogin | password   
> Adding an alias directly in file :-
> aliases will be kept in same cqlshrc file.
> [aliases]
> dk = desc keyspaces;
> sl = select * from
> sle = select * from login.user ;
> now if we type just "sle" it will autocomplete rest of it and show next 
> options.
> Example of safe mode :-
> cassandra@cqlsh> truncate login.user ;
> Are you sure you want to do this? (y/n) > n
> Not performing any action.
> cassandra@cqlsh> updatee login.user set password=null;
> Are you sure you want to do this? (y/n) > 
> Not performing any action.
> Initial commit :- 
> https://github.com/vineet01/cassandra/commit/0bfce2ccfc610021a74a1f82ed24aa63e1b72fec
> Current version :- 
> https://github.com/vineet01/cassandra/blob/trunk/bin/cqlsh.py
> Please review and suggest any improvements.



--
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-12349) Adding some new features to cqlsh



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-12349:
-
Status: Open  (was: Patch Available)

> Adding some new features to cqlsh
> -
>
> Key: CASSANDRA-12349
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12349
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Legacy/Tools
> Environment: All
>Reporter: vin01
>Priority: Low
>  Labels: cqlsh
>
> I will like to have following features in in cqlsh, I have made a patch to 
> enable them as well.
> 1. Aliases.
> 2. Safe mode (prompt on delete,update,truncate,drop if safe_mode is true).
> 3. Press q to exit.
> Its also shared here -> 
> https://github.com/vineet01/cassandra/blob/trunk/new_features.txt
> Example for aliases :-
> cassandra@cqlsh> show 
>  ;  ALIASES  HOST SESSION  VERSION  
> cassandra@cqlsh> show ALIASES ;
> Aliases :> {'dk': 'desc keyspaces;', 'sl': 'select * from'}
> now if you type dk and press  it will auto complete it to "desc 
> keyspace".
> Adding an alias from shell :-
> cassandra@cqlsh> alias slu=select * from login.user ;
> Alias added successfully - sle:select * login.user ;
> cassandra@cqlsh> show ALIASES ;
> Aliases :> {'slu': 'select * from login.user ;', 'dk': 'desc keyspaces;', 
> 'sl': 'select * from'}
> cassandra@cqlsh> sle
> Expanded alias to> select * from login.user ;
>  username | blacklisted | lastlogin | password   
> Adding an alias directly in file :-
> aliases will be kept in same cqlshrc file.
> [aliases]
> dk = desc keyspaces;
> sl = select * from
> sle = select * from login.user ;
> now if we type just "sle" it will autocomplete rest of it and show next 
> options.
> Example of safe mode :-
> cassandra@cqlsh> truncate login.user ;
> Are you sure you want to do this? (y/n) > n
> Not performing any action.
> cassandra@cqlsh> updatee login.user set password=null;
> Are you sure you want to do this? (y/n) > 
> Not performing any action.
> Initial commit :- 
> https://github.com/vineet01/cassandra/commit/0bfce2ccfc610021a74a1f82ed24aa63e1b72fec
> Current version :- 
> https://github.com/vineet01/cassandra/blob/trunk/bin/cqlsh.py
> Please review and suggest any improvements.



--
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-16703) Exception thrown by custom QueryHandler constructor is ignored



[ 
https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372911#comment-17372911
 ] 

Brandon Williams commented on CASSANDRA-16703:
--

+1

> Exception thrown by custom QueryHandler constructor is ignored
> --
>
> Key: CASSANDRA-16703
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16703
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Francisco Bento
>Assignee: Zoltan Ersek
>Priority: Normal
> Attachments: 16703-trunk.txt
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> When a exception is thrown during the instantiation of the 
> _cassandra.custom_query_handler_class,_ depending on the exception thrown 
> cassandra will simply log an info message and proceed with the bootstraping 
> with the standard _QueryHandler_ as a fallback measure: 
> [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104]
> The end-user will never know if the custom _QueryHandler_ is actually 
> registered or not, unless he notices the info message on the logs.
> Ideally, the message should be logged as error and JVM should stop as it 
> cannot proceed according with the user expected configuration.
> *Scenario*:
> In our scenario, we have a custom _QueryHandler_ that receives specific 
> configuration, and we throw a _ConfigurationException_ at instantiation time 
> in case of any invalid config value. It is expected that cassandra stop the 
> bootstraping instead of skipping the QH.



--
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-16784) Conditional update on super column table returns too many rows

2021-07-01 Thread Marten Kenbeek (Jira)



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marten Kenbeek updated CASSANDRA-16784:
---
Description: 
We have a (dense) supercolumn table that we're trying to upgrade from 2.2 to 
3.x. On this table we perform conditional updates on one of the values using a 
CQL query. In 2.2 this works as expected: the query returns either a 
single-column row with {{true}}, or a two-column row with {{false}} and the 
current value.

In 3.x this query is internally rewritten to work on a map, using a 
{{Maps.SetterByKey}} operation. The update itself is applied correctly, but 
when the condition fails and the update is not applied, the query returns all 
values in the supercolumn/map instead of just the value of the subcolumn/key 
from the where clause.

In particular, since it returns _just_ the values, and not the keys/mapping, 
there's no way to know which of the values is the value of the row we're trying 
to update.

 
{code:java}
– Super column table (created through Thrift)
 CREATE TABLE store.shopping_items (
 key text,
 column1 text,
 column2 text,
 "" map,
 value text,
 PRIMARY KEY (key, column1, column2)
 ) WITH COMPACT STORAGE;
– Create some data
 cqlsh:store> INSERT INTO shopping_items (key, column1, column2, value) VALUES 
('item1', 'default', 'id', '1');
 cqlsh:store> INSERT INTO shopping_items (key, column1, column2, value) VALUES 
('item1', 'default', 'color', 'blue');
– This query returns multiple rows
 cqlsh:store> UPDATE shopping_items SET value ='2' WHERE key ='item1' AND 
column1 = 'default' AND column2 = 'id' IF value = null;
[applied] | value
 --+---
 False | 'blue'
 False | '1'
{code}
 

See the attached patch for a test that succeeds on 2.2, but fails with the 
described behavior on 3.0 and on the latest 3.11. 

  was:
We have a (dense) supercolumn table that we're trying to upgrade from 2.2 to 
3.x. On this table we perform conditional updates on one of the values using a 
CQL query. In 2.2 this works as expected: the query returns either a 
single-column row with {{true}}, or a two-column row with {{false}} and the 
current value.

In 3.x this query is internally rewritten to work on a map, using a 
{{Maps.SetterByKey}} operation. The update itself is applied correctly, but 
when the condition fails and the update is not applied, the query returns all 
values in the supercolumn/map instead of just the value of the subcolumn/key 
from the where clause.

In particular, since it returns _just_ the values, and not the keys/mapping, 
there's no way to know which of the values is the value of the row we're trying 
to update.
-- Super column table (created through Thrift)
CREATE TABLE store.shopping_items (
key text,
column1 text,
column2 text,
"" map,
value text,
PRIMARY KEY (key, column1, column2)
) WITH COMPACT STORAGE;

-- Create some data
cqlsh:store> INSERT INTO shopping_items (key, column1, column2, value) VALUES 
('item1', 'default', 'id', '1');
cqlsh:store> INSERT INTO shopping_items (key, column1, column2, value) VALUES 
('item1', 'default', 'color', 'blue');

-- This query returns multiple rows
cqlsh:store> UPDATE shopping_items SET value ='2' WHERE key ='item1' AND 
column1 = 'default' AND column2 = 'id' IF value = null;

 [applied] | value
---+
 False | 'blue'
 False |'1'
See the attached patch for a test that succeeds on 2.2, but fails with the 
described behavior on 3.0 and on the latest 3.11. 


> Conditional update on super column table returns too many rows
> --
>
> Key: CASSANDRA-16784
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16784
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Lightweight Transactions
>Reporter: Marten Kenbeek
>Priority: Normal
> Attachments: dense_supercolumn_lwt_test.patch
>
>
> We have a (dense) supercolumn table that we're trying to upgrade from 2.2 to 
> 3.x. On this table we perform conditional updates on one of the values using 
> a CQL query. In 2.2 this works as expected: the query returns either a 
> single-column row with {{true}}, or a two-column row with {{false}} and the 
> current value.
> In 3.x this query is internally rewritten to work on a map, using a 
> {{Maps.SetterByKey}} operation. The update itself is applied correctly, but 
> when the condition fails and the update is not applied, the query returns all 
> values in the supercolumn/map instead of just the value of the subcolumn/key 
> from the where clause.
> In particular, since it returns _just_ the values, and not the keys/mapping, 
> there's no way to know which of the values is the value of the row we're 
> trying to update.
>  
> {code:java}
> – Super column table (created through Thrift)
>  CREATE

[jira] [Created] (CASSANDRA-16785) Improvements to CircleCI CI/CD pipeline

2021-07-01 Thread Johanna Griffin (Jira)

Johanna Griffin created CASSANDRA-16785:
---

 Summary: Improvements to CircleCI CI/CD pipeline
 Key: CASSANDRA-16785
 URL: https://issues.apache.org/jira/browse/CASSANDRA-16785
 Project: Cassandra
  Issue Type: Improvement
  Components: CI
Reporter: Johanna Griffin
 Attachments: DataStax Config Review & Combined Dynamic Config Setup 
Workflows (2021) (2).pdf

h1. About

DataStax is the company [associated with Apache’s open-source 
Cassandra|https://stackoverflow.com/questions/24564725/apache-cassandra-vs-datastax-cassandra]
 project. 

 

The DataStax team requested a configuration review to do a more modern and 
general revamp of their pipeline for the 2021 config prepared with the Setup 
Workflows feature (setup).

 

GitHub Demo Repo for CircleCI Setup Workflows & Dynamic Configuration scripts 
[here|https://github.com/CircleCI-Public/blog-dynamic-config-examples].

 
h1. Current Configuration & Workflow

 

The current state of their configuration can be found at the [Cassandra 
open-source GitHub 
repository|https://github.com/datastax/cassandra/tree/ds-trunk/.circleci].

 

 

Because Cassandra works with users contributing to the repo who are not a part 
of the organization, they expect these users to be able to run tests on 
CircleCI. 

 

There are three tiers: Medium, Large and X-Large test tiers that users may 
qualify to run. Right now, the process to create a valid CircleCI configuration 
to run is complex in that it involves copying the right config to the 
.circleci/config.yml file based on what you’re attempting to run. 

 

Now: config.yml.LOWRES is the default config. MIDRES and HIGHRES are custom 
configs for those who have access to premium CircleCI resources.













h1. Overview
h2. Goals and Desired Outcome

The team is looking for ways to modernize their workflow. Ideally, there is one 
config.yml that will run various workflows based on the parameters provided and 
contexts allowed to the team member. Updating the config master should be done 
via GitHub and opening issues on the JIRA Board. 

 

Suggestions
 #  Currently the process is manual to trigger steps within the build. We'll 
investigate the best ways to provide a more automotive experience to cut down 
on developer time.

Solution: setup workflows, dynamic configuration/conditional workflows and 
[restricted 
contexts|https://circleci.com/docs/2.0/contexts/#running-workflows-with-a-restricted-context]
  
 #  Easy User Management: The ability for their team to add users through the 
UI instead of needing to submit a support ticket. 

Solution: DevOps Customer Engineering worked with the product team in 2020 to 
add shared organization management functionality to the UI. On our roadmap for 
2021 is to add users via the UI. See 
 #  Tracking Test Results: Tracking test results across runs to get a 
historical look at build times, flaky builds, etc.








h2. Q Pause














 # Using the LOWRES config as an example which then can be translated to the 
other config tiers, jobs with environment variables that could be stored in 
[Contexts as environment variables and restricted or unrestricted based on user 
team/tier|https://circleci.com/docs/2.0/contexts/#restrict-a-context-to-a-security-group-or-groups]
 or passed as a pipeline parameters:

 
 * Java 8 JVM Upgrade Distributed Tests (j8_jvm_upgrade_dtests)
 * - ANT_HOME: /usr/share/ant
 * - JAVA11_HOME: /usr/lib/jvm/java-11-openjdk-amd64
 * - JAVA8_HOME: /usr/lib/jvm/java-8-openjdk-amd64
 * - LANG: en_US.UTF-8
 * - KEEP_TEST_DIR: true
 * - DEFAULT_DIR: /home/cassandra/cassandra-dtest
 * - PYTHONIOENCODING: utf-8
 * - PYTHONUNBUFFERED: true
 * - CASS_DRIVER_NO_EXTENSIONS: true
 * - CASS_DRIVER_NO_CYTHON: true
 * - CASSANDRA_SKIP_SYNC: true
 * - DTEST_REPO: git://github.com/apache/cassandra-dtest.git
 * - DTEST_BRANCH: trunk
 * - CCM_MAX_HEAP_SIZE: 1024M
 * - CCM_HEAP_NEWSIZE: 256M
 * - REPEATED_UTEST_TARGET: testsome
 * - REPEATED_UTEST_CLASS: null
 * - REPEATED_UTEST_METHODS: null
 * - REPEATED_UTEST_COUNT: 100
 * - REPEATED_UTEST_STOP_ON_FAILURE: false
 * - REPEATED_DTEST_NAME: null
 * - REPEATED_DTEST_VNODES: false
 * - REPEATED_DTEST_COUNT: 100
 * - REPEATED_DTEST_STOP_ON_FAILURE: false
 * - JAVA_HOME: /usr/lib/jvm/java-8-openjdk-amd64
 * - JDK_HOME: /usr/lib/jvm/java-8-openjdk-amd64


 * Java 8 cqlsh Distributed Tests python 2 with VNodes 
[j8_cqlsh-dtests-py2-with-vnodes]
 * - ANT_HOME: /usr/share/ant
 * - JAVA11_HOME: /usr/lib/jvm/java-11-openjdk-amd64
 * - JAVA8_HOME: /usr/lib/jvm/java-8-openjdk-amd64
 * - LANG: en_US.UTF-8
 * - KEEP_TEST_DIR: true
 * - DEFAULT_DIR: /home/cassandra/cassandra-dtest
 * - PYTHONIOENCODING: utf-8
 * - PYTHONUNBUFFERED: true
 * - CASS_DRIVER_NO_EXTENSIONS:

[jira] [Created] (CASSANDRA-16784) Conditional update on super column table returns too many rows

2021-07-01 Thread Marten Kenbeek (Jira)

Marten Kenbeek created CASSANDRA-16784:
--

 Summary: Conditional update on super column table returns too many 
rows
 Key: CASSANDRA-16784
 URL: https://issues.apache.org/jira/browse/CASSANDRA-16784
 Project: Cassandra
  Issue Type: Bug
  Components: Feature/Lightweight Transactions
Reporter: Marten Kenbeek
 Attachments: dense_supercolumn_lwt_test.patch

We have a (dense) supercolumn table that we're trying to upgrade from 2.2 to 
3.x. On this table we perform conditional updates on one of the values using a 
CQL query. In 2.2 this works as expected: the query returns either a 
single-column row with {{true}}, or a two-column row with {{false}} and the 
current value.

In 3.x this query is internally rewritten to work on a map, using a 
{{Maps.SetterByKey}} operation. The update itself is applied correctly, but 
when the condition fails and the update is not applied, the query returns all 
values in the supercolumn/map instead of just the value of the subcolumn/key 
from the where clause.

In particular, since it returns _just_ the values, and not the keys/mapping, 
there's no way to know which of the values is the value of the row we're trying 
to update.
-- Super column table (created through Thrift)
CREATE TABLE store.shopping_items (
key text,
column1 text,
column2 text,
"" map,
value text,
PRIMARY KEY (key, column1, column2)
) WITH COMPACT STORAGE;

-- Create some data
cqlsh:store> INSERT INTO shopping_items (key, column1, column2, value) VALUES 
('item1', 'default', 'id', '1');
cqlsh:store> INSERT INTO shopping_items (key, column1, column2, value) VALUES 
('item1', 'default', 'color', 'blue');

-- This query returns multiple rows
cqlsh:store> UPDATE shopping_items SET value ='2' WHERE key ='item1' AND 
column1 = 'default' AND column2 = 'id' IF value = null;

 [applied] | value
---+
 False | 'blue'
 False |'1'
See the attached patch for a test that succeeds on 2.2, but fails with the 
described behavior on 3.0 and on the latest 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-10983) Metrics for tracking offending queries



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-10983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-10983:
-
Status: Open  (was: Patch Available)

> Metrics for tracking offending queries
> --
>
> Key: CASSANDRA-10983
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10983
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Observability
>Reporter: Sharvanath Pathak
>Priority: Normal
>  Labels: github-import
> Fix For: 2.1.x
>
>
> I have seen big GC pauses leading to nodes being marked DOWN in our cluster. 
> The most common issue is someone, would add a large range scan and it would 
> be difficult to pin-point the specific query. I have added a mechanism to 
> account the memory allocation for a specific query. In order to allow 
> aggregates over a period I added a metric as well. Attached is the diff.
> I was wondering if something like this would be interesting for more general 
> audience. There are some things which need to be fixed for proper release. 
> For instance, Cleaning up existing metrics on server restart. However, just 
> wanted to check before that if something like this would be useful for others.



--
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-13920) Adding regular column to COMPACT STORAGE with w/o clustering keys table causes an exception



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Lerer updated CASSANDRA-13920:
---
Resolution: Duplicate
Status: Resolved  (was: Open)

> Adding regular column to COMPACT STORAGE with w/o clustering keys table 
> causes an exception
> ---
>
> Key: CASSANDRA-13920
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13920
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core, Legacy/CQL
>Reporter: Alex Petrov
>Priority: Low
>
> When trying to {{ALTER}} a {{COMPACT TABLE}} without clustering keys (i.e. 
> non-dense one), you'll get an exception.
> Adding regular columns to non-dense compact tables should be forbidden 
> (adding static ones already fails with {{Static columns are not allowed in 
> COMPACT STORAGE tables}}), just as adding columns to dense compact tables 
> which throws {{Cannot add new column to a COMPACT STORAGE table}} (or the 
> error message should be adjusted).
> dtest to reproduce:
> {code}
> from cql_tests import CQLTester
> class StorageProxyCQLTester(CQLTester):
> def test_sparse_compact(self):
> session = self.prepare(nodes=2, rf=2)
> session.execute("CREATE TABLE sparse_compact_table (k int PRIMARY 
> KEY, v1 int, v2 int) WITH COMPACT STORAGE;")
> session.execute("ALTER TABLE sparse_compact_table ADD wat int",)
> {code}
> Exception:
> {code}
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.db.CompactTables.getCompactValueColumn(CompactTables.java:67)
>  ~[main/:na]
> at 
> org.apache.cassandra.config.CFMetaData.rebuild(CFMetaData.java:337) 
> ~[main/:na]
> at 
> org.apache.cassandra.config.CFMetaData.validate(CFMetaData.java:935) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.MigrationManager.announceColumnFamilyUpdate(MigrationManager.java:421)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.AlterTableStatement.announceMigration(AlterTableStatement.java:288)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(SchemaAlteringStatement.java:93)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:237) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:222) 
> ~[main/:na]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [main/:na]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:357)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:348)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_121]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [main/:na]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
> {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-14564) issue while adding a column in a table with compact storage



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Lerer updated CASSANDRA-14564:
---
Fix Version/s: 4.0.x
   3.0.x

> issue while adding a column in a table with compact storage   
> --
>
> Key: CASSANDRA-14564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14564
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core, Legacy/CQL
>Reporter: Laxmikant Upadhyay
>Assignee: Vincent White
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> I have upgraded my system from cassandra 2.1.16 to 3.11.2. We had some tables 
> with COMPACT STORAGE enabled. We see some weird   behaviour of cassandra 
> while adding a column into it.
> Cassandra does not give any error while altering  however the added column is 
> invisible. 
> Same behaviour when we create a new table with compact storage and try to 
> alter it. Below is the commands ran in sequence: 
>  
> {code:java}
> x@cqlsh:xuser> CREATE TABLE xuser.employee(emp_id int PRIMARY KEY,emp_name 
> text, emp_city text, emp_sal varint, emp_phone varint ) WITH  COMPACT STORAGE;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';{code}
> Now altering the table by adding a new column:
>   
> {code:java}
> x@cqlsh:xuser>  alter table employee add profile text;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}
> notice that above desc table result does not have newly added column profile. 
> However when i try to add it again it gives column already exist;
> {code:java}
> x@cqlsh:xuser>  alter table employee add profile text;
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid 
> column name profile because it conflicts with an existing column"
> x@cqlsh:xuser> select emp_name,profile from employee;
>  emp_name | profile
> --+-
> (0 rows)
> x@cqlsh:xuser>
> {code}
> Inserting also behaves strange:
> {code:java}
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone 
> , emp_sal ,profile) VALUES ( 1, 'ggn', 'john', 123456, 5, 'SE');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Some 
> clustering keys are missing: column1"
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone 
> , emp_sal ,profile,column1) VALUES ( 1, 'ggn', 'john', 123456, 5, 
> 'SE',null);
> x@cqlsh:xuser> select * from employee;
>  emp_id | emp_city | emp_name | emp_phone | emp_sal
> +--+--+---+-
> (0 rows)
> {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-14564) issue while adding a column in a table with compact storage



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Lerer updated CASSANDRA-14564:
---
Status: Open  (was: Patch Available)

> issue while adding a column in a table with compact storage   
> --
>
> Key: CASSANDRA-14564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14564
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core, Legacy/CQL
>Reporter: Laxmikant Upadhyay
>Assignee: Vincent White
>Priority: Normal
> Fix For: 3.11.x
>
>
> I have upgraded my system from cassandra 2.1.16 to 3.11.2. We had some tables 
> with COMPACT STORAGE enabled. We see some weird   behaviour of cassandra 
> while adding a column into it.
> Cassandra does not give any error while altering  however the added column is 
> invisible. 
> Same behaviour when we create a new table with compact storage and try to 
> alter it. Below is the commands ran in sequence: 
>  
> {code:java}
> x@cqlsh:xuser> CREATE TABLE xuser.employee(emp_id int PRIMARY KEY,emp_name 
> text, emp_city text, emp_sal varint, emp_phone varint ) WITH  COMPACT STORAGE;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';{code}
> Now altering the table by adding a new column:
>   
> {code:java}
> x@cqlsh:xuser>  alter table employee add profile text;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}
> notice that above desc table result does not have newly added column profile. 
> However when i try to add it again it gives column already exist;
> {code:java}
> x@cqlsh:xuser>  alter table employee add profile text;
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid 
> column name profile because it conflicts with an existing column"
> x@cqlsh:xuser> select emp_name,profile from employee;
>  emp_name | profile
> --+-
> (0 rows)
> x@cqlsh:xuser>
> {code}
> Inserting also behaves strange:
> {code:java}
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone 
> , emp_sal ,profile) VALUES ( 1, 'ggn', 'john', 123456, 5, 'SE');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Some 
> clustering keys are missing: column1"
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone 
> , emp_sal ,profile,column1) VALUES ( 1, 'ggn', 'john', 123456, 5, 
> 'SE',null);
> x@cqlsh:xuser> select * from employee;
>  emp_id | emp_city | emp_name | emp_phone | emp_sal
> +--+--+---+-
> (0 rows)
> {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-14564) issue while adding a column in a table with compact storage



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Lerer updated CASSANDRA-14564:
---
Complexity: Low Hanging Fruit

> issue while adding a column in a table with compact storage   
> --
>
> Key: CASSANDRA-14564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14564
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core, Legacy/CQL
>Reporter: Laxmikant Upadhyay
>Assignee: Vincent White
>Priority: Normal
> Fix For: 3.11.x
>
>
> I have upgraded my system from cassandra 2.1.16 to 3.11.2. We had some tables 
> with COMPACT STORAGE enabled. We see some weird   behaviour of cassandra 
> while adding a column into it.
> Cassandra does not give any error while altering  however the added column is 
> invisible. 
> Same behaviour when we create a new table with compact storage and try to 
> alter it. Below is the commands ran in sequence: 
>  
> {code:java}
> x@cqlsh:xuser> CREATE TABLE xuser.employee(emp_id int PRIMARY KEY,emp_name 
> text, emp_city text, emp_sal varint, emp_phone varint ) WITH  COMPACT STORAGE;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';{code}
> Now altering the table by adding a new column:
>   
> {code:java}
> x@cqlsh:xuser>  alter table employee add profile text;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}
> notice that above desc table result does not have newly added column profile. 
> However when i try to add it again it gives column already exist;
> {code:java}
> x@cqlsh:xuser>  alter table employee add profile text;
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid 
> column name profile because it conflicts with an existing column"
> x@cqlsh:xuser> select emp_name,profile from employee;
>  emp_name | profile
> --+-
> (0 rows)
> x@cqlsh:xuser>
> {code}
> Inserting also behaves strange:
> {code:java}
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone 
> , emp_sal ,profile) VALUES ( 1, 'ggn', 'john', 123456, 5, 'SE');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Some 
> clustering keys are missing: column1"
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone 
> , emp_sal ,profile,column1) VALUES ( 1, 'ggn', 'john', 123456, 5, 
> 'SE',null);
> x@cqlsh:xuser> select * from employee;
>  emp_id | emp_city | emp_name | emp_phone | emp_sal
> +--+--+---+-
> (0 rows)
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14564) issue while adding a column in a table with compact storage



[ 
https://issues.apache.org/jira/browse/CASSANDRA-14564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372880#comment-17372880
 ] 

Benjamin Lerer commented on CASSANDRA-14564:


[~VincentWhite] as mentioned in CASSANDRA-13920 we do not allow adding columns 
to other type of COMPACT tables. It makes more sense to me to go for the 
solution sugested in CASSANDRA-13920 which is to reject the statement as 
invalid, specially considering that COMPACT tables are now deprecated.
Are you interested in providing a patch for it?

> issue while adding a column in a table with compact storage   
> --
>
> Key: CASSANDRA-14564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14564
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core, Legacy/CQL
>Reporter: Laxmikant Upadhyay
>Assignee: Vincent White
>Priority: Normal
> Fix For: 3.11.x
>
>
> I have upgraded my system from cassandra 2.1.16 to 3.11.2. We had some tables 
> with COMPACT STORAGE enabled. We see some weird   behaviour of cassandra 
> while adding a column into it.
> Cassandra does not give any error while altering  however the added column is 
> invisible. 
> Same behaviour when we create a new table with compact storage and try to 
> alter it. Below is the commands ran in sequence: 
>  
> {code:java}
> x@cqlsh:xuser> CREATE TABLE xuser.employee(emp_id int PRIMARY KEY,emp_name 
> text, emp_city text, emp_sal varint, emp_phone varint ) WITH  COMPACT STORAGE;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';{code}
> Now altering the table by adding a new column:
>   
> {code:java}
> x@cqlsh:xuser>  alter table employee add profile text;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}
> notice that above desc table result does not have newly added column profile. 
> However when i try to add it again it gives column already exist;
> {code:java}
> x@cqlsh:xuser>  alter table employee add profile text;
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid 
> column name profile because it conflicts with an existing column"
> x@cqlsh:xuser> select emp_name,profile from employee;
>  emp_name | profile
> --+-
> (0 rows)
> x@cqlsh:xuser>
> {code}
> Inserting also behaves strange:
> {code:java}
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone 
> , emp_sal ,profile) VALUES ( 1, 'ggn', 'john', 123456, 5, 'SE');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Some 
> clustering keys are missing: column1"
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone 
> , emp_sal ,profile,column1) VALUES ( 1, 'ggn', 'john', 123456, 5, 
> 'SE',null);
> x@cqlsh:xuser> select * from employee;
>  emp_id | emp_city | emp_name | emp_phone | emp_sal
> +--+--+---+-
> (0 rows)
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail:

[jira] [Updated] (CASSANDRA-16781) Fix upgrade dtests (after cassandra-4.0 branch bumped to 4.0.1)



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Semb Wever updated CASSANDRA-16781:
---
Fix Version/s: 4.x

> Fix upgrade dtests (after cassandra-4.0 branch bumped to 4.0.1)
> ---
>
> Key: CASSANDRA-16781
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16781
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> {noformat}
> Regression
> dtest-upgrade.upgrade_tests.paging_test.TestPagingDataNodes2RF1_Upgrade_current_4_0_x_To_indev_4_0_x.test_static_columns_paging
>  (from Cassandra dtests)
> Failing for the past 1 build (Since Unstable#116 )
> Took 46 sec.
>  Failed 1 times in the last 29 runs. Flakiness: 3%, Stability: 96%
> Error Message
> TypeError: '<' not supported between instances of 'str' and 'int'
> Stacktrace
> self =  object at 0x7f5ff1817c10>
> @since('2.0.6')
> def test_static_columns_paging(self):
> """
> Exercises paging with static columns to detect bugs
> @jira_ticket CASSANDRA-8502.
> """
> cursor = self.prepare(row_factory=named_tuple_factory)
> cursor.execute("CREATE TABLE test (a int, b int, c int, s1 int 
> static, s2 int static, PRIMARY KEY (a, b))")
> 
> for is_upgraded, cursor in self.do_upgrade(cursor, 
> row_factory=named_tuple_factory):
> >   min_version = min(self.get_node_versions())
> upgrade_tests/paging_test.py:661: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> /usr/lib/python3.8/distutils/version.py:52: in __lt__
> c = self._cmp(other)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> self = LooseVersion ('4.0-rc1'), other = LooseVersion ('4.0.1')
> def _cmp (self, other):
> if isinstance(other, str):
> other = LooseVersion(other)
> 
> if self.version == other.version:
> return 0
> >   if self.version < other.version:
> E   TypeError: '<' not supported between instances of 'str' and 'int'
> /usr/lib/python3.8/distutils/version.py:337: TypeError
> {noformat}
> from 
> https://ci-cassandra.apache.org/job/Cassandra-4.0/116/testReport/junit/dtest-upgrade.upgrade_tests.paging_test/TestPagingDataNodes2RF1_Upgrade_current_4_0_x_To_indev_4_0_x/test_static_columns_paging/
>  
> ref: https://the-asf.slack.com/archives/CK23JSY2K/p1625125464283300 



--
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-16781) Fix upgrade dtests (after cassandra-4.0 branch bumped to 4.0.1)



[ 
https://issues.apache.org/jira/browse/CASSANDRA-16781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372865#comment-17372865
 ] 

Michael Semb Wever edited comment on CASSANDRA-16781 at 7/1/21, 3:22 PM:
-

A number of dtests do {{'…  >= CASSANDRA_4_0 '}} comparisons.

I've updated the patch so the cassandra-4.0.0 branch is the {{CASSANDRA_4_0}} 
version family, and the cassandra-4.0 branch is the {{CASSANDRA_4_0_X}} version 
family, so that {{'CASSANDRA_4_0_X  >= CASSANDRA_4_0 '}}.

CI
- 4.0.0 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/394/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/394/]
- 4.0 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/395/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/395/]
- trunk 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/396/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/396/]


was (Author: michaelsembwever):
A number of dtests do {{'…  >= CASSANDRA_4_0 '}} comparisons.

I've updated the patch so the cassandra-4.0.0 branch is the {{CASSANDRA_4_0}} 
version family, and the cassandra-4.0 branch is the {{CASSANDRA_4_0_X}} version 
family, so that {{'CASSANDRA_4_0_X  >= CASSANDRA_4_0 '}}.

CI
- 4.0.0 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/391/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/391/]
- 4.0 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/391/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/392/]
- trunk 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/391/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/393/]

> Fix upgrade dtests (after cassandra-4.0 branch bumped to 4.0.1)
> ---
>
> Key: CASSANDRA-16781
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16781
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.x
>
>
> {noformat}
> Regression
> dtest-upgrade.upgrade_tests.paging_test.TestPagingDataNodes2RF1_Upgrade_current_4_0_x_To_indev_4_0_x.test_static_columns_paging
>  (from Cassandra dtests)
> Failing for the past 1 build (Since Unstable#116 )
> Took 46 sec.
>  Failed 1 times in the last 29 runs. Flakiness: 3%, Stability: 96%
> Error Message
> TypeError: '<' not supported between instances of 'str' and 'int'
> Stacktrace
> self =  object at 0x7f5ff1817c10>
> @since('2.0.6')
> def test_static_columns_paging(self):
> """
> Exercises paging with static columns to detect bugs
> @jira_ticket CASSANDRA-8502.
> """
> cursor = self.prepare(row_factory=named_tuple_factory)
> cursor.execute("CREATE TABLE test (a int, b int, c int, s1 int 
> static, s2 int static, PRIMARY KEY (a, b))")
> 
> for is_upgraded, cursor in self.do_upgrade(cursor, 
> row_factory=named_tuple_factory):
> >   min_version = min(self.get_node_versions())
> upgrade_tests/paging_test.py:661: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> /usr/lib/python3.8/distutils/version.py:52: in __lt__
> c = self._cmp(other)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> self = LooseVersion ('4.0-rc1'), other = LooseVersion ('4.0.1')
> def _cmp (self, other):
> if isinstance(other, str):
> other = LooseVersion(other)
> 
> if self.version == other.version:
> return 0
> >   if self.version < other.version:
> E   TypeError: '<' not supported between instances of 'str' and 'int'
> /usr/lib/python3.8/distutils/version.py:337: TypeError
> {noformat}
> from 
> https://ci-cassandra.apache.org/job/Cassandra-4.0/116/testReport/junit/dtest-upgrade.upgrade_tests.paging_test/TestPagingDataNodes2RF1_Upgrade_current_4_0_x_To_indev_4_0_x/test_static_columns_paging/
>  
> ref: https://the-asf.slack.com/archives/CK23JSY2K/p1625125464283300 



--
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-16781) Fix upgrade dtests (after cassandra-4.0 branch bumped to 4.0.1)



[ 
https://issues.apache.org/jira/browse/CASSANDRA-16781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372865#comment-17372865
 ] 

Michael Semb Wever commented on CASSANDRA-16781:


A number of dtests do {{'…  >= CASSANDRA_4_0 '}} comparisons.

I've updated the patch so the cassandra-4.0.0 branch is the {{CASSANDRA_4_0}} 
version family, and the cassandra-4.0 branch is the {{CASSANDRA_4_0_X}} version 
family, so that {{'CASSANDRA_4_0_X  >= CASSANDRA_4_0 '}}.

CI
- 4.0.0 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/391/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/391/]
- 4.0 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/391/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/392/]
- trunk 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/391/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/393/]

> Fix upgrade dtests (after cassandra-4.0 branch bumped to 4.0.1)
> ---
>
> Key: CASSANDRA-16781
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16781
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.x
>
>
> {noformat}
> Regression
> dtest-upgrade.upgrade_tests.paging_test.TestPagingDataNodes2RF1_Upgrade_current_4_0_x_To_indev_4_0_x.test_static_columns_paging
>  (from Cassandra dtests)
> Failing for the past 1 build (Since Unstable#116 )
> Took 46 sec.
>  Failed 1 times in the last 29 runs. Flakiness: 3%, Stability: 96%
> Error Message
> TypeError: '<' not supported between instances of 'str' and 'int'
> Stacktrace
> self =  object at 0x7f5ff1817c10>
> @since('2.0.6')
> def test_static_columns_paging(self):
> """
> Exercises paging with static columns to detect bugs
> @jira_ticket CASSANDRA-8502.
> """
> cursor = self.prepare(row_factory=named_tuple_factory)
> cursor.execute("CREATE TABLE test (a int, b int, c int, s1 int 
> static, s2 int static, PRIMARY KEY (a, b))")
> 
> for is_upgraded, cursor in self.do_upgrade(cursor, 
> row_factory=named_tuple_factory):
> >   min_version = min(self.get_node_versions())
> upgrade_tests/paging_test.py:661: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> /usr/lib/python3.8/distutils/version.py:52: in __lt__
> c = self._cmp(other)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> self = LooseVersion ('4.0-rc1'), other = LooseVersion ('4.0.1')
> def _cmp (self, other):
> if isinstance(other, str):
> other = LooseVersion(other)
> 
> if self.version == other.version:
> return 0
> >   if self.version < other.version:
> E   TypeError: '<' not supported between instances of 'str' and 'int'
> /usr/lib/python3.8/distutils/version.py:337: TypeError
> {noformat}
> from 
> https://ci-cassandra.apache.org/job/Cassandra-4.0/116/testReport/junit/dtest-upgrade.upgrade_tests.paging_test/TestPagingDataNodes2RF1_Upgrade_current_4_0_x_To_indev_4_0_x/test_static_columns_paging/
>  
> ref: https://the-asf.slack.com/archives/CK23JSY2K/p1625125464283300 



--
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-16783) Delay auth setup to after gossip has settled to avoid unavailables on startup



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-16783:

Test and Documentation Plan: cci run
 Status: Patch Available  (was: Open)

[https://github.com/krummas/cassandra/commits/marcuse/16783]

[https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2F16783]
 

> Delay auth setup to after gossip has settled to avoid unavailables on startup
> -
>
> Key: CASSANDRA-16783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16783
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> We should delay trying to do auth setup until after gossip has settled to 
> avoid getting unavailables from trying to read the auth tables before knowing 
> of any neighbours 



--
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-16783) Delay auth setup to after gossip has settled to avoid unavailables on startup



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-16783:

 Bug Category: Parent values: Availability(12983)Level 1 values: 
Unavailable(12994)
   Complexity: Low Hanging Fruit
Discovered By: Adhoc Test
Fix Version/s: 4.x
Reviewers: Sam Tunnicliffe
 Severity: Low
   Status: Open  (was: Triage Needed)

> Delay auth setup to after gossip has settled to avoid unavailables on startup
> -
>
> Key: CASSANDRA-16783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16783
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> We should delay trying to do auth setup until after gossip has settled to 
> avoid getting unavailables from trying to read the auth tables before knowing 
> of any neighbours 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-16783) Delay auth setup to after gossip has settled to avoid unavailables on startup

Marcus Eriksson created CASSANDRA-16783:
---

 Summary: Delay auth setup to after gossip has settled to avoid 
unavailables on startup
 Key: CASSANDRA-16783
 URL: https://issues.apache.org/jira/browse/CASSANDRA-16783
 Project: Cassandra
  Issue Type: Bug
  Components: Local/Startup and Shutdown
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson


We should delay trying to do auth setup until after gossip has settled to avoid 
getting unavailables from trying to read the auth tables before knowing of any 
neighbours 



--
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-11927) dtest failure in replication_test.ReplicationTest.simple_test



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-11927:
-
Resolution: Not A Problem
Status: Resolved  (was: Open)

This is no longer an issue.

> dtest failure in replication_test.ReplicationTest.simple_test
> -
>
> Key: CASSANDRA-11927
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11927
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Sean McCarthy
>Assignee: Paulo Motta (Deprecated)
>Priority: Normal
>  Labels: dtest
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log, 
> node3.log, node3_debug.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/387/testReport/replication_test/ReplicationTest/simple_test
> Failed on CassCI build trunk_novnode_dtest #387
> Logs are attached.
> Unexpected error in question:
> {code}
> ERROR [SharedPool-Worker-1] 2016-05-30 16:00:17,211 Keyspace.java:504 - 
> Attempting to mutate non-existant table 99f5be60-267f-11e6-ad5f-f13d771494ea 
> (test.test)
> {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-11927) dtest failure in replication_test.ReplicationTest.simple_test



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-11927:
-
Status: Open  (was: Patch Available)

> dtest failure in replication_test.ReplicationTest.simple_test
> -
>
> Key: CASSANDRA-11927
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11927
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Sean McCarthy
>Assignee: Paulo Motta (Deprecated)
>Priority: Normal
>  Labels: dtest
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log, 
> node3.log, node3_debug.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/387/testReport/replication_test/ReplicationTest/simple_test
> Failed on CassCI build trunk_novnode_dtest #387
> Logs are attached.
> Unexpected error in question:
> {code}
> ERROR [SharedPool-Worker-1] 2016-05-30 16:00:17,211 Keyspace.java:504 - 
> Attempting to mutate non-existant table 99f5be60-267f-11e6-ad5f-f13d771494ea 
> (test.test)
> {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-16782) Improve the way we pick sstables for STCS-in-L0 and in TWCS 'current' window



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-16782:

Test and Documentation Plan: cci run
 Status: Patch Available  (was: Open)

This patch collects smallest sstables until the total size is 1GB or we reach 
1000 sstables (both configurable), and compacts them together. Once we can't do 
any compactions like that (say the 4 smallest sstables size is > 1GB) we start 
doing L0 -> L1 compactions instead, this avoids creating huge sstables in L0.
 
With TWCS we take the same approach, but once we can't do any more compactions 
like that we do regular STCS
 
[https://github.com/krummas/cassandra/commits/marcuse/16782]
[https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2F16782]
 

> Improve the way we pick sstables for STCS-in-L0 and in TWCS 'current' window
> 
>
> Key: CASSANDRA-16782
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16782
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction/LCS, Local/Compaction/TWCS
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> The goal when being behind in L0 should always be to get the number of 
> sstables down to a reasonable level as soon as possible. Currently it is 
> common that we run compactions on the large sstables but leave thousands of 
> tiny sstables behind.



--
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-16782) Improve the way we pick sstables for STCS-in-L0 and in TWCS 'current' window



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-16782:

Change Category: Operability
 Complexity: Normal
Component/s: Local/Compaction/TWCS
 Local/Compaction/LCS
  Fix Version/s: 4.x
 Status: Open  (was: Triage Needed)

> Improve the way we pick sstables for STCS-in-L0 and in TWCS 'current' window
> 
>
> Key: CASSANDRA-16782
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16782
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction/LCS, Local/Compaction/TWCS
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> The goal when being behind in L0 should always be to get the number of 
> sstables down to a reasonable level as soon as possible. Currently it is 
> common that we run compactions on the large sstables but leave thousands of 
> tiny sstables behind.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-16782) Improve the way we pick sstables for STCS-in-L0 and in TWCS 'current' window

Marcus Eriksson created CASSANDRA-16782:
---

 Summary: Improve the way we pick sstables for STCS-in-L0 and in 
TWCS 'current' window
 Key: CASSANDRA-16782
 URL: https://issues.apache.org/jira/browse/CASSANDRA-16782
 Project: Cassandra
  Issue Type: Improvement
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson


The goal when being behind in L0 should always be to get the number of sstables 
down to a reasonable level as soon as possible. Currently it is common that we 
run compactions on the large sstables but leave thousands of tiny sstables 
behind.



--
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-16703) Exception thrown by custom QueryHandler constructor is ignored



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-16703:
-
Reviewers: Brandon Williams, Francisco Bento, Brandon Williams  (was: 
Brandon Williams, Francisco Bento)
   Brandon Williams, Francisco Bento, Brandon Williams  (was: 
Brandon Williams, Francisco Bento)
   Status: Review In Progress  (was: Patch Available)

> Exception thrown by custom QueryHandler constructor is ignored
> --
>
> Key: CASSANDRA-16703
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16703
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Francisco Bento
>Assignee: Zoltan Ersek
>Priority: Normal
> Attachments: 16703-trunk.txt
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> When a exception is thrown during the instantiation of the 
> _cassandra.custom_query_handler_class,_ depending on the exception thrown 
> cassandra will simply log an info message and proceed with the bootstraping 
> with the standard _QueryHandler_ as a fallback measure: 
> [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104]
> The end-user will never know if the custom _QueryHandler_ is actually 
> registered or not, unless he notices the info message on the logs.
> Ideally, the message should be logged as error and JVM should stop as it 
> cannot proceed according with the user expected configuration.
> *Scenario*:
> In our scenario, we have a custom _QueryHandler_ that receives specific 
> configuration, and we throw a _ConfigurationException_ at instantiation time 
> in case of any invalid config value. It is expected that cassandra stop the 
> bootstraping instead of skipping the QH.



--
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-16703) Exception thrown by custom QueryHandler constructor is ignored



[ 
https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372819#comment-17372819
 ] 

Brandon Williams commented on CASSANDRA-16703:
--

[Circle 
CI|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-16703]

> Exception thrown by custom QueryHandler constructor is ignored
> --
>
> Key: CASSANDRA-16703
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16703
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Francisco Bento
>Assignee: Zoltan Ersek
>Priority: Normal
> Attachments: 16703-trunk.txt
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> When a exception is thrown during the instantiation of the 
> _cassandra.custom_query_handler_class,_ depending on the exception thrown 
> cassandra will simply log an info message and proceed with the bootstraping 
> with the standard _QueryHandler_ as a fallback measure: 
> [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104]
> The end-user will never know if the custom _QueryHandler_ is actually 
> registered or not, unless he notices the info message on the logs.
> Ideally, the message should be logged as error and JVM should stop as it 
> cannot proceed according with the user expected configuration.
> *Scenario*:
> In our scenario, we have a custom _QueryHandler_ that receives specific 
> configuration, and we throw a _ConfigurationException_ at instantiation time 
> in case of any invalid config value. It is expected that cassandra stop the 
> bootstraping instead of skipping the QH.



--
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-16780) Log when writing many tombstones to a partition



[ 
https://issues.apache.org/jira/browse/CASSANDRA-16780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372814#comment-17372814
 ] 

Brandon Williams commented on CASSANDRA-16780:
--

+1

> Log when writing many tombstones to a partition
> ---
>
> Key: CASSANDRA-16780
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16780
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> Log when writing many tombstones to a partition like we do when writing a 
> large partition



--
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-16780) Log when writing many tombstones to a partition



[ 
https://issues.apache.org/jira/browse/CASSANDRA-16780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372789#comment-17372789
 ] 

Marcus Eriksson commented on CASSANDRA-16780:
-

yep, good point, pushed a fix

> Log when writing many tombstones to a partition
> ---
>
> Key: CASSANDRA-16780
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16780
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> Log when writing many tombstones to a partition like we do when writing a 
> large partition



--
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-16703) Exception thrown by custom QueryHandler constructor is ignored



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-16703:
-
Status: Patch Available  (was: Review In Progress)

> Exception thrown by custom QueryHandler constructor is ignored
> --
>
> Key: CASSANDRA-16703
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16703
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Francisco Bento
>Assignee: Zoltan Ersek
>Priority: Normal
> Attachments: 16703-trunk.txt
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> When a exception is thrown during the instantiation of the 
> _cassandra.custom_query_handler_class,_ depending on the exception thrown 
> cassandra will simply log an info message and proceed with the bootstraping 
> with the standard _QueryHandler_ as a fallback measure: 
> [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104]
> The end-user will never know if the custom _QueryHandler_ is actually 
> registered or not, unless he notices the info message on the logs.
> Ideally, the message should be logged as error and JVM should stop as it 
> cannot proceed according with the user expected configuration.
> *Scenario*:
> In our scenario, we have a custom _QueryHandler_ that receives specific 
> configuration, and we throw a _ConfigurationException_ at instantiation time 
> in case of any invalid config value. It is expected that cassandra stop the 
> bootstraping instead of skipping the QH.



--
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-16703) Exception thrown by custom QueryHandler constructor is ignored

2021-07-01 Thread Zoltan Ersek (Jira)



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zoltan Ersek updated CASSANDRA-16703:
-
Status: Review In Progress  (was: Changes Suggested)

> Exception thrown by custom QueryHandler constructor is ignored
> --
>
> Key: CASSANDRA-16703
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16703
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Francisco Bento
>Assignee: Zoltan Ersek
>Priority: Normal
> Attachments: 16703-trunk.txt
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> When a exception is thrown during the instantiation of the 
> _cassandra.custom_query_handler_class,_ depending on the exception thrown 
> cassandra will simply log an info message and proceed with the bootstraping 
> with the standard _QueryHandler_ as a fallback measure: 
> [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104]
> The end-user will never know if the custom _QueryHandler_ is actually 
> registered or not, unless he notices the info message on the logs.
> Ideally, the message should be logged as error and JVM should stop as it 
> cannot proceed according with the user expected configuration.
> *Scenario*:
> In our scenario, we have a custom _QueryHandler_ that receives specific 
> configuration, and we throw a _ConfigurationException_ at instantiation time 
> in case of any invalid config value. It is expected that cassandra stop the 
> bootstraping instead of skipping the QH.



--
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-16703) Exception thrown by custom QueryHandler constructor is ignored

2021-07-01 Thread Zoltan Ersek (Jira)



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zoltan Ersek updated CASSANDRA-16703:
-
Attachment: 16703-trunk.txt

> Exception thrown by custom QueryHandler constructor is ignored
> --
>
> Key: CASSANDRA-16703
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16703
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Francisco Bento
>Assignee: Zoltan Ersek
>Priority: Normal
> Attachments: 16703-trunk.txt
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> When a exception is thrown during the instantiation of the 
> _cassandra.custom_query_handler_class,_ depending on the exception thrown 
> cassandra will simply log an info message and proceed with the bootstraping 
> with the standard _QueryHandler_ as a fallback measure: 
> [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104]
> The end-user will never know if the custom _QueryHandler_ is actually 
> registered or not, unless he notices the info message on the logs.
> Ideally, the message should be logged as error and JVM should stop as it 
> cannot proceed according with the user expected configuration.
> *Scenario*:
> In our scenario, we have a custom _QueryHandler_ that receives specific 
> configuration, and we throw a _ConfigurationException_ at instantiation time 
> in case of any invalid config value. It is expected that cassandra stop the 
> bootstraping instead of skipping the QH.



--
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-16703) Exception thrown by custom QueryHandler constructor is ignored

2021-07-01 Thread Zoltan Ersek (Jira)



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zoltan Ersek updated CASSANDRA-16703:
-
Attachment: (was: 16703-trunk.txt)

> Exception thrown by custom QueryHandler constructor is ignored
> --
>
> Key: CASSANDRA-16703
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16703
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Francisco Bento
>Assignee: Zoltan Ersek
>Priority: Normal
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> When a exception is thrown during the instantiation of the 
> _cassandra.custom_query_handler_class,_ depending on the exception thrown 
> cassandra will simply log an info message and proceed with the bootstraping 
> with the standard _QueryHandler_ as a fallback measure: 
> [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104]
> The end-user will never know if the custom _QueryHandler_ is actually 
> registered or not, unless he notices the info message on the logs.
> Ideally, the message should be logged as error and JVM should stop as it 
> cannot proceed according with the user expected configuration.
> *Scenario*:
> In our scenario, we have a custom _QueryHandler_ that receives specific 
> configuration, and we throw a _ConfigurationException_ at instantiation time 
> in case of any invalid config value. It is expected that cassandra stop the 
> bootstraping instead of skipping the QH.



--
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-11671) Remove check on gossip status from DynamicEndpointSnitch::updateScores



[ 
https://issues.apache.org/jira/browse/CASSANDRA-11671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372781#comment-17372781
 ] 

Brandon Williams commented on CASSANDRA-11671:
--

LGTM, +1.

> Remove check on gossip status from DynamicEndpointSnitch::updateScores
> --
>
> Key: CASSANDRA-11671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11671
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Coordination
>Reporter: Sam Tunnicliffe
>Assignee: Artsiom Yudovin
>Priority: Low
>  Labels: pull-request-available
> Fix For: 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It seems that historically there were initialization ordering issues which 
> affected DES and StorageService (CASSANDRA-1756) and so a condition was added 
> to DES::updateScores() to ensure that SS had finished setup. In fact, the 
> check was actually testing whether gossip was active or not. CASSANDRA-10134 
> preserved this behaviour, but it seems likely that the check can be removed 
> from DES completely now. If not, it can at least be switched to use 
> SS::isInitialized() which post CASSANDRA-10134 actually reports what it's 
> name suggests.



--
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-16779) Display bytes per level for LCS in tablestats



[ 
https://issues.apache.org/jira/browse/CASSANDRA-16779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372757#comment-17372757
 ] 

Brandon Williams commented on CASSANDRA-16779:
--

+1

> Display bytes per level for LCS in tablestats
> -
>
> Key: CASSANDRA-16779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16779
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction/LCS
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.x
>
>
> Tablestats should show the size of each level in bytes



--
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-16780) Log when writing many tombstones to a partition



[ 
https://issues.apache.org/jira/browse/CASSANDRA-16780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372754#comment-17372754
 ] 

Brandon Williams commented on CASSANDRA-16780:
--

I think we should add this to the yaml with comments explaining it too.

> Log when writing many tombstones to a partition
> ---
>
> Key: CASSANDRA-16780
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16780
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> Log when writing many tombstones to a partition like we do when writing a 
> large partition



--
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-16703) Exception thrown by custom QueryHandler constructor is ignored



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-16703:
-
Reviewers: Brandon Williams, Francisco Bento  (was: Brandon Williams, 
Francisco Bento)

> Exception thrown by custom QueryHandler constructor is ignored
> --
>
> Key: CASSANDRA-16703
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16703
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Francisco Bento
>Assignee: Zoltan Ersek
>Priority: Normal
> Attachments: 16703-trunk.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When a exception is thrown during the instantiation of the 
> _cassandra.custom_query_handler_class,_ depending on the exception thrown 
> cassandra will simply log an info message and proceed with the bootstraping 
> with the standard _QueryHandler_ as a fallback measure: 
> [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104]
> The end-user will never know if the custom _QueryHandler_ is actually 
> registered or not, unless he notices the info message on the logs.
> Ideally, the message should be logged as error and JVM should stop as it 
> cannot proceed according with the user expected configuration.
> *Scenario*:
> In our scenario, we have a custom _QueryHandler_ that receives specific 
> configuration, and we throw a _ConfigurationException_ at instantiation time 
> in case of any invalid config value. It is expected that cassandra stop the 
> bootstraping instead of skipping the QH.



--
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-16703) Exception thrown by custom QueryHandler constructor is ignored



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-16703:
-
Status: Changes Suggested  (was: Review In Progress)

> Exception thrown by custom QueryHandler constructor is ignored
> --
>
> Key: CASSANDRA-16703
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16703
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Francisco Bento
>Assignee: Zoltan Ersek
>Priority: Normal
> Attachments: 16703-trunk.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When a exception is thrown during the instantiation of the 
> _cassandra.custom_query_handler_class,_ depending on the exception thrown 
> cassandra will simply log an info message and proceed with the bootstraping 
> with the standard _QueryHandler_ as a fallback measure: 
> [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104]
> The end-user will never know if the custom _QueryHandler_ is actually 
> registered or not, unless he notices the info message on the logs.
> Ideally, the message should be logged as error and JVM should stop as it 
> cannot proceed according with the user expected configuration.
> *Scenario*:
> In our scenario, we have a custom _QueryHandler_ that receives specific 
> configuration, and we throw a _ConfigurationException_ at instantiation time 
> in case of any invalid config value. It is expected that cassandra stop the 
> bootstraping instead of skipping the QH.



--
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-16703) Exception thrown by custom QueryHandler constructor is ignored



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-16703:
-
Reviewers: Francisco Bento, Brandon Williams  (was: Brandon Williams, 
Francisco Bento)
   Francisco Bento, Brandon Williams
   Status: Review In Progress  (was: Patch Available)

> Exception thrown by custom QueryHandler constructor is ignored
> --
>
> Key: CASSANDRA-16703
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16703
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Francisco Bento
>Assignee: Zoltan Ersek
>Priority: Normal
> Attachments: 16703-trunk.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When a exception is thrown during the instantiation of the 
> _cassandra.custom_query_handler_class,_ depending on the exception thrown 
> cassandra will simply log an info message and proceed with the bootstraping 
> with the standard _QueryHandler_ as a fallback measure: 
> [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104]
> The end-user will never know if the custom _QueryHandler_ is actually 
> registered or not, unless he notices the info message on the logs.
> Ideally, the message should be logged as error and JVM should stop as it 
> cannot proceed according with the user expected configuration.
> *Scenario*:
> In our scenario, we have a custom _QueryHandler_ that receives specific 
> configuration, and we throw a _ConfigurationException_ at instantiation time 
> in case of any invalid config value. It is expected that cassandra stop the 
> bootstraping instead of skipping the QH.



--
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-16781) Fix upgrade dtests (after cassandra-4.0 branch bumped to 4.0.1)



[ 
https://issues.apache.org/jira/browse/CASSANDRA-16781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372750#comment-17372750
 ] 

Brandon Williams commented on CASSANDRA-16781:
--

CI is looking good, +1 assuming it continues.

> Fix upgrade dtests (after cassandra-4.0 branch bumped to 4.0.1)
> ---
>
> Key: CASSANDRA-16781
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16781
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.x
>
>
> {noformat}
> Regression
> dtest-upgrade.upgrade_tests.paging_test.TestPagingDataNodes2RF1_Upgrade_current_4_0_x_To_indev_4_0_x.test_static_columns_paging
>  (from Cassandra dtests)
> Failing for the past 1 build (Since Unstable#116 )
> Took 46 sec.
>  Failed 1 times in the last 29 runs. Flakiness: 3%, Stability: 96%
> Error Message
> TypeError: '<' not supported between instances of 'str' and 'int'
> Stacktrace
> self =  object at 0x7f5ff1817c10>
> @since('2.0.6')
> def test_static_columns_paging(self):
> """
> Exercises paging with static columns to detect bugs
> @jira_ticket CASSANDRA-8502.
> """
> cursor = self.prepare(row_factory=named_tuple_factory)
> cursor.execute("CREATE TABLE test (a int, b int, c int, s1 int 
> static, s2 int static, PRIMARY KEY (a, b))")
> 
> for is_upgraded, cursor in self.do_upgrade(cursor, 
> row_factory=named_tuple_factory):
> >   min_version = min(self.get_node_versions())
> upgrade_tests/paging_test.py:661: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> /usr/lib/python3.8/distutils/version.py:52: in __lt__
> c = self._cmp(other)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> self = LooseVersion ('4.0-rc1'), other = LooseVersion ('4.0.1')
> def _cmp (self, other):
> if isinstance(other, str):
> other = LooseVersion(other)
> 
> if self.version == other.version:
> return 0
> >   if self.version < other.version:
> E   TypeError: '<' not supported between instances of 'str' and 'int'
> /usr/lib/python3.8/distutils/version.py:337: TypeError
> {noformat}
> from 
> https://ci-cassandra.apache.org/job/Cassandra-4.0/116/testReport/junit/dtest-upgrade.upgrade_tests.paging_test/TestPagingDataNodes2RF1_Upgrade_current_4_0_x_To_indev_4_0_x/test_static_columns_paging/
>  
> ref: https://the-asf.slack.com/archives/CK23JSY2K/p1625125464283300 



--
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-16781) Fix upgrade dtests (after cassandra-4.0 branch bumped to 4.0.1)



[ 
https://issues.apache.org/jira/browse/CASSANDRA-16781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372726#comment-17372726
 ] 

Michael Semb Wever edited comment on CASSANDRA-16781 at 7/1/21, 12:38 PM:
--

patch 
https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16781
 

CI
 - 4.0.0 
https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/388/
 - 4.0 
https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/389/
 - trunk 
https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/390/


was (Author: michaelsembwever):
patch 
https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16781
 

CI
 - 4.0.0 
https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/885/
 - 4.0 
https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/886/
 - trunk 
https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/887/

> Fix upgrade dtests (after cassandra-4.0 branch bumped to 4.0.1)
> ---
>
> Key: CASSANDRA-16781
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16781
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.x
>
>
> {noformat}
> Regression
> dtest-upgrade.upgrade_tests.paging_test.TestPagingDataNodes2RF1_Upgrade_current_4_0_x_To_indev_4_0_x.test_static_columns_paging
>  (from Cassandra dtests)
> Failing for the past 1 build (Since Unstable#116 )
> Took 46 sec.
>  Failed 1 times in the last 29 runs. Flakiness: 3%, Stability: 96%
> Error Message
> TypeError: '<' not supported between instances of 'str' and 'int'
> Stacktrace
> self =  object at 0x7f5ff1817c10>
> @since('2.0.6')
> def test_static_columns_paging(self):
> """
> Exercises paging with static columns to detect bugs
> @jira_ticket CASSANDRA-8502.
> """
> cursor = self.prepare(row_factory=named_tuple_factory)
> cursor.execute("CREATE TABLE test (a int, b int, c int, s1 int 
> static, s2 int static, PRIMARY KEY (a, b))")
> 
> for is_upgraded, cursor in self.do_upgrade(cursor, 
> row_factory=named_tuple_factory):
> >   min_version = min(self.get_node_versions())
> upgrade_tests/paging_test.py:661: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> /usr/lib/python3.8/distutils/version.py:52: in __lt__
> c = self._cmp(other)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> self = LooseVersion ('4.0-rc1'), other = LooseVersion ('4.0.1')
> def _cmp (self, other):
> if isinstance(other, str):
> other = LooseVersion(other)
> 
> if self.version == other.version:
> return 0
> >   if self.version < other.version:
> E   TypeError: '<' not supported between instances of 'str' and 'int'
> /usr/lib/python3.8/distutils/version.py:337: TypeError
> {noformat}
> from 
> https://ci-cassandra.apache.org/job/Cassandra-4.0/116/testReport/junit/dtest-upgrade.upgrade_tests.paging_test/TestPagingDataNodes2RF1_Upgrade_current_4_0_x_To_indev_4_0_x/test_static_columns_paging/
>  
> ref: https://the-asf.slack.com/archives/CK23JSY2K/p1625125464283300 



--
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-16781) Fix upgrade dtests (after cassandra-4.0 branch bumped to 4.0.1)



[ 
https://issues.apache.org/jira/browse/CASSANDRA-16781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372726#comment-17372726
 ] 

Michael Semb Wever edited comment on CASSANDRA-16781 at 7/1/21, 12:29 PM:
--

patch 
https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16781
 

CI
 - 4.0.0 
https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/885/
 - 4.0 
https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/886/
 - trunk 
https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/887/


was (Author: michaelsembwever):
patch 
https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16781
 

> Fix upgrade dtests (after cassandra-4.0 branch bumped to 4.0.1)
> ---
>
> Key: CASSANDRA-16781
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16781
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.x
>
>
> {noformat}
> Regression
> dtest-upgrade.upgrade_tests.paging_test.TestPagingDataNodes2RF1_Upgrade_current_4_0_x_To_indev_4_0_x.test_static_columns_paging
>  (from Cassandra dtests)
> Failing for the past 1 build (Since Unstable#116 )
> Took 46 sec.
>  Failed 1 times in the last 29 runs. Flakiness: 3%, Stability: 96%
> Error Message
> TypeError: '<' not supported between instances of 'str' and 'int'
> Stacktrace
> self =  object at 0x7f5ff1817c10>
> @since('2.0.6')
> def test_static_columns_paging(self):
> """
> Exercises paging with static columns to detect bugs
> @jira_ticket CASSANDRA-8502.
> """
> cursor = self.prepare(row_factory=named_tuple_factory)
> cursor.execute("CREATE TABLE test (a int, b int, c int, s1 int 
> static, s2 int static, PRIMARY KEY (a, b))")
> 
> for is_upgraded, cursor in self.do_upgrade(cursor, 
> row_factory=named_tuple_factory):
> >   min_version = min(self.get_node_versions())
> upgrade_tests/paging_test.py:661: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> /usr/lib/python3.8/distutils/version.py:52: in __lt__
> c = self._cmp(other)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> self = LooseVersion ('4.0-rc1'), other = LooseVersion ('4.0.1')
> def _cmp (self, other):
> if isinstance(other, str):
> other = LooseVersion(other)
> 
> if self.version == other.version:
> return 0
> >   if self.version < other.version:
> E   TypeError: '<' not supported between instances of 'str' and 'int'
> /usr/lib/python3.8/distutils/version.py:337: TypeError
> {noformat}
> from 
> https://ci-cassandra.apache.org/job/Cassandra-4.0/116/testReport/junit/dtest-upgrade.upgrade_tests.paging_test/TestPagingDataNodes2RF1_Upgrade_current_4_0_x_To_indev_4_0_x/test_static_columns_paging/
>  
> ref: https://the-asf.slack.com/archives/CK23JSY2K/p1625125464283300 



--
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-16781) Fix upgrade dtests (after cassandra-4.0 branch bumped to 4.0.1)



[ 
https://issues.apache.org/jira/browse/CASSANDRA-16781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372726#comment-17372726
 ] 

Michael Semb Wever commented on CASSANDRA-16781:


patch 
https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16781
 

> Fix upgrade dtests (after cassandra-4.0 branch bumped to 4.0.1)
> ---
>
> Key: CASSANDRA-16781
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16781
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.x
>
>
> {noformat}
> Regression
> dtest-upgrade.upgrade_tests.paging_test.TestPagingDataNodes2RF1_Upgrade_current_4_0_x_To_indev_4_0_x.test_static_columns_paging
>  (from Cassandra dtests)
> Failing for the past 1 build (Since Unstable#116 )
> Took 46 sec.
>  Failed 1 times in the last 29 runs. Flakiness: 3%, Stability: 96%
> Error Message
> TypeError: '<' not supported between instances of 'str' and 'int'
> Stacktrace
> self =  object at 0x7f5ff1817c10>
> @since('2.0.6')
> def test_static_columns_paging(self):
> """
> Exercises paging with static columns to detect bugs
> @jira_ticket CASSANDRA-8502.
> """
> cursor = self.prepare(row_factory=named_tuple_factory)
> cursor.execute("CREATE TABLE test (a int, b int, c int, s1 int 
> static, s2 int static, PRIMARY KEY (a, b))")
> 
> for is_upgraded, cursor in self.do_upgrade(cursor, 
> row_factory=named_tuple_factory):
> >   min_version = min(self.get_node_versions())
> upgrade_tests/paging_test.py:661: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> /usr/lib/python3.8/distutils/version.py:52: in __lt__
> c = self._cmp(other)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> self = LooseVersion ('4.0-rc1'), other = LooseVersion ('4.0.1')
> def _cmp (self, other):
> if isinstance(other, str):
> other = LooseVersion(other)
> 
> if self.version == other.version:
> return 0
> >   if self.version < other.version:
> E   TypeError: '<' not supported between instances of 'str' and 'int'
> /usr/lib/python3.8/distutils/version.py:337: TypeError
> {noformat}
> from 
> https://ci-cassandra.apache.org/job/Cassandra-4.0/116/testReport/junit/dtest-upgrade.upgrade_tests.paging_test/TestPagingDataNodes2RF1_Upgrade_current_4_0_x_To_indev_4_0_x/test_static_columns_paging/
>  
> ref: https://the-asf.slack.com/archives/CK23JSY2K/p1625125464283300 



--
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-16737) ALTER ... ADD can increase the number of SSTables being read