[jira] [Created] (CASSANDRA-16240) Having issues creating a table with name profiles

2020-11-01 Thread Anuj Kulkarni (Jira)
Anuj Kulkarni created CASSANDRA-16240:
-

 Summary: Having issues creating a table with name profiles
 Key: CASSANDRA-16240
 URL: https://issues.apache.org/jira/browse/CASSANDRA-16240
 Project: Cassandra
  Issue Type: Bug
Reporter: Anuj Kulkarni
 Attachments: image-2020-11-02-12-13-16-999.png

Whenever I try to create a table with name profiles, it always gets created 
with additional quotes surrounding it. Attaching the screenshot.
I am on Cassandra 3.7
I tried creating the table in another keyspace. I also tried creating new 
virtual machines with the same AMI and same Cassandra version, but to no avail.
If I try to create a table with any other name, there are no issues at all. 
It's just with the name profiles.
I am on Ubuntu 18.04 by the way.




!image-2020-11-02-12-13-16-999.png!



--
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-16213) Cannot replace_address /X because it doesn't exist in gossip

2020-11-01 Thread Paulo Motta (Jira)


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

Paulo Motta commented on CASSANDRA-16213:
-

Thanks, added some comments to the commit. Please let me know what do you think.

> Cannot replace_address /X because it doesn't exist in gossip
> 
>
> Key: CASSANDRA-16213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16213
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Gossip, Cluster/Membership
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
>
> We see this exception around nodes crashing and trying to do a host 
> replacement; this error appears to be correlated around multiple node 
> failures.
> A simplified case to trigger this is the following
> *) Have a N node cluster
> *) Shutdown all N nodes
> *) Bring up N-1 nodes (at least 1 seed, else replace seed)
> *) Host replace the N-1th node -> this will fail with the above
> The reason this happens is that the N-1th node isn’t gossiping anymore, and 
> the existing nodes do not have its details in gossip (but have the details in 
> the peers table), so the host replacement fails as the node isn’t known in 
> gossip.
> This affects all versions (tested 3.0 and trunk, assume 2.2 as well)



--
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-14477) The check of num_tokens against the length of inital_token in the yaml triggers unexpectedly

2020-11-01 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever updated CASSANDRA-14477:
---
Status: Changes Suggested  (was: Review In Progress)

> The check of num_tokens against the length of inital_token in the yaml 
> triggers unexpectedly
> 
>
> Key: CASSANDRA-14477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14477
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Vincent White
>Assignee: Stefan Miklosovic
>Priority: Low
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> In CASSANDRA-10120 we added a check that compares num_tokens against the 
> number of tokens supplied in the yaml via initial_token. From my reading of 
> CASSANDRA-10120 it was to prevent cassandra starting if the yaml contained 
> contradictory values for num_tokens and initial_tokens which should help 
> prevent misconfiguration via human error. The current behaviour appears to 
> differ slightly in that it performs this comparison regardless of whether 
> num_tokens is included in the yaml or not. Below are proposed patches to only 
> perform the check if both options are present in the yaml.
> ||Branch||
> |[3.0.x|https://github.com/apache/cassandra/compare/cassandra-3.0...vincewhite:num_tokens_30]|
> |[3.x|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:num_tokens_test_1_311]|



--
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-14477) The check of num_tokens against the length of inital_token in the yaml triggers unexpectedly

2020-11-01 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever edited comment on CASSANDRA-14477 at 11/1/20, 8:34 PM:
--

1. The 
{{DatabaseDescriptorTest.testApplyInitialTokensInitialTokensSetNumTokensNotSet}}
 demonstrates an unspecified {{num_tokens}} becomes the default of {{1}} but 
can still be combined with any number of {{initial_token}} values. Are they any 
compatibility issues with changing {{DatabaseDescriptor}} to throw a 
{{ConfigurationException}} in this situation? I cannot see how any existing 
cluster would have been configured with this combination.

2. The 3.0 tests fail for me because of {{ConfigurationException("Missing 
required directive CommitLogSync", false)}} from 
{{DatabaseDescriptor.load(config)}}. Can we move the lines (658-677) related to 
tokens in {{DatabaseDescriptor}} to a separate method, like 
{{applyTokensConfig(Config config)}}.
Example 
[here|https://github.com/apache/cassandra/commit/b0855523f6e80ecdffde41170a410a71380a683a]
 (ontop your 3.0 branch).









was (Author: michaelsembwever):
The 
{{DatabaseDescriptorTest.testApplyInitialTokensInitialTokensSetNumTokensNotSet}}
 demonstrates an unspecified {{num_tokens}} becomes the default of {{1}} but 
can still be combined with any number of {{initial_token}} values. Are they any 
compatibility issues with changing {{DatabaseDescriptor}} to throw a 
{{ConfigurationException}} in this situation? I cannot see how any existing 
cluster would have been configured with this combination.

The 3.0 tests fail for me because of {{ConfigurationException("Missing required 
directive CommitLogSync", false)}} from {{DatabaseDescriptor.load(config)}}.

Can we move the lines (658-677) related to tokens in {{DatabaseDescriptor}} to 
a separate method, like {{applyTokensConfig(Config config)}}.
Example 
[here|https://github.com/apache/cassandra/commit/b0855523f6e80ecdffde41170a410a71380a683a]
 (ontop your 3.0 branch).








> The check of num_tokens against the length of inital_token in the yaml 
> triggers unexpectedly
> 
>
> Key: CASSANDRA-14477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14477
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Vincent White
>Assignee: Stefan Miklosovic
>Priority: Low
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> In CASSANDRA-10120 we added a check that compares num_tokens against the 
> number of tokens supplied in the yaml via initial_token. From my reading of 
> CASSANDRA-10120 it was to prevent cassandra starting if the yaml contained 
> contradictory values for num_tokens and initial_tokens which should help 
> prevent misconfiguration via human error. The current behaviour appears to 
> differ slightly in that it performs this comparison regardless of whether 
> num_tokens is included in the yaml or not. Below are proposed patches to only 
> perform the check if both options are present in the yaml.
> ||Branch||
> |[3.0.x|https://github.com/apache/cassandra/compare/cassandra-3.0...vincewhite:num_tokens_30]|
> |[3.x|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:num_tokens_test_1_311]|



--
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-14477) The check of num_tokens against the length of inital_token in the yaml triggers unexpectedly

2020-11-01 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever commented on CASSANDRA-14477:


The 
{{DatabaseDescriptorTest.testApplyInitialTokensInitialTokensSetNumTokensNotSet}}
 demonstrates an unspecified {{num_tokens}} becomes the default of {{1}} but 
can still be combined with any number of {{initial_token}} values. Are they any 
compatibility issues with changing {{DatabaseDescriptor}} to throw a 
{{ConfigurationException}} in this situation? I cannot see how any existing 
cluster would have been configured with this combination.

The 3.0 tests fail for me because of {{ConfigurationException("Missing required 
directive CommitLogSync", false)}} from {{DatabaseDescriptor.load(config)}}.

Can we move the lines (658-677) related to tokens in {{DatabaseDescriptor}} to 
a separate method, like {{applyTokensConfig(Config config)}}.
Example 
[here|https://github.com/apache/cassandra/commit/b0855523f6e80ecdffde41170a410a71380a683a]
 (ontop your 3.0 branch).








> The check of num_tokens against the length of inital_token in the yaml 
> triggers unexpectedly
> 
>
> Key: CASSANDRA-14477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14477
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Vincent White
>Assignee: Stefan Miklosovic
>Priority: Low
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> In CASSANDRA-10120 we added a check that compares num_tokens against the 
> number of tokens supplied in the yaml via initial_token. From my reading of 
> CASSANDRA-10120 it was to prevent cassandra starting if the yaml contained 
> contradictory values for num_tokens and initial_tokens which should help 
> prevent misconfiguration via human error. The current behaviour appears to 
> differ slightly in that it performs this comparison regardless of whether 
> num_tokens is included in the yaml or not. Below are proposed patches to only 
> perform the check if both options are present in the yaml.
> ||Branch||
> |[3.0.x|https://github.com/apache/cassandra/compare/cassandra-3.0...vincewhite:num_tokens_30]|
> |[3.x|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:num_tokens_test_1_311]|



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