[jira] [Commented] (CASSANDRA-12365) Document cassandra stress
[ https://issues.apache.org/jira/browse/CASSANDRA-12365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15804701#comment-15804701 ] Christopher Batey commented on CASSANDRA-12365: --- Thanks [~spo...@gmail.com] I've updated the branch based on your comments > Document cassandra stress > - > > Key: CASSANDRA-12365 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12365 > Project: Cassandra > Issue Type: Improvement > Components: Documentation and Website >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Minor > Labels: stress > Fix For: 3.x > > > I've started on this so creating a ticket to avoid duplicate work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12563) Stress daemon help is incorrect
[ https://issues.apache.org/jira/browse/CASSANDRA-12563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15804666#comment-15804666 ] Christopher Batey commented on CASSANDRA-12563: --- Thanks [~bdeggleston] updated patch here: https://github.com/chbatey/cassandra-1/commit/99c82862381c6d6f1c8b2b731411bb60b6921147.patch > Stress daemon help is incorrect > --- > > Key: CASSANDRA-12563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12563 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Trivial > Labels: stress > Fix For: 3.x > > > It says provide the option -sendToDaemon where as only -send-to and -sendto > work > Fix here: > https://github.com/chbatey/cassandra-1/tree/stress-daemon -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11634) Add write timestamp to trace
[ https://issues.apache.org/jira/browse/CASSANDRA-11634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15804658#comment-15804658 ] Christopher Batey commented on CASSANDRA-11634: --- Agreed, this was pretty hacky :) > Add write timestamp to trace > > > Key: CASSANDRA-11634 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11634 > Project: Cassandra > Issue Type: Improvement > Components: Observability >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Minor > Fix For: 3.x > > Attachments: 0001-Add-trace-message-for-write-timestamp.patch > > > Diagnosing issues with clock drift would be easier if trace had the mutation > timestamp. I'll add a patch for this soon. > Patch attached or at: > https://github.com/chbatey/cassandra-1/tree/trace-write-timestamp -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-13108) Uncaught exeption stack traces not logged
[
https://issues.apache.org/jira/browse/CASSANDRA-13108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Batey updated CASSANDRA-13108:
--
Status: Patch Available (was: Open)
Trivial patch here:
https://github.com/chbatey/cassandra-1/commit/fc81ff82fc96288336836d066d249b35edf44994.patch
> Uncaught exeption stack traces not logged
> -
>
> Key: CASSANDRA-13108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13108
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Christopher Batey
>Assignee: Christopher Batey
>Priority: Trivial
>
> In a refactoring to parameterized logging we lost the stack traces of
> uncaught exceptions. This means, apart from the thread, I have no idea where
> they come from e.g.
> {code}
> ERROR [OptionalTasks:1] 2017-01-06 12:53:14,204 CassandraDaemon.java:231 -
> Exception in thread Thread[OptionalTasks:1,5,main]
> java.lang.NullPointerException: null
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-13108) Uncaught exeption stack traces not logged
Christopher Batey created CASSANDRA-13108:
-
Summary: Uncaught exeption stack traces not logged
Key: CASSANDRA-13108
URL: https://issues.apache.org/jira/browse/CASSANDRA-13108
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Christopher Batey
Assignee: Christopher Batey
Priority: Trivial
In a refactoring to parameterized logging we lost the stack traces of uncaught
exceptions. This means, apart from the thread, I have no idea where they come
from e.g.
{code}
ERROR [OptionalTasks:1] 2017-01-06 12:53:14,204 CassandraDaemon.java:231 -
Exception in thread Thread[OptionalTasks:1,5,main]
java.lang.NullPointerException: null
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12625) Distinguish between CAS prepare and propose failures
[
https://issues.apache.org/jira/browse/CASSANDRA-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15503208#comment-15503208
]
Christopher Batey edited comment on CASSANDRA-12625 at 9/19/16 12:01 PM:
-
{quote}
We can, though my preferred way of adding that information would probably be to
add a new boolean to WriteTimeoutException when WriteType is CAS to indicate if
we can guarantee it won't be applied or not (could call it canSafelyReply for
instance).
{quote}
Agreed. This can still be made applicable even if we entirely change our paxos
algorithm e.g. epaxos
I'll put together a patch.
was (Author: chbatey):
??
We can, though my preferred way of adding that information would probably be to
add a new boolean to WriteTimeoutException when WriteType is CAS to indicate if
we can guarantee it won't be applied or not (could call it canSafelyReply for
instance).
??
Agreed. This can still be made applicable even if we entirely change our paxos
algorithm e.g. epaxos
I'll put together a patch.
> Distinguish between CAS prepare and propose failures
>
>
> Key: CASSANDRA-12625
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12625
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Christopher Batey
>Assignee: Christopher Batey
>Priority: Minor
> Labels: cas
> Fix For: 3.x
>
>
> I spoke to a lot of users at the summit and had the feedback that the hardest
> part of building applications using LWTs is dealing with WriteTimeouts of
> type CAS.
> Following up from https://issues.apache.org/jira/browse/CASSANDRA-8672 I
> think we should add a separate WriteType for timing out during the prepare
> phase assuming we can advise users to retry the operation or be confident it
> has failed as it won't be completed by a later SERIAL read or LWT.
> We can't remove the ambiguity at the propose phase but this will remove one
> of the unknown cases.
> cc [~slebresne] [~bdeggleston] [~spo...@gmail.com]
> Happy to do a patch for this but assuming it will need a native protocol
> change when can we do it?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12625) Distinguish between CAS prepare and propose failures
[ https://issues.apache.org/jira/browse/CASSANDRA-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15503208#comment-15503208 ] Christopher Batey commented on CASSANDRA-12625: --- ?? We can, though my preferred way of adding that information would probably be to add a new boolean to WriteTimeoutException when WriteType is CAS to indicate if we can guarantee it won't be applied or not (could call it canSafelyReply for instance). ?? Agreed. This can still be made applicable even if we entirely change our paxos algorithm e.g. epaxos I'll put together a patch. > Distinguish between CAS prepare and propose failures > > > Key: CASSANDRA-12625 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12625 > Project: Cassandra > Issue Type: Improvement >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Minor > Labels: cas > Fix For: 3.x > > > I spoke to a lot of users at the summit and had the feedback that the hardest > part of building applications using LWTs is dealing with WriteTimeouts of > type CAS. > Following up from https://issues.apache.org/jira/browse/CASSANDRA-8672 I > think we should add a separate WriteType for timing out during the prepare > phase assuming we can advise users to retry the operation or be confident it > has failed as it won't be completed by a later SERIAL read or LWT. > We can't remove the ambiguity at the propose phase but this will remove one > of the unknown cases. > cc [~slebresne] [~bdeggleston] [~spo...@gmail.com] > Happy to do a patch for this but assuming it will need a native protocol > change when can we do it? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12237) Cassandra stress graphing is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15495642#comment-15495642
]
Christopher Batey commented on CASSANDRA-12237:
---
Doh! Now it is [~slebresne]
> Cassandra stress graphing is broken
> ---
>
> Key: CASSANDRA-12237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12237
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
> Fix For: 3.x
>
>
> Cassandra stress relies on a tmp file with the stress output so it can parse
> it and put it the the graph html.
> However the contents of this file is now broken:
> {code}
> Sleeping 2s...Sleeping 2s...
> Sleeping 2s...
> Warming up WRITE with 5 iterations...Warming up WRITE with 5
> iterations...
> Warming up WRITE with 5 iterations...
> Running WRITE with 500 threads 10 secondsRunning WRITE with 500 threads 10
> seconds
> Running WRITE with 500 threads 10 seconds
> ...
> {code}
> This is as we create a {code}MultiPrintStream{code} that inherits from
> {code}PrintWriter{code} and then delegate the call to super as well as a list
> of other PrintWriters
> The call to super for println comes back into our print method so every line
> gets logged multiple times as we do the for (PrintStream s: newStreams) many
> times.
> We can change this to use composition and use our own interface if we want to
> use a composite for logging the results
> This results in the parsing of this file not quite working and the aggregate
> stats not working in produced graphs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12237) Cassandra stress graphing is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15491148#comment-15491148
]
Christopher Batey commented on CASSANDRA-12237:
---
Thanks [~slebresne] i have rebased the branch
> Cassandra stress graphing is broken
> ---
>
> Key: CASSANDRA-12237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12237
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
> Fix For: 3.x
>
>
> Cassandra stress relies on a tmp file with the stress output so it can parse
> it and put it the the graph html.
> However the contents of this file is now broken:
> {code}
> Sleeping 2s...Sleeping 2s...
> Sleeping 2s...
> Warming up WRITE with 5 iterations...Warming up WRITE with 5
> iterations...
> Warming up WRITE with 5 iterations...
> Running WRITE with 500 threads 10 secondsRunning WRITE with 500 threads 10
> seconds
> Running WRITE with 500 threads 10 seconds
> ...
> {code}
> This is as we create a {code}MultiPrintStream{code} that inherits from
> {code}PrintWriter{code} and then delegate the call to super as well as a list
> of other PrintWriters
> The call to super for println comes back into our print method so every line
> gets logged multiple times as we do the for (PrintStream s: newStreams) many
> times.
> We can change this to use composition and use our own interface if we want to
> use a composite for logging the results
> This results in the parsing of this file not quite working and the aggregate
> stats not working in produced graphs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12626) LWT contention appears to be under reported
[
https://issues.apache.org/jira/browse/CASSANDRA-12626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Batey updated CASSANDRA-12626:
--
Status: Patch Available (was: Open)
Branch here: https://github.com/chbatey/cassandra-1/tree/issue-12626
Or patch for the commit:
https://github.com/chbatey/cassandra-1/commit/5aa75573a8e3a48460d1e1faf52308038e550ff5.patch
> LWT contention appears to be under reported
> ---
>
> Key: CASSANDRA-12626
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12626
> Project: Cassandra
> Issue Type: Bug
> Components: Observability
>Reporter: Christopher Batey
>Assignee: Christopher Batey
>Priority: Minor
> Fix For: 3.x
>
>
> I was surprised how little contention was being reported and looking at the
> code we miss out reporting contention when there is a timeout at the prepare
> phase.
> If this {{StorageProxy.beginAndRepairPaxos}} throws then the contentions
> count isn't added to the histogram.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12626) LWT contention appears to be under reported
[
https://issues.apache.org/jira/browse/CASSANDRA-12626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Batey updated CASSANDRA-12626:
--
Description:
I was surprised how little contention was being reported and looking at the
code we miss out reporting contention when there is a timeout at the prepare
phase.
If this {{StorageProxy.beginAndRepairPaxos}} throws then the contentions count
isn't added to the histogram.
was:
I was surprised how little contention was being reported and looking at the
code we miss out reporting contention when there is a timeout at the prepare
phase.
If this {{StorageProxy.beginAndRepairPaxos}} throws then the contentions
variable isn't added to the metric.
The current way we do it means that we only update the counter once in the
finally but given the expense of LWTs / the fact we also sleep after contention
perhaps we should just increment it in the loop.
> LWT contention appears to be under reported
> ---
>
> Key: CASSANDRA-12626
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12626
> Project: Cassandra
> Issue Type: Bug
> Components: Observability
>Reporter: Christopher Batey
>Assignee: Christopher Batey
>Priority: Minor
> Fix For: 3.x
>
>
> I was surprised how little contention was being reported and looking at the
> code we miss out reporting contention when there is a timeout at the prepare
> phase.
> If this {{StorageProxy.beginAndRepairPaxos}} throws then the contentions
> count isn't added to the histogram.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12626) LWT contention appears to be under reported
Christopher Batey created CASSANDRA-12626:
-
Summary: LWT contention appears to be under reported
Key: CASSANDRA-12626
URL: https://issues.apache.org/jira/browse/CASSANDRA-12626
Project: Cassandra
Issue Type: Bug
Components: Observability
Reporter: Christopher Batey
Assignee: Christopher Batey
Priority: Minor
Fix For: 3.x
I was surprised how little contention was being reported and looking at the
code we miss out reporting contention when there is a timeout at the prepare
phase.
If this {{StorageProxy.beginAndRepairPaxos}} throws then the contentions
variable isn't added to the metric.
The current way we do it means that we only update the counter once in the
finally but given the expense of LWTs / the fact we also sleep after contention
perhaps we should just increment it in the loop.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12625) Distinguish between CAS prepare and propose failures
[ https://issues.apache.org/jira/browse/CASSANDRA-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey updated CASSANDRA-12625: -- Labels: cas (was: ) > Distinguish between CAS prepare and propose failures > > > Key: CASSANDRA-12625 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12625 > Project: Cassandra > Issue Type: Improvement >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Minor > Labels: cas > Fix For: 3.x > > > I spoke to a lot of users at the summit and had the feedback that the hardest > part of building applications using LWTs is dealing with WriteTimeouts of > type CAS. > Following up from https://issues.apache.org/jira/browse/CASSANDRA-8672 I > think we should add a separate WriteType for timing out during the prepare > phase assuming we can advise users to retry the operation or be confident it > has failed as it won't be completed by a later SERIAL read or LWT. > We can't remove the ambiguity at the propose phase but this will remove one > of the unknown cases. > cc [~slebresne] [~bdeggleston] [~spo...@gmail.com] > Happy to do a patch for this but assuming it will need a native protocol > change when can we do it? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12625) Distinguish between CAS prepare and propose failures
Christopher Batey created CASSANDRA-12625: - Summary: Distinguish between CAS prepare and propose failures Key: CASSANDRA-12625 URL: https://issues.apache.org/jira/browse/CASSANDRA-12625 Project: Cassandra Issue Type: Improvement Reporter: Christopher Batey Assignee: Christopher Batey Priority: Minor Fix For: 3.x I spoke to a lot of users at the summit and had the feedback that the hardest part of building applications using LWTs is dealing with WriteTimeouts of type CAS. Following up from https://issues.apache.org/jira/browse/CASSANDRA-8672 I think we should add a separate WriteType for timing out during the prepare phase assuming we can advise users to retry the operation or be confident it has failed as it won't be completed by a later SERIAL read or LWT. We can't remove the ambiguity at the propose phase but this will remove one of the unknown cases. cc [~slebresne] [~bdeggleston] [~spo...@gmail.com] Happy to do a patch for this but assuming it will need a native protocol change when can we do it? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12585) Fixup Cassandra Stress reporting thread model and precision
[ https://issues.apache.org/jira/browse/CASSANDRA-12585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15465090#comment-15465090 ] Christopher Batey commented on CASSANDRA-12585: --- I'll aim to review this week unless you get to it first [~tjake] > Fixup Cassandra Stress reporting thread model and precision > --- > > Key: CASSANDRA-12585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12585 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Nitsan Wakart >Assignee: Nitsan Wakart >Priority: Minor > Labels: stress > > Stress current reporting thread currently has a complex, slow and imprecise > method of collecting measurements from the Consumer threads. > StressMetrics thread iterates through the Timers (one Timer per op per > Consumer thread), blocks until the consumer thread collects a measurement on > that operation, which forces the consumer thread to collect a report and > unblock the StressMetrics thread. This means: > - Reporting intervals are effected by sleep interval accuracy on the > StressMetrics thread > - Interval report timing is staggered as the operations get collected. > - The intended logging interval often does not resemble the effective > interval. > This patch simplifies collection method and resolves the above issues: > - Each Consumer thread submits timing data to a queue > - StressMetrics thread reads from the queues and merges the data into a report > - StressMetrics reads and reports for the intended interval, so not effected > by timing inaccuracies > - Measurement intervals are aligned to the second, improving the ease of > measurements correlation from several nodes. > See branch here: > https://github.com/nitsanw/cassandra/tree/fix-reporting-sync-issues -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12237) Cassandra stress graphing is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15459409#comment-15459409
]
Christopher Batey commented on CASSANDRA-12237:
---
Fixed
> Cassandra stress graphing is broken
> ---
>
> Key: CASSANDRA-12237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12237
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
> Fix For: 3.x
>
>
> Cassandra stress relies on a tmp file with the stress output so it can parse
> it and put it the the graph html.
> However the contents of this file is now broken:
> {code}
> Sleeping 2s...Sleeping 2s...
> Sleeping 2s...
> Warming up WRITE with 5 iterations...Warming up WRITE with 5
> iterations...
> Warming up WRITE with 5 iterations...
> Running WRITE with 500 threads 10 secondsRunning WRITE with 500 threads 10
> seconds
> Running WRITE with 500 threads 10 seconds
> ...
> {code}
> This is as we create a {code}MultiPrintStream{code} that inherits from
> {code}PrintWriter{code} and then delegate the call to super as well as a list
> of other PrintWriters
> The call to super for println comes back into our print method so every line
> gets logged multiple times as we do the for (PrintStream s: newStreams) many
> times.
> We can change this to use composition and use our own interface if we want to
> use a composite for logging the results
> This results in the parsing of this file not quite working and the aggregate
> stats not working in produced graphs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12237) Cassandra stress graphing is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15458257#comment-15458257
]
Christopher Batey commented on CASSANDRA-12237:
---
[~iamaleksey] Updated the commit msg, CHANGES.txt and StressAction.
> Cassandra stress graphing is broken
> ---
>
> Key: CASSANDRA-12237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12237
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
> Fix For: 3.x
>
>
> Cassandra stress relies on a tmp file with the stress output so it can parse
> it and put it the the graph html.
> However the contents of this file is now broken:
> {code}
> Sleeping 2s...Sleeping 2s...
> Sleeping 2s...
> Warming up WRITE with 5 iterations...Warming up WRITE with 5
> iterations...
> Warming up WRITE with 5 iterations...
> Running WRITE with 500 threads 10 secondsRunning WRITE with 500 threads 10
> seconds
> Running WRITE with 500 threads 10 seconds
> ...
> {code}
> This is as we create a {code}MultiPrintStream{code} that inherits from
> {code}PrintWriter{code} and then delegate the call to super as well as a list
> of other PrintWriters
> The call to super for println comes back into our print method so every line
> gets logged multiple times as we do the for (PrintStream s: newStreams) many
> times.
> We can change this to use composition and use our own interface if we want to
> use a composite for logging the results
> This results in the parsing of this file not quite working and the aggregate
> stats not working in produced graphs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12237) Cassandra stress graphing is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15385861#comment-15385861
]
Christopher Batey edited comment on CASSANDRA-12237 at 9/2/16 7:36 AM:
---
Branch here: https://github.com/chbatey/cassandra-1/tree/stress-graph-logging
* The temporary results log contained each line three times
* None of the aggregate metrics showed up due to name changes in the logs/stats
json
* Auto run results were all the same color as the graph code was looking for a
log line that the user hadn't specified a thread count was no long there (all
results ended up with the same name)
* Only the first aggregates were shown for a multi run
was (Author: chbatey):
Branch here: https://github.com/chbatey/cassandra-1/tree/stress-graph-logging
Commit msg explains all the changes. I found a few more issues before i could
get graphs working again.
> Cassandra stress graphing is broken
> ---
>
> Key: CASSANDRA-12237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12237
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
> Fix For: 3.x
>
>
> Cassandra stress relies on a tmp file with the stress output so it can parse
> it and put it the the graph html.
> However the contents of this file is now broken:
> {code}
> Sleeping 2s...Sleeping 2s...
> Sleeping 2s...
> Warming up WRITE with 5 iterations...Warming up WRITE with 5
> iterations...
> Warming up WRITE with 5 iterations...
> Running WRITE with 500 threads 10 secondsRunning WRITE with 500 threads 10
> seconds
> Running WRITE with 500 threads 10 seconds
> ...
> {code}
> This is as we create a {code}MultiPrintStream{code} that inherits from
> {code}PrintWriter{code} and then delegate the call to super as well as a list
> of other PrintWriters
> The call to super for println comes back into our print method so every line
> gets logged multiple times as we do the for (PrintStream s: newStreams) many
> times.
> We can change this to use composition and use our own interface if we want to
> use a composite for logging the results
> This results in the parsing of this file not quite working and the aggregate
> stats not working in produced graphs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12237) Cassandra stress graphing is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15455693#comment-15455693
]
Christopher Batey commented on CASSANDRA-12237:
---
Thanks [~jkni] I have removed the patch just in case.
> Cassandra stress graphing is broken
> ---
>
> Key: CASSANDRA-12237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12237
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
> Fix For: 3.x
>
>
> Cassandra stress relies on a tmp file with the stress output so it can parse
> it and put it the the graph html.
> However the contents of this file is now broken:
> {code}
> Sleeping 2s...Sleeping 2s...
> Sleeping 2s...
> Warming up WRITE with 5 iterations...Warming up WRITE with 5
> iterations...
> Warming up WRITE with 5 iterations...
> Running WRITE with 500 threads 10 secondsRunning WRITE with 500 threads 10
> seconds
> Running WRITE with 500 threads 10 seconds
> ...
> {code}
> This is as we create a {code}MultiPrintStream{code} that inherits from
> {code}PrintWriter{code} and then delegate the call to super as well as a list
> of other PrintWriters
> The call to super for println comes back into our print method so every line
> gets logged multiple times as we do the for (PrintStream s: newStreams) many
> times.
> We can change this to use composition and use our own interface if we want to
> use a composite for logging the results
> This results in the parsing of this file not quite working and the aggregate
> stats not working in produced graphs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12237) Cassandra stress graphing is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15455693#comment-15455693
]
Christopher Batey edited comment on CASSANDRA-12237 at 9/1/16 3:02 PM:
---
Thanks [~jkni] I have removed the patch just in case. I also rebased as the
print settings heavily conflicted.
was (Author: chbatey):
Thanks [~jkni] I have removed the patch just in case.
> Cassandra stress graphing is broken
> ---
>
> Key: CASSANDRA-12237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12237
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
> Fix For: 3.x
>
>
> Cassandra stress relies on a tmp file with the stress output so it can parse
> it and put it the the graph html.
> However the contents of this file is now broken:
> {code}
> Sleeping 2s...Sleeping 2s...
> Sleeping 2s...
> Warming up WRITE with 5 iterations...Warming up WRITE with 5
> iterations...
> Warming up WRITE with 5 iterations...
> Running WRITE with 500 threads 10 secondsRunning WRITE with 500 threads 10
> seconds
> Running WRITE with 500 threads 10 seconds
> ...
> {code}
> This is as we create a {code}MultiPrintStream{code} that inherits from
> {code}PrintWriter{code} and then delegate the call to super as well as a list
> of other PrintWriters
> The call to super for println comes back into our print method so every line
> gets logged multiple times as we do the for (PrintStream s: newStreams) many
> times.
> We can change this to use composition and use our own interface if we want to
> use a composite for logging the results
> This results in the parsing of this file not quite working and the aggregate
> stats not working in produced graphs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12237) Cassandra stress graphing is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Batey updated CASSANDRA-12237:
--
Attachment: (was: 12237-trunk.txt)
> Cassandra stress graphing is broken
> ---
>
> Key: CASSANDRA-12237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12237
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
> Fix For: 3.x
>
>
> Cassandra stress relies on a tmp file with the stress output so it can parse
> it and put it the the graph html.
> However the contents of this file is now broken:
> {code}
> Sleeping 2s...Sleeping 2s...
> Sleeping 2s...
> Warming up WRITE with 5 iterations...Warming up WRITE with 5
> iterations...
> Warming up WRITE with 5 iterations...
> Running WRITE with 500 threads 10 secondsRunning WRITE with 500 threads 10
> seconds
> Running WRITE with 500 threads 10 seconds
> ...
> {code}
> This is as we create a {code}MultiPrintStream{code} that inherits from
> {code}PrintWriter{code} and then delegate the call to super as well as a list
> of other PrintWriters
> The call to super for println comes back into our print method so every line
> gets logged multiple times as we do the for (PrintStream s: newStreams) many
> times.
> We can change this to use composition and use our own interface if we want to
> use a composite for logging the results
> This results in the parsing of this file not quite working and the aggregate
> stats not working in produced graphs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12237) Cassandra stress graphing is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15454458#comment-15454458
]
Christopher Batey commented on CASSANDRA-12237:
---
Thanks [~jkni]
I've updated the commit to remove the comment and change the test name.
> Cassandra stress graphing is broken
> ---
>
> Key: CASSANDRA-12237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12237
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
> Fix For: 3.x
>
> Attachments: 12237-trunk.txt
>
>
> Cassandra stress relies on a tmp file with the stress output so it can parse
> it and put it the the graph html.
> However the contents of this file is now broken:
> {code}
> Sleeping 2s...Sleeping 2s...
> Sleeping 2s...
> Warming up WRITE with 5 iterations...Warming up WRITE with 5
> iterations...
> Warming up WRITE with 5 iterations...
> Running WRITE with 500 threads 10 secondsRunning WRITE with 500 threads 10
> seconds
> Running WRITE with 500 threads 10 seconds
> ...
> {code}
> This is as we create a {code}MultiPrintStream{code} that inherits from
> {code}PrintWriter{code} and then delegate the call to super as well as a list
> of other PrintWriters
> The call to super for println comes back into our print method so every line
> gets logged multiple times as we do the for (PrintStream s: newStreams) many
> times.
> We can change this to use composition and use our own interface if we want to
> use a composite for logging the results
> This results in the parsing of this file not quite working and the aggregate
> stats not working in produced graphs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12365) Document cassandra stress
[ https://issues.apache.org/jira/browse/CASSANDRA-12365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey updated CASSANDRA-12365: -- Fix Version/s: 3.x Status: Patch Available (was: Open) I've done some initial docs. Branch here: https://github.com/chbatey/cassandra-1/tree/stress-docs or happy to provide a patch. > Document cassandra stress > - > > Key: CASSANDRA-12365 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12365 > Project: Cassandra > Issue Type: Improvement > Components: Documentation and Website >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Minor > Labels: stress > Fix For: 3.x > > > I've started on this so creating a ticket to avoid duplicate work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12365) Document cassandra stress
[ https://issues.apache.org/jira/browse/CASSANDRA-12365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey updated CASSANDRA-12365: -- Labels: stress (was: ) > Document cassandra stress > - > > Key: CASSANDRA-12365 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12365 > Project: Cassandra > Issue Type: Improvement > Components: Documentation and Website >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Minor > Labels: stress > > I've started on this so creating a ticket to avoid duplicate work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12564) Stress daemon mode no longer works
[ https://issues.apache.org/jira/browse/CASSANDRA-12564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey updated CASSANDRA-12564: -- Fix Version/s: 3.x Status: Patch Available (was: Open) Patch available here: https://github.com/chbatey/cassandra-1/tree/issue-12564 > Stress daemon mode no longer works > -- > > Key: CASSANDRA-12564 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12564 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Minor > Labels: stress > Fix For: 3.x > > > All of settings are no longer Serializable. > I intend to fix this but if anyone gets there before me feel free to take the > issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12564) Stress daemon mode no longer works
Christopher Batey created CASSANDRA-12564: - Summary: Stress daemon mode no longer works Key: CASSANDRA-12564 URL: https://issues.apache.org/jira/browse/CASSANDRA-12564 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Christopher Batey Assignee: Christopher Batey Priority: Minor All of settings are no longer Serializable. I intend to fix this but if anyone gets there before me feel free to take the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12563) Stress daemon help is incorrect
[ https://issues.apache.org/jira/browse/CASSANDRA-12563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey updated CASSANDRA-12563: -- Labels: stress (was: ) Component/s: Tools > Stress daemon help is incorrect > --- > > Key: CASSANDRA-12563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12563 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Trivial > Labels: stress > Fix For: 3.x > > > It says provide the option -sendToDaemon where as only -send-to and -sendto > work > Fix here: > https://github.com/chbatey/cassandra-1/tree/stress-daemon -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12563) Stress daemon help is incorrect
[ https://issues.apache.org/jira/browse/CASSANDRA-12563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey updated CASSANDRA-12563: -- Status: Patch Available (was: Open) https://github.com/chbatey/cassandra-1/tree/stress-daemon > Stress daemon help is incorrect > --- > > Key: CASSANDRA-12563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12563 > Project: Cassandra > Issue Type: Bug >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Trivial > Fix For: 3.x > > > It says provide the option -sendToDaemon where as only -send-to and -sendto > work > Fix here: > https://github.com/chbatey/cassandra-1/tree/stress-daemon -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12563) Stress daemon help is incorrect
Christopher Batey created CASSANDRA-12563: - Summary: Stress daemon help is incorrect Key: CASSANDRA-12563 URL: https://issues.apache.org/jira/browse/CASSANDRA-12563 Project: Cassandra Issue Type: Bug Reporter: Christopher Batey Assignee: Christopher Batey Priority: Trivial Fix For: 3.x It says provide the option -sendToDaemon where as only -send-to and -sendto work Fix here: https://github.com/chbatey/cassandra-1/tree/stress-daemon -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12237) Cassandra stress graphing is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15439197#comment-15439197
]
Christopher Batey commented on CASSANDRA-12237:
---
Hey [~JoshuaMcKenzie] any update on a review? Hoping to stop using my branch of
stress
> Cassandra stress graphing is broken
> ---
>
> Key: CASSANDRA-12237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12237
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
> Fix For: 3.x
>
> Attachments: 12237-trunk.txt
>
>
> Cassandra stress relies on a tmp file with the stress output so it can parse
> it and put it the the graph html.
> However the contents of this file is now broken:
> {code}
> Sleeping 2s...Sleeping 2s...
> Sleeping 2s...
> Warming up WRITE with 5 iterations...Warming up WRITE with 5
> iterations...
> Warming up WRITE with 5 iterations...
> Running WRITE with 500 threads 10 secondsRunning WRITE with 500 threads 10
> seconds
> Running WRITE with 500 threads 10 seconds
> ...
> {code}
> This is as we create a {code}MultiPrintStream{code} that inherits from
> {code}PrintWriter{code} and then delegate the call to super as well as a list
> of other PrintWriters
> The call to super for println comes back into our print method so every line
> gets logged multiple times as we do the for (PrintStream s: newStreams) many
> times.
> We can change this to use composition and use our own interface if we want to
> use a composite for logging the results
> This results in the parsing of this file not quite working and the aggregate
> stats not working in produced graphs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12365) Document cassandra stress
Christopher Batey created CASSANDRA-12365: - Summary: Document cassandra stress Key: CASSANDRA-12365 URL: https://issues.apache.org/jira/browse/CASSANDRA-12365 Project: Cassandra Issue Type: Improvement Components: Documentation and Website Reporter: Christopher Batey Assignee: Christopher Batey Priority: Minor I've started on this so creating a ticket to avoid duplicate work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12273) Casandra stess graph: option to create directory for graph if it doesn't exist
Christopher Batey created CASSANDRA-12273: - Summary: Casandra stess graph: option to create directory for graph if it doesn't exist Key: CASSANDRA-12273 URL: https://issues.apache.org/jira/browse/CASSANDRA-12273 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Christopher Batey Assignee: Christopher Batey Priority: Minor I am running it in CI with ephemeral workspace / build dirs. It would be nice if CS would create the directory so my build tool doesn't have to -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12258) Casandra stress version option
[ https://issues.apache.org/jira/browse/CASSANDRA-12258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey updated CASSANDRA-12258: -- Status: Patch Available (was: Open) I picked up the version from the file that is in the main cassandra jar. Will provide a patch if reviewer prefers otherwise the commit is on: https://github.com/chbatey/cassandra-1/tree/stress-version-option > Casandra stress version option > -- > > Key: CASSANDRA-12258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12258 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Minor > Fix For: 3.x > > > I install cassandra stress to multiple machines in different environments and > would like an easy way (with out looking at jar files etc) to see the version > of stress running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12258) Casandra stress version option
Christopher Batey created CASSANDRA-12258: - Summary: Casandra stress version option Key: CASSANDRA-12258 URL: https://issues.apache.org/jira/browse/CASSANDRA-12258 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Christopher Batey Assignee: Christopher Batey Priority: Minor Fix For: 3.x I install cassandra stress to multiple machines in different environments and would like an easy way (with out looking at jar files etc) to see the version of stress running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12233) Casasndra stress should obfuscate password in cmd in graph
[ https://issues.apache.org/jira/browse/CASSANDRA-12233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey updated CASSANDRA-12233: -- Attachment: 0001-Obfuscate-password-in-stress-graphs.patch > Casasndra stress should obfuscate password in cmd in graph > -- > > Key: CASSANDRA-12233 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12233 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Minor > Fix For: 3.x > > Attachments: 0001-Obfuscate-password-in-stress-graphs.patch > > > The graph currently has the entire cmd which will could contain a user / > password -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12233) Casasndra stress should obfuscate password in cmd in graph
[ https://issues.apache.org/jira/browse/CASSANDRA-12233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey updated CASSANDRA-12233: -- Fix Version/s: 3.x Status: Patch Available (was: Open) Patch is for trunk. Very simple replace so I can publish the graphs in CI https://github.com/chbatey/cassandra-1/tree/stress-graph-obfuscate-password > Casasndra stress should obfuscate password in cmd in graph > -- > > Key: CASSANDRA-12233 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12233 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Minor > Fix For: 3.x > > > The graph currently has the entire cmd which will could contain a user / > password -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12237) Cassandra stress graphing is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15385861#comment-15385861
]
Christopher Batey edited comment on CASSANDRA-12237 at 7/20/16 1:34 PM:
Branch here: https://github.com/chbatey/cassandra-1/tree/stress-graph-logging
Commit msg explains all the changes. I found a few more issues before i could
get graphs working again.
was (Author: chbatey):
Branch here: https://github.com/chbatey/cassandra-1/tree/stress-graph-logging
Commit msg explains all the changes
> Cassandra stress graphing is broken
> ---
>
> Key: CASSANDRA-12237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12237
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
> Fix For: 3.x
>
> Attachments: 12237-trunk.txt
>
>
> Cassandra stress relies on a tmp file with the stress output so it can parse
> it and put it the the graph html.
> However the contents of this file is now broken:
> {code}
> Sleeping 2s...Sleeping 2s...
> Sleeping 2s...
> Warming up WRITE with 5 iterations...Warming up WRITE with 5
> iterations...
> Warming up WRITE with 5 iterations...
> Running WRITE with 500 threads 10 secondsRunning WRITE with 500 threads 10
> seconds
> Running WRITE with 500 threads 10 seconds
> ...
> {code}
> This is as we create a {code}MultiPrintStream{code} that inherits from
> {code}PrintWriter{code} and then delegate the call to super as well as a list
> of other PrintWriters
> The call to super for println comes back into our print method so every line
> gets logged multiple times as we do the for (PrintStream s: newStreams) many
> times.
> We can change this to use composition and use our own interface if we want to
> use a composite for logging the results
> This results in the parsing of this file not quite working and the aggregate
> stats not working in produced graphs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12237) Cassandra stress graphing is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Batey updated CASSANDRA-12237:
--
Attachment: 12237-trunk.txt
> Cassandra stress graphing is broken
> ---
>
> Key: CASSANDRA-12237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12237
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
> Fix For: 3.x
>
> Attachments: 12237-trunk.txt
>
>
> Cassandra stress relies on a tmp file with the stress output so it can parse
> it and put it the the graph html.
> However the contents of this file is now broken:
> {code}
> Sleeping 2s...Sleeping 2s...
> Sleeping 2s...
> Warming up WRITE with 5 iterations...Warming up WRITE with 5
> iterations...
> Warming up WRITE with 5 iterations...
> Running WRITE with 500 threads 10 secondsRunning WRITE with 500 threads 10
> seconds
> Running WRITE with 500 threads 10 seconds
> ...
> {code}
> This is as we create a {code}MultiPrintStream{code} that inherits from
> {code}PrintWriter{code} and then delegate the call to super as well as a list
> of other PrintWriters
> The call to super for println comes back into our print method so every line
> gets logged multiple times as we do the for (PrintStream s: newStreams) many
> times.
> We can change this to use composition and use our own interface if we want to
> use a composite for logging the results
> This results in the parsing of this file not quite working and the aggregate
> stats not working in produced graphs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12237) Cassandra stress graphing is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Batey updated CASSANDRA-12237:
--
Fix Version/s: 3.x
Status: Patch Available (was: Open)
Branch here: https://github.com/chbatey/cassandra-1/tree/stress-graph-logging
Commit msg explains all the changes
> Cassandra stress graphing is broken
> ---
>
> Key: CASSANDRA-12237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12237
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
> Fix For: 3.x
>
>
> Cassandra stress relies on a tmp file with the stress output so it can parse
> it and put it the the graph html.
> However the contents of this file is now broken:
> {code}
> Sleeping 2s...Sleeping 2s...
> Sleeping 2s...
> Warming up WRITE with 5 iterations...Warming up WRITE with 5
> iterations...
> Warming up WRITE with 5 iterations...
> Running WRITE with 500 threads 10 secondsRunning WRITE with 500 threads 10
> seconds
> Running WRITE with 500 threads 10 seconds
> ...
> {code}
> This is as we create a {code}MultiPrintStream{code} that inherits from
> {code}PrintWriter{code} and then delegate the call to super as well as a list
> of other PrintWriters
> The call to super for println comes back into our print method so every line
> gets logged multiple times as we do the for (PrintStream s: newStreams) many
> times.
> We can change this to use composition and use our own interface if we want to
> use a composite for logging the results
> This results in the parsing of this file not quite working and the aggregate
> stats not working in produced graphs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12237) Cassandra stress graphing is broken
Christopher Batey created CASSANDRA-12237:
-
Summary: Cassandra stress graphing is broken
Key: CASSANDRA-12237
URL: https://issues.apache.org/jira/browse/CASSANDRA-12237
Project: Cassandra
Issue Type: Bug
Components: Tools
Reporter: Christopher Batey
Assignee: Christopher Batey
Cassandra stress relies on a tmp file with the stress output so it can parse it
and put it the the graph html.
However the contents of this file is now broken:
{code}
Sleeping 2s...Sleeping 2s...
Sleeping 2s...
Warming up WRITE with 5 iterations...Warming up WRITE with 5
iterations...
Warming up WRITE with 5 iterations...
Running WRITE with 500 threads 10 secondsRunning WRITE with 500 threads 10
seconds
Running WRITE with 500 threads 10 seconds
...
{code}
This is as we create a {code}MultiPrintStream{code} that inherits from
{code}PrintWriter{code} and then delegate the call to super as well as a list
of other PrintWriters
The call to super for println comes back into our print method so every line
gets logged multiple times as we do the for (PrintStream s: newStreams) many
times.
We can change this to use composition and use our own interface if we want to
use a composite for logging the results
This results in the parsing of this file not quite working and the aggregate
stats not working in produced graphs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12233) Casasndra stress should obfuscate password in cmd in graph
Christopher Batey created CASSANDRA-12233: - Summary: Casasndra stress should obfuscate password in cmd in graph Key: CASSANDRA-12233 URL: https://issues.apache.org/jira/browse/CASSANDRA-12233 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Christopher Batey Assignee: Christopher Batey Priority: Minor The graph currently has the entire cmd which will could contain a user / password -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11638) Add cassandra-stress test source
[
https://issues.apache.org/jira/browse/CASSANDRA-11638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358483#comment-15358483
]
Christopher Batey commented on CASSANDRA-11638:
---
looks good, thanks [~jkni]
> Add cassandra-stress test source
>
>
> Key: CASSANDRA-11638
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11638
> Project: Cassandra
> Issue Type: Test
> Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
>Priority: Minor
> Labels: stress
> Fix For: 3.x
>
> Attachments:
> 0001-Add-a-test-source-directory-for-Cassandra-stress.patch
>
>
> This adds a test root for cassandra-stress and a couple of noddy tests for a
> jira I did last week to prove it works / fails the build if they fail.
> I put the source in {{tools/stress/test/unit}} and the classes in
> {{build/test/stress-classes}} (rather than putting them in with the main test
> classes).
> Patch attached or at: https://github.com/chbatey/cassandra-1/tree/stress-tests
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-8467) Monitoring UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-8467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey reassigned CASSANDRA-8467: Assignee: Christopher Batey > Monitoring UDFs > --- > > Key: CASSANDRA-8467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8467 > Project: Cassandra > Issue Type: New Feature > Components: Observability >Reporter: Robert Stupp >Assignee: Christopher Batey >Priority: Minor > Labels: tracing, udf > > This thicket's about to add UDF executions to session-tracing. > Tracing these parameters for UDF invocations could become very interesting. > * name of UDF > * # of invocations > * # of rejected executions > * min/max/avg execution times > "Rejected executions" would count UDFs that are not executed because an input > parameter is null/empty (CASSANDRA-8374). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11638) Add cassandra-stress test source
[
https://issues.apache.org/jira/browse/CASSANDRA-11638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15256818#comment-15256818
]
Christopher Batey commented on CASSANDRA-11638:
---
Review now. Will add more tests as I work on features.
> Add cassandra-stress test source
>
>
> Key: CASSANDRA-11638
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11638
> Project: Cassandra
> Issue Type: Test
> Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
>Priority: Minor
> Labels: stress
> Fix For: 3.x
>
> Attachments:
> 0001-Add-a-test-source-directory-for-Cassandra-stress.patch
>
>
> This adds a test root for cassandra-stress and a couple of noddy tests for a
> jira I did last week to prove it works / fails the build if they fail.
> I put the source in {{tools/stress/test/unit}} and the classes in
> {{build/test/stress-classes}} (rather than putting them in with the main test
> classes).
> Patch attached or at: https://github.com/chbatey/cassandra-1/tree/stress-tests
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11634) Add write timestamp to trace
[ https://issues.apache.org/jira/browse/CASSANDRA-11634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey updated CASSANDRA-11634: -- Reviewer: Aleksey Yeschenko Fix Version/s: 3.x Status: Patch Available (was: Open) > Add write timestamp to trace > > > Key: CASSANDRA-11634 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11634 > Project: Cassandra > Issue Type: Improvement > Components: Observability >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Minor > Fix For: 3.x > > Attachments: 0001-Add-trace-message-for-write-timestamp.patch > > > Diagnosing issues with clock drift would be easier if trace had the mutation > timestamp. I'll add a patch for this soon. > Patch attached or at: > https://github.com/chbatey/cassandra-1/tree/trace-write-timestamp -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11634) Add write timestamp to trace
[ https://issues.apache.org/jira/browse/CASSANDRA-11634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey updated CASSANDRA-11634: -- Description: Diagnosing issues with clock drift would be easier if trace had the mutation timestamp. I'll add a patch for this soon. Patch attached or at: https://github.com/chbatey/cassandra-1/tree/trace-write-timestamp was:Diagnosing issues with clock drift would be easier if trace had the mutation timestamp. I'll add a patch for this soon. > Add write timestamp to trace > > > Key: CASSANDRA-11634 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11634 > Project: Cassandra > Issue Type: Improvement > Components: Observability >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Minor > Attachments: 0001-Add-trace-message-for-write-timestamp.patch > > > Diagnosing issues with clock drift would be easier if trace had the mutation > timestamp. I'll add a patch for this soon. > Patch attached or at: > https://github.com/chbatey/cassandra-1/tree/trace-write-timestamp -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11634) Add write timestamp to trace
[ https://issues.apache.org/jira/browse/CASSANDRA-11634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey updated CASSANDRA-11634: -- Attachment: 0001-Add-trace-message-for-write-timestamp.patch > Add write timestamp to trace > > > Key: CASSANDRA-11634 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11634 > Project: Cassandra > Issue Type: Improvement > Components: Observability >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Minor > Attachments: 0001-Add-trace-message-for-write-timestamp.patch > > > Diagnosing issues with clock drift would be easier if trace had the mutation > timestamp. I'll add a patch for this soon. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11634) Add write timestamp to trace
[ https://issues.apache.org/jira/browse/CASSANDRA-11634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15255671#comment-15255671 ] Christopher Batey commented on CASSANDRA-11634: --- Thanks [~iamaleksey] I've added it at the cql layer where the timestamp is either generated or taken from the client. This trace would have helped me twice in the last week. Once for a clock skew issue for an insert, delete, read, then still see the value as the delete went to a coordinator with its clock behind and another issue where an app team were sure they weren't specifying the timestamp but were due to a driver upgrade. > Add write timestamp to trace > > > Key: CASSANDRA-11634 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11634 > Project: Cassandra > Issue Type: Improvement > Components: Observability >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Minor > > Diagnosing issues with clock drift would be easier if trace had the mutation > timestamp. I'll add a patch for this soon. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8607) Introduce unit tests or dtests for cassandra-stress
[ https://issues.apache.org/jira/browse/CASSANDRA-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15255571#comment-15255571 ] Christopher Batey commented on CASSANDRA-8607: -- Thanks [~jkni]. I am a little way off submitting anything with substantial coverage. In the mean time I created https://issues.apache.org/jira/browse/CASSANDRA-11638 to just add a test source directory and a couple of noddy tests to encourage any new features for cassandra-stress to include tests. > Introduce unit tests or dtests for cassandra-stress > --- > > Key: CASSANDRA-8607 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8607 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Benedict >Assignee: Christopher Batey > > Right now we don't have any tests in place to ensure we don't break stress. > In general we've relied on simply noticing problems as part of the > development process, since we've typically developed features in tandem with > related c* functionality, so we would see if we'd gotten it wrong. However > now that it is being used more widely, we could do with some automated > testing to ensure we haven't accidentally broken anything. If we mock up some > non-random random classes and permit them to be swapped in wherever necessary > we could construct some known dataset / visitation etc behaviours that elicit > all of the edge cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11638) Add cassandra-stress test source
[
https://issues.apache.org/jira/browse/CASSANDRA-11638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Batey updated CASSANDRA-11638:
--
Description:
This adds a test root for cassandra-stress and a couple of noddy tests for a
jira I did last week to prove it works / fails the build if they fail.
I put the source in {{tools/stress/test/unit}} and the classes in
{{build/test/stress-classes}} (rather than putting them in with the main test
classes).
Patch attached or at: https://github.com/chbatey/cassandra-1/tree/stress-tests
was:
This adds a test root for cassandra-stress and a couple of noddy tests for a
jira I did last week to prove it works / fails the build if they fail.
I put the source in {tools/stress/test/unit} and the classes in
{build/test/stress-classes} (rather than putting them in with the main test
classes).
Patch attached or at: https://github.com/chbatey/cassandra-1/tree/stress-tests
> Add cassandra-stress test source
>
>
> Key: CASSANDRA-11638
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11638
> Project: Cassandra
> Issue Type: Test
> Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
>Priority: Minor
> Labels: stress
> Fix For: 3.x
>
> Attachments:
> 0001-Add-a-test-source-directory-for-Cassandra-stress.patch
>
>
> This adds a test root for cassandra-stress and a couple of noddy tests for a
> jira I did last week to prove it works / fails the build if they fail.
> I put the source in {{tools/stress/test/unit}} and the classes in
> {{build/test/stress-classes}} (rather than putting them in with the main test
> classes).
> Patch attached or at: https://github.com/chbatey/cassandra-1/tree/stress-tests
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11638) Add cassandra-stress test source
Christopher Batey created CASSANDRA-11638:
-
Summary: Add cassandra-stress test source
Key: CASSANDRA-11638
URL: https://issues.apache.org/jira/browse/CASSANDRA-11638
Project: Cassandra
Issue Type: Test
Components: Tools
Reporter: Christopher Batey
Assignee: Christopher Batey
Priority: Minor
Fix For: 3.x
Attachments:
0001-Add-a-test-source-directory-for-Cassandra-stress.patch
This adds a test root for cassandra-stress and a couple of noddy tests for a
jira I did last week to prove it works / fails the build if they fail.
I put the source in {tools/stress/test/unit} and the classes in
{build/test/stress-classes} (rather than putting them in with the main test
classes).
Patch attached or at: https://github.com/chbatey/cassandra-1/tree/stress-tests
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11481) Example metrics config has DroppedMetrics
[ https://issues.apache.org/jira/browse/CASSANDRA-11481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey updated CASSANDRA-11481: -- Component/s: Documentation and Website > Example metrics config has DroppedMetrics > - > > Key: CASSANDRA-11481 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11481 > Project: Cassandra > Issue Type: Bug > Components: Documentation and Website >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Minor > Fix For: 3.x > > Attachments: fix-example-metrics.patch > > > Noticed this when setting up metrics reporting on a new cluster. I assume it > is meant to be DroppedMessage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11481) Example metrics config has DroppedMetrics
[ https://issues.apache.org/jira/browse/CASSANDRA-11481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey updated CASSANDRA-11481: -- Fix Version/s: 3.x > Example metrics config has DroppedMetrics > - > > Key: CASSANDRA-11481 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11481 > Project: Cassandra > Issue Type: Bug >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Minor > Fix For: 3.x > > Attachments: fix-example-metrics.patch > > > Noticed this when setting up metrics reporting on a new cluster. I assume it > is meant to be DroppedMessage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-11634) Add write timestamp to trace
Christopher Batey created CASSANDRA-11634: - Summary: Add write timestamp to trace Key: CASSANDRA-11634 URL: https://issues.apache.org/jira/browse/CASSANDRA-11634 Project: Cassandra Issue Type: Improvement Components: Observability Reporter: Christopher Batey Assignee: Christopher Batey Priority: Minor Diagnosing issues with clock drift would be easier if trace had the mutation timestamp. I'll add a patch for this soon. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11547) Add background thread to check for clock drift
[ https://issues.apache.org/jira/browse/CASSANDRA-11547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15245453#comment-15245453 ] Christopher Batey commented on CASSANDRA-11547: --- If we don't think this is Cassandra's business it could be pulled out into a separate project as a javaagent like jHiccup. I would use it. > Add background thread to check for clock drift > -- > > Key: CASSANDRA-11547 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11547 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jason Brown >Assignee: Jason Brown >Priority: Minor > Labels: clocks, time > > The system clock has the potential to drift while a system is running. As a > simple way to check if this occurs, we can run a background thread that wakes > up every n seconds, reads the system clock, and checks to see if, indeed, n > seconds have passed. > * If the clock's current time is less than the last recorded time (captured n > seconds in the past), we know the clock has jumped backward. > * If n seconds have not elapsed, we know the system clock is running slow or > has moved backward (by a value less than n) > * If (n + a small offset) seconds have elapsed, we can assume we are within > an acceptable window of clock movement. Reasons for including an offset are > the clock checking thread might not have been scheduled on time, or garbage > collection, and so on. > * If the clock is greater than (n + a small offset) seconds, we can assume > the clock jumped forward. > In the unhappy cases, we can write a message to the log and increment some > metric that the user's monitoring systems can trigger/alert on. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-7960) cassandra-stress should support LWT
[ https://issues.apache.org/jira/browse/CASSANDRA-7960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey reassigned CASSANDRA-7960: Assignee: Christopher Batey (was: Liang Xie) > cassandra-stress should support LWT > --- > > Key: CASSANDRA-7960 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7960 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Benedict >Assignee: Christopher Batey >Priority: Minor > Labels: stress > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7960) cassandra-stress should support LWT
[ https://issues.apache.org/jira/browse/CASSANDRA-7960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15245226#comment-15245226 ] Christopher Batey commented on CASSANDRA-7960: -- I plan to start working on this soon as I need to do some benchmarking of LWTs. [~xieliang007] or anyone else feel free to take this off me if you beat me to it. > cassandra-stress should support LWT > --- > > Key: CASSANDRA-7960 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7960 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Benedict >Assignee: Liang Xie >Priority: Minor > Labels: stress > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8607) Introduce unit tests or dtests for cassandra-stress
[ https://issues.apache.org/jira/browse/CASSANDRA-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15244888#comment-15244888 ] Christopher Batey commented on CASSANDRA-8607: -- I have a fork of cassandra stress that has unit tests. I plan to submit it soon. This could be this ticket or I could raise a separate one as I don't plan to add e2e/dtests yet which I think would be very valuable. > Introduce unit tests or dtests for cassandra-stress > --- > > Key: CASSANDRA-8607 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8607 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Benedict >Assignee: Christopher Batey > > Right now we don't have any tests in place to ensure we don't break stress. > In general we've relied on simply noticing problems as part of the > development process, since we've typically developed features in tandem with > related c* functionality, so we would see if we'd gotten it wrong. However > now that it is being used more widely, we could do with some automated > testing to ensure we haven't accidentally broken anything. If we mock up some > non-random random classes and permit them to be swapped in wherever necessary > we could construct some known dataset / visitation etc behaviours that elicit > all of the edge cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-8607) Introduce unit tests or dtests for cassandra-stress
[ https://issues.apache.org/jira/browse/CASSANDRA-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey reassigned CASSANDRA-8607: Assignee: Christopher Batey > Introduce unit tests or dtests for cassandra-stress > --- > > Key: CASSANDRA-8607 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8607 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Benedict >Assignee: Christopher Batey > > Right now we don't have any tests in place to ensure we don't break stress. > In general we've relied on simply noticing problems as part of the > development process, since we've typically developed features in tandem with > related c* functionality, so we would see if we'd gotten it wrong. However > now that it is being used more widely, we could do with some automated > testing to ensure we haven't accidentally broken anything. If we mock up some > non-random random classes and permit them to be swapped in wherever necessary > we could construct some known dataset / visitation etc behaviours that elicit > all of the edge cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-11591) Cassandra-stress doesn't support explicit datacenter for DCAwareRoundRobinPolicy
Christopher Batey created CASSANDRA-11591: - Summary: Cassandra-stress doesn't support explicit datacenter for DCAwareRoundRobinPolicy Key: CASSANDRA-11591 URL: https://issues.apache.org/jira/browse/CASSANDRA-11591 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Christopher Batey Assignee: Christopher Batey Priority: Minor Fix For: 3.x Attachments: 0001-Add-option-datacenter-to-node-options.patch The driver defaults to the DC of the first host it gets but for some testing I am doing atm it would be easier for me to specify the DC rather than change the configured hosts. Still defaults to the same behaviour if -node datacenter= is not set. Added a patch or available at https://github.com/chbatey/cassandra-1/tree/cassandra-stress-dc -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8467) Monitoring UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-8467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235805#comment-15235805 ] Christopher Batey commented on CASSANDRA-8467: -- Having an MBean that I could see total time spent in UDF and a latency distribution of UDF execution would be very nice. > Monitoring UDFs > --- > > Key: CASSANDRA-8467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8467 > Project: Cassandra > Issue Type: New Feature > Components: Observability >Reporter: Robert Stupp >Priority: Minor > Labels: tracing, udf > > This thicket's about to add UDF executions to session-tracing. > Tracing these parameters for UDF invocations could become very interesting. > * name of UDF > * # of invocations > * # of rejected executions > * min/max/avg execution times > "Rejected executions" would count UDFs that are not executed because an input > parameter is null/empty (CASSANDRA-8374). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11537) Give clear error when certain nodetool commands are issued before server is ready
[
https://issues.apache.org/jira/browse/CASSANDRA-11537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15234926#comment-15234926
]
Christopher Batey commented on CASSANDRA-11537:
---
Given we know exactly what this exception could we avoid showing the stack
trace? The fewer stack traces users see the better
> Give clear error when certain nodetool commands are issued before server is
> ready
> -
>
> Key: CASSANDRA-11537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11537
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>Priority: Minor
>
> As an ops person upgrading and servicing Cassandra servers, I require a more
> clear message when I issue a nodetool command that the server is not ready
> for it so that I am not confused.
> Technical description:
> If you deploy a new binary, restart, and issue nodetool
> scrub/compact/updatess etc you get unfriendly assertion. An exception would
> be easier to understand. Also if a user has turned assertions off it is
> unclear what might happen.
> {noformat}
> EC1: Throw exception to make it clear server is still in start up process.
> :~# nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:97)
> at
> org.apache.cassandra.service.StorageService.getValidKeyspace(StorageService.java:2573)
> at
> org.apache.cassandra.service.StorageService.getValidColumnFamilies(StorageService.java:2661)
> at
> org.apache.cassandra.service.StorageService.upgradeSSTables(StorageService.java:2421)
> {noformat}
> EC1:
> Patch against 2.1 (branch)
> https://github.com/apache/cassandra/compare/trunk...edwardcapriolo:exception-on-startup?expand=1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11544) NullPointerException if metrics reporter config file doesn't exist
Christopher Batey created CASSANDRA-11544: - Summary: NullPointerException if metrics reporter config file doesn't exist Key: CASSANDRA-11544 URL: https://issues.apache.org/jira/browse/CASSANDRA-11544 Project: Cassandra Issue Type: Bug Components: Configuration Reporter: Christopher Batey Assignee: Christopher Batey Priority: Minor Attachments: 0001-Avoid-NPE-exception-when-metrics-reporter-config-doe.patch Patch attached or at https://github.com/chbatey/cassandra-1/tree/npe-when-metrics-file-not-exist -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-11481) Example metrics config has DroppedMetrics
[ https://issues.apache.org/jira/browse/CASSANDRA-11481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey reassigned CASSANDRA-11481: - Assignee: Christopher Batey > Example metrics config has DroppedMetrics > - > > Key: CASSANDRA-11481 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11481 > Project: Cassandra > Issue Type: Bug >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Minor > Attachments: fix-example-metrics.patch > > > Noticed this when setting up metrics reporting on a new cluster. I assume it > is meant to be DroppedMessage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-11507) Nodetool proxyhistograms is missing CAS stats
Christopher Batey created CASSANDRA-11507: - Summary: Nodetool proxyhistograms is missing CAS stats Key: CASSANDRA-11507 URL: https://issues.apache.org/jira/browse/CASSANDRA-11507 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Christopher Batey Priority: Critical Attachments: 0001-Add-missing-CAS-metrics-to-proxystats.patch At the moment only writes/reads are shown. Attached patch adds CASRead/CASWrite and ViewWrite. Github branch here: https://github.com/chbatey/cassandra-1/tree/cas-metrics-in-proxystats -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-11507) Nodetool proxyhistograms is missing CAS stats
[ https://issues.apache.org/jira/browse/CASSANDRA-11507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Batey reassigned CASSANDRA-11507: - Assignee: Christopher Batey > Nodetool proxyhistograms is missing CAS stats > - > > Key: CASSANDRA-11507 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11507 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Christopher Batey >Assignee: Christopher Batey >Priority: Critical > Attachments: 0001-Add-missing-CAS-metrics-to-proxystats.patch > > > At the moment only writes/reads are shown. Attached patch adds > CASRead/CASWrite and ViewWrite. > Github branch here: > https://github.com/chbatey/cassandra-1/tree/cas-metrics-in-proxystats -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-11481) Example metrics config has DroppedMetrics
Christopher Batey created CASSANDRA-11481: - Summary: Example metrics config has DroppedMetrics Key: CASSANDRA-11481 URL: https://issues.apache.org/jira/browse/CASSANDRA-11481 Project: Cassandra Issue Type: Bug Reporter: Christopher Batey Priority: Minor Attachments: fix-example-metrics.patch Noticed this when setting up metrics reporting on a new cluster. I assume it is meant to be DroppedMessage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9723) UDF / UDA execution time in trace
[ https://issues.apache.org/jira/browse/CASSANDRA-9723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14631224#comment-14631224 ] Christopher Batey commented on CASSANDRA-9723: -- Ready for review: https://github.com/chbatey/cassandra-1/tree/udf-trace UDF / UDA execution time in trace - Key: CASSANDRA-9723 URL: https://issues.apache.org/jira/browse/CASSANDRA-9723 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Christopher Batey Assignee: Christopher Batey Priority: Minor Fix For: 2.2.x I'd like to see how long my UDF/As take in the trace. Checked in 2.2rc1 and doesn't appear to be mentioned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-6477) Materialized Views (was: Global Indexes)
[
https://issues.apache.org/jira/browse/CASSANDRA-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14616644#comment-14616644
]
Christopher Batey edited comment on CASSANDRA-6477 at 7/7/15 12:58 PM:
---
I got a lot of these in my log when playing with the branch, however the views
I created worked fine.
{code}
WARN [CompactionExecutor:111] 2015-07-07 10:57:09,023
MaterializedViewBuilder.java:189 - Materialized View failed to complete,
sleeping 5 minutes before restarting
org.apache.cassandra.exceptions.InvalidRequestException: Missing mandatory
PRIMARY KEY part host_id
at
org.apache.cassandra.cql3.statements.RequestValidations.invalidRequest(RequestValidations.java:199)
~[main/:na]
at
org.apache.cassandra.cql3.statements.RequestValidations.checkTrue(RequestValidations.java:63)
~[main/:na]
at
org.apache.cassandra.cql3.statements.RequestValidations.checkNotNull(RequestValidations.java:140)
~[main/:na]
at
org.apache.cassandra.cql3.statements.ModificationStatement.buildPartitionKeyNames(ModificationStatement.java:395)
~[main/:na]
at
org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:752)
~[main/:na]
at
org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:727)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:293)
~[main/:na]
at
org.apache.cassandra.db.SystemKeyspace.setMaterializedViewBuilt(SystemKeyspace.java:453)
~[main/:na]
at
org.apache.cassandra.db.SystemKeyspace.finishMaterializedViewBuildStatus(SystemKeyspace.java:472)
~[main/:na]
at
org.apache.cassandra.db.view.MaterializedViewBuilder.run(MaterializedViewBuilder.java:174)
~[main/:na]
at
org.apache.cassandra.db.compaction.CompactionManager$13.run(CompactionManager.java:1364)
[main/:na]
{code}
was (Author: chbatey):
I got a lot of these in my log when playing with the branch, however the views
I created worked fine.
{quote}
WARN [CompactionExecutor:111] 2015-07-07 10:57:09,023
MaterializedViewBuilder.java:189 - Materialized View failed to complete,
sleeping 5 minutes before restarting
org.apache.cassandra.exceptions.InvalidRequestException: Missing mandatory
PRIMARY KEY part host_id
at
org.apache.cassandra.cql3.statements.RequestValidations.invalidRequest(RequestValidations.java:199)
~[main/:na]
at
org.apache.cassandra.cql3.statements.RequestValidations.checkTrue(RequestValidations.java:63)
~[main/:na]
at
org.apache.cassandra.cql3.statements.RequestValidations.checkNotNull(RequestValidations.java:140)
~[main/:na]
at
org.apache.cassandra.cql3.statements.ModificationStatement.buildPartitionKeyNames(ModificationStatement.java:395)
~[main/:na]
at
org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:752)
~[main/:na]
at
org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:727)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:293)
~[main/:na]
at
org.apache.cassandra.db.SystemKeyspace.setMaterializedViewBuilt(SystemKeyspace.java:453)
~[main/:na]
at
org.apache.cassandra.db.SystemKeyspace.finishMaterializedViewBuildStatus(SystemKeyspace.java:472)
~[main/:na]
at
org.apache.cassandra.db.view.MaterializedViewBuilder.run(MaterializedViewBuilder.java:174)
~[main/:na]
at
org.apache.cassandra.db.compaction.CompactionManager$13.run(CompactionManager.java:1364)
[main/:na]
{quote}
Materialized Views (was: Global Indexes)
Key: CASSANDRA-6477
URL: https://issues.apache.org/jira/browse/CASSANDRA-6477
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Assignee: Carl Yeksigian
Labels: cql
Fix For: 3.0 beta 1
Attachments: test-view-data.sh
Local indexes are suitable for low-cardinality data, where spreading the
index across the cluster is a Good Thing. However, for high-cardinality
data, local indexes require querying most nodes in the cluster even if only a
handful of rows is returned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6477) Materialized Views (was: Global Indexes)
[
https://issues.apache.org/jira/browse/CASSANDRA-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14616644#comment-14616644
]
Christopher Batey commented on CASSANDRA-6477:
--
I got a lot of these in my log when playing with the branch, however the views
I created worked fine.
{quote}
WARN [CompactionExecutor:111] 2015-07-07 10:57:09,023
MaterializedViewBuilder.java:189 - Materialized View failed to complete,
sleeping 5 minutes before restarting
org.apache.cassandra.exceptions.InvalidRequestException: Missing mandatory
PRIMARY KEY part host_id
at
org.apache.cassandra.cql3.statements.RequestValidations.invalidRequest(RequestValidations.java:199)
~[main/:na]
at
org.apache.cassandra.cql3.statements.RequestValidations.checkTrue(RequestValidations.java:63)
~[main/:na]
at
org.apache.cassandra.cql3.statements.RequestValidations.checkNotNull(RequestValidations.java:140)
~[main/:na]
at
org.apache.cassandra.cql3.statements.ModificationStatement.buildPartitionKeyNames(ModificationStatement.java:395)
~[main/:na]
at
org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:752)
~[main/:na]
at
org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:727)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:293)
~[main/:na]
at
org.apache.cassandra.db.SystemKeyspace.setMaterializedViewBuilt(SystemKeyspace.java:453)
~[main/:na]
at
org.apache.cassandra.db.SystemKeyspace.finishMaterializedViewBuildStatus(SystemKeyspace.java:472)
~[main/:na]
at
org.apache.cassandra.db.view.MaterializedViewBuilder.run(MaterializedViewBuilder.java:174)
~[main/:na]
at
org.apache.cassandra.db.compaction.CompactionManager$13.run(CompactionManager.java:1364)
[main/:na]
{quote}
Materialized Views (was: Global Indexes)
Key: CASSANDRA-6477
URL: https://issues.apache.org/jira/browse/CASSANDRA-6477
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Assignee: Carl Yeksigian
Labels: cql
Fix For: 3.0 beta 1
Attachments: test-view-data.sh
Local indexes are suitable for low-cardinality data, where spreading the
index across the cluster is a Good Thing. However, for high-cardinality
data, local indexes require querying most nodes in the cluster even if only a
handful of rows is returned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-9735) Add ignore extra fields for inserting JSON?
Christopher Batey created CASSANDRA-9735: Summary: Add ignore extra fields for inserting JSON? Key: CASSANDRA-9735 URL: https://issues.apache.org/jira/browse/CASSANDRA-9735 Project: Cassandra Issue Type: Improvement Components: API Reporter: Christopher Batey Priority: Minor One of the use cases I see for the INSERT into JSON ... syntax is for when incoming data matches their schema. It would be nice to allow extra fields as to not be too brittle. However I think strict validation should be the default so maybe the insert or table can include an extra flag? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9735) Add ignore extra fields for inserting JSON?
[ https://issues.apache.org/jira/browse/CASSANDRA-9735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14615197#comment-14615197 ] Christopher Batey commented on CASSANDRA-9735: -- I don't think silently dropping is a good idea, i think it should be explicit in the insert. Say you're storing a response from another system but don't want to keep all the fields or break if they add a field you aren't interested in. Add ignore extra fields for inserting JSON? --- Key: CASSANDRA-9735 URL: https://issues.apache.org/jira/browse/CASSANDRA-9735 Project: Cassandra Issue Type: Improvement Components: API Reporter: Christopher Batey Priority: Minor One of the use cases I see for the INSERT into JSON ... syntax is for when incoming data matches their schema. It would be nice to allow extra fields as to not be too brittle. However I think strict validation should be the default so maybe the insert or table can include an extra flag? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-9737) Log warning when using an aggregate without partition key
Christopher Batey created CASSANDRA-9737: Summary: Log warning when using an aggregate without partition key Key: CASSANDRA-9737 URL: https://issues.apache.org/jira/browse/CASSANDRA-9737 Project: Cassandra Issue Type: Wish Components: Core Reporter: Christopher Batey Assignee: Robert Stupp Priority: Trivial After a discussion with [~pmcfadin] thought it best to raise this. Aggregates are awesome but they are going to be mis-used. There are very few cases I can think of where we'd want users to use them across partition so maybe we should log a warning like with large batches? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-9725) CQL docs do not build due to duplicate name
Christopher Batey created CASSANDRA-9725: Summary: CQL docs do not build due to duplicate name Key: CASSANDRA-9725 URL: https://issues.apache.org/jira/browse/CASSANDRA-9725 Project: Cassandra Issue Type: Bug Components: Documentation website Reporter: Christopher Batey Fix on branch broken-cql-docs in g...@github.com:chbatey/cassandra-1.git -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-9726) Built in aggregate docs do not display examples due to whitespace error
Christopher Batey created CASSANDRA-9726: Summary: Built in aggregate docs do not display examples due to whitespace error Key: CASSANDRA-9726 URL: https://issues.apache.org/jira/browse/CASSANDRA-9726 Project: Cassandra Issue Type: Bug Components: Documentation website Reporter: Christopher Batey Fix on branch aggregate-docs at https://github.com/chbatey/cassandra-1.git -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-9724) UDA appears to be causing query to be executed multiple times
Christopher Batey created CASSANDRA-9724:
Summary: UDA appears to be causing query to be executed multiple
times
Key: CASSANDRA-9724
URL: https://issues.apache.org/jira/browse/CASSANDRA-9724
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Christopher Batey
Priority: Critical
Not sure if this is intended behaviour.
Example table:
{quote}
CREATE TABLE raw_weather_data (
wsid text, // Composite of Air Force Datsav3 station number
and NCDC WBAN number
year int,// Year collected
month int, // Month collected
day int, // Day collected
hour int,// Hour collected
temperature double, // Air temperature (degrees Celsius)
dewpoint double, // Dew point temperature (degrees Celsius)
pressure double, // Sea level pressure (hectopascals)
wind_direction int, // Wind direction in degrees. 0-359
wind_speed double,// Wind speed (meters per second)
sky_condition int, // Total cloud cover (coded, see format
documentation)
sky_condition_text text, // Non-coded sky conditions
one_hour_precip double, // One-hour accumulated liquid precipitation
(millimeters)
six_hour_precip double, // Six-hour accumulated liquid precipitation
(millimeters)
PRIMARY KEY ((wsid), year, month, day, hour)
) WITH CLUSTERING ORDER BY (year DESC, month DESC, day DESC, hour DESC);
{quote}
1 node cluster 2.2rc1. Trace for: select temperature from raw_weather_data
where wsid = '725030:14732' and year = 2008;
{quote}
activity
| timestamp | source|
source_elapsed
-++---+
Execute CQL3 query | 2015-07-03 09:53:25.002000 | 127.0.0.1 |
0
Parsing select temperature from raw_weather_data where wsid = '725030:14732'
and year = 2008; [SharedPool-Worker-1] | 2015-07-03 09:53:25.002000 | 127.0.0.1
|109
Preparing statement [SharedPool-Worker-1] | 2015-07-03 09:53:25.002000 |
127.0.0.1 |193
Executing single-partition query on
raw_weather_data [SharedPool-Worker-2] | 2015-07-03 09:53:25.002000 | 127.0.0.1
|519
Acquiring
sstable references [SharedPool-Worker-2] | 2015-07-03 09:53:25.002000 |
127.0.0.1 |544
Merging
memtable tombstones [SharedPool-Worker-2] | 2015-07-03 09:53:25.002000 |
127.0.0.1 |558
Skipped 0/0 non-slice-intersecting sstables, included 0
due to tombstones [SharedPool-Worker-2] | 2015-07-03 09:53:25.002001 |
127.0.0.1 |600
Merging data from memtables
and 0 sstables [SharedPool-Worker-2] | 2015-07-03 09:53:25.002001 | 127.0.0.1 |
612
Read 92 live and 0
tombstone cells [SharedPool-Worker-2] | 2015-07-03 09:53:25.003000 | 127.0.0.1
|848
Request complete | 2015-07-03 09:53:25.003680 | 127.0.0.1 |
1680
{quote}
However once i include the min function i get: select min(temperature) from
raw_weather_data where wsid = '725030:14732' and year = 2008;
{quote}
activity
| timestamp | source
| source_elapsed
--++---+
Execute CQL3 query | 2015-07-03 09:56:15.904000 |
127.0.0.1 | 0
Parsing select min(temperature) from raw_weather_data where wsid =
'725030:14732' and year = 2008; [SharedPool-Worker-1] | 2015-07-03
09:56:15.904000 | 127.0.0.1 |108
Preparing statement [SharedPool-Worker-1] | 2015-07-03 09:56:15.904000 |
127.0.0.1 |201
Executing single-partition
[jira] [Created] (CASSANDRA-9723) UDF / UDA execution time in trace
Christopher Batey created CASSANDRA-9723: Summary: UDF / UDA execution time in trace Key: CASSANDRA-9723 URL: https://issues.apache.org/jira/browse/CASSANDRA-9723 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Christopher Batey Priority: Minor I'd like to see how long my UDF/As take in the trace. Checked in 2.2rc1 and doesn't appear to be mentioned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9724) UDA appears to be causing query to be executed multiple times
[
https://issues.apache.org/jira/browse/CASSANDRA-9724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Batey updated CASSANDRA-9724:
-
Attachment: data.zip
Dump of rows from raw_weather_data table
UDA appears to be causing query to be executed multiple times
-
Key: CASSANDRA-9724
URL: https://issues.apache.org/jira/browse/CASSANDRA-9724
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Christopher Batey
Assignee: Robert Stupp
Priority: Critical
Attachments: data.zip
Not sure if this is intended behaviour.
Example table:
{quote}
CREATE TABLE raw_weather_data (
wsid text, // Composite of Air Force Datsav3 station number
and NCDC WBAN number
year int,// Year collected
month int, // Month collected
day int, // Day collected
hour int,// Hour collected
temperature double, // Air temperature (degrees Celsius)
dewpoint double, // Dew point temperature (degrees Celsius)
pressure double, // Sea level pressure (hectopascals)
wind_direction int, // Wind direction in degrees. 0-359
wind_speed double,// Wind speed (meters per second)
sky_condition int, // Total cloud cover (coded, see format
documentation)
sky_condition_text text, // Non-coded sky conditions
one_hour_precip double, // One-hour accumulated liquid precipitation
(millimeters)
six_hour_precip double, // Six-hour accumulated liquid precipitation
(millimeters)
PRIMARY KEY ((wsid), year, month, day, hour)
) WITH CLUSTERING ORDER BY (year DESC, month DESC, day DESC, hour DESC);
{quote}
1 node cluster 2.2rc1. Trace for: select temperature from raw_weather_data
where wsid = '725030:14732' and year = 2008;
{quote}
activity
| timestamp | source
| source_elapsed
-++---+
Execute CQL3 query | 2015-07-03 09:53:25.002000 |
127.0.0.1 | 0
Parsing select temperature from raw_weather_data where wsid = '725030:14732'
and year = 2008; [SharedPool-Worker-1] | 2015-07-03 09:53:25.002000 |
127.0.0.1 |109
Preparing statement [SharedPool-Worker-1] | 2015-07-03 09:53:25.002000 |
127.0.0.1 |193
Executing single-partition query on
raw_weather_data [SharedPool-Worker-2] | 2015-07-03 09:53:25.002000 |
127.0.0.1 |519
Acquiring
sstable references [SharedPool-Worker-2] | 2015-07-03 09:53:25.002000 |
127.0.0.1 |544
Merging
memtable tombstones [SharedPool-Worker-2] | 2015-07-03 09:53:25.002000 |
127.0.0.1 |558
Skipped 0/0 non-slice-intersecting sstables, included 0
due to tombstones [SharedPool-Worker-2] | 2015-07-03 09:53:25.002001 |
127.0.0.1 |600
Merging data from
memtables and 0 sstables [SharedPool-Worker-2] | 2015-07-03 09:53:25.002001 |
127.0.0.1 |612
Read 92 live and
0 tombstone cells [SharedPool-Worker-2] | 2015-07-03 09:53:25.003000 |
127.0.0.1 |848
Request complete | 2015-07-03 09:53:25.003680 |
127.0.0.1 | 1680
{quote}
However once i include the min function i get: select min(temperature) from
raw_weather_data where wsid = '725030:14732' and year = 2008;
{quote}
activity
| timestamp |
source| source_elapsed
--++---+
Execute CQL3 query | 2015-07-03 09:56:15.904000 |
127.0.0.1 | 0
Parsing select min(temperature) from raw_weather_data where wsid =
[jira] [Commented] (CASSANDRA-9724) UDA appears to be causing query to be executed multiple times
[
https://issues.apache.org/jira/browse/CASSANDRA-9724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14613035#comment-14613035
]
Christopher Batey commented on CASSANDRA-9724:
--
Uploaded, CSV from the table the queries are done on.
UDA appears to be causing query to be executed multiple times
-
Key: CASSANDRA-9724
URL: https://issues.apache.org/jira/browse/CASSANDRA-9724
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Christopher Batey
Assignee: Robert Stupp
Priority: Critical
Attachments: data.zip
Not sure if this is intended behaviour.
Example table:
{quote}
CREATE TABLE raw_weather_data (
wsid text, // Composite of Air Force Datsav3 station number
and NCDC WBAN number
year int,// Year collected
month int, // Month collected
day int, // Day collected
hour int,// Hour collected
temperature double, // Air temperature (degrees Celsius)
dewpoint double, // Dew point temperature (degrees Celsius)
pressure double, // Sea level pressure (hectopascals)
wind_direction int, // Wind direction in degrees. 0-359
wind_speed double,// Wind speed (meters per second)
sky_condition int, // Total cloud cover (coded, see format
documentation)
sky_condition_text text, // Non-coded sky conditions
one_hour_precip double, // One-hour accumulated liquid precipitation
(millimeters)
six_hour_precip double, // Six-hour accumulated liquid precipitation
(millimeters)
PRIMARY KEY ((wsid), year, month, day, hour)
) WITH CLUSTERING ORDER BY (year DESC, month DESC, day DESC, hour DESC);
{quote}
1 node cluster 2.2rc1. Trace for: select temperature from raw_weather_data
where wsid = '725030:14732' and year = 2008;
{quote}
activity
| timestamp | source
| source_elapsed
-++---+
Execute CQL3 query | 2015-07-03 09:53:25.002000 |
127.0.0.1 | 0
Parsing select temperature from raw_weather_data where wsid = '725030:14732'
and year = 2008; [SharedPool-Worker-1] | 2015-07-03 09:53:25.002000 |
127.0.0.1 |109
Preparing statement [SharedPool-Worker-1] | 2015-07-03 09:53:25.002000 |
127.0.0.1 |193
Executing single-partition query on
raw_weather_data [SharedPool-Worker-2] | 2015-07-03 09:53:25.002000 |
127.0.0.1 |519
Acquiring
sstable references [SharedPool-Worker-2] | 2015-07-03 09:53:25.002000 |
127.0.0.1 |544
Merging
memtable tombstones [SharedPool-Worker-2] | 2015-07-03 09:53:25.002000 |
127.0.0.1 |558
Skipped 0/0 non-slice-intersecting sstables, included 0
due to tombstones [SharedPool-Worker-2] | 2015-07-03 09:53:25.002001 |
127.0.0.1 |600
Merging data from
memtables and 0 sstables [SharedPool-Worker-2] | 2015-07-03 09:53:25.002001 |
127.0.0.1 |612
Read 92 live and
0 tombstone cells [SharedPool-Worker-2] | 2015-07-03 09:53:25.003000 |
127.0.0.1 |848
Request complete | 2015-07-03 09:53:25.003680 |
127.0.0.1 | 1680
{quote}
However once i include the min function i get: select min(temperature) from
raw_weather_data where wsid = '725030:14732' and year = 2008;
{quote}
activity
| timestamp |
source| source_elapsed
--++---+
Execute CQL3 query | 2015-07-03 09:56:15.904000 |
127.0.0.1 | 0
Parsing select
[jira] [Created] (CASSANDRA-9480) Example UDFs don't work
Christopher Batey created CASSANDRA-9480: Summary: Example UDFs don't work Key: CASSANDRA-9480 URL: https://issues.apache.org/jira/browse/CASSANDRA-9480 Project: Cassandra Issue Type: Bug Components: Documentation website Reporter: Christopher Batey Priority: Minor The example function isn't updated for https://issues.apache.org/jira/browse/CASSANDRA-8374 and example aggregate example CQL has create type rather than create table. Updated on this branch: https://github.com/chbatey/cassandra-1/tree/patch-1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9480) Example UDFs don't work
[ https://issues.apache.org/jira/browse/CASSANDRA-9480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14559386#comment-14559386 ] Christopher Batey commented on CASSANDRA-9480: -- Sorry my branch changed the wrong CREATE, it is the CREATE TYPE atable ( pk int PRIMARY KEY, val int); That needs changed. Example UDFs don't work --- Key: CASSANDRA-9480 URL: https://issues.apache.org/jira/browse/CASSANDRA-9480 Project: Cassandra Issue Type: Bug Components: Documentation website Reporter: Christopher Batey Assignee: Robert Stupp Priority: Minor Fix For: 2.2.0 rc1 Attachments: 9480.txt The example function isn't updated for https://issues.apache.org/jira/browse/CASSANDRA-8374 and example aggregate example CQL has create type rather than create table. Updated on this branch: https://github.com/chbatey/cassandra-1/tree/patch-1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
