[jira] [Commented] (CASSANDRA-9779) Append-only optimization
[
https://issues.apache.org/jira/browse/CASSANDRA-9779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14984278#comment-14984278
]
Yasuharu Goto commented on CASSANDRA-9779:
--
How about WITH INSERTS ONLY option for each columns?
In our use case, we have mutable and immutable columns in a table and we're
indexing only immutable columns manually now.
We'll be happy if this optimization could be applied to our app.
> Append-only optimization
>
>
> Key: CASSANDRA-9779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9779
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL
>Reporter: Jonathan Ellis
> Fix For: 3.x
>
>
> Many common workloads are append-only: that is, they insert new rows but do
> not update existing ones. However, Cassandra has no way to infer this and so
> it must treat all tables as if they may experience updates in the future.
> If we added syntax to tell Cassandra about this ({{WITH INSERTS ONLY}} for
> instance) then we could do a number of optimizations:
> - Compaction would only need to worry about defragmenting partitions, not
> rows. We could default to DTCS or similar.
> - CollationController could stop scanning sstables as soon as it finds a
> matching row
> - Most importantly, materialized views wouldn't need to worry about deleting
> prior values, which would eliminate the majority of the MV overhead
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10023) Emit a metric for number of local read and write calls
[ https://issues.apache.org/jira/browse/CASSANDRA-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tushar Agrawal updated CASSANDRA-10023: --- Attachment: (was: CASSANDRA-10023.txt) > Emit a metric for number of local read and write calls > -- > > Key: CASSANDRA-10023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10023 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: Tushar Agrawal >Priority: Minor > Labels: lhf > > Many C* drivers have feature to be replica aware and chose the co-ordinator > which is a replica. We should add a metric which tells us whether all calls > to the co-ordinator are replica aware. > We have seen issues where client thinks they are replica aware when they > forget to add routing key at various places in the code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10023) Emit a metric for number of local read and write calls
[ https://issues.apache.org/jira/browse/CASSANDRA-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14984298#comment-14984298 ] Tushar Agrawal commented on CASSANDRA-10023: Oops!! Still learning. Corrections: Please review the update patch. - Reverted changes in StorageProxy.canDoLocalRequest - For read, added metrics in AbstractReadExecutor.java - For writes added code in StorageProxy (not sure if this is right). > Emit a metric for number of local read and write calls > -- > > Key: CASSANDRA-10023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10023 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: Tushar Agrawal >Priority: Minor > Labels: lhf > > Many C* drivers have feature to be replica aware and chose the co-ordinator > which is a replica. We should add a metric which tells us whether all calls > to the co-ordinator are replica aware. > We have seen issues where client thinks they are replica aware when they > forget to add routing key at various places in the code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10023) Emit a metric for number of local read and write calls
[ https://issues.apache.org/jira/browse/CASSANDRA-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tushar Agrawal updated CASSANDRA-10023: --- Attachment: 0001-CASSANDRA-10023.patch > Emit a metric for number of local read and write calls > -- > > Key: CASSANDRA-10023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10023 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: Tushar Agrawal >Priority: Minor > Labels: lhf > Attachments: 0001-CASSANDRA-10023.patch > > > Many C* drivers have feature to be replica aware and chose the co-ordinator > which is a replica. We should add a metric which tells us whether all calls > to the co-ordinator are replica aware. > We have seen issues where client thinks they are replica aware when they > forget to add routing key at various places in the code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10023) Emit a metric for number of local read and write calls
[ https://issues.apache.org/jira/browse/CASSANDRA-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tushar Agrawal updated CASSANDRA-10023: --- Reviewer: sankalp kohli (was: Carl Yeksigian) > Emit a metric for number of local read and write calls > -- > > Key: CASSANDRA-10023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10023 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: Tushar Agrawal >Priority: Minor > Labels: lhf > Attachments: 0001-CASSANDRA-10023.patch > > > Many C* drivers have feature to be replica aware and chose the co-ordinator > which is a replica. We should add a metric which tells us whether all calls > to the co-ordinator are replica aware. > We have seen issues where client thinks they are replica aware when they > forget to add routing key at various places in the code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10631) JSON Update not working with PreparedStatement
Henrik Karlsson created CASSANDRA-10631:
---
Summary: JSON Update not working with PreparedStatement
Key: CASSANDRA-10631
URL: https://issues.apache.org/jira/browse/CASSANDRA-10631
Project: Cassandra
Issue Type: Bug
Components: CQL
Environment: Windows 7, Datastax Java Driver 2.2.0-rc2
Reporter: Henrik Karlsson
Attachments: test-json.zip
When using PreparedStatement to insert and update a row with JSON the first
"INSERT INTO {tablename} JSON ?" statement works OK. But when calling it a
second time with a changed value on a field the field is not updated. If I use
a SimpleStatement instead ("INSERT INTO {tablename} JSON '"+json+"'") the
modified field is updated as expected.
Attaching a test project that shows the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10365) Store types by their CQL names in schema tables instead of fully-qualified internal class names
[
https://issues.apache.org/jira/browse/CASSANDRA-10365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14984357#comment-14984357
]
Robert Stupp edited comment on CASSANDRA-10365 at 11/1/15 11:58 AM:
Apologies for the compilation failure. Fixed it and force-pushed an update.
WRT to the other issues around {{CREATE AGGREGATE}} (e.g. failing tests,
initcond parse errors), we definitely need CASSANDRA-10617 to get it working.
EDIT: --Regarding the NPE with the non-existing keyspace: that's a bug for
{{CREATE AGGREGATE}} and at least {{CREATE TABLE}}. Will open a separate ticket
for this.--
[~iamaleksey], the NPE is caused by the change in {{CQL3Type}}
({{CQL3Type.prepare(String)}} now always executes
{{Schema.instance.getKSMetaData(keyspace).types}} which will NPE for a
non-existing KS). Usually we check for non-existing keyspaces in
{{CQLStatement.validate}} - but that's called after the statement's been
{{prepareKeyspace}}/{{prepare}} methods have been called.
was (Author: snazy):
Apologies for the compilation failure. Fixed it and force-pushed an update.
WRT to the other issues around {{CREATE AGGREGATE}} (e.g. failing tests), we
definitely need CASSANDRA-10617 to get it working.
Regarding the NPE with the non-existing keyspace: that's a bug for {{CREATE
AGGREGATE}} and at least {{CREATE TABLE}}. Will open a separate ticket for this.
> Store types by their CQL names in schema tables instead of fully-qualified
> internal class names
> ---
>
> Key: CASSANDRA-10365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10365
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
> Labels: client-impacting
> Fix For: 3.0.0
>
>
> Consider saving CQL types names for column, UDF/UDA arguments and return
> types, and UDT components.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9960) UDTs still visible after drop/recreate keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-9960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14984328#comment-14984328 ] Robert Stupp commented on CASSANDRA-9960: - Nope - was not able to reproduce. > UDTs still visible after drop/recreate keyspace > --- > > Key: CASSANDRA-9960 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9960 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata >Reporter: Jaroslav Kamenik >Assignee: Robert Stupp >Priority: Minor > Fix For: 2.2.x > > Attachments: CrashTest.java > > > When deploying my app from the scratch I run sequence - drop keyspaces, > create keyspaces, create UDTs, create tables, generate lots of data... After > few cycles, randomly, cassandra ends in state, where I cannot see anything in > table system.schema_usertypes, when I select all rows, but queries with > specified keyspace_name and type_name return old values. Usually it helps to > restart C* and old data disapear, sometimes it needs to delete all C* data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10365) Store types by their CQL names in schema tables instead of fully-qualified internal class names
[
https://issues.apache.org/jira/browse/CASSANDRA-10365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14984357#comment-14984357
]
Robert Stupp commented on CASSANDRA-10365:
--
Apologies for the compilation failure. Fixed it and force-pushed an update.
WRT to the other issues around {{CREATE AGGREGATE}} (e.g. failing tests), we
definitely need CASSANDRA-10617 to get it working.
Regarding the NPE with the non-existing keyspace: that's a bug for {{CREATE
AGGREGATE}} and at least {{CREATE TABLE}}. Will open a separate ticket for this.
> Store types by their CQL names in schema tables instead of fully-qualified
> internal class names
> ---
>
> Key: CASSANDRA-10365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10365
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
> Labels: client-impacting
> Fix For: 3.0.0
>
>
> Consider saving CQL types names for column, UDF/UDA arguments and return
> types, and UDT components.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9543) Integrate release 2.2 java driver
[
https://issues.apache.org/jira/browse/CASSANDRA-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14984344#comment-14984344
]
Robert Stupp commented on CASSANDRA-9543:
-
Yes, we would need JAVA-922 backported to the 2.2 driver.
> Integrate release 2.2 java driver
> -
>
> Key: CASSANDRA-9543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9543
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Assignee: Jeremiah Jordan
> Fix For: 2.2.x
>
>
> Follow-up of CASSANDRA-9493.
> Hint: cleanup {{build.xml}} for commented out {{çassandra-driver-core}} maven
> dependencies.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10311) It looks like our type alterations may be buggy
[ https://issues.apache.org/jira/browse/CASSANDRA-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14984389#comment-14984389 ] Robert Stupp commented on CASSANDRA-10311: -- Do we need type alterations at all? The number of possible, non-breaking type alterations is quite small. The ability to alter a type relies on the current *internal* (storage) representation. Having (documented) type alterations makes it practically impossible for us to change the storage representation for a type in the future. > It looks like our type alterations may be buggy > --- > > Key: CASSANDRA-10311 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10311 > Project: Cassandra > Issue Type: Bug >Reporter: Benedict > > We should document how type coercion works, in all contexts (UDFs, query > responses, merging), and what our criteria are for success. Right now it > looks like we perform no conversion, so we should require that they are > compared in the same way (if they are clusterings), and that they at least > have the same number of bytes (if both fixed width). > Integer type considers itself value compatible with Int32 and Long, which > from an AlterTable point of view at least seems potentially problematic. > It's very likely I'm missing something. However as it stands we seem able to > read an old type from an sstable, have it make it through a compaction > unscathed, and write out the same bytes "as" the new type. If I'm correct > about this behaviour, this will corrupt this partition in the new sstable so > that it cannot be read. > Not marking as critical/blocker, as I'm not familiar enough with how this > works to say if this brief analysis is correct, but if I am we should raise > the priority. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9223) ArithmeticException after decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-9223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14984604#comment-14984604
]
Stefania commented on CASSANDRA-9223:
-
+1
CI is here:
http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-9223-testall/
http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-9223-dtest/
testall is the same as trunk and the new test succeeded both locally and on
Jenkins; dtest did not run but this patch is so trivial (replaces an exception
with a return) that I don't think we need to launch the dtests.
> ArithmeticException after decommission
> --
>
> Key: CASSANDRA-9223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9223
> Project: Cassandra
> Issue Type: Bug
>Reporter: Brandon Williams
>Assignee: Branimir Lambov
>Priority: Minor
> Fix For: 3.1
>
>
> Also seen on trunk while working on CASSANDRA-8072:
> {noformat}
> ERROR 19:21:33 Exception in thread Thread[BatchlogTasks:1,5,main]
> java.lang.ArithmeticException: / by zero
> at
> org.apache.cassandra.db.BatchlogManager.replayAllFailedBatches(BatchlogManager.java:173)
> ~[main/:na]
> at
> org.apache.cassandra.db.BatchlogManager.access$000(BatchlogManager.java:61)
> ~[main/:na]
> at
> org.apache.cassandra.db.BatchlogManager$1.runMayThrow(BatchlogManager.java:91)
> ~[main/:na]
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:82)
> ~[main/:na]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_76]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> [na:1.7.0_76]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> [na:1.7.0_76]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [na:1.7.0_76]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_76]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_76]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_76]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10298) Replaced dead node stayed in gossip forever
[
https://issues.apache.org/jira/browse/CASSANDRA-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14984617#comment-14984617
]
Stefania commented on CASSANDRA-10298:
--
+1, pending CI here:
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10298-2.1-testall/
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10298-2.1-dtest/
The code that catches the exception in {{handleStateLeft()}} will be improved
by CASSANDRA-10089 where we will return an empty collection in case of no
tokens therefore removing the need for a try/catch. We must also remember to
check for {{!tokens.isEmpty()}} in {{excise()}} but we'll deal with this in
10089.
A test to reproduce this problem would be helpful to ensure we don't break it
again later on. [~dikanggu] are you able to reproduce this regularly and if so
what are the exact steps?
> Replaced dead node stayed in gossip forever
> ---
>
> Key: CASSANDRA-10298
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10298
> Project: Cassandra
> Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Dikang Gu
> Fix For: 2.1.x
>
> Attachments: CASSANDRA-10298.patch
>
>
> The dead node stayed in the nodetool status,
> DN 10.210.165.55379.76 GB 256 ? null
> And in the log, it throws NPE when trying to remove it.
> {code}
> 2015-09-10_06:41:22.92453 ERROR 06:41:22 Exception in thread
> Thread[GossipStage:1,5,main]
> 2015-09-10_06:41:22.92454 java.lang.NullPointerException: null
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.utils.UUIDGen.decompose(UUIDGen.java:100)
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.db.HintedHandOffManager.deleteHintsForEndpoint(HintedHandOffManager.java:201)
>
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.service.StorageService.excise(StorageService.java:1886)
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.service.StorageService.excise(StorageService.java:1902)
> 2015-09-10_06:41:22.92456 at
> org.apache.cassandra.service.StorageService.handleStateLeft(StorageService.java:1805)
> 2015-09-10_06:41:22.92457 at
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:1473)
>
> 2015-09-10_06:41:22.92457 at
> org.apache.cassandra.service.StorageService.onJoin(StorageService.java:2099)
> 2015-09-10_06:41:22.92457 at
> org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1009)
> 2015-09-10_06:41:22.92458 at
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1085)
> 2015-09-10_06:41:22.92458 at
> org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49)
>
> 2015-09-10_06:41:22.92458 at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62)
> 2015-09-10_06:41:22.92459 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_45]
> 2015-09-10_06:41:22.92460 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_45]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7306) Support "edge dcs" with more flexible gossip
[
https://issues.apache.org/jira/browse/CASSANDRA-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14984783#comment-14984783
]
Jeff Jirsa commented on CASSANDRA-7306:
---
This ticket title mentions "more flexible gossip" - does this carry into
requests/CL as well? What's the desired/expected behavior if a KS uses NTS to
have rf=3 in dcs {a,b,c}, but hosts in dc=b are set not to gossip with hosts in
dc=c, and vice versa? CL=ALL fails, CL=QUORUM fills with a+b, and writes just
assume all nodes in c are down? Or should it be smart enough to know that c is
disconnected, and not count hosts in c towards quorum/ALL ?
> Support "edge dcs" with more flexible gossip
>
>
> Key: CASSANDRA-7306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7306
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Tupshin Harper
> Labels: ponies
>
> As Cassandra clusters get bigger and bigger, and their topology becomes more
> complex, there is more and more need for a notion of "hub" and "spoke"
> datacenters.
> One of the big obstacles to supporting hundreds (or thousands) of remote dcs,
> is the assumption that all dcs need to talk to each other (and be connected
> all the time).
> This ticket is a vague placeholder with the goals of achieving:
> 1) better behavioral support for occasionally disconnected datacenters
> 2) explicit support for custom dc to dc routing. A simple approach would be
> an optional per-dc annotation of which other DCs that DC could gossip with.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
