[jira] [Assigned] (CASSANDRA-14092) Max ttl of 20 years will overflow localDeletionTime
[
https://issues.apache.org/jira/browse/CASSANDRA-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manish Khandelwal reassigned CASSANDRA-14092:
-
Assignee: Manish Khandelwal (was: Paulo Motta)
> 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: Manish Khandelwal
>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-14952) NPE when using allocate_tokens_for_keyspace and add new DC
[
https://issues.apache.org/jira/browse/CASSANDRA-14952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903537#comment-16903537
]
Jaydeepkumar Chovatia commented on CASSANDRA-14952:
---
[~michaelsembwever] Looks good to me. Sorry for the late response.
> 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-15170) Reduce the time needed to release in-JVM dtest cluster resources after close
[
https://issues.apache.org/jira/browse/CASSANDRA-15170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903511#comment-16903511
]
Jon Meredith commented on CASSANDRA-15170:
--
Hopefully this is all the feedback addressed. I've also unified the API
between all of the active branches so things should be stable again post
internode messaging overhaul. I ended up keeping my original IsolatedExecutor
change to make the special shutdown executors as the
{{Executors.newSingleThreadExecutor}} threads hang around a lot longer making
debugging harder.
2.2 |
[Branch|https://github.com/jonmeredith/cassandra/commits/in-jvm-dtest-fixes-v6-2.2]
|
[CircleCI|https://circleci.com/gh/jonmeredith/cassandra/tree/in-jvm-dtest-fixes-v6-2%2E2]
3.0 |
[Branch|https://github.com/jonmeredith/cassandra/commits/in-jvm-dtest-fixes-v6-3.0]
|
[CircleCI|https://circleci.com/gh/jonmeredith/cassandra/tree/in-jvm-dtest-fixes-v6-3%2E0]
3.11 |
[Branch|https://github.com/jonmeredith/cassandra/commits/in-jvm-dtest-fixes-v6-3.11]
|
[CircleCI|https://circleci.com/gh/jonmeredith/cassandra/tree/in-jvm-dtest-fixes-v6-3%2E11]
trunk |
[Branch|https://github.com/jonmeredith/cassandra/commits/in-jvm-dtest-fixes-v6-trunk]
|
[CircleCI|https://circleci.com/gh/jonmeredith/cassandra/tree/in-jvm-dtest-fixes-v6-trunk]
> 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-15267) Client error metrics not updated when no host is available
[
https://issues.apache.org/jira/browse/CASSANDRA-15267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink updated CASSANDRA-15267:
--
Resolution: Invalid
Status: Resolved (was: Triage Needed)
> 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-15267) Client error metrics not updated when no host is available
[
https://issues.apache.org/jira/browse/CASSANDRA-15267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903467#comment-16903467
]
Chris Lohfink commented on CASSANDRA-15267:
---
That’s the DataStax java driver, which is a client to Cassandra but a different
project located [https://github.com/datastax/java-driver] you can open a issue
for it at [https://datastax-oss.atlassian.net/browse/JAVA]
> 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] [Comment Edited] (CASSANDRA-15267) Client error metrics not updated when no host is available
[
https://issues.apache.org/jira/browse/CASSANDRA-15267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903457#comment-16903457
]
Abhijit Sarkar edited comment on CASSANDRA-15267 at 8/9/19 1:08 AM:
[~cnlwsu] the ticket clearly mentions client metrics. More specifically, I'm
looking at
https://github.com/datastax/java-driver/blob/3.5.x/driver-core/src/main/java/com/datastax/driver/core/Metrics.java#L43
was (Author: sarkara1):
[~cnlwsu] the ticket clearly mentions client metrics. More specifically,
https://github.com/tfredrich/cassandra-java-driver/blob/master/driver-core/src/main/java/com/datastax/driver/core/Metrics.java#L44
> 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-15267) Client error metrics not updated when no host is available
[
https://issues.apache.org/jira/browse/CASSANDRA-15267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903457#comment-16903457
]
Abhijit Sarkar commented on CASSANDRA-15267:
[~cnlwsu] the ticket clearly mentions client metrics. More specifically,
https://github.com/tfredrich/cassandra-java-driver/blob/master/driver-core/src/main/java/com/datastax/driver/core/Metrics.java#L44
> 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-15267) Client error metrics not updated when no host is available
[
https://issues.apache.org/jira/browse/CASSANDRA-15267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903414#comment-16903414
]
Chris Lohfink commented on CASSANDRA-15267:
---
Which metric exactly are you looking at? NoHostAvailableException is a driver
error when theres no connections to any (acceptable) Cassandra hosts. Any
metric on that would have to be on the drivers client side and not something in
the Cassandra project.
> 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] [Updated] (CASSANDRA-15270) cassandra jdbc connection string from exasol
[ https://issues.apache.org/jira/browse/CASSANDRA-15270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-15270: Resolution: Not A Bug Status: Resolved (was: Triage Needed) Hi [~rathomai], this type of question is more appropriately asked on our user mail list. Please see the following page for details on signing up: http://cassandra.apache.org/community/ > cassandra jdbc connection string from exasol > > > Key: CASSANDRA-15270 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15270 > Project: Cassandra > Issue Type: Bug >Reporter: Manishkumar Rathod >Priority: Normal > > Hello, could you please share how we can create cassandra jdbc connection > string from exasol to connect cassndra db with SSL option and multi node > option. -- 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-14410) tablehistograms with non-existent table gives an exception
[
https://issues.apache.org/jira/browse/CASSANDRA-14410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink updated CASSANDRA-14410:
--
Fix Version/s: (was: 3.11.x)
Source Control Link:
https://github.com/apache/cassandra/commit/d6c049f0835f137fc07711ec5cf9adc323347c65
Since Version: 4.0
Status: Resolved (was: Ready to Commit)
Resolution: Fixed
> tablehistograms with non-existent table gives an exception
> --
>
> Key: CASSANDRA-14410
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14410
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Tools
>Reporter: Hannu Kröger
>Assignee: Hannu Kröger
>Priority: Normal
> Labels: lhf
> Fix For: 4.x
>
>
> nodetool tablehistograms with non-existent table gives a crazy exception. It
> should give a nice error message like "Table acdc.abba doesn't exist" or
> something like that.
>
> Example:
> {code:java}
> $ nodetool tablehistograms acdc.abba
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=acdc,scope=abba,name=EstimatedPartitionSizeHistogram
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=acdc,scope=abba,name=EstimatedPartitionSizeHistogram
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1445)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
> at
> javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:639)
> at sun.reflect.GeneratedMethodAccessor297.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at
> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
> at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
> at
> javax.management.remote.rmi.RMIConnectionImpl_Stub.getAttribute(Unknown
> Source)
> at
> javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.getAttribute(RMIConnector.java:903)
> at
> javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:273)
> at com.sun.proxy.$Proxy20.getValue(Unknown Source)
> at
> org.apache.cassandra.tools.NodeProbe.getColumnFamilyMetric(NodeProbe.java:1334)
> at
> org.apache.cassandra.tools.nodetool.TableHistograms.execute(TableHistograms.java:62)
> at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:254)
> at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:168){code}
>
--
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 trunk updated: Fix error with non-existent table for nodetool tablehistograms
This is an automated email from the ASF dual-hosted git repository.
clohfink pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new d6c049f Fix error with non-existent table for nodetool tablehistograms
d6c049f is described below
commit d6c049f0835f137fc07711ec5cf9adc323347c65
Author: Hannu Kroger
AuthorDate: Thu Aug 8 11:02:15 2019 -0700
Fix error with non-existent table for nodetool tablehistograms
Patch by Hannu Kroger; reviewed by Chris Lohfink for CASSANDRA-14410
---
CHANGES.txt| 1 +
.../cassandra/tools/nodetool/TableHistograms.java | 50 +-
2 files changed, 30 insertions(+), 21 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index c9adf59..1d0e11d 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0
+ * Fix error with non-existent table for nodetool tablehistograms
(CASSANDRA-14410)
* Catch non-IOException in FileUtils.close to make sure that all resources
are closed (CASSANDRA-15225)
* Align load column in nodetool status output (CASSANDRA-14787)
* CassandraNetworkAuthorizer uses cached roles info (CASSANDRA-15089)
diff --git a/src/java/org/apache/cassandra/tools/nodetool/TableHistograms.java
b/src/java/org/apache/cassandra/tools/nodetool/TableHistograms.java
index f24c8a3..cb3b946 100644
--- a/src/java/org/apache/cassandra/tools/nodetool/TableHistograms.java
+++ b/src/java/org/apache/cassandra/tools/nodetool/TableHistograms.java
@@ -23,17 +23,19 @@ import io.airlift.airline.Arguments;
import io.airlift.airline.Command;
import java.util.ArrayList;
-import java.util.Arrays;
-import java.util.HashMap;
import java.util.Iterator;
import java.util.List;
import java.util.Map;
+import com.google.common.collect.HashMultimap;
+import com.google.common.collect.Multimap;
+
import org.apache.cassandra.db.ColumnFamilyStoreMBean;
import org.apache.cassandra.metrics.CassandraMetricsRegistry;
import org.apache.cassandra.tools.NodeProbe;
import org.apache.cassandra.tools.NodeTool.NodeToolCmd;
import org.apache.cassandra.utils.EstimatedHistogram;
+
import org.apache.commons.lang3.ArrayUtils;
@Command(name = "tablehistograms", description = "Print statistic histograms
for a given table")
@@ -45,40 +47,46 @@ public class TableHistograms extends NodeToolCmd
@Override
public void execute(NodeProbe probe)
{
-Map> tablesList = new HashMap<>();
+Multimap tablesList = HashMultimap.create();
+
+// a > mapping for verification or as reference
if none provided
+Multimap allTables = HashMultimap.create();
+Iterator> tableMBeans =
probe.getColumnFamilyStoreMBeanProxies();
+while (tableMBeans.hasNext())
+{
+Map.Entry entry =
tableMBeans.next();
+allTables.put(entry.getKey(), entry.getValue().getTableName());
+}
+
if (args.size() == 2)
{
-tablesList.put(args.get(0), new
ArrayList(Arrays.asList(args.get(1;
+tablesList.put(args.get(0), args.get(1));
}
else if (args.size() == 1)
{
String[] input = args.get(0).split("\\.");
checkArgument(input.length == 2, "tablehistograms requires
keyspace and table name arguments");
-tablesList.put(input[0], new
ArrayList(Arrays.asList(input[1])));
+tablesList.put(input[0], input[1]);
}
else
{
-// get a list of table stores
-Iterator> tableMBeans =
probe.getColumnFamilyStoreMBeanProxies();
-while (tableMBeans.hasNext())
+// use all tables
+tablesList = allTables;
+}
+
+// verify that all tables to list exist
+for (String keyspace : tablesList.keys())
+{
+for (String table : tablesList.get(keyspace))
{
-Map.Entry entry =
tableMBeans.next();
-String keyspaceName = entry.getKey();
-ColumnFamilyStoreMBean tableProxy = entry.getValue();
-if (!tablesList.containsKey(keyspaceName))
-{
-tablesList.put(keyspaceName, new ArrayList());
-}
-tablesList.get(keyspaceName).add(tableProxy.getTableName());
+if (!allTables.containsEntry(keyspace, table))
+throw new IllegalArgumentException("Unknown table " +
keyspace + '.' + table);
}
}
-Iterator>> iter =
tablesList.entrySet().iterator();
-while(iter.hasNext())
+for (String keyspace : tablesList.keys())
{
-Map.Entry> entry = iter.next();
-String keyspace = entry.getKey();
-for (String table : entry.getValue())
+for (String table : tablesList.get(keyspace))
{
[jira] [Commented] (CASSANDRA-15263) LegacyLayout RangeTombstoneList throws java.lang.NullPointerException: null
[ https://issues.apache.org/jira/browse/CASSANDRA-15263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903177#comment-16903177 ] Benedict commented on CASSANDRA-15263: -- Thanks for the extra info [~ferozshaik...@gmail.com]. I've pushed a slightly tweaked branch [here|https://github.com/belliottsmith/cassandra/tree/15263-debug], that is based on 3.11.4. If you build and run this on your upgraded node, the errors should print some useful information. This will include the range tombstones that are having their digest computed and, more importantly, the affected partition key. If you could then run sstableexport for the partition key on all sstables, for all nodes, and upload the per-node output somewhere I can access it that would be great. Hopefully that should be enough to at least pin down the problematic data, and we can work from there. > 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-15246) Add more information around commit message format expected for a patch
[ https://issues.apache.org/jira/browse/CASSANDRA-15246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-15246: - Resolution: Fixed Status: Resolved (was: Triage Needed) > Add more information around commit message format expected for a patch > -- > > Key: CASSANDRA-15246 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15246 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Normal > Labels: pull-request-available > Fix For: 4.0 > > Attachments: patch_commit_message.patch > > Time Spent: 20m > Remaining Estimate: 0h > > This is primarily from the suggestion > https://issues.apache.org/jira/browse/CASSANDRA-15013?focusedCommentId=16885255=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16885255, > to have the expected commit message format documented. -- 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 trunk updated: Add more information around commit message format expected for a patch
This is an automated email from the ASF dual-hosted git repository. benedict pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new 905ed48 Add more information around commit message format expected for a patch new bf41319 Merge pull request #338 from sumanth-pasupuleti/15246_trunk 905ed48 is described below commit 905ed484932688b14f5bfe83e99b14d63094d62b Author: Sumanth Pasupuleti AuthorDate: Thu Aug 8 08:50:42 2019 -0700 Add more information around commit message format expected for a patch --- doc/source/development/patches.rst | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/doc/source/development/patches.rst b/doc/source/development/patches.rst index 43bdb8c..f3a2cca 100644 --- a/doc/source/development/patches.rst +++ b/doc/source/development/patches.rst @@ -108,7 +108,14 @@ So you've finished coding and the great moment arrives: it's time to submit your a. Attach a patch to JIRA with a single squashed commit in it (per branch), or b. Squash the commits in-place in your branches into one - 6. Include a CHANGES.txt entry (put it at the top of the list), and format the commit message appropriately in your patch ending with the following statement on the last line: ``patch by X; reviewed by Y for CASSANDRA-Z`` + 6. Include a CHANGES.txt entry (put it at the top of the list), and format the commit message appropriately in your patch as below. + +:: + + + + patch by ; reviewed by for CASSANDRA-# + 7. When you're happy with the result, create a patch: :: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15246) Add more information around commit message format expected for a patch
[ https://issues.apache.org/jira/browse/CASSANDRA-15246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903095#comment-16903095 ] Sumanth Pasupuleti commented on CASSANDRA-15246: Thanks [~zznate]. Realized I was not up to date w.r.t. documentation patch submission. This is a much easier workflow. Here is the pull request: https://github.com/apache/cassandra/pull/338. I guess this may also imply I will have to rework my patch around release lifecycle in https://issues.apache.org/jira/browse/CASSANDRA-15249. Will be on it soon. > Add more information around commit message format expected for a patch > -- > > Key: CASSANDRA-15246 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15246 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Normal > Labels: pull-request-available > Fix For: 4.0 > > Attachments: patch_commit_message.patch > > Time Spent: 10m > Remaining Estimate: 0h > > This is primarily from the suggestion > https://issues.apache.org/jira/browse/CASSANDRA-15013?focusedCommentId=16885255=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16885255, > to have the expected commit message format documented. -- 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-15246) Add more information around commit message format expected for a patch
[ https://issues.apache.org/jira/browse/CASSANDRA-15246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-15246: --- Labels: pull-request-available (was: ) > Add more information around commit message format expected for a patch > -- > > Key: CASSANDRA-15246 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15246 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Normal > Labels: pull-request-available > Fix For: 4.0 > > Attachments: patch_commit_message.patch > > > This is primarily from the suggestion > https://issues.apache.org/jira/browse/CASSANDRA-15013?focusedCommentId=16885255=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16885255, > to have the expected commit message format documented. -- 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-14952) NPE when using allocate_tokens_for_keyspace and add new DC
[
https://issues.apache.org/jira/browse/CASSANDRA-14952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899686#comment-16899686
]
mck edited comment on CASSANDRA-14952 at 8/8/19 3:43 PM:
-
> Do we want to treat the first node added in a new datacenter as a unique
> unit, which is what we get with rack = 1?
It seems to make sense to treat such a node as its own unique unit (as it's the
first in any eventuating unit group). Although seeds (non-autobootstrapping)
and non-existant dc names (CASSANDRA-12681) can also prevent that from
happening.
A slightly modified version of your fix [~chovatia.jayd...@gmail.com]
||branch||circleci||asf jenkins testall||asf jenkins dtests||
|[CASSANDRA-14952|https://github.com/thelastpickle/cassandra/commit/3a72a51f9cb06ac85a4c78f3719a598a3a754909]|[circleci|https://circleci.com/workflow-run/b1f8b919-f889-47c5-9019-22a3468a428d]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/41//badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/41/]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/678//badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/678/]|
was (Author: michaelsembwever):
> Do we want to treat the first node added in a new datacenter as a unique
> unit, which is what we get with rack = 1?
It seems to make sense to treat such a node as its own unique unit (as it's the
first in any eventuating unit group). Although seeds (non-autobootstrapping)
and non-existant dc names (CASSANDRA-12681) can also prevent that from
happening.
A slightly modified version of your fix [~chovatia.jayd...@gmail.com]
|| branch || circleci || asf jenkins testall || asf jenkins dtests ||
|
[CASSANDRA-14952|https://github.com/thelastpickle/cassandra/commit/3a72a51f9cb06ac85a4c78f3719a598a3a754909]
|
[circleci|https://circleci.com/workflow-run/b1f8b919-f889-47c5-9019-22a3468a428d]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/40//badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/40/]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/675//badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/675/]
|
> 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
>
[jira] [Created] (CASSANDRA-15270) cassandra jdbc connection string from exasol
Manishkumar Rathod created CASSANDRA-15270: -- Summary: cassandra jdbc connection string from exasol Key: CASSANDRA-15270 URL: https://issues.apache.org/jira/browse/CASSANDRA-15270 Project: Cassandra Issue Type: Bug Reporter: Manishkumar Rathod Hello, could you please share how we can create cassandra jdbc connection string from exasol to connect cassndra db with SSL option and multi node option. -- 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
[
https://issues.apache.org/jira/browse/CASSANDRA-15263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902955#comment-16902955
]
feroz shaik commented on CASSANDRA-15263:
-
I have a confirmation from the team that we had thrift schema before but we did
create new tables(cql) and migrated the data. So the problems related to thrift
and tombstone may be ruled out.
Also, as part of experimenting that single node that got upgraded to 3.11.4,
the upgradesstable step completed. The warnings still show up.
"WARN [ReadStage-4] 2019-08-08 09:04:55,157
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-4,5,main]: {}
java.lang.NullPointerException: null".
[~benedict] - It would be great if you can provide us that special build you
mentioned previously to get us the exact error. Thanks for the help.
> 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
[ https://issues.apache.org/jira/browse/CASSANDRA-15232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-15232: - Status: Changes Suggested (was: Review In Progress) > 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] [Updated] (CASSANDRA-15232) Arithmetic operators over decimal truncate results
[ https://issues.apache.org/jira/browse/CASSANDRA-15232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-15232: - Status: Review In Progress (was: Patch Available) > 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
[
https://issues.apache.org/jira/browse/CASSANDRA-15232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902898#comment-16902898
]
Benedict commented on CASSANDRA-15232:
--
Thanks [~Override], I agree that's the best way forward.
The patch is almost ready to commit. I have a couple of nits for you to
consider:
# {{CONTEXT_WITH_MAX_PRECISION}} and {{MAX_PRECISION}} could be merged into
simply {{MAX_PRECISION}} (as a {{MathContext}}) for brevity, since
{{MAX_PRECISION}} isn't used independently?
# {{leftOperandFirstDigitPos}} and {{rightOperandFirstDigitPos}} both subtract
1, which is cancelled out by the subtraction of one from the other, and are no
longer used for any other calculation. Perhaps rename the variables to
something that indicates we're just getting the normalised scale wrt each
other's decimal point? I haven't come up with an immediately good name, but
I'm sure it's possible. Of course, I hope the compiler eliminates the extra
calculation for us, so it's not strictly necessary - but it helps to avoid
triggering any human linters in future, and more clearly defines the purpose of
the variables.
Otherwise the patch looks ready to commit to me, thanks again for another great
submission.
Reviewing this ticket highlights another follow-up ticket, or discussion,
around the mod operator: I'm not entirely sure makes a lot of sense over
decimal values. Is this definitely a function we want to provide? I've only
ever understood it to be defined over the integer domain. I note that
{{BigDecimal}} names it {{remainder}}, and in fact the Java Language Spec does
the same, so it is not modulus we are offering here and we should rename it
internally and in any docs anyway.
We should probably discuss this for all value types, particularly floating
point types. I honestly was unaware Java supported remainder for floating
point, and the behaviour is unintuitive to say the least ({{0.4 % 0.25 ==
0.15}} ??)
I've also noted your other follow-up, it's good we're shaking out these minor
issues before we release the feature, so your help here is greatly appreciated!
> 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] [Updated] (CASSANDRA-15232) Arithmetic operators over decimal truncate results
[ https://issues.apache.org/jira/browse/CASSANDRA-15232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liudmila Kornilova updated CASSANDRA-15232: --- Test and Documentation Plan: I did not run tests except OperationFctsTest Status: Patch Available (was: In Progress) > 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
[ https://issues.apache.org/jira/browse/CASSANDRA-15232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902870#comment-16902870 ] Liudmila Kornilova commented on CASSANDRA-15232: Hello [~benedict], I removed calculation of first digits. In postgres it makes sense because the operation requires only array element accesses. Also it's a heuristic that does not always lead to better result (in case when first to digits are equal) > 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] [Created] (CASSANDRA-15269) Cassandra fails to process OperationExecutionException which causes ClassCastException
Liudmila Kornilova created CASSANDRA-15269:
--
Summary: Cassandra fails to process OperationExecutionException
which causes ClassCastException
Key: CASSANDRA-15269
URL: https://issues.apache.org/jira/browse/CASSANDRA-15269
Project: Cassandra
Issue Type: Bug
Components: CQL/Interpreter
Reporter: Liudmila Kornilova
While working on CASSANDRA-15232 I noticed that OperationExecutionException is
not processed correctly.
How to reproduce the issue:
1. {{create table d (numerator decimal primary key, denominator decimal);}}
2. {{insert into d (numerator, denominator) values
(123456789112345678921234567893123456, 2);}}
3. {{select numerator % denominator from d;}}
What happens:
1. remainder operation throws ArithmeticException (BigDecimal:1854)
2. The exception is wrapped in OperationExecutionException
3. ClassCastException appears (OperationExecutionException cannot be cast to
FunctionExecutionException at ErrorMessage.java:280)
What should happen:
OperationExecutionException with message "the operation 'decimal % decimal'
failed: Division impossible" should be delivered to user
Note that after fixing CASSANDRA-15232 {{select numerator % denominator from
d;}} will produce correct result of remainder operation.
Currently I am not aware of other cases when OperationExecutionException may
be treated as FunctionExecutionException
--
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] [Created] (CASSANDRA-15268) Published documentation doesn't have correct title
Alex Ott created CASSANDRA-15268: Summary: Published documentation doesn't have correct title Key: CASSANDRA-15268 URL: https://issues.apache.org/jira/browse/CASSANDRA-15268 Project: Cassandra Issue Type: Improvement Components: Documentation/Blog Reporter: Alex Ott The documentation that is currently published on the site (like [this|http://cassandra.apache.org/doc/latest/cql/types.html]) doesn't have correct titles - all pages are having generic title "Documentation", so it's hard to recognize tab with needed documentation, use with Pocket, etc. It would be nice to change title of the pages to include version, section title, for example, for link above: "Cassandra Documentation - 4.0-SNAPSHOT - Data Types" -- 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
