[jira] [Commented] (CASSANDRA-15194) Improve readability of Table metrics Virtual tables units

2019-08-09 Thread Chris Lohfink (JIRA) 


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

Chris Lohfink commented on CASSANDRA-15194:
---

changed per feedback and squashed

> Improve readability of Table metrics Virtual tables units
> -
>
> Key: CASSANDRA-15194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15194
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Virtual Tables
>Reporter: Jon Haddad
>Assignee: Chris Lohfink
>Priority: Normal
> Fix For: 4.0
>
>
> I just noticed this strange output in the coordinator_reads output::
> {code}
> cqlsh:system_views> select * from coordinator_reads ;
>  count | keyspace_name  | table_name | 99th | max | 
> median | per_second
> ---+++--+-++
>   7573 | tlp_stress |   keyvalue |0 |   0 |   
>0 | 2.2375e-16
>   6076 | tlp_stress |  random_access |0 |   0 |   
>0 | 7.4126e-12
>390 | tlp_stress |sensor_data_udt |0 |   0 |   
>0 | 1.7721e-64
> 30 | system |  local |0 |   0 |   
>0 |   0.006406
> 11 |  system_schema |columns |0 |   0 |   
>0 | 1.1192e-16
> 11 |  system_schema |indexes |0 |   0 |   
>0 | 1.1192e-16
> 11 |  system_schema | tables |0 |   0 |   
>0 | 1.1192e-16
> 11 |  system_schema |  views |0 |   0 |   
>0 | 1.1192e-16
> {code}
> cc [~cnlwsu]
> btw I realize the output is technically correct, but it's not very readable.  
> For practical purposes this should just say 0.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (CASSANDRA-15194) Improve readability of Table metrics Virtual tables units

2019-08-09 Thread Chris Lohfink (JIRA) 


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

Chris Lohfink updated CASSANDRA-15194:
--
Status: In Progress  (was: Changes Suggested)

> Improve readability of Table metrics Virtual tables units
> -
>
> Key: CASSANDRA-15194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15194
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Virtual Tables
>Reporter: Jon Haddad
>Assignee: Chris Lohfink
>Priority: Normal
> Fix For: 4.0
>
>
> I just noticed this strange output in the coordinator_reads output::
> {code}
> cqlsh:system_views> select * from coordinator_reads ;
>  count | keyspace_name  | table_name | 99th | max | 
> median | per_second
> ---+++--+-++
>   7573 | tlp_stress |   keyvalue |0 |   0 |   
>0 | 2.2375e-16
>   6076 | tlp_stress |  random_access |0 |   0 |   
>0 | 7.4126e-12
>390 | tlp_stress |sensor_data_udt |0 |   0 |   
>0 | 1.7721e-64
> 30 | system |  local |0 |   0 |   
>0 |   0.006406
> 11 |  system_schema |columns |0 |   0 |   
>0 | 1.1192e-16
> 11 |  system_schema |indexes |0 |   0 |   
>0 | 1.1192e-16
> 11 |  system_schema | tables |0 |   0 |   
>0 | 1.1192e-16
> 11 |  system_schema |  views |0 |   0 |   
>0 | 1.1192e-16
> {code}
> cc [~cnlwsu]
> btw I realize the output is technically correct, but it's not very readable.  
> For practical purposes this should just say 0.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (CASSANDRA-15194) Improve readability of Table metrics Virtual tables units

2019-08-09 Thread Chris Lohfink (JIRA) 


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

Chris Lohfink updated CASSANDRA-15194:
--
Status: Patch Available  (was: In Progress)

> Improve readability of Table metrics Virtual tables units
> -
>
> Key: CASSANDRA-15194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15194
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Virtual Tables
>Reporter: Jon Haddad
>Assignee: Chris Lohfink
>Priority: Normal
> Fix For: 4.0
>
>
> I just noticed this strange output in the coordinator_reads output::
> {code}
> cqlsh:system_views> select * from coordinator_reads ;
>  count | keyspace_name  | table_name | 99th | max | 
> median | per_second
> ---+++--+-++
>   7573 | tlp_stress |   keyvalue |0 |   0 |   
>0 | 2.2375e-16
>   6076 | tlp_stress |  random_access |0 |   0 |   
>0 | 7.4126e-12
>390 | tlp_stress |sensor_data_udt |0 |   0 |   
>0 | 1.7721e-64
> 30 | system |  local |0 |   0 |   
>0 |   0.006406
> 11 |  system_schema |columns |0 |   0 |   
>0 | 1.1192e-16
> 11 |  system_schema |indexes |0 |   0 |   
>0 | 1.1192e-16
> 11 |  system_schema | tables |0 |   0 |   
>0 | 1.1192e-16
> 11 |  system_schema |  views |0 |   0 |   
>0 | 1.1192e-16
> {code}
> cc [~cnlwsu]
> btw I realize the output is technically correct, but it's not very readable.  
> For practical purposes this should just say 0.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (CASSANDRA-15260) Add `allocate_tokens_for_dc_rf` yaml option for token allocation

2019-08-09 Thread mck (JIRA) 


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

mck commented on CASSANDRA-15260:
-

[~blambov], in context of this thread 
https://lists.apache.org/thread.html/56435ee11852ea842443d462500277eebe76743e6657e0cfdd7d67df@%3Cdev.cassandra.apache.org%3E
would you agree with the default of `allocate_tokens_for_local_rf=3` if 
`num_tokens=16` also became the default?

> Add `allocate_tokens_for_dc_rf` yaml option for token allocation
> 
>
> Key: CASSANDRA-15260
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15260
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: mck
>Assignee: mck
>Priority: Normal
> Fix For: 4.x
>
>
> Similar to DSE's option: {{allocate_tokens_for_local_replication_factor}}
> Currently the 
> [ReplicationAwareTokenAllocator|https://www.datastax.com/dev/blog/token-allocation-algorithm]
>  requires a defined keyspace and a replica factor specified in the current 
> datacenter.
> This is problematic in a number of ways. The real keyspace can not be used 
> when adding new datacenters as, in practice, all its nodes need to be up and 
> running before it has the capacity to replicate data into it. New datacenters 
> (or lift-and-shifting a cluster via datacenter migration) therefore has to be 
> done using a dummy keyspace that duplicates the replication strategy+factor 
> of the real keyspace. This gets even more difficult come version 4.0, as the 
> replica factor can not even be defined in new datacenters before those 
> datacenters are up and running. 
> These issues are removed by avoiding the keyspace definition and lookup, and 
> presuming the replica strategy is by datacenter, ie NTS. This can be done 
> with the use of an {{allocate_tokens_for_dc_rf}} option.
> It may also be of value considering whether {{allocate_tokens_for_dc_rf=3}} 
> becomes the default? as this is the replication factor for the vast majority 
> of datacenters in production. I suspect this would be a good improvement over 
> the existing randomly generated tokens algorithm.
> Initial patch is available in 
> [https://github.com/thelastpickle/cassandra/commit/fc4865b0399570e58f11215565ba17dc4a53da97]
> The patch does not remove the existing {{allocate_tokens_for_keyspace}} 
> option, as that provides the codebase for handling different replication 
> strategies.
>  
> fyi [~blambov] [~jay.zhuang] [~chovatia.jayd...@gmail.com] [~alokamvenki] 
> [~alexchueshev]



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (CASSANDRA-15170) Reduce the time needed to release in-JVM dtest cluster resources after close

2019-08-09 Thread Jon Meredith (JIRA) 


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

Jon Meredith commented on CASSANDRA-15170:
--

Thanks for explaining the issue with the termination, I've gone through and 
fixed the shutdowns to match trunk and pushed commits.

> Reduce the time needed to release in-JVM dtest cluster resources after close
> 
>
> Key: CASSANDRA-15170
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15170
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>
> There are a few issues that slow the in-JVM dtests from reclaiming metaspace 
> once the cluster is closed.
> IsolatedExecutor issues the shutdown on a SingleExecutorThreadPool, sometimes 
> this thread was still running 10s after the dtest cluster was closed.  
> Instead, switch to a ThreadPoolExecutor with a core pool size of 0 so that 
> the thread executing the class loader close executes sooner.
> If an OutboundTcpConnection is waiting to connect() and the endpoint is not 
> answering, it has to wait for a timeout before it exits. Instead it should 
> check the isShutdown flag and terminate early if shutdown has been requested.
> In 3.0 and above, HintsCatalog.load uses java.nio.Files.list outside of a 
> try-with-resources construct and leaks a file handle for the directory.  This 
> doesn't matter for normal usage, it leaks a file handle for each dtest 
> Instance created.
> On trunk, Netty global event executor threads are still running and delay GC 
> for the instance class loader.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (CASSANDRA-14952) NPE when using allocate_tokens_for_keyspace and add new DC

2019-08-09 Thread mck (JIRA) 


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

mck updated CASSANDRA-14952:

  Fix Version/s: (was: 3.0.x)
 4.0
 3.11.5
 3.0.19
Source Control Link: 
https://github.com/apache/cassandra/commit/2374a74eba6a4df84f9bda3fd311916c820e9cd6
  Since Version: 3.0 alpha 1
 Status: Resolved  (was: Ready to Commit)
 Resolution: Fixed

Committed as 2374a74eba6a4df84f9bda3fd311916c820e9cd6

> NPE when using allocate_tokens_for_keyspace and add new DC
> --
>
> Key: CASSANDRA-14952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14952
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Gossip
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Low
> Fix For: 3.0.19, 3.11.5, 4.0
>
>
> Received following NPE while bootstrapping very first node in the new 
> datacenter with {{allocate_tokens_for_keyspace}} yaml option
> {code:java}
> INFO  21:44:13 JOINING: getting bootstrap token
> Exception (java.lang.NullPointerException) encountered during startup: null
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.dht.tokenallocator.TokenAllocation.getStrategy(TokenAllocation.java:208)
>   at 
> org.apache.cassandra.dht.tokenallocator.TokenAllocation.getStrategy(TokenAllocation.java:170)
>   at 
> org.apache.cassandra.dht.tokenallocator.TokenAllocation.allocateTokens(TokenAllocation.java:55)
>   at 
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
>   at 
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:173)
>   at 
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:854)
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:666)
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:579)
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:351)
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:586)
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:714)
> {code}
> Please find reproducible steps here:
>  1. Set {{allocate_tokens_for_keyspace}} property with 
> {{Networktopologystrategy}} say Networktopologystrategy, 'dc1' : 1, 'dc2' 
> : 1
>  2. Start first node in {{dc1}}
>  3. Now bootstrap second node in {{dc2,}} it will throw above exception.
> RCA:
>  
> [doAddEndpoint|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/locator/TokenMetadata.java#L1325]
>  is invoked from the 
> [bootstrap|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L1254]
>  and at this time [local node's rack 
> information|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/locator/TokenMetadata.java#L1276]
>  is available
> However with have {{allocate_tokens_for_keyspace}} option, daemon tries to 
> access rack information even before calling 
> [bootstrap|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L1241]
>  function, at [this 
> place|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L878]
>  which results in NPE
> Fix:
>  Since this is applicable to only very first node for new dc, we can check 
> for {{null}} as:
> {code:java}
> diff --git 
> a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java 
> b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
> index 8d8a6ffeca..e162757d95 100644
> --- a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
> +++ b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
> @@ -205,7 +205,11 @@ public class TokenAllocation
>  final int replicas = rs.getReplicationFactor(dc);
>  
>  Topology topology = tokenMetadata.getTopology();
> -int racks = topology.getDatacenterRacks().get(dc).asMap().size();
> +int racks = 1;
> +if (topology.getDatacenterRacks().get(dc) != null)
> +{
> +racks = topology.getDatacenterRacks().get(dc).asMap().size();
> +}
>  
>  if (racks >= replicas)
>  {
> {code}
> Let me know your comments.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[cassandra] branch cassandra-3.11 updated (c7ca9b8 -> 5d72cdd)

2019-08-09 Thread mck 
This is an automated email from the ASF dual-hosted git repository.

mck pushed a change to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git.


from c7ca9b8  Merge branch 'cassandra-3.0' into cassandra-3.11
 new 2374a74  Fix NPE when using allocate_tokens_for_keyspace on new DC/rack
 new 5d72cdd  Merge branch 'cassandra-3.0' into cassandra-3.11

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 +
 .../org/apache/cassandra/dht/tokenallocator/TokenAllocation.java| 6 +-
 2 files changed, 6 insertions(+), 1 deletion(-)


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

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

2019-08-09 Thread mck 
This is an automated email from the ASF dual-hosted git repository.

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

commit 5a0e720375f8983231532b256c76327209756efe
Merge: d6c049f 5d72cdd
Author: Mick Semb Wever 
AuthorDate: Fri Aug 9 19:44:22 2019 +0200

Merge branch 'cassandra-3.11' into trunk

 CHANGES.txt | 1 +
 .../org/apache/cassandra/dht/tokenallocator/TokenAllocation.java| 6 +-
 2 files changed, 6 insertions(+), 1 deletion(-)



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

[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11

2019-08-09 Thread mck 
This is an automated email from the ASF dual-hosted git repository.

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

commit 5d72cdde8e4480e441e01851d3a3f452e5c2d461
Merge: c7ca9b8 2374a74
Author: Mick Semb Wever 
AuthorDate: Fri Aug 9 19:43:13 2019 +0200

Merge branch 'cassandra-3.0' into cassandra-3.11

 CHANGES.txt | 1 +
 .../org/apache/cassandra/dht/tokenallocator/TokenAllocation.java| 6 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --cc CHANGES.txt
index a1107b4,e4f4d22..5da96e6
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,9 -1,5 +1,10 @@@
 -3.0.19
 +3.11.5
 + * Make sure user defined compaction transactions are always closed 
(CASSANDRA-15123)
 + * Fix cassandra-env.sh to use $CASSANDRA_CONF to find cassandra-jaas.config 
(CASSANDRA-14305)
 + * Fixed nodetool cfstats printing index name twice (CASSANDRA-14903)
 + * Add flag to disable SASI indexes, and warnings on creation 
(CASSANDRA-14866)
 +Merged from 3.0:
+  * Fix NPE when using allocate_tokens_for_keyspace on new DC/rack 
(CASSANDRA-14592)
   * Filter sstables earlier when running cleanup (CASSANDRA-15100)
   * Use mean row count instead of mean column count for index selectivity 
calculation (CASSANDRA-15259)
   * Avoid updating unchanged gossip states (CASSANDRA-15097)
diff --cc src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
index 9c50613,5501378..8a3ede7
--- a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
+++ b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
@@@ -200,33 -198,12 +200,37 @@@ public class TokenAllocatio
  final String dc = snitch.getDatacenter(endpoint);
  final int replicas = rs.getReplicationFactor(dc);
  
 +if (replicas == 0 || replicas == 1)
 +{
 +// No replication, each node is treated as separate.
 +return new StrategyAdapter()
 +{
 +@Override
 +public int replicas()
 +{
 +return 1;
 +}
 +
 +@Override
 +public Object getGroup(InetAddress unit)
 +{
 +return unit;
 +}
 +
 +@Override
 +public boolean inAllocationRing(InetAddress other)
 +{
 +return dc.equals(snitch.getDatacenter(other));
 +}
 +};
 +}
 +
  Topology topology = tokenMetadata.getTopology();
- int racks = topology.getDatacenterRacks().get(dc).asMap().size();
+ 
+ // if topology hasn't been setup yet for this endpoint+rack then 
treat it as a separate unit
+ int racks = topology.getDatacenterRacks().get(dc) != null && 
topology.getDatacenterRacks().get(dc).containsKey(snitch.getRack(endpoint))
+ ? topology.getDatacenterRacks().get(dc).asMap().size()
+ : 1;
  
  if (racks >= replicas)
  {


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

[cassandra] branch trunk updated (d6c049f -> 5a0e720)

2019-08-09 Thread mck 
This is an automated email from the ASF dual-hosted git repository.

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


from d6c049f  Fix error with non-existent table for nodetool tablehistograms
 new 2374a74  Fix NPE when using allocate_tokens_for_keyspace on new DC/rack
 new 5d72cdd  Merge branch 'cassandra-3.0' into cassandra-3.11
 new 5a0e720  Merge branch 'cassandra-3.11' into trunk

The 3 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 +
 .../org/apache/cassandra/dht/tokenallocator/TokenAllocation.java| 6 +-
 2 files changed, 6 insertions(+), 1 deletion(-)


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

[cassandra] branch cassandra-3.0 updated: Fix NPE when using allocate_tokens_for_keyspace on new DC/rack

2019-08-09 Thread mck 
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/cassandra-3.0 by this push:
 new 2374a74  Fix NPE when using allocate_tokens_for_keyspace on new DC/rack
2374a74 is described below

commit 2374a74eba6a4df84f9bda3fd311916c820e9cd6
Author: Mick Semb Wever 
AuthorDate: Sun Aug 4 20:31:05 2019 +0200

Fix NPE when using allocate_tokens_for_keyspace on new DC/rack

 patch by Jaydeepkumar Chovatia; reviewed by Mick Semb Wever for 
CASSANDRA-14592
---
 CHANGES.txt | 1 +
 .../org/apache/cassandra/dht/tokenallocator/TokenAllocation.java| 6 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/CHANGES.txt b/CHANGES.txt
index c07457b..e4f4d22 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.19
+ * Fix NPE when using allocate_tokens_for_keyspace on new DC/rack 
(CASSANDRA-14592)
  * Filter sstables earlier when running cleanup (CASSANDRA-15100)
  * Use mean row count instead of mean column count for index selectivity 
calculation (CASSANDRA-15259)
  * Avoid updating unchanged gossip states (CASSANDRA-15097)
diff --git 
a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java 
b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
index 971a120..5501378 100644
--- a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
+++ b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
@@ -199,7 +199,11 @@ public class TokenAllocation
 final int replicas = rs.getReplicationFactor(dc);
 
 Topology topology = tokenMetadata.getTopology();
-int racks = topology.getDatacenterRacks().get(dc).asMap().size();
+
+// if topology hasn't been setup yet for this endpoint+rack then treat 
it as a separate unit
+int racks = topology.getDatacenterRacks().get(dc) != null && 
topology.getDatacenterRacks().get(dc).containsKey(snitch.getRack(endpoint))
+? topology.getDatacenterRacks().get(dc).asMap().size()
+: 1;
 
 if (racks >= replicas)
 {


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

[jira] [Created] (CASSANDRA-15271) CASSANDRA-13426 changed the behavior of "CLUSTERING ORDER" on "CREATE TABLE"

2019-08-09 Thread Jeremiah Jordan (JIRA) 
Jeremiah Jordan created CASSANDRA-15271:
---

 Summary: CASSANDRA-13426 changed the behavior of "CLUSTERING 
ORDER" on "CREATE TABLE"
 Key: CASSANDRA-15271
 URL: https://issues.apache.org/jira/browse/CASSANDRA-15271
 Project: Cassandra
  Issue Type: Bug
  Components: CQL/Syntax
Reporter: Jeremiah Jordan


CASSANDRA-13426 changed the behavior of "CLUSTERING ORDER" on "CREATE TABLE", 
it now complains if you don't specify all the columns.

It was nice that previously you could just specify to make the first clustering 
DESC and leave the rest ASC without needing to specify them.  Also it would be 
nice I think to avoid breaking changes to the CREATE TABLE syntax.

We should either update NEWS.txt to call out the breaking change there, or 
update the new code to be able to default the columns which were not mentioned.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (CASSANDRA-15271) CASSANDRA-13426 changed the behavior of "CLUSTERING ORDER" on "CREATE TABLE"

2019-08-09 Thread Jeremiah Jordan (JIRA) 


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

Jeremiah Jordan updated CASSANDRA-15271:

Fix Version/s: 4.0

> CASSANDRA-13426 changed the behavior of "CLUSTERING ORDER" on "CREATE TABLE"
> 
>
> Key: CASSANDRA-15271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15271
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Syntax
>Reporter: Jeremiah Jordan
>Priority: Normal
> Fix For: 4.0
>
>
> CASSANDRA-13426 changed the behavior of "CLUSTERING ORDER" on "CREATE TABLE", 
> it now complains if you don't specify all the columns.
> It was nice that previously you could just specify to make the first 
> clustering DESC and leave the rest ASC without needing to specify them.  Also 
> it would be nice I think to avoid breaking changes to the CREATE TABLE syntax.
> We should either update NEWS.txt to call out the breaking change there, or 
> update the new code to be able to default the columns which were not 
> mentioned.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (CASSANDRA-15170) Reduce the time needed to release in-JVM dtest cluster resources after close

2019-08-09 Thread Benedict (JIRA) 


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

Benedict commented on CASSANDRA-15170:
--

Thanks, looks good.

bq. The shutdown->shutdownNow change on the InfiniteLoopExecutor was just to 
match trunk naming, there's no functional change.

It was an unrelated point that I noticed, at the places you made the 
modification, we were invoking {{Executor.awaitTermination}} instead of 
{{ExecutorUtils.awaitTermination}}, the latter of which actually reports a 
failure to terminate as an exception.  We probably have other places in which 
we are inconsistent, I simply noticed these places while looking at the changes.

It looks like there's a related bad merge to trunk for 
{{shutdownReferenceReaper}}.  The {{EXEC}} and {{STRONG_LEAK_DETECTOR}} are 
being shutdown/awaited separately?

bq.  Sadly I can't reproduce it now and have lost the heap dump showing an 
example

The problem is that there's no good reason for this to have any impact.  If the 
shutdown task exits, the thread pool will be shutdown, so there's no apparent 
reason to need to depend on the instant core thread timeout.  It's not terribly 
important, since the change should only confer a very minor difference in code 
clarity, but it may cause people to scratch their heads later.  Anyway, it's 
probably not worth further investigation.

bq. The ColumnFamilyStore.shutdownExecutorsAndWait uses the builder so it can 
add the perDiskflushExecutors

My mistake, thanks for clarifying.

bq. We could introduce the shutdown and wait, but would mean 4 variants of it, 
I don't mind it as it is at the moment.

I don't mind terribly either way, either.

> Reduce the time needed to release in-JVM dtest cluster resources after close
> 
>
> Key: CASSANDRA-15170
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15170
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>
> There are a few issues that slow the in-JVM dtests from reclaiming metaspace 
> once the cluster is closed.
> IsolatedExecutor issues the shutdown on a SingleExecutorThreadPool, sometimes 
> this thread was still running 10s after the dtest cluster was closed.  
> Instead, switch to a ThreadPoolExecutor with a core pool size of 0 so that 
> the thread executing the class loader close executes sooner.
> If an OutboundTcpConnection is waiting to connect() and the endpoint is not 
> answering, it has to wait for a timeout before it exits. Instead it should 
> check the isShutdown flag and terminate early if shutdown has been requested.
> In 3.0 and above, HintsCatalog.load uses java.nio.Files.list outside of a 
> try-with-resources construct and leaks a file handle for the directory.  This 
> doesn't matter for normal usage, it leaks a file handle for each dtest 
> Instance created.
> On trunk, Netty global event executor threads are still running and delay GC 
> for the instance class loader.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (CASSANDRA-15170) Reduce the time needed to release in-JVM dtest cluster resources after close

2019-08-09 Thread Jon Meredith (JIRA) 


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

Jon Meredith commented on CASSANDRA-15170:
--

Thanks for the review, and apologies for the messy history. I've just pushed 
deltas to each branch this time.

Losing the Feature enum was just a misunderstanding of change history - I was 
matching trunk instead of 3.0.  Agree the enum is nicer and have implemented 
that across releases instead.

On the IsolatedExecutor shutdown executor.  When the dtests run successfully 
there isn't a problem with shutting down, it's just when there are issues with 
the instance class loaders not being released there were several cases where 
the nodeX_shutdown thread was still around and also causing a root to the 
instance class loader.  Sadly I can't reproduce it now and have lost the heap 
dump showing an example, but I know that when I was debugging it made the heap 
dump have less active threads in it which made it easier to analyze.

On to the minor items.

* For NanoTimeToCurrentTimeMillis, I've left it alone on 2.2/3.0 as trying to 
minimize change on older versions.  3.11 and above use the 
FastScheduledTaskExecutor for it.

* The ColumnFamilyStore.shutdownExecutorsAndWait uses the builder so it can add 
the perDiskflushExecutors, so I just made the code as similar as possible. 
Happy to change if you'd really like ImmutableList.of.

* The shutdown->shutdownNow change on the InfiniteLoopExecutor was just to 
match trunk naming, there's no functional change.

* We could introduce the shutdown and wait, but would mean 4 variants of it, I 
don't mind it as it is at the moment.


> Reduce the time needed to release in-JVM dtest cluster resources after close
> 
>
> Key: CASSANDRA-15170
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15170
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>
> There are a few issues that slow the in-JVM dtests from reclaiming metaspace 
> once the cluster is closed.
> IsolatedExecutor issues the shutdown on a SingleExecutorThreadPool, sometimes 
> this thread was still running 10s after the dtest cluster was closed.  
> Instead, switch to a ThreadPoolExecutor with a core pool size of 0 so that 
> the thread executing the class loader close executes sooner.
> If an OutboundTcpConnection is waiting to connect() and the endpoint is not 
> answering, it has to wait for a timeout before it exits. Instead it should 
> check the isShutdown flag and terminate early if shutdown has been requested.
> In 3.0 and above, HintsCatalog.load uses java.nio.Files.list outside of a 
> try-with-resources construct and leaks a file handle for the directory.  This 
> doesn't matter for normal usage, it leaks a file handle for each dtest 
> Instance created.
> On trunk, Netty global event executor threads are still running and delay GC 
> for the instance class loader.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (CASSANDRA-15170) Reduce the time needed to release in-JVM dtest cluster resources after close

2019-08-09 Thread Benedict (JIRA) 


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

Benedict commented on CASSANDRA-15170:
--

Thanks.  It's looking good, just a few more minor(ish) items:

* {{NanoTimeToCurrentTimeMillis}}: {{updater}} should be {{final}} to ensure 
visibility, but better still would be to probably use {{InfiniteLoopExecutor}}. 
 I have a number of question marks around the pre-existing code there, though 
(like why it’s using an {{Object}} for waiting for instance), so up to you 
exactly what you do there.
* {{blockingIOThreead}} probably also needs to be {{volatile}}
* I may have lost track of changes here, but any reason why you got rid of the 
{{Feature}} enum in preference for a long?
* {{ColumnFamilyStore.shutdownExecutorsAndWait}}: use {{ImmutableList.of}}?
* Should we introduce {{ExecutorUtils.shutdownAndWait}} since we do it 
repeatedly?
* Some of the places you’ve switched {{shutdown}} to {{shutdownNow]} it might 
also be good to switch to {{ExecutorUtils.awaitTermination}} so that we can be 
informed if we haven’t shutdown/

Could you elaborate on what you saw with the single threaded executor?  It 
shouldn’t have had any impact on how long the threads were around for, and it 
might be indicative of some other problem?

For future reference, it helps for review to update existing branches with new 
commits, without rebasing, instead of creating new ones with a clean commit 
history.  We tend to rebase and clean-up just prior to commit, so that the 
reviewer can easily see what has changed between versions.  It's admittedly 
painful working with multiple branches, for all involved.

> Reduce the time needed to release in-JVM dtest cluster resources after close
> 
>
> Key: CASSANDRA-15170
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15170
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>
> There are a few issues that slow the in-JVM dtests from reclaiming metaspace 
> once the cluster is closed.
> IsolatedExecutor issues the shutdown on a SingleExecutorThreadPool, sometimes 
> this thread was still running 10s after the dtest cluster was closed.  
> Instead, switch to a ThreadPoolExecutor with a core pool size of 0 so that 
> the thread executing the class loader close executes sooner.
> If an OutboundTcpConnection is waiting to connect() and the endpoint is not 
> answering, it has to wait for a timeout before it exits. Instead it should 
> check the isShutdown flag and terminate early if shutdown has been requested.
> In 3.0 and above, HintsCatalog.load uses java.nio.Files.list outside of a 
> try-with-resources construct and leaks a file handle for the directory.  This 
> doesn't matter for normal usage, it leaks a file handle for each dtest 
> Instance created.
> On trunk, Netty global event executor threads are still running and delay GC 
> for the instance class loader.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (CASSANDRA-15263) LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null

2019-08-09 Thread Benedict (JIRA) 


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

Benedict commented on CASSANDRA-15263:
--

Thanks [~ferozshaik...@gmail.com].  If you could download the latest version 
and run again, I can get some further information about where the problematic 
range tombstone bound is being instantiated.

> LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null
> ---
>
> Key: CASSANDRA-15263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15263
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: feroz shaik
>Assignee: Benedict
>Priority: Normal
>  Labels: 2.1.16, 3.11.4
> Attachments: sample.system.log, schema.txt, stack_trace.txt, 
> system.log, system_latest.log
>
>
> We have  hit a problem today while upgrading from 2.1.16 to 3.11.4.
> we encountered this as soon as the first node started up with 3.11.4 
> The full error stack is attached - [^stack_trace.txt] 
>  
> The below errors continued in the log file as long as the process was up.
> ERROR [Native-Transport-Requests-12] 2019-08-06 03:00:47,135 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-8] 2019-08-06 03:00:48,778 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-13] 2019-08-06 03:00:57,454 
>  
> The nodetool version says 3.11.4 and the no of connections on native por t- 
> 9042 was similar to other nodes. The exceptions were scary that we had to 
> call off the change. Any help and insights to this problem from the community 
> is appreciated.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[cassandra] branch 15263-debug updated: more debugging

2019-08-09 Thread benedict 
This is an automated email from the ASF dual-hosted git repository.

benedict pushed a commit to branch 15263-debug
in repository https://gitbox.apache.org/repos/asf/cassandra.git


The following commit(s) were added to refs/heads/15263-debug by this push:
 new 6b6f774  more debugging
6b6f774 is described below

commit 6b6f774c526437715bb8fb0b725926d8d4b207e2
Author: Benedict Elliott Smith 
AuthorDate: Fri Aug 9 13:42:36 2019 +0100

more debugging
---
 src/java/org/apache/cassandra/db/ClusteringBound.java | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/java/org/apache/cassandra/db/ClusteringBound.java 
b/src/java/org/apache/cassandra/db/ClusteringBound.java
index c45f7ba..a683423 100644
--- a/src/java/org/apache/cassandra/db/ClusteringBound.java
+++ b/src/java/org/apache/cassandra/db/ClusteringBound.java
@@ -23,6 +23,9 @@ package org.apache.cassandra.db;
 import java.nio.ByteBuffer;
 import java.util.List;
 
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
 import org.apache.cassandra.utils.memory.AbstractAllocator;
 
 /**
@@ -30,6 +33,8 @@ import org.apache.cassandra.utils.memory.AbstractAllocator;
  */
 public class ClusteringBound extends ClusteringBoundOrBoundary
 {
+private static final Logger logger = 
LoggerFactory.getLogger(ClusteringBound.class);
+
 /** The smallest start bound, i.e. the one that starts before any row. */
 public static final ClusteringBound BOTTOM = new 
ClusteringBound(Kind.INCL_START_BOUND, EMPTY_VALUES_ARRAY);
 /** The biggest end bound, i.e. the one that ends after any row. */
@@ -38,6 +43,17 @@ public class ClusteringBound extends 
ClusteringBoundOrBoundary
 protected ClusteringBound(Kind kind, ByteBuffer[] values)
 {
 super(kind, values);
+if (kind == Kind.INCL_END_BOUND && values.length == 2 && 
values[values.length - 1] == null)
+{
+try
+{
+throw new RuntimeException();
+}
+catch (Throwable t)
+{
+logger.error("", t);
+}
+}
 }
 
 public static ClusteringBound create(Kind kind, ByteBuffer[] values)


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

[jira] [Commented] (CASSANDRA-15263) LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null

2019-08-09 Thread feroz shaik (JIRA) 


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

feroz shaik commented on CASSANDRA-15263:
-

I added the latest system.log. Thanks once again [~benedict] Another step 
closer. We know which table is offending one now.

> LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null
> ---
>
> Key: CASSANDRA-15263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15263
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: feroz shaik
>Assignee: Benedict
>Priority: Normal
>  Labels: 2.1.16, 3.11.4
> Attachments: sample.system.log, schema.txt, stack_trace.txt, 
> system.log, system_latest.log
>
>
> We have  hit a problem today while upgrading from 2.1.16 to 3.11.4.
> we encountered this as soon as the first node started up with 3.11.4 
> The full error stack is attached - [^stack_trace.txt] 
>  
> The below errors continued in the log file as long as the process was up.
> ERROR [Native-Transport-Requests-12] 2019-08-06 03:00:47,135 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-8] 2019-08-06 03:00:48,778 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-13] 2019-08-06 03:00:57,454 
>  
> The nodetool version says 3.11.4 and the no of connections on native por t- 
> 9042 was similar to other nodes. The exceptions were scary that we had to 
> call off the change. Any help and insights to this problem from the community 
> is appreciated.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (CASSANDRA-15263) LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null

2019-08-09 Thread feroz shaik (JIRA) 


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

feroz shaik updated CASSANDRA-15263:

Attachment: system_latest.log

> LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null
> ---
>
> Key: CASSANDRA-15263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15263
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: feroz shaik
>Assignee: Benedict
>Priority: Normal
>  Labels: 2.1.16, 3.11.4
> Attachments: sample.system.log, schema.txt, stack_trace.txt, 
> system.log, system_latest.log
>
>
> We have  hit a problem today while upgrading from 2.1.16 to 3.11.4.
> we encountered this as soon as the first node started up with 3.11.4 
> The full error stack is attached - [^stack_trace.txt] 
>  
> The below errors continued in the log file as long as the process was up.
> ERROR [Native-Transport-Requests-12] 2019-08-06 03:00:47,135 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-8] 2019-08-06 03:00:48,778 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-13] 2019-08-06 03:00:57,454 
>  
> The nodetool version says 3.11.4 and the no of connections on native por t- 
> 9042 was similar to other nodes. The exceptions were scary that we had to 
> call off the change. Any help and insights to this problem from the community 
> is appreciated.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Assigned] (CASSANDRA-14092) Max ttl of 20 years will overflow localDeletionTime

2019-08-09 Thread Manish Khandelwal (JIRA) 


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

Manish Khandelwal reassigned CASSANDRA-14092:
-

Assignee: Paulo Motta  (was: Manish Khandelwal)

> Max ttl of 20 years will overflow localDeletionTime
> ---
>
> Key: CASSANDRA-14092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14092
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Urgent
> Fix For: 2.1.20, 2.2.12, 3.0.16, 3.11.2
>
> Attachments: 2.1-14092-dtest.png, 2.1-14092-testall.png, 
> 2.2-14092-dtest.png, 2.2-14092-testall.png, 3.0-14092-dtest.png, 
> 3.0-14092-testall.png, 3.11-14092-dtest.png, 3.11-14092-testall.png, 
> trunk-14092-dtest.png, trunk-14092-testall.png
>
>
> CASSANDRA-4771 added a max value of 20 years for ttl to protect against [year 
> 2038 overflow bug|https://en.wikipedia.org/wiki/Year_2038_problem] for 
> {{localDeletionTime}}.
> It turns out that next year the {{localDeletionTime}} will start overflowing 
> with the maximum ttl of 20 years ({{System.currentTimeMillis() + ttl(20 
> years) > Integer.MAX_VALUE}}), so we should remove this limitation.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (CASSANDRA-15263) LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null

2019-08-09 Thread feroz shaik (JIRA) 


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

feroz shaik commented on CASSANDRA-15263:
-

Sure . will update soon.

> LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null
> ---
>
> Key: CASSANDRA-15263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15263
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: feroz shaik
>Assignee: Benedict
>Priority: Normal
>  Labels: 2.1.16, 3.11.4
> Attachments: sample.system.log, schema.txt, stack_trace.txt, 
> system.log
>
>
> We have  hit a problem today while upgrading from 2.1.16 to 3.11.4.
> we encountered this as soon as the first node started up with 3.11.4 
> The full error stack is attached - [^stack_trace.txt] 
>  
> The below errors continued in the log file as long as the process was up.
> ERROR [Native-Transport-Requests-12] 2019-08-06 03:00:47,135 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-8] 2019-08-06 03:00:48,778 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-13] 2019-08-06 03:00:57,454 
>  
> The nodetool version says 3.11.4 and the no of connections on native por t- 
> 9042 was similar to other nodes. The exceptions were scary that we had to 
> call off the change. Any help and insights to this problem from the community 
> is appreciated.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (CASSANDRA-14952) NPE when using allocate_tokens_for_keyspace and add new DC

2019-08-09 Thread mck (JIRA) 


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

mck updated CASSANDRA-14952:

Authors: Jaydeepkumar Chovatia, mck  (was: Jaydeepkumar Chovatia)

> NPE when using allocate_tokens_for_keyspace and add new DC
> --
>
> Key: CASSANDRA-14952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14952
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Gossip
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Low
> Fix For: 3.0.x
>
>
> Received following NPE while bootstrapping very first node in the new 
> datacenter with {{allocate_tokens_for_keyspace}} yaml option
> {code:java}
> INFO  21:44:13 JOINING: getting bootstrap token
> Exception (java.lang.NullPointerException) encountered during startup: null
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.dht.tokenallocator.TokenAllocation.getStrategy(TokenAllocation.java:208)
>   at 
> org.apache.cassandra.dht.tokenallocator.TokenAllocation.getStrategy(TokenAllocation.java:170)
>   at 
> org.apache.cassandra.dht.tokenallocator.TokenAllocation.allocateTokens(TokenAllocation.java:55)
>   at 
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
>   at 
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:173)
>   at 
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:854)
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:666)
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:579)
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:351)
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:586)
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:714)
> {code}
> Please find reproducible steps here:
>  1. Set {{allocate_tokens_for_keyspace}} property with 
> {{Networktopologystrategy}} say Networktopologystrategy, 'dc1' : 1, 'dc2' 
> : 1
>  2. Start first node in {{dc1}}
>  3. Now bootstrap second node in {{dc2,}} it will throw above exception.
> RCA:
>  
> [doAddEndpoint|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/locator/TokenMetadata.java#L1325]
>  is invoked from the 
> [bootstrap|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L1254]
>  and at this time [local node's rack 
> information|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/locator/TokenMetadata.java#L1276]
>  is available
> However with have {{allocate_tokens_for_keyspace}} option, daemon tries to 
> access rack information even before calling 
> [bootstrap|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L1241]
>  function, at [this 
> place|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L878]
>  which results in NPE
> Fix:
>  Since this is applicable to only very first node for new dc, we can check 
> for {{null}} as:
> {code:java}
> diff --git 
> a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java 
> b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
> index 8d8a6ffeca..e162757d95 100644
> --- a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
> +++ b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
> @@ -205,7 +205,11 @@ public class TokenAllocation
>  final int replicas = rs.getReplicationFactor(dc);
>  
>  Topology topology = tokenMetadata.getTopology();
> -int racks = topology.getDatacenterRacks().get(dc).asMap().size();
> +int racks = 1;
> +if (topology.getDatacenterRacks().get(dc) != null)
> +{
> +racks = topology.getDatacenterRacks().get(dc).asMap().size();
> +}
>  
>  if (racks >= replicas)
>  {
> {code}
> Let me know your comments.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (CASSANDRA-14952) NPE when using allocate_tokens_for_keyspace and add new DC

2019-08-09 Thread mck (JIRA) 


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

mck updated CASSANDRA-14952:

Status: Ready to Commit  (was: Review In Progress)

> NPE when using allocate_tokens_for_keyspace and add new DC
> --
>
> Key: CASSANDRA-14952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14952
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Gossip
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Low
> Fix For: 3.0.x
>
>
> Received following NPE while bootstrapping very first node in the new 
> datacenter with {{allocate_tokens_for_keyspace}} yaml option
> {code:java}
> INFO  21:44:13 JOINING: getting bootstrap token
> Exception (java.lang.NullPointerException) encountered during startup: null
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.dht.tokenallocator.TokenAllocation.getStrategy(TokenAllocation.java:208)
>   at 
> org.apache.cassandra.dht.tokenallocator.TokenAllocation.getStrategy(TokenAllocation.java:170)
>   at 
> org.apache.cassandra.dht.tokenallocator.TokenAllocation.allocateTokens(TokenAllocation.java:55)
>   at 
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
>   at 
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:173)
>   at 
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:854)
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:666)
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:579)
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:351)
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:586)
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:714)
> {code}
> Please find reproducible steps here:
>  1. Set {{allocate_tokens_for_keyspace}} property with 
> {{Networktopologystrategy}} say Networktopologystrategy, 'dc1' : 1, 'dc2' 
> : 1
>  2. Start first node in {{dc1}}
>  3. Now bootstrap second node in {{dc2,}} it will throw above exception.
> RCA:
>  
> [doAddEndpoint|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/locator/TokenMetadata.java#L1325]
>  is invoked from the 
> [bootstrap|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L1254]
>  and at this time [local node's rack 
> information|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/locator/TokenMetadata.java#L1276]
>  is available
> However with have {{allocate_tokens_for_keyspace}} option, daemon tries to 
> access rack information even before calling 
> [bootstrap|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L1241]
>  function, at [this 
> place|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L878]
>  which results in NPE
> Fix:
>  Since this is applicable to only very first node for new dc, we can check 
> for {{null}} as:
> {code:java}
> diff --git 
> a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java 
> b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
> index 8d8a6ffeca..e162757d95 100644
> --- a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
> +++ b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
> @@ -205,7 +205,11 @@ public class TokenAllocation
>  final int replicas = rs.getReplicationFactor(dc);
>  
>  Topology topology = tokenMetadata.getTopology();
> -int racks = topology.getDatacenterRacks().get(dc).asMap().size();
> +int racks = 1;
> +if (topology.getDatacenterRacks().get(dc) != null)
> +{
> +racks = topology.getDatacenterRacks().get(dc).asMap().size();
> +}
>  
>  if (racks >= replicas)
>  {
> {code}
> Let me know your comments.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (CASSANDRA-14952) NPE when using allocate_tokens_for_keyspace and add new DC

2019-08-09 Thread mck (JIRA) 


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

mck updated CASSANDRA-14952:

Status: Review In Progress  (was: Patch Available)

> NPE when using allocate_tokens_for_keyspace and add new DC
> --
>
> Key: CASSANDRA-14952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14952
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Gossip
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Low
> Fix For: 3.0.x
>
>
> Received following NPE while bootstrapping very first node in the new 
> datacenter with {{allocate_tokens_for_keyspace}} yaml option
> {code:java}
> INFO  21:44:13 JOINING: getting bootstrap token
> Exception (java.lang.NullPointerException) encountered during startup: null
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.dht.tokenallocator.TokenAllocation.getStrategy(TokenAllocation.java:208)
>   at 
> org.apache.cassandra.dht.tokenallocator.TokenAllocation.getStrategy(TokenAllocation.java:170)
>   at 
> org.apache.cassandra.dht.tokenallocator.TokenAllocation.allocateTokens(TokenAllocation.java:55)
>   at 
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
>   at 
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:173)
>   at 
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:854)
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:666)
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:579)
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:351)
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:586)
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:714)
> {code}
> Please find reproducible steps here:
>  1. Set {{allocate_tokens_for_keyspace}} property with 
> {{Networktopologystrategy}} say Networktopologystrategy, 'dc1' : 1, 'dc2' 
> : 1
>  2. Start first node in {{dc1}}
>  3. Now bootstrap second node in {{dc2,}} it will throw above exception.
> RCA:
>  
> [doAddEndpoint|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/locator/TokenMetadata.java#L1325]
>  is invoked from the 
> [bootstrap|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L1254]
>  and at this time [local node's rack 
> information|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/locator/TokenMetadata.java#L1276]
>  is available
> However with have {{allocate_tokens_for_keyspace}} option, daemon tries to 
> access rack information even before calling 
> [bootstrap|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L1241]
>  function, at [this 
> place|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L878]
>  which results in NPE
> Fix:
>  Since this is applicable to only very first node for new dc, we can check 
> for {{null}} as:
> {code:java}
> diff --git 
> a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java 
> b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
> index 8d8a6ffeca..e162757d95 100644
> --- a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
> +++ b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
> @@ -205,7 +205,11 @@ public class TokenAllocation
>  final int replicas = rs.getReplicationFactor(dc);
>  
>  Topology topology = tokenMetadata.getTopology();
> -int racks = topology.getDatacenterRacks().get(dc).asMap().size();
> +int racks = 1;
> +if (topology.getDatacenterRacks().get(dc) != null)
> +{
> +racks = topology.getDatacenterRacks().get(dc).asMap().size();
> +}
>  
>  if (racks >= replicas)
>  {
> {code}
> Let me know your comments.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (CASSANDRA-15263) LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null

2019-08-09 Thread Benedict (JIRA) 


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

Benedict commented on CASSANDRA-15263:
--

Thanks [~ferozshaik...@gmail.com], this has the complete messages.  
Unfortunately I just noticed I didn't push my most recent version for you to 
use, and so we do not have the affected table name in the message.  If you pull 
the branch again and rebuild, these messages should print the table name as 
well, so you can more easily source the affected sstables (and I can take a 
look at the relevant schema definition)

> LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null
> ---
>
> Key: CASSANDRA-15263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15263
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: feroz shaik
>Assignee: Benedict
>Priority: Normal
>  Labels: 2.1.16, 3.11.4
> Attachments: sample.system.log, schema.txt, stack_trace.txt, 
> system.log
>
>
> We have  hit a problem today while upgrading from 2.1.16 to 3.11.4.
> we encountered this as soon as the first node started up with 3.11.4 
> The full error stack is attached - [^stack_trace.txt] 
>  
> The below errors continued in the log file as long as the process was up.
> ERROR [Native-Transport-Requests-12] 2019-08-06 03:00:47,135 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-8] 2019-08-06 03:00:48,778 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-13] 2019-08-06 03:00:57,454 
>  
> The nodetool version says 3.11.4 and the no of connections on native por t- 
> 9042 was similar to other nodes. The exceptions were scary that we had to 
> call off the change. Any help and insights to this problem from the community 
> is appreciated.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[cassandra] 01/01: print some debug info if we fail to update the RT digest in LegacyUnfilteredPartition

2019-08-09 Thread benedict 
This is an automated email from the ASF dual-hosted git repository.

benedict pushed a commit to branch 15263-debug
in repository https://gitbox.apache.org/repos/asf/cassandra.git

commit 7f300c15754e0bfcbea723966c737a634041801d
Author: Benedict Elliott Smith 
AuthorDate: Thu Aug 8 18:28:49 2019 +0100

print some debug info if we fail to update the RT digest in 
LegacyUnfilteredPartition
---
 src/java/org/apache/cassandra/db/LegacyLayout.java | 20 +---
 src/java/org/apache/cassandra/db/ReadResponse.java |  5 +
 2 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/src/java/org/apache/cassandra/db/LegacyLayout.java 
b/src/java/org/apache/cassandra/db/LegacyLayout.java
index 87b5d58..a114b68 100644
--- a/src/java/org/apache/cassandra/db/LegacyLayout.java
+++ b/src/java/org/apache/cassandra/db/LegacyLayout.java
@@ -478,7 +478,7 @@ public abstract class LegacyLayout
 }
 }
 
-return new LegacyUnfilteredPartition(info.getPartitionDeletion(), rtl, 
cells);
+return new LegacyUnfilteredPartition(iterator.metadata(), 
partition.partitionKey(), info.getPartitionDeletion(), rtl, cells);
 }
 
 public static void serializeAsLegacyPartition(ReadCommand command, 
UnfilteredRowIterator partition, DataOutputPlus out, int version) throws 
IOException
@@ -1435,12 +1435,16 @@ public abstract class LegacyLayout
 
 public static class LegacyUnfilteredPartition
 {
+final CFMetaData cfMetaData;
+final DecoratedKey partitionKey;
 public final DeletionTime partitionDeletion;
 public final LegacyRangeTombstoneList rangeTombstones;
 public final List cells;
 
-private LegacyUnfilteredPartition(DeletionTime partitionDeletion, 
LegacyRangeTombstoneList rangeTombstones, List cells)
+private LegacyUnfilteredPartition(CFMetaData cfMetaData, DecoratedKey 
partitionKey, DeletionTime partitionDeletion, LegacyRangeTombstoneList 
rangeTombstones, List cells)
 {
+this.cfMetaData = cfMetaData;
+this.partitionKey = partitionKey;
 this.partitionDeletion = partitionDeletion;
 this.rangeTombstones = rangeTombstones;
 this.cells = cells;
@@ -1476,7 +1480,17 @@ public abstract class LegacyLayout
 
digest.update(ByteBufferUtil.bytes(partitionDeletion.markedForDeleteAt()));
 
 if (!rangeTombstones.isEmpty())
-rangeTombstones.updateDigest(digest);
+{
+try
+{
+rangeTombstones.updateDigest(digest);
+}
+catch (Throwable t)
+{
+logger.error("{} {} {}", cfMetaData.cfName, 
cfMetaData.getKeyValidator().getString(partitionKey.getKey()), 
rangeTombstones.toString(), t);
+throw t;
+}
+}
 }
 }
 
diff --git a/src/java/org/apache/cassandra/db/ReadResponse.java 
b/src/java/org/apache/cassandra/db/ReadResponse.java
index 7aa915e..1cd7d98 100644
--- a/src/java/org/apache/cassandra/db/ReadResponse.java
+++ b/src/java/org/apache/cassandra/db/ReadResponse.java
@@ -26,6 +26,9 @@ import java.util.List;
 
 import com.google.common.annotations.VisibleForTesting;
 
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
 import org.apache.cassandra.config.CFMetaData;
 import org.apache.cassandra.db.filter.ClusteringIndexFilter;
 import org.apache.cassandra.db.filter.ColumnFilter;
@@ -45,6 +48,8 @@ import org.apache.cassandra.utils.FBUtilities;
 
 public abstract class ReadResponse
 {
+private static final Logger logger = 
LoggerFactory.getLogger(ReadResponse.class);
+
 // Serializer for single partition read response
 public static final IVersionedSerializer serializer = new 
Serializer();
 // Serializer for the pre-3.0 rang slice responses.


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

[cassandra] branch 15263-debug created (now 7f300c1)

2019-08-09 Thread benedict 
This is an automated email from the ASF dual-hosted git repository.

benedict pushed a change to branch 15263-debug
in repository https://gitbox.apache.org/repos/asf/cassandra.git.


  at 7f300c1  print some debug info if we fail to update the RT digest in 
LegacyUnfilteredPartition

This branch includes the following new commits:

 new 7f300c1  print some debug info if we fail to update the RT digest in 
LegacyUnfilteredPartition

The 1 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.



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

[jira] [Updated] (CASSANDRA-15263) LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null

2019-08-09 Thread feroz shaik (JIRA) 


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

feroz shaik updated CASSANDRA-15263:

Attachment: system.log

> LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null
> ---
>
> Key: CASSANDRA-15263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15263
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: feroz shaik
>Assignee: Benedict
>Priority: Normal
>  Labels: 2.1.16, 3.11.4
> Attachments: sample.system.log, schema.txt, stack_trace.txt, 
> system.log
>
>
> We have  hit a problem today while upgrading from 2.1.16 to 3.11.4.
> we encountered this as soon as the first node started up with 3.11.4 
> The full error stack is attached - [^stack_trace.txt] 
>  
> The below errors continued in the log file as long as the process was up.
> ERROR [Native-Transport-Requests-12] 2019-08-06 03:00:47,135 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-8] 2019-08-06 03:00:48,778 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-13] 2019-08-06 03:00:57,454 
>  
> The nodetool version says 3.11.4 and the no of connections on native por t- 
> 9042 was similar to other nodes. The exceptions were scary that we had to 
> call off the change. Any help and insights to this problem from the community 
> is appreciated.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (CASSANDRA-15263) LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null

2019-08-09 Thread feroz shaik (JIRA) 


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

feroz shaik commented on CASSANDRA-15263:
-

[^system.log] This has additional log entries than previous one.

> LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null
> ---
>
> Key: CASSANDRA-15263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15263
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: feroz shaik
>Assignee: Benedict
>Priority: Normal
>  Labels: 2.1.16, 3.11.4
> Attachments: sample.system.log, schema.txt, stack_trace.txt
>
>
> We have  hit a problem today while upgrading from 2.1.16 to 3.11.4.
> we encountered this as soon as the first node started up with 3.11.4 
> The full error stack is attached - [^stack_trace.txt] 
>  
> The below errors continued in the log file as long as the process was up.
> ERROR [Native-Transport-Requests-12] 2019-08-06 03:00:47,135 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-8] 2019-08-06 03:00:48,778 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-13] 2019-08-06 03:00:57,454 
>  
> The nodetool version says 3.11.4 and the no of connections on native por t- 
> 9042 was similar to other nodes. The exceptions were scary that we had to 
> call off the change. Any help and insights to this problem from the community 
> is appreciated.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Comment Edited] (CASSANDRA-15263) LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null

2019-08-09 Thread Benedict (JIRA) 


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

Benedict edited comment on CASSANDRA-15263 at 8/9/19 9:06 AM:
--

Thanks.  The sample system log appears to have had the message truncated though?

I'm not sure if the ASF has a secure system to upload to - perhaps somebody in 
the community knows better?  

[~ferozshaik...@gmail.com]: if you have somewhere you can upload it, and 
provide me access, that might be easier though.

Otherwise I'll see if I can find some other mechanism.


was (Author: benedict):
Thanks [~ferozshaik...@gmail.com].  The sample system log appears to have had 
the message truncated?

> LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null
> ---
>
> Key: CASSANDRA-15263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15263
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: feroz shaik
>Assignee: Benedict
>Priority: Normal
>  Labels: 2.1.16, 3.11.4
> Attachments: sample.system.log, schema.txt, stack_trace.txt
>
>
> We have  hit a problem today while upgrading from 2.1.16 to 3.11.4.
> we encountered this as soon as the first node started up with 3.11.4 
> The full error stack is attached - [^stack_trace.txt] 
>  
> The below errors continued in the log file as long as the process was up.
> ERROR [Native-Transport-Requests-12] 2019-08-06 03:00:47,135 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-8] 2019-08-06 03:00:48,778 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-13] 2019-08-06 03:00:57,454 
>  
> The nodetool version says 3.11.4 and the no of connections on native por t- 
> 9042 was similar to other nodes. The exceptions were scary that we had to 
> call off the change. Any help and insights to this problem from the community 
> is appreciated.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (CASSANDRA-15263) LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null

2019-08-09 Thread Benedict (JIRA) 


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

Benedict commented on CASSANDRA-15263:
--

Thanks [~ferozshaik...@gmail.com].  The sample system log appears to have had 
the message truncated?

> LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null
> ---
>
> Key: CASSANDRA-15263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15263
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: feroz shaik
>Assignee: Benedict
>Priority: Normal
>  Labels: 2.1.16, 3.11.4
> Attachments: sample.system.log, schema.txt, stack_trace.txt
>
>
> We have  hit a problem today while upgrading from 2.1.16 to 3.11.4.
> we encountered this as soon as the first node started up with 3.11.4 
> The full error stack is attached - [^stack_trace.txt] 
>  
> The below errors continued in the log file as long as the process was up.
> ERROR [Native-Transport-Requests-12] 2019-08-06 03:00:47,135 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-8] 2019-08-06 03:00:48,778 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-13] 2019-08-06 03:00:57,454 
>  
> The nodetool version says 3.11.4 and the no of connections on native por t- 
> 9042 was similar to other nodes. The exceptions were scary that we had to 
> call off the change. Any help and insights to this problem from the community 
> is appreciated.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (CASSANDRA-15263) LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null

2019-08-09 Thread feroz shaik (JIRA) 


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

feroz shaik commented on CASSANDRA-15263:
-

Thank you [~benedict]. I managed to build it locally and place that snapshot 
3.11.4 version on the upgraded node. Below is the sample of the logs for your 
quick reference. I can identify the key from the output and trying to figure 
out which table it might belong to. I shall provide you soon the sstableexport 
to secure location. Please let me know where to do that. [^sample.system.log]

 

 

> LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null
> ---
>
> Key: CASSANDRA-15263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15263
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: feroz shaik
>Assignee: Benedict
>Priority: Normal
>  Labels: 2.1.16, 3.11.4
> Attachments: sample.system.log, schema.txt, stack_trace.txt
>
>
> We have  hit a problem today while upgrading from 2.1.16 to 3.11.4.
> we encountered this as soon as the first node started up with 3.11.4 
> The full error stack is attached - [^stack_trace.txt] 
>  
> The below errors continued in the log file as long as the process was up.
> ERROR [Native-Transport-Requests-12] 2019-08-06 03:00:47,135 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-8] 2019-08-06 03:00:48,778 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-13] 2019-08-06 03:00:57,454 
>  
> The nodetool version says 3.11.4 and the no of connections on native por t- 
> 9042 was similar to other nodes. The exceptions were scary that we had to 
> call off the change. Any help and insights to this problem from the community 
> is appreciated.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (CASSANDRA-15263) LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null

2019-08-09 Thread feroz shaik (JIRA) 


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

feroz shaik updated CASSANDRA-15263:

Attachment: sample.system.log

> LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null
> ---
>
> Key: CASSANDRA-15263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15263
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: feroz shaik
>Assignee: Benedict
>Priority: Normal
>  Labels: 2.1.16, 3.11.4
> Attachments: sample.system.log, schema.txt, stack_trace.txt
>
>
> We have  hit a problem today while upgrading from 2.1.16 to 3.11.4.
> we encountered this as soon as the first node started up with 3.11.4 
> The full error stack is attached - [^stack_trace.txt] 
>  
> The below errors continued in the log file as long as the process was up.
> ERROR [Native-Transport-Requests-12] 2019-08-06 03:00:47,135 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-8] 2019-08-06 03:00:48,778 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-13] 2019-08-06 03:00:57,454 
>  
> The nodetool version says 3.11.4 and the no of connections on native por t- 
> 9042 was similar to other nodes. The exceptions were scary that we had to 
> call off the change. Any help and insights to this problem from the community 
> is appreciated.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (CASSANDRA-15263) LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null

2019-08-09 Thread Benedict (JIRA) 


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

Benedict commented on CASSANDRA-15263:
--

Yes, the branch is definitely 3.11.4, however that message should not be 
showing.  Are you perhaps building trunk, and not 15263-debug?  {{ant real 
clean && ant}} should produce {{build/apache-cassandra-3.11.4-SNAPSHOT.jar}}

> LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null
> ---
>
> Key: CASSANDRA-15263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15263
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: feroz shaik
>Assignee: Benedict
>Priority: Normal
>  Labels: 2.1.16, 3.11.4
> Attachments: schema.txt, stack_trace.txt
>
>
> We have  hit a problem today while upgrading from 2.1.16 to 3.11.4.
> we encountered this as soon as the first node started up with 3.11.4 
> The full error stack is attached - [^stack_trace.txt] 
>  
> The below errors continued in the log file as long as the process was up.
> ERROR [Native-Transport-Requests-12] 2019-08-06 03:00:47,135 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-8] 2019-08-06 03:00:48,778 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-13] 2019-08-06 03:00:57,454 
>  
> The nodetool version says 3.11.4 and the no of connections on native por t- 
> 9042 was similar to other nodes. The exceptions were scary that we had to 
> call off the change. Any help and insights to this problem from the community 
> is appreciated.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (CASSANDRA-15267) Client error metrics not updated when no host is available

2019-08-09 Thread Abhijit Sarkar (JIRA) 


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

Abhijit Sarkar commented on CASSANDRA-15267:


Filed https://datastax-oss.atlassian.net/browse/JAVA-2388

> Client error metrics not updated when no host is available
> --
>
> Key: CASSANDRA-15267
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15267
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Membership, Observability/Metrics
>Reporter: Abhijit Sarkar
>Priority: Normal
>
> None of the client error metrics are updated when 
> {{NoHostAvailableException}} is thrown.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (CASSANDRA-15263) LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null

2019-08-09 Thread feroz shaik (JIRA) 


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

feroz shaik commented on CASSANDRA-15263:
-

Hi Benedict, are we sure this build is 3.11.4 based? When i built it on the 
upgraded node and trying to start - I get this message "Cassandra 4.0 requires 
either Java 8 (update 151 or newer) or Java 11 (or newer). Java 8 update 131 is 
not supported." Can you kindly check please.

> LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null
> ---
>
> Key: CASSANDRA-15263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15263
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: feroz shaik
>Assignee: Benedict
>Priority: Normal
>  Labels: 2.1.16, 3.11.4
> Attachments: schema.txt, stack_trace.txt
>
>
> We have  hit a problem today while upgrading from 2.1.16 to 3.11.4.
> we encountered this as soon as the first node started up with 3.11.4 
> The full error stack is attached - [^stack_trace.txt] 
>  
> The below errors continued in the log file as long as the process was up.
> ERROR [Native-Transport-Requests-12] 2019-08-06 03:00:47,135 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-8] 2019-08-06 03:00:48,778 
> ErrorMessage.java:384 - Unexpected exception during request
>  java.lang.NullPointerException: null
>  ERROR [Native-Transport-Requests-13] 2019-08-06 03:00:57,454 
>  
> The nodetool version says 3.11.4 and the no of connections on native por t- 
> 9042 was similar to other nodes. The exceptions were scary that we had to 
> call off the change. Any help and insights to this problem from the community 
> is appreciated.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (CASSANDRA-15232) Arithmetic operators over decimal truncate results

2019-08-09 Thread Liudmila Kornilova (JIRA) 


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

Liudmila Kornilova updated CASSANDRA-15232:
---
Status: Review In Progress  (was: Changes Suggested)

> Arithmetic operators over decimal truncate results
> --
>
> Key: CASSANDRA-15232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15232
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Benedict
>Assignee: Liudmila Kornilova
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The decimal operators hard-code a 128 bit precision for their computations.  
> Probably a precision needs to be configured or decided somehow, but it’s not 
> clear why 128bit was chosen.  Particularly for multiplication and addition, 
> it’s very unclear why we truncate, which is different to our behaviour for 
> e.g. sum() aggregates.  Probably for division we should also ensure that we 
> do not reduce the precision of the two operands.  A minimum of decimal128 
> seems reasonable, but a maximum does not.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (CASSANDRA-15232) Arithmetic operators over decimal truncate results

2019-08-09 Thread Liudmila Kornilova (JIRA) 


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

Liudmila Kornilova commented on CASSANDRA-15232:


1. (y)
2. I inlined expressions and added a comment

I'll create a ticket about modulo operation for floating point types

I'll take a look at CASSANDRA-15269. Even if this commit is merged first, it 
will be possible to work on the problem by reverting this commit locally

> Arithmetic operators over decimal truncate results
> --
>
> Key: CASSANDRA-15232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15232
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Benedict
>Assignee: Liudmila Kornilova
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The decimal operators hard-code a 128 bit precision for their computations.  
> Probably a precision needs to be configured or decided somehow, but it’s not 
> clear why 128bit was chosen.  Particularly for multiplication and addition, 
> it’s very unclear why we truncate, which is different to our behaviour for 
> e.g. sum() aggregates.  Probably for division we should also ensure that we 
> do not reduce the precision of the two operands.  A minimum of decimal128 
> seems reasonable, but a maximum does not.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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