[jira] [Commented] (CASSANDRA-11482) nodetool: Found unexpected parameters: [gettimeout, read]

[Yuki Morishita (JIRA)]

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

Yuki Morishita commented on CASSANDRA-11482:


{{gettimeout}} is added in v3.4(CASSANDRA-10953).
Can you check your cassandra version?

> nodetool: Found unexpected parameters: [gettimeout, read]
> -
>
> Key: CASSANDRA-11482
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11482
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Dinesh Kumar
>  Labels: gettimeout, nodetool
>
> While getting timeout values from nodetool giving below error.
> {quote}
> root@ubuntu:~# nodetool gettimeout read
> nodetool: Found unexpected parameters: [gettimeout, read]
> See 'nodetool help' or 'nodetool help '.
> {quote}
> Getting the same error on CCM as well.
> {quote}
> $ ccm node1 nodetool gettimeout read
> Traceback (most recent call last):
>   File "E:\Studies\Cassandra\ccm\ccm-master\ccm.py", line 74, in 
> cmd.run()
>   File "E:\Studies\Cassandra\ccm\ccm-master\ccmlib\cmds\node_cmds.py", line 
> 267, in run
> stdout, stderr = self.node.nodetool(" ".join(self.args[1:]))
>   File "E:\Studies\Cassandra\ccm\ccm-master\ccmlib\node.py", line 699, in 
> nodetool
> raise NodetoolError(" ".join(args), exit_status, stdout, stderr)
> ccmlib.node.NodetoolError: Nodetool command 
> 'C:\Users\dins2\.ccm\repository\3.0.3\bin\nodetool.bat -h localhost -p 7100 
> gettimeout read' failed; exit status: 1; stdout: nodetool: Found unexpected 
> parameters: [gettimeout, read]
> See 'nodetool help' or 'nodetool help '.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11482) nodetool: Found unexpected parameters: [gettimeout, read]

[Dinesh Kumar (JIRA)]

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

Dinesh Kumar updated CASSANDRA-11482:
-
Labels: gettimeout nodetool  (was: )

> nodetool: Found unexpected parameters: [gettimeout, read]
> -
>
> Key: CASSANDRA-11482
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11482
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Dinesh Kumar
>  Labels: gettimeout, nodetool
>
> While getting timeout values from nodetool giving below error.
> {quote}
> root@ubuntu:~# nodetool gettimeout read
> nodetool: Found unexpected parameters: [gettimeout, read]
> See 'nodetool help' or 'nodetool help '.
> {quote}
> Getting the same error on CCM as well.
> {quote}
> $ ccm node1 nodetool gettimeout read
> Traceback (most recent call last):
>   File "E:\Studies\Cassandra\ccm\ccm-master\ccm.py", line 74, in 
> cmd.run()
>   File "E:\Studies\Cassandra\ccm\ccm-master\ccmlib\cmds\node_cmds.py", line 
> 267, in run
> stdout, stderr = self.node.nodetool(" ".join(self.args[1:]))
>   File "E:\Studies\Cassandra\ccm\ccm-master\ccmlib\node.py", line 699, in 
> nodetool
> raise NodetoolError(" ".join(args), exit_status, stdout, stderr)
> ccmlib.node.NodetoolError: Nodetool command 
> 'C:\Users\dins2\.ccm\repository\3.0.3\bin\nodetool.bat -h localhost -p 7100 
> gettimeout read' failed; exit status: 1; stdout: nodetool: Found unexpected 
> parameters: [gettimeout, read]
> See 'nodetool help' or 'nodetool help '.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-11482) nodetool: Found unexpected parameters: [gettimeout, read]

[Dinesh Kumar (JIRA)]

Dinesh Kumar created CASSANDRA-11482:


 Summary: nodetool: Found unexpected parameters: [gettimeout, read]
 Key: CASSANDRA-11482
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11482
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Dinesh Kumar


While getting timeout values from nodetool giving below error.

{quote}
root@ubuntu:~# nodetool gettimeout read
nodetool: Found unexpected parameters: [gettimeout, read]
See 'nodetool help' or 'nodetool help '.
{quote}

Getting the same error on CCM as well.

{quote}
$ ccm node1 nodetool gettimeout read
Traceback (most recent call last):
  File "E:\Studies\Cassandra\ccm\ccm-master\ccm.py", line 74, in 
cmd.run()
  File "E:\Studies\Cassandra\ccm\ccm-master\ccmlib\cmds\node_cmds.py", line 
267, in run
stdout, stderr = self.node.nodetool(" ".join(self.args[1:]))
  File "E:\Studies\Cassandra\ccm\ccm-master\ccmlib\node.py", line 699, in 
nodetool
raise NodetoolError(" ".join(args), exit_status, stdout, stderr)
ccmlib.node.NodetoolError: Nodetool command 
'C:\Users\dins2\.ccm\repository\3.0.3\bin\nodetool.bat -h localhost -p 7100 
gettimeout read' failed; exit status: 1; stdout: nodetool: Found unexpected 
parameters: [gettimeout, read]
See 'nodetool help' or 'nodetool help '.
{quote}





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-11183) Enable SASI index for static columns

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich edited comment on CASSANDRA-11183 at 4/3/16 3:46 AM:
-

I think it would be better if instead of Set satisfiesBy and 
localSatisfiesBy methods are to have staticRow instead e.g. 
{{\{local\}SatisfiedBy(Unfiltered currentCluster, Row statics, boolean 
allowMissingColumns)}} and {{ColumnIndex.getValueOf(ColumnDefinition, Row 
cluster, Row statics, int now)}} would just pick correct row to get value data 
from by adding {{case STATIC}}.

Edit: forgot to mention that doing the way in the patch breaks OR support, the 
only feasible way I see to fix that is to use the way I've described which 
doesn't really distinguesh without normal and static columns.


was (Author: xedin):
I think it would be better if instead of Set satisfiesBy and 
localSatisfiesBy methods are to have staticRow instead e.g. 
{{\{local\}SatisfiedBy(Unfiltered currentCluster, Row statics, boolean 
allowMissingColumns)}} and {{ColumnIndex.getValueOf(ColumnDefinition, Row 
cluster, Row statics, int now)}} would just pick correct row to get value data 
from by adding {{case STATIC}}.

> Enable SASI index for static columns
> 
>
> Key: CASSANDRA-11183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11183
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: DOAN DuyHai
>Assignee: DOAN DuyHai
>Priority: Minor
> Fix For: 3.6
>
> Attachments: patch_SASI_for_Static.txt
>
>
> This is a follow up ticket for post Cassandra 3.4 SASI integration.
> Since [CASSANDRA-8103] it is possible to index static columns, which is 
> *extremely useful* for some scenarios (find all sensors whose characteristics 
> are saved in static columns)
> /cc [~xedin] [~rustyrazorblade] [~jkrupan]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-9666) Provide an alternative to DTCS

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis commented on CASSANDRA-9666:
---

I'm working with [~rustyrazorblade] and [~jshook] on getting actual write + 
read amplification numbers on DTCS-with-tiering vs TWCS.

> Provide an alternative to DTCS
> --
>
> Key: CASSANDRA-9666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9666
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 2.1.x, 2.2.x
>
> Attachments: dtcs-twcs-io.png, dtcs-twcs-load.png
>
>
> DTCS is great for time series data, but it comes with caveats that make it 
> difficult to use in production (typical operator behaviors such as bootstrap, 
> removenode, and repair have MAJOR caveats as they relate to 
> max_sstable_age_days, and hints/read repair break the selection algorithm).
> I'm proposing an alternative, TimeWindowCompactionStrategy, that sacrifices 
> the tiered nature of DTCS in order to address some of DTCS' operational 
> shortcomings. I believe it is necessary to propose an alternative rather than 
> simply adjusting DTCS, because it fundamentally removes the tiered nature in 
> order to remove the parameter max_sstable_age_days - the result is very very 
> different, even if it is heavily inspired by DTCS. 
> Specifically, rather than creating a number of windows of ever increasing 
> sizes, this strategy allows an operator to choose the window size, compact 
> with STCS within the first window of that size, and aggressive compact down 
> to a single sstable once that window is no longer current. The window size is 
> a combination of unit (minutes, hours, days) and size (1, etc), such that an 
> operator can expect all data using a block of that size to be compacted 
> together (that is, if your unit is hours, and size is 6, you will create 
> roughly 4 sstables per day, each one containing roughly 6 hours of data). 
> The result addresses a number of the problems with 
> DateTieredCompactionStrategy:
> - At the present time, DTCS’s first window is compacted using an unusual 
> selection criteria, which prefers files with earlier timestamps, but ignores 
> sizes. In TimeWindowCompactionStrategy, the first window data will be 
> compacted with the well tested, fast, reliable STCS. All STCS options can be 
> passed to TimeWindowCompactionStrategy to configure the first window’s 
> compaction behavior.
> - HintedHandoff may put old data in new sstables, but it will have little 
> impact other than slightly reduced efficiency (sstables will cover a wider 
> range, but the old timestamps will not impact sstable selection criteria 
> during compaction)
> - ReadRepair may put old data in new sstables, but it will have little impact 
> other than slightly reduced efficiency (sstables will cover a wider range, 
> but the old timestamps will not impact sstable selection criteria during 
> compaction)
> - Small, old sstables resulting from streams of any kind will be swiftly and 
> aggressively compacted with the other sstables matching their similar 
> maxTimestamp, without causing sstables in neighboring windows to grow in size.
> - The configuration options are explicit and straightforward - the tuning 
> parameters leave little room for error. The window is set in common, easily 
> understandable terms such as “12 hours”, “1 Day”, “30 days”. The 
> minute/hour/day options are granular enough for users keeping data for hours, 
> and users keeping data for years. 
> - There is no explicitly configurable max sstable age, though sstables will 
> naturally stop compacting once new data is written in that window. 
> - Streaming operations can create sstables with old timestamps, and they'll 
> naturally be joined together with sstables in the same time bucket. This is 
> true for bootstrap/repair/sstableloader/removenode. 
> - It remains true that if old data and new data is written into the memtable 
> at the same time, the resulting sstables will be treated as if they were new 
> sstables, however, that no longer negatively impacts the compaction 
> strategy’s selection criteria for older windows. 
> Patch provided for : 
> - 2.1: https://github.com/jeffjirsa/cassandra/commits/twcs-2.1 
> - 2.2: https://github.com/jeffjirsa/cassandra/commits/twcs-2.2
> - trunk (post-8099):  https://github.com/jeffjirsa/cassandra/commits/twcs 
> Rebased, force-pushed July 18, with bug fixes for estimated pending 
> compactions and potential starvation if more than min_threshold tables 
> existed in current window but STCS did not consider them viable candidates
> Rebased, force-pushed Aug 20 to bring in relevant logic from CASSANDRA-9882



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11183) Enable SASI index for static columns

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich commented on CASSANDRA-11183:
-

I think it would be better if instead of Set satisfiesBy and 
localSatisfiesBy methods are to have staticRow instead e.g. 
{{\{local\}SatisfiedBy(Unfiltered currentCluster, Row statics, boolean 
allowMissingColumns)}} and {{ColumnIndex.getValue(ColumnDefinition, Row 
cluster, Row statics, int now)}} would just pick correct row to get value data 
from by adding {{case STATIC}}.

> Enable SASI index for static columns
> 
>
> Key: CASSANDRA-11183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11183
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: DOAN DuyHai
>Assignee: DOAN DuyHai
>Priority: Minor
> Fix For: 3.6
>
> Attachments: patch_SASI_for_Static.txt
>
>
> This is a follow up ticket for post Cassandra 3.4 SASI integration.
> Since [CASSANDRA-8103] it is possible to index static columns, which is 
> *extremely useful* for some scenarios (find all sensors whose characteristics 
> are saved in static columns)
> /cc [~xedin] [~rustyrazorblade] [~jkrupan]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-11183) Enable SASI index for static columns

[Pavel Yaskevich (JIRA)]

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

Pavel Yaskevich edited comment on CASSANDRA-11183 at 4/3/16 2:00 AM:
-

I think it would be better if instead of Set satisfiesBy and 
localSatisfiesBy methods are to have staticRow instead e.g. 
{{\{local\}SatisfiedBy(Unfiltered currentCluster, Row statics, boolean 
allowMissingColumns)}} and {{ColumnIndex.getValueOf(ColumnDefinition, Row 
cluster, Row statics, int now)}} would just pick correct row to get value data 
from by adding {{case STATIC}}.


was (Author: xedin):
I think it would be better if instead of Set satisfiesBy and 
localSatisfiesBy methods are to have staticRow instead e.g. 
{{\{local\}SatisfiedBy(Unfiltered currentCluster, Row statics, boolean 
allowMissingColumns)}} and {{ColumnIndex.getValue(ColumnDefinition, Row 
cluster, Row statics, int now)}} would just pick correct row to get value data 
from by adding {{case STATIC}}.

> Enable SASI index for static columns
> 
>
> Key: CASSANDRA-11183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11183
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: DOAN DuyHai
>Assignee: DOAN DuyHai
>Priority: Minor
> Fix For: 3.6
>
> Attachments: patch_SASI_for_Static.txt
>
>
> This is a follow up ticket for post Cassandra 3.4 SASI integration.
> Since [CASSANDRA-8103] it is possible to index static columns, which is 
> *extremely useful* for some scenarios (find all sensors whose characteristics 
> are saved in static columns)
> /cc [~xedin] [~rustyrazorblade] [~jkrupan]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11462) IncomingStreamingConnection version check message wrong

[Ryan Magnusson (JIRA)]

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

Ryan Magnusson updated CASSANDRA-11462:
---
Status: Patch Available  (was: Open)

> IncomingStreamingConnection version check message wrong
> ---
>
> Key: CASSANDRA-11462
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11462
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Priority: Trivial
>
> If compares against {{StreamMessage.CURRENT_VERSION}} but prints 
> {{MessagingService.current_version}}. The error message is confusing tho.
> {code}
> if (version != StreamMessage.CURRENT_VERSION)
> throw new IOException(String.format("Received stream using 
> protocol version %d (my version %d). Terminating connection", version, 
> MessagingService.current_version));
> {code}
> EDIT: That message is only printed at debug log level



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11462) IncomingStreamingConnection version check message wrong

[Ryan Magnusson (JIRA)]

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

Ryan Magnusson commented on CASSANDRA-11462:


Updated this quick fix here: 
[11462-trunk|https://github.com/RyanMagnusson/cassandra/tree/11462-trunk].



> IncomingStreamingConnection version check message wrong
> ---
>
> Key: CASSANDRA-11462
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11462
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Priority: Trivial
>
> If compares against {{StreamMessage.CURRENT_VERSION}} but prints 
> {{MessagingService.current_version}}. The error message is confusing tho.
> {code}
> if (version != StreamMessage.CURRENT_VERSION)
> throw new IOException(String.format("Received stream using 
> protocol version %d (my version %d). Terminating connection", version, 
> MessagingService.current_version));
> {code}
> EDIT: That message is only printed at debug log level



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (CASSANDRA-5992) Add a logger.trace call to Tracing

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan reopened CASSANDRA-5992:


> Add a logger.trace call to Tracing
> --
>
> Key: CASSANDRA-5992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5992
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeremiah Jordan
>Priority: Minor
>  Labels: lhf
> Attachments: CASSANDRA-5992.txt
>
>
> A bunch of stuff is now written to Tracing, and there are no logging trace 
> calls any more.  If a node is having issues on the read/write path and 
> tracing can't actually save data, there is no way to see through logging what 
> is going on.  Would be nice if we made all Tracing messages also go out at 
> logger.trace so that you could enable that to debug stuff.
> Being able to change the RF of the system_traces KS might also help here, but 
> there would still be classes of problems that it would be good to have the 
> logging there for. Added CASSANDRA-6016 for that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-5992) Add a logger.trace call to Tracing

[Ryan Magnusson (JIRA)]

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

Ryan Magnusson commented on CASSANDRA-5992:
---

Was this change ever committed?

> Add a logger.trace call to Tracing
> --
>
> Key: CASSANDRA-5992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5992
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeremiah Jordan
>Priority: Minor
>  Labels: lhf
> Attachments: CASSANDRA-5992.txt
>
>
> A bunch of stuff is now written to Tracing, and there are no logging trace 
> calls any more.  If a node is having issues on the read/write path and 
> tracing can't actually save data, there is no way to see through logging what 
> is going on.  Would be nice if we made all Tracing messages also go out at 
> logger.trace so that you could enable that to debug stuff.
> Being able to change the RF of the system_traces KS might also help here, but 
> there would still be classes of problems that it would be good to have the 
> logging there for. Added CASSANDRA-6016 for that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-11481) Example metrics config has DroppedMetrics

[Christopher Batey (JIRA)]

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-9666) Provide an alternative to DTCS

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-9666:
---

Rebased April 1, includes changes for CASSANDRA-3 and CASSANDRA-10099

Trunk: https://github.com/jeffjirsa/cassandra/commits/twcs ( 
http://cassci.datastax.com/job/jeffjirsa-twcs-testall/ ) 

If desired: 
2.2: https://github.com/jeffjirsa/cassandra/commits/twcs-2.2 ( 
http://cassci.datastax.com/job/jeffjirsa-twcs-2.2-testall/ )
2.1: https://github.com/jeffjirsa/cassandra/commits/twcs-2.1 ( 
http://cassci.datastax.com/job/jeffjirsa-twcs-2.1-testall/ ) 

In the standalone version for 3.0+, I had a toggle to enable auto-cleanup 
during compaction - I've removed that from this version.  



> Provide an alternative to DTCS
> --
>
> Key: CASSANDRA-9666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9666
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 2.1.x, 2.2.x
>
> Attachments: dtcs-twcs-io.png, dtcs-twcs-load.png
>
>
> DTCS is great for time series data, but it comes with caveats that make it 
> difficult to use in production (typical operator behaviors such as bootstrap, 
> removenode, and repair have MAJOR caveats as they relate to 
> max_sstable_age_days, and hints/read repair break the selection algorithm).
> I'm proposing an alternative, TimeWindowCompactionStrategy, that sacrifices 
> the tiered nature of DTCS in order to address some of DTCS' operational 
> shortcomings. I believe it is necessary to propose an alternative rather than 
> simply adjusting DTCS, because it fundamentally removes the tiered nature in 
> order to remove the parameter max_sstable_age_days - the result is very very 
> different, even if it is heavily inspired by DTCS. 
> Specifically, rather than creating a number of windows of ever increasing 
> sizes, this strategy allows an operator to choose the window size, compact 
> with STCS within the first window of that size, and aggressive compact down 
> to a single sstable once that window is no longer current. The window size is 
> a combination of unit (minutes, hours, days) and size (1, etc), such that an 
> operator can expect all data using a block of that size to be compacted 
> together (that is, if your unit is hours, and size is 6, you will create 
> roughly 4 sstables per day, each one containing roughly 6 hours of data). 
> The result addresses a number of the problems with 
> DateTieredCompactionStrategy:
> - At the present time, DTCS’s first window is compacted using an unusual 
> selection criteria, which prefers files with earlier timestamps, but ignores 
> sizes. In TimeWindowCompactionStrategy, the first window data will be 
> compacted with the well tested, fast, reliable STCS. All STCS options can be 
> passed to TimeWindowCompactionStrategy to configure the first window’s 
> compaction behavior.
> - HintedHandoff may put old data in new sstables, but it will have little 
> impact other than slightly reduced efficiency (sstables will cover a wider 
> range, but the old timestamps will not impact sstable selection criteria 
> during compaction)
> - ReadRepair may put old data in new sstables, but it will have little impact 
> other than slightly reduced efficiency (sstables will cover a wider range, 
> but the old timestamps will not impact sstable selection criteria during 
> compaction)
> - Small, old sstables resulting from streams of any kind will be swiftly and 
> aggressively compacted with the other sstables matching their similar 
> maxTimestamp, without causing sstables in neighboring windows to grow in size.
> - The configuration options are explicit and straightforward - the tuning 
> parameters leave little room for error. The window is set in common, easily 
> understandable terms such as “12 hours”, “1 Day”, “30 days”. The 
> minute/hour/day options are granular enough for users keeping data for hours, 
> and users keeping data for years. 
> - There is no explicitly configurable max sstable age, though sstables will 
> naturally stop compacting once new data is written in that window. 
> - Streaming operations can create sstables with old timestamps, and they'll 
> naturally be joined together with sstables in the same time bucket. This is 
> true for bootstrap/repair/sstableloader/removenode. 
> - It remains true that if old data and new data is written into the memtable 
> at the same time, the resulting sstables will be treated as if they were new 
> sstables, however, that no longer negatively impacts the compaction 
> strategy’s selection criteria for older windows. 
> Patch provided for : 
> - 2.1: https://github.com/jeffjirsa/cassandra/commits/twcs-2.1 
> - 2.2: 

[jira] [Updated] (CASSANDRA-11480) Fix uptodate check for antlr files after 11372

[Robert Stupp (JIRA)]

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

Robert Stupp updated CASSANDRA-11480:
-
Fix Version/s: 3.x

> Fix uptodate check for antlr files after 11372
> --
>
> Key: CASSANDRA-11480
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11480
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Trivial
>  Labels: lhf
> Fix For: 3.x
>
> Attachments: fix-antlr.txt
>
>
> CASSANDRA-11372 has split {{Cql.g}} into three separate files.
> The {{uptodate}} check in {{build.xml}} just checks against {{Cql.g}} but not 
> the two new files.
> Attached trivial patch fixes {{build.xml}} to check against all three files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11480) Fix uptodate check for antlr files after 11372

[Robert Stupp (JIRA)]

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

Robert Stupp updated CASSANDRA-11480:
-
Status: Patch Available  (was: Open)

> Fix uptodate check for antlr files after 11372
> --
>
> Key: CASSANDRA-11480
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11480
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Trivial
> Fix For: 3.x
>
> Attachments: fix-antlr.txt
>
>
> CASSANDRA-11372 has split {{Cql.g}} into three separate files.
> The {{uptodate}} check in {{build.xml}} just checks against {{Cql.g}} but not 
> the two new files.
> Attached trivial patch fixes {{build.xml}} to check against all three files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11480) Fix uptodate check for antlr files after 11372

[Robert Stupp (JIRA)]

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

Robert Stupp updated CASSANDRA-11480:
-
Labels: lhf  (was: )

> Fix uptodate check for antlr files after 11372
> --
>
> Key: CASSANDRA-11480
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11480
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Trivial
>  Labels: lhf
> Fix For: 3.x
>
> Attachments: fix-antlr.txt
>
>
> CASSANDRA-11372 has split {{Cql.g}} into three separate files.
> The {{uptodate}} check in {{build.xml}} just checks against {{Cql.g}} but not 
> the two new files.
> Attached trivial patch fixes {{build.xml}} to check against all three files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-11480) Fix uptodate check for antlr files after 11372

[Robert Stupp (JIRA)]

Robert Stupp created CASSANDRA-11480:


 Summary: Fix uptodate check for antlr files after 11372
 Key: CASSANDRA-11480
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11480
 Project: Cassandra
  Issue Type: Bug
Reporter: Robert Stupp
Assignee: Robert Stupp
Priority: Trivial
 Attachments: fix-antlr.txt

CASSANDRA-11372 has split {{Cql.g}} into three separate files.
The {{uptodate}} check in {{build.xml}} just checks against {{Cql.g}} but not 
the two new files.

Attached trivial patch fixes {{build.xml}} to check against all three files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10273) Reduce number of data directory scans during startup

[Alex Kaiser (JIRA)]

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

Alex Kaiser commented on CASSANDRA-10273:
-

No, been busy, if someone else wants to work on it, feel free.

> Reduce number of data directory scans during startup
> 
>
> Key: CASSANDRA-10273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10273
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Priority: Minor
>  Labels: lhf
>
> ATM we scan each data directory four times. We could easily reduce that to at 
> least two, maybe to one.
> 1. pre-flight (startup tests) scrub
> 1. pre-flight (startup tests) sstable min version
> 1. {{ColumnFamilyStore.createColumnFamilyStore}}
> 1. {{ColumnFamilyStore.}} (if {{loadSSTables==true}})
> First two pre-flight tests could be combined to one and 3+4 could also be 
> combined, as both appear at pretty related code paths.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10273) Reduce number of data directory scans during startup

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-10273:
--

[~alextkaiser], are you still working on this?

> Reduce number of data directory scans during startup
> 
>
> Key: CASSANDRA-10273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10273
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Priority: Minor
>  Labels: lhf
>
> ATM we scan each data directory four times. We could easily reduce that to at 
> least two, maybe to one.
> 1. pre-flight (startup tests) scrub
> 1. pre-flight (startup tests) sstable min version
> 1. {{ColumnFamilyStore.createColumnFamilyStore}}
> 1. {{ColumnFamilyStore.}} (if {{loadSSTables==true}})
> First two pre-flight tests could be combined to one and 3+4 could also be 
> combined, as both appear at pretty related code paths.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-9861) When forcibly exiting due to OOM, we should produce a heap dump

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-9861:
-

Adding the jmap option to also print the heap histogram as proposed in 
CASSANDRA-9604 sounds like a good option.

> When forcibly exiting due to OOM, we should produce a heap dump
> ---
>
> Key: CASSANDRA-9861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Lifecycle
>Reporter: Benedict
>Assignee: Benjamin Lerer
>Priority: Minor
>  Labels: lhf
> Fix For: 2.2.x
>
> Attachments: 9861-2.2.txt
>
>
> CASSANDRA-7507 introduced earlier termination on encountering an OOM, due to 
> lack of certainty about system state. However a side effect is that we never 
> produce heap dumps on OOM. We should ideally try to produce one forcibly 
> before exiting.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-9861) When forcibly exiting due to OOM, we should produce a heap dump

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-9861:
-

There's {{org.hyperic.sigar.Sigar#getPid}} to get the process ID.
Maybe we should use {{jmap}} from {{System.getProperty("java.home") + 
"/bin/jmap"}} (resp. {{jmap.exe}}) and only use {{map}}/{{jmap.exe}} as a 
fallback.


> When forcibly exiting due to OOM, we should produce a heap dump
> ---
>
> Key: CASSANDRA-9861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9861
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Lifecycle
>Reporter: Benedict
>Assignee: Benjamin Lerer
>Priority: Minor
>  Labels: lhf
> Fix For: 2.2.x
>
> Attachments: 9861-2.2.txt
>
>
> CASSANDRA-7507 introduced earlier termination on encountering an OOM, due to 
> lack of certainty about system state. However a side effect is that we never 
> produce heap dumps on OOM. We should ideally try to produce one forcibly 
> before exiting.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11467) Paging loses rows in certain conditions

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-11467:
---
   Resolution: Fixed
Reproduced In: 2.2.5, 2.1.13, 2.0.12  (was: 2.0.12, 2.1.13, 2.2.5)
   Status: Resolved  (was: Ready to Commit)

Committed into 2.1 at ea9b42e7d7bf9003dd6ed911035d3a85a2d99bac and merged into 
2.2

> Paging loses rows in certain conditions
> ---
>
> Key: CASSANDRA-11467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11467
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Ian McMahon
>Assignee: Benjamin Lerer
> Fix For: 2.1.14, 2.2.6
>
> Attachments: 11467-2.2.txt, pagination_test.go
>
>
> The bug occurs under the following conditions:
>   - RandomPartitioner
>   - a compact storage CF
>   - querying across rows
>   - a tombstone in the first column of a row on the pagesize boundary
>   - you need to be querying at least 2*pagesize + 1 records
> Attached is a go program using gocql which reproduces the bug fairly 
> minimally.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11467) Paging loses rows in certain conditions

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-11467:
---
Fix Version/s: (was: 2.2.x)
   2.2.6
   2.1.14

> Paging loses rows in certain conditions
> ---
>
> Key: CASSANDRA-11467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11467
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Ian McMahon
>Assignee: Benjamin Lerer
> Fix For: 2.1.14, 2.2.6
>
> Attachments: 11467-2.2.txt, pagination_test.go
>
>
> The bug occurs under the following conditions:
>   - RandomPartitioner
>   - a compact storage CF
>   - querying across rows
>   - a tombstone in the first column of a row on the pagesize boundary
>   - you need to be querying at least 2*pagesize + 1 records
> Attached is a go program using gocql which reproduces the bug fairly 
> minimally.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[3/3] cassandra git commit: Merge branch cassandra-2.2 into cassandra-3.0

[blerer]

Merge branch cassandra-2.2 into cassandra-3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8b32d48d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8b32d48d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8b32d48d

Branch: refs/heads/cassandra-3.0
Commit: 8b32d48de015bedfcbbc174471eae2a0ca183270
Parents: c6e6fa9 2ed8555
Author: Benjamin Lerer 
Authored: Sat Apr 2 18:03:39 2016 +0200
Committer: Benjamin Lerer 
Committed: Sat Apr 2 18:03:48 2016 +0200

--

--

[1/3] cassandra git commit: Fix paging for COMPACT tables without clustering columns

[blerer]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 c6e6fa94d -> 8b32d48de


Fix paging for COMPACT tables without clustering columns

patch by Benjamin Lerer; reviewed by Tyler Hobbs for CASSANDRA-11467


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ea9b42e7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ea9b42e7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ea9b42e7

Branch: refs/heads/cassandra-3.0
Commit: ea9b42e7d7bf9003dd6ed911035d3a85a2d99bac
Parents: f3b3c41
Author: Benjamin Lerer 
Authored: Sat Apr 2 17:55:04 2016 +0200
Committer: Benjamin Lerer 
Committed: Sat Apr 2 17:55:04 2016 +0200

--
 CHANGES.txt   | 3 ++-
 .../org/apache/cassandra/service/pager/AbstractQueryPager.java| 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ea9b42e7/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 50bc894..113da17 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
 2.1.14
- * Fix out-of-space error treatment in memtable flushing (CASSANDRA-11448).
+ * Fix paging for COMPACT tables without clustering columns (CASSANDRA-11467)
+ * Fix out-of-space error treatment in memtable flushing (CASSANDRA-11448)
  * Backport CASSANDRA-10859 (CASSANDRA-11415)
  * COPY FROM fails when importing blob (CASSANDRA-11375)
  * Backport CASSANDRA-10679 (CASSANDRA-9598)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ea9b42e7/src/java/org/apache/cassandra/service/pager/AbstractQueryPager.java
--
diff --git 
a/src/java/org/apache/cassandra/service/pager/AbstractQueryPager.java 
b/src/java/org/apache/cassandra/service/pager/AbstractQueryPager.java
index 6056b9a..8bbf6d6 100644
--- a/src/java/org/apache/cassandra/service/pager/AbstractQueryPager.java
+++ b/src/java/org/apache/cassandra/service/pager/AbstractQueryPager.java
@@ -359,6 +359,9 @@ abstract class AbstractQueryPager implements QueryPager
 // paging and a deletion (pretty unlikely), so this is probably 
acceptable.
 int liveCount = columnCounter().countAll(cf).live();
 
+if (liveCount == toDiscard)
+return toDiscard;
+
 ColumnCounter counter = columnCounter();
 // Discard the last 'toDiscard' live (so stop adding as sound as we're 
past 'liveCount - toDiscard')
 while (iter.hasNext())

[2/3] cassandra git commit: Merge branch cassandra-2.1 into cassandra-2.2

[blerer]

Merge branch cassandra-2.1 into cassandra-2.2


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2ed85559
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2ed85559
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2ed85559

Branch: refs/heads/cassandra-3.0
Commit: 2ed855592ab77399e061f03f73a943aefbd44eaf
Parents: 0ac2072 ea9b42e
Author: Benjamin Lerer 
Authored: Sat Apr 2 17:59:37 2016 +0200
Committer: Benjamin Lerer 
Committed: Sat Apr 2 17:59:37 2016 +0200

--
 CHANGES.txt   | 1 +
 .../org/apache/cassandra/service/pager/AbstractQueryPager.java| 3 +++
 2 files changed, 4 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2ed85559/CHANGES.txt
--
diff --cc CHANGES.txt
index 28903c5,113da17..4c81a98
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,48 -1,8 +1,49 @@@
 -2.1.14
 +2.2.6
 + * DatabaseDescriptor should log stacktrace in case of Eception during seed 
provider creation (CASSANDRA-11312)
 + * Use canonical path for directory in SSTable descriptor (CASSANDRA-10587)
 + * Add cassandra-stress keystore option (CASSANDRA-9325)
 + * Fix out-of-space error treatment in memtable flushing (CASSANDRA-11448).
 + * Dont mark sstables as repairing with sub range repairs (CASSANDRA-11451)
 + * Fix use of NullUpdater for 2i during compaction (CASSANDRA-11450)
 + * Notify when sstables change after cancelling compaction (CASSANDRA-11373)
 + * cqlsh: COPY FROM should check that explicit column names are valid 
(CASSANDRA-11333)
 + * Add -Dcassandra.start_gossip startup option (CASSANDRA-10809)
 + * Fix UTF8Validator.validate() for modified UTF-8 (CASSANDRA-10748)
 + * Clarify that now() function is calculated on the coordinator node in CQL 
documentation (CASSANDRA-10900)
 + * Fix bloom filter sizing with LCS (CASSANDRA-11344)
 + * (cqlsh) Fix error when result is 0 rows with EXPAND ON (CASSANDRA-11092)
 + * Fix intra-node serialization issue for multicolumn-restrictions 
(CASSANDRA-11196)
 + * Non-obsoleting compaction operations over compressed files can impose rate 
limit on normal reads (CASSANDRA-11301)
 + * Add missing newline at end of bin/cqlsh (CASSANDRA-11325)
 + * Fix AE in nodetool cfstats (backport CASSANDRA-10859) (CASSANDRA-11297)
 + * Unresolved hostname leads to replace being ignored (CASSANDRA-11210)
 + * Fix filtering on non-primary key columns for thrift static column families
 +   (CASSANDRA-6377)
 + * Only log yaml config once, at startup (CASSANDRA-11217)
 + * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
 + * Reference leak with parallel repairs on the same table (CASSANDRA-11215)
 + * Range.compareTo() violates the contract of Comparable (CASSANDRA-11216)
 + * Avoid NPE when serializing ErrorMessage with null message (CASSANDRA-11167)
 + * Replacing an aggregate with a new version doesn't reset INITCOND 
(CASSANDRA-10840)
 + * (cqlsh) cqlsh cannot be called through symlink (CASSANDRA-11037)
 + * fix ohc and java-driver pom dependencies in build.xml (CASSANDRA-10793)
 + * Protect from keyspace dropped during repair (CASSANDRA-11065)
 + * Handle adding fields to a UDT in SELECT JSON and toJson() (CASSANDRA-11146)
 + * Better error message for cleanup (CASSANDRA-10991)
 + * cqlsh pg-style-strings broken if line ends with ';' (CASSANDRA-11123)
 + * Use cloned TokenMetadata in size estimates to avoid race against 
membership check
 +   (CASSANDRA-10736)
 + * Always persist upsampled index summaries (CASSANDRA-10512)
 + * (cqlsh) Fix inconsistent auto-complete (CASSANDRA-10733)
 + * Make SELECT JSON and toJson() threadsafe (CASSANDRA-11048)
 + * Fix SELECT on tuple relations for mixed ASC/DESC clustering order 
(CASSANDRA-7281)
 + * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030)
 + * Fix paging on DISTINCT queries repeats result when first row in partition 
changes
 +   (CASSANDRA-10010)
 +Merged from 2.1:
+  * Fix paging for COMPACT tables without clustering columns (CASSANDRA-11467)
 - * Fix out-of-space error treatment in memtable flushing (CASSANDRA-11448)
 - * Backport CASSANDRA-10859 (CASSANDRA-11415)
 - * COPY FROM fails when importing blob (CASSANDRA-11375)
 + * Add a -j parameter to scrub/cleanup/upgradesstables to state how
 +   many threads to use (CASSANDRA-11179)
   * Backport CASSANDRA-10679 (CASSANDRA-9598)
   * Don't do defragmentation if reading from repaired sstables 
(CASSANDRA-10342)
   * Fix streaming_socket_timeout_in_ms not enforced (CASSANDRA-11286)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/2ed85559/src/java/org/apache/cassandra/service/pager/AbstractQueryPager.java

[1/2] cassandra git commit: Fix paging for COMPACT tables without clustering columns

[blerer]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 0ac2072bb -> 2ed855592


Fix paging for COMPACT tables without clustering columns

patch by Benjamin Lerer; reviewed by Tyler Hobbs for CASSANDRA-11467


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ea9b42e7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ea9b42e7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ea9b42e7

Branch: refs/heads/cassandra-2.2
Commit: ea9b42e7d7bf9003dd6ed911035d3a85a2d99bac
Parents: f3b3c41
Author: Benjamin Lerer 
Authored: Sat Apr 2 17:55:04 2016 +0200
Committer: Benjamin Lerer 
Committed: Sat Apr 2 17:55:04 2016 +0200

--
 CHANGES.txt   | 3 ++-
 .../org/apache/cassandra/service/pager/AbstractQueryPager.java| 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ea9b42e7/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 50bc894..113da17 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
 2.1.14
- * Fix out-of-space error treatment in memtable flushing (CASSANDRA-11448).
+ * Fix paging for COMPACT tables without clustering columns (CASSANDRA-11467)
+ * Fix out-of-space error treatment in memtable flushing (CASSANDRA-11448)
  * Backport CASSANDRA-10859 (CASSANDRA-11415)
  * COPY FROM fails when importing blob (CASSANDRA-11375)
  * Backport CASSANDRA-10679 (CASSANDRA-9598)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ea9b42e7/src/java/org/apache/cassandra/service/pager/AbstractQueryPager.java
--
diff --git 
a/src/java/org/apache/cassandra/service/pager/AbstractQueryPager.java 
b/src/java/org/apache/cassandra/service/pager/AbstractQueryPager.java
index 6056b9a..8bbf6d6 100644
--- a/src/java/org/apache/cassandra/service/pager/AbstractQueryPager.java
+++ b/src/java/org/apache/cassandra/service/pager/AbstractQueryPager.java
@@ -359,6 +359,9 @@ abstract class AbstractQueryPager implements QueryPager
 // paging and a deletion (pretty unlikely), so this is probably 
acceptable.
 int liveCount = columnCounter().countAll(cf).live();
 
+if (liveCount == toDiscard)
+return toDiscard;
+
 ColumnCounter counter = columnCounter();
 // Discard the last 'toDiscard' live (so stop adding as sound as we're 
past 'liveCount - toDiscard')
 while (iter.hasNext())

[2/2] cassandra git commit: Merge branch cassandra-2.1 into cassandra-2.2

[blerer]

Merge branch cassandra-2.1 into cassandra-2.2


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2ed85559
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2ed85559
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2ed85559

Branch: refs/heads/cassandra-2.2
Commit: 2ed855592ab77399e061f03f73a943aefbd44eaf
Parents: 0ac2072 ea9b42e
Author: Benjamin Lerer 
Authored: Sat Apr 2 17:59:37 2016 +0200
Committer: Benjamin Lerer 
Committed: Sat Apr 2 17:59:37 2016 +0200

--
 CHANGES.txt   | 1 +
 .../org/apache/cassandra/service/pager/AbstractQueryPager.java| 3 +++
 2 files changed, 4 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2ed85559/CHANGES.txt
--
diff --cc CHANGES.txt
index 28903c5,113da17..4c81a98
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,48 -1,8 +1,49 @@@
 -2.1.14
 +2.2.6
 + * DatabaseDescriptor should log stacktrace in case of Eception during seed 
provider creation (CASSANDRA-11312)
 + * Use canonical path for directory in SSTable descriptor (CASSANDRA-10587)
 + * Add cassandra-stress keystore option (CASSANDRA-9325)
 + * Fix out-of-space error treatment in memtable flushing (CASSANDRA-11448).
 + * Dont mark sstables as repairing with sub range repairs (CASSANDRA-11451)
 + * Fix use of NullUpdater for 2i during compaction (CASSANDRA-11450)
 + * Notify when sstables change after cancelling compaction (CASSANDRA-11373)
 + * cqlsh: COPY FROM should check that explicit column names are valid 
(CASSANDRA-11333)
 + * Add -Dcassandra.start_gossip startup option (CASSANDRA-10809)
 + * Fix UTF8Validator.validate() for modified UTF-8 (CASSANDRA-10748)
 + * Clarify that now() function is calculated on the coordinator node in CQL 
documentation (CASSANDRA-10900)
 + * Fix bloom filter sizing with LCS (CASSANDRA-11344)
 + * (cqlsh) Fix error when result is 0 rows with EXPAND ON (CASSANDRA-11092)
 + * Fix intra-node serialization issue for multicolumn-restrictions 
(CASSANDRA-11196)
 + * Non-obsoleting compaction operations over compressed files can impose rate 
limit on normal reads (CASSANDRA-11301)
 + * Add missing newline at end of bin/cqlsh (CASSANDRA-11325)
 + * Fix AE in nodetool cfstats (backport CASSANDRA-10859) (CASSANDRA-11297)
 + * Unresolved hostname leads to replace being ignored (CASSANDRA-11210)
 + * Fix filtering on non-primary key columns for thrift static column families
 +   (CASSANDRA-6377)
 + * Only log yaml config once, at startup (CASSANDRA-11217)
 + * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
 + * Reference leak with parallel repairs on the same table (CASSANDRA-11215)
 + * Range.compareTo() violates the contract of Comparable (CASSANDRA-11216)
 + * Avoid NPE when serializing ErrorMessage with null message (CASSANDRA-11167)
 + * Replacing an aggregate with a new version doesn't reset INITCOND 
(CASSANDRA-10840)
 + * (cqlsh) cqlsh cannot be called through symlink (CASSANDRA-11037)
 + * fix ohc and java-driver pom dependencies in build.xml (CASSANDRA-10793)
 + * Protect from keyspace dropped during repair (CASSANDRA-11065)
 + * Handle adding fields to a UDT in SELECT JSON and toJson() (CASSANDRA-11146)
 + * Better error message for cleanup (CASSANDRA-10991)
 + * cqlsh pg-style-strings broken if line ends with ';' (CASSANDRA-11123)
 + * Use cloned TokenMetadata in size estimates to avoid race against 
membership check
 +   (CASSANDRA-10736)
 + * Always persist upsampled index summaries (CASSANDRA-10512)
 + * (cqlsh) Fix inconsistent auto-complete (CASSANDRA-10733)
 + * Make SELECT JSON and toJson() threadsafe (CASSANDRA-11048)
 + * Fix SELECT on tuple relations for mixed ASC/DESC clustering order 
(CASSANDRA-7281)
 + * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030)
 + * Fix paging on DISTINCT queries repeats result when first row in partition 
changes
 +   (CASSANDRA-10010)
 +Merged from 2.1:
+  * Fix paging for COMPACT tables without clustering columns (CASSANDRA-11467)
 - * Fix out-of-space error treatment in memtable flushing (CASSANDRA-11448)
 - * Backport CASSANDRA-10859 (CASSANDRA-11415)
 - * COPY FROM fails when importing blob (CASSANDRA-11375)
 + * Add a -j parameter to scrub/cleanup/upgradesstables to state how
 +   many threads to use (CASSANDRA-11179)
   * Backport CASSANDRA-10679 (CASSANDRA-9598)
   * Don't do defragmentation if reading from repaired sstables 
(CASSANDRA-10342)
   * Fix streaming_socket_timeout_in_ms not enforced (CASSANDRA-11286)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/2ed85559/src/java/org/apache/cassandra/service/pager/AbstractQueryPager.java

cassandra git commit: Fix paging for COMPACT tables without clustering columns

[blerer]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 f3b3c410a -> ea9b42e7d


Fix paging for COMPACT tables without clustering columns

patch by Benjamin Lerer; reviewed by Tyler Hobbs for CASSANDRA-11467


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ea9b42e7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ea9b42e7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ea9b42e7

Branch: refs/heads/cassandra-2.1
Commit: ea9b42e7d7bf9003dd6ed911035d3a85a2d99bac
Parents: f3b3c41
Author: Benjamin Lerer 
Authored: Sat Apr 2 17:55:04 2016 +0200
Committer: Benjamin Lerer 
Committed: Sat Apr 2 17:55:04 2016 +0200

--
 CHANGES.txt   | 3 ++-
 .../org/apache/cassandra/service/pager/AbstractQueryPager.java| 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ea9b42e7/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 50bc894..113da17 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
 2.1.14
- * Fix out-of-space error treatment in memtable flushing (CASSANDRA-11448).
+ * Fix paging for COMPACT tables without clustering columns (CASSANDRA-11467)
+ * Fix out-of-space error treatment in memtable flushing (CASSANDRA-11448)
  * Backport CASSANDRA-10859 (CASSANDRA-11415)
  * COPY FROM fails when importing blob (CASSANDRA-11375)
  * Backport CASSANDRA-10679 (CASSANDRA-9598)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ea9b42e7/src/java/org/apache/cassandra/service/pager/AbstractQueryPager.java
--
diff --git 
a/src/java/org/apache/cassandra/service/pager/AbstractQueryPager.java 
b/src/java/org/apache/cassandra/service/pager/AbstractQueryPager.java
index 6056b9a..8bbf6d6 100644
--- a/src/java/org/apache/cassandra/service/pager/AbstractQueryPager.java
+++ b/src/java/org/apache/cassandra/service/pager/AbstractQueryPager.java
@@ -359,6 +359,9 @@ abstract class AbstractQueryPager implements QueryPager
 // paging and a deletion (pretty unlikely), so this is probably 
acceptable.
 int liveCount = columnCounter().countAll(cf).live();
 
+if (liveCount == toDiscard)
+return toDiscard;
+
 ColumnCounter counter = columnCounter();
 // Discard the last 'toDiscard' live (so stop adding as sound as we're 
past 'liveCount - toDiscard')
 while (iter.hasNext())

[jira] [Updated] (CASSANDRA-11349) MerkleTree mismatch when multiple range tombstones exists for the same partition and interval

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-11349:
---
Attachment: (was: 11349-2.1.patch)

> MerkleTree mismatch when multiple range tombstones exists for the same 
> partition and interval
> -
>
> Key: CASSANDRA-11349
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11349
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Fabien Rousseau
>Assignee: Stefan Podkowinski
>  Labels: repair
> Fix For: 2.1.x, 2.2.x
>
> Attachments: 11349-2.1.patch
>
>
> We observed that repair, for some of our clusters, streamed a lot of data and 
> many partitions were "out of sync".
> Moreover, the read repair mismatch ratio is around 3% on those clusters, 
> which is really high.
> After investigation, it appears that, if two range tombstones exists for a 
> partition for the same range/interval, they're both included in the merkle 
> tree computation.
> But, if for some reason, on another node, the two range tombstones were 
> already compacted into a single range tombstone, this will result in a merkle 
> tree difference.
> Currently, this is clearly bad because MerkleTree differences are dependent 
> on compactions (and if a partition is deleted and created multiple times, the 
> only way to ensure that repair "works correctly"/"don't overstream data" is 
> to major compact before each repair... which is not really feasible).
> Below is a list of steps allowing to easily reproduce this case:
> {noformat}
> ccm create test -v 2.1.13 -n 2 -s
> ccm node1 cqlsh
> CREATE KEYSPACE test_rt WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 2};
> USE test_rt;
> CREATE TABLE IF NOT EXISTS table1 (
> c1 text,
> c2 text,
> c3 float,
> c4 float,
> PRIMARY KEY ((c1), c2)
> );
> INSERT INTO table1 (c1, c2, c3, c4) VALUES ( 'a', 'b', 1, 2);
> DELETE FROM table1 WHERE c1 = 'a' AND c2 = 'b';
> ctrl ^d
> # now flush only one of the two nodes
> ccm node1 flush 
> ccm node1 cqlsh
> USE test_rt;
> INSERT INTO table1 (c1, c2, c3, c4) VALUES ( 'a', 'b', 1, 3);
> DELETE FROM table1 WHERE c1 = 'a' AND c2 = 'b';
> ctrl ^d
> ccm node1 repair
> # now grep the log and observe that there was some inconstencies detected 
> between nodes (while it shouldn't have detected any)
> ccm node1 showlog | grep "out of sync"
> {noformat}
> Consequences of this are a costly repair, accumulating many small SSTables 
> (up to thousands for a rather short period of time when using VNodes, the 
> time for compaction to absorb those small files), but also an increased size 
> on disk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11349) MerkleTree mismatch when multiple range tombstones exists for the same partition and interval

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-11349:
---
Attachment: 11349-2.1.patch

> MerkleTree mismatch when multiple range tombstones exists for the same 
> partition and interval
> -
>
> Key: CASSANDRA-11349
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11349
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Fabien Rousseau
>Assignee: Stefan Podkowinski
>  Labels: repair
> Fix For: 2.1.x, 2.2.x
>
> Attachments: 11349-2.1.patch
>
>
> We observed that repair, for some of our clusters, streamed a lot of data and 
> many partitions were "out of sync".
> Moreover, the read repair mismatch ratio is around 3% on those clusters, 
> which is really high.
> After investigation, it appears that, if two range tombstones exists for a 
> partition for the same range/interval, they're both included in the merkle 
> tree computation.
> But, if for some reason, on another node, the two range tombstones were 
> already compacted into a single range tombstone, this will result in a merkle 
> tree difference.
> Currently, this is clearly bad because MerkleTree differences are dependent 
> on compactions (and if a partition is deleted and created multiple times, the 
> only way to ensure that repair "works correctly"/"don't overstream data" is 
> to major compact before each repair... which is not really feasible).
> Below is a list of steps allowing to easily reproduce this case:
> {noformat}
> ccm create test -v 2.1.13 -n 2 -s
> ccm node1 cqlsh
> CREATE KEYSPACE test_rt WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 2};
> USE test_rt;
> CREATE TABLE IF NOT EXISTS table1 (
> c1 text,
> c2 text,
> c3 float,
> c4 float,
> PRIMARY KEY ((c1), c2)
> );
> INSERT INTO table1 (c1, c2, c3, c4) VALUES ( 'a', 'b', 1, 2);
> DELETE FROM table1 WHERE c1 = 'a' AND c2 = 'b';
> ctrl ^d
> # now flush only one of the two nodes
> ccm node1 flush 
> ccm node1 cqlsh
> USE test_rt;
> INSERT INTO table1 (c1, c2, c3, c4) VALUES ( 'a', 'b', 1, 3);
> DELETE FROM table1 WHERE c1 = 'a' AND c2 = 'b';
> ctrl ^d
> ccm node1 repair
> # now grep the log and observe that there was some inconstencies detected 
> between nodes (while it shouldn't have detected any)
> ccm node1 showlog | grep "out of sync"
> {noformat}
> Consequences of this are a costly repair, accumulating many small SSTables 
> (up to thousands for a rather short period of time when using VNodes, the 
> time for compaction to absorb those small files), but also an increased size 
> on disk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11349) MerkleTree mismatch when multiple range tombstones exists for the same partition and interval

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski commented on CASSANDRA-11349:


It makes sense just to modify {{onDiskAtomComparator}}. Given the generic name 
I assumed the comparator is used in other places as well, but since its only 
used in {{LazyCompactedRow}} we can just change the patch as suggested and 
simply remove the timestamp tie-break behaviour in {{onDiskAtomComparator}}. 

As for regular compactions, I agree with Tyler that this should not effect 
compactions in a way that it does with validation compaction. Before the patch, 
{{LazyCompactedRow}} would not reduce both RTs but instead have 
{{ColumnIndex.buildForCompaction()}} iterate over both RTs and have them added 
to the {{RangeTombstone.Tracker}}. The tracker would merge them in a way 
{{LCR.Reducer.getReduced}} would after the patch. However, I’m not fully sure 
if there could be some other for more complex cases where this still would 
cause problems.

Although the patch should fix the described issue, the way we deal with RTs 
during validation compaction is still not ideal. The problem is that LCR lacks 
some handling of relationships between RTs compared to 
{{RangeTombstone.Tracker}}. If we create digests column by column, we get wrong 
results for shadowing tombstones not sharing the same intervals.

{noformat}
CREATE KEYSPACE test_rt WITH replication = {'class': 'SimpleStrategy', 
'replication_factor': 2};
USE test_rt;
CREATE TABLE IF NOT EXISTS table1 (
c1 text,
c2 text,
c3 text,
c4 float,
PRIMARY KEY (c1, c2, c3)
) WITH compaction = {'class': 'SizeTieredCompactionStrategy', 'enabled': 
'false'};
DELETE FROM table1 WHERE c1 = 'a' AND c2 = 'b' AND c3 = 'c';

ccm node1 flush

DELETE FROM table1 WHERE c1 = 'a' AND c2 = 'b';

ccm node1 repair test_rt table1
{noformat}


In this case the (c1, c2, c3) RT will always be repaired after it has been 
compacted with (c1, c2) on any node. 
So I’m wondering if we shouldn’t take a more bold approach here than the patch 
does. 


> MerkleTree mismatch when multiple range tombstones exists for the same 
> partition and interval
> -
>
> Key: CASSANDRA-11349
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11349
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Fabien Rousseau
>Assignee: Stefan Podkowinski
>  Labels: repair
> Fix For: 2.1.x, 2.2.x
>
> Attachments: 11349-2.1.patch
>
>
> We observed that repair, for some of our clusters, streamed a lot of data and 
> many partitions were "out of sync".
> Moreover, the read repair mismatch ratio is around 3% on those clusters, 
> which is really high.
> After investigation, it appears that, if two range tombstones exists for a 
> partition for the same range/interval, they're both included in the merkle 
> tree computation.
> But, if for some reason, on another node, the two range tombstones were 
> already compacted into a single range tombstone, this will result in a merkle 
> tree difference.
> Currently, this is clearly bad because MerkleTree differences are dependent 
> on compactions (and if a partition is deleted and created multiple times, the 
> only way to ensure that repair "works correctly"/"don't overstream data" is 
> to major compact before each repair... which is not really feasible).
> Below is a list of steps allowing to easily reproduce this case:
> {noformat}
> ccm create test -v 2.1.13 -n 2 -s
> ccm node1 cqlsh
> CREATE KEYSPACE test_rt WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 2};
> USE test_rt;
> CREATE TABLE IF NOT EXISTS table1 (
> c1 text,
> c2 text,
> c3 float,
> c4 float,
> PRIMARY KEY ((c1), c2)
> );
> INSERT INTO table1 (c1, c2, c3, c4) VALUES ( 'a', 'b', 1, 2);
> DELETE FROM table1 WHERE c1 = 'a' AND c2 = 'b';
> ctrl ^d
> # now flush only one of the two nodes
> ccm node1 flush 
> ccm node1 cqlsh
> USE test_rt;
> INSERT INTO table1 (c1, c2, c3, c4) VALUES ( 'a', 'b', 1, 3);
> DELETE FROM table1 WHERE c1 = 'a' AND c2 = 'b';
> ctrl ^d
> ccm node1 repair
> # now grep the log and observe that there was some inconstencies detected 
> between nodes (while it shouldn't have detected any)
> ccm node1 showlog | grep "out of sync"
> {noformat}
> Consequences of this are a costly repair, accumulating many small SSTables 
> (up to thousands for a rather short period of time when using VNodes, the 
> time for compaction to absorb those small files), but also an increased size 
> on disk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11183) Enable SASI index for static columns

[DOAN DuyHai (JIRA)]

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

DOAN DuyHai updated CASSANDRA-11183:

Fix Version/s: 3.6
   Status: Patch Available  (was: Open)

> Enable SASI index for static columns
> 
>
> Key: CASSANDRA-11183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11183
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: DOAN DuyHai
>Assignee: DOAN DuyHai
>Priority: Minor
> Fix For: 3.6
>
> Attachments: patch_SASI_for_Static.txt
>
>
> This is a follow up ticket for post Cassandra 3.4 SASI integration.
> Since [CASSANDRA-8103] it is possible to index static columns, which is 
> *extremely useful* for some scenarios (find all sensors whose characteristics 
> are saved in static columns)
> /cc [~xedin] [~rustyrazorblade] [~jkrupan]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[cassandra] Git Push Summary

[jake]

Repository: cassandra
Updated Tags:  refs/tags/3.5-tentative [created] 89bd93502

[jira] [Updated] (CASSANDRA-11309) Generic Java UDF types broken for RETURNS NULL ON NULL INPUT

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-11309:
---
Fix Version/s: (was: 3.5)
   3.6

> Generic Java UDF types broken for RETURNS NULL ON NULL INPUT
> 
>
> Key: CASSANDRA-11309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11309
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.6
>
>
> The Java source generated for Java UDFs as introduced by CASSANDRA-10819 is 
> broken for {{RETURNS NULL ON NULL INPUT}} (not for {{CALLED ON NULL INPUT}}). 
> This means that the generic types are lost for RETURNS NULL ON NULL INPUT but 
> work as expected for CALLED ON NULL INPUT.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-10649) Improve field-checking and error reporting in cassandra.yaml

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-10649:
---
Fix Version/s: (was: 3.0.5)
   (was: 3.5)
   3.0.6
   3.6

> Improve field-checking and error reporting in cassandra.yaml
> 
>
> Key: CASSANDRA-10649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10649
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
> Environment: Linux: Fedora-16 64 bit
>Reporter: sandeep thakur
>Assignee: Benjamin Lerer
>Priority: Minor
> Fix For: 2.2.6, 3.6, 3.0.6
>
> Attachments: 10649-2.2-V2.txt, 10649-2.2.txt, 10649-3.0-V2.txt, 
> 10649-3.0.txt, cassandra.yaml
>
>
> I am trying to setup cassandra single node cluster. i've downloaded below 
> build:
> apache-cassandra-2.1.11-bin.tar.gz
> I've upgraded Java to 1.8 as well, as earlier it was throwing errors related 
> to Java version.
> {code}
> [root@localhost cassandra]# java -version
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
> {code}
> I've also verified the cassandra.yaml file from "http://www.yamllint.com/; as 
> well. But while starting cassandra, I am getting vague exception as below:
> {code}
> INFO  15:52:11 Compacting 
> [SSTableReader(path='/home/sandeep/bck_up/data/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/system-local-ka-18-Data.db'),
>  
> SSTableReader(path='/home/sandeep/bck_up/data/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/system-local-ka-17-Data.db'),
>  
> SSTableReader(path='/home/sandeep/bck_up/data/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/system-local-ka-20-Data.db'),
>  
> SSTableReader(path='/home/sandeep/bck_up/data/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/system-local-ka-19-Data.db')]
> INFO  15:52:11 Node localhost/127.0.0.1 state jump to normal
> INFO  15:52:11 Netty using native Epoll event loop
> ERROR 15:52:11 Exception encountered during startup
> java.lang.NullPointerException: null
> at org.apache.cassandra.transport.Server.run(Server.java:171) 
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at org.apache.cassandra.transport.Server.start(Server.java:117) 
> ~[apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:492) 
> [apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:575)
>  [apache-cassandra-2.1.11.jar:2.1.11]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:651) 
> [apache-cassandra-2.1.11.jar:2.1.11]
> java.lang.NullPointerException
> at org.apache.cassandra.transport.Server.run(Server.java:171)
> at org.apache.cassandra.transport.Server.start(Server.java:117)
> at 
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:492)
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:575)
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:651)
> Exception encountered during startup: null
> INFO  15:52:11 Announcing shutdown
> INFO  15:52:11 Node localhost/127.0.0.1 state jump to normal
> INFO  15:52:11 Compacted 4 sstables to 
> [/home/sandeep/bck_up/data/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/system-local-ka-21,].
>   11,427 bytes to 5,749 (~50% of original) in 199ms = 0.027551MB/s.  4 total 
> partitions merged to 1.  Partition merge counts were {4:1, }
> INFO  15:52:13 Waiting for messaging service to quiesce
> INFO  15:52:13 MessagingService has terminated the accept() thread
> [root@localhost server]#
> {code}
> I've also posted the issue on stack overflow as well:
> http://stackoverflow.com/questions/33514745/cassandra-startup-failed-with-exception-exception-encountered-during-startup
> Request some one to assist on this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[cassandra] Git Push Summary

[jake]

Repository: cassandra
Updated Tags:  refs/tags/3.0.5-tentative [created] c6e6fa94d

[5/8] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.5

[jake]

Merge branch 'cassandra-3.0' into cassandra-3.5


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a28d6d18
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a28d6d18
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a28d6d18

Branch: refs/heads/trunk
Commit: a28d6d18d3a644aae1c3522795dc3a13f95c6552
Parents: 18f8c2f c6e6fa9
Author: T Jake Luciani 
Authored: Sat Apr 2 07:58:45 2016 -0400
Committer: T Jake Luciani 
Committed: Sat Apr 2 07:58:45 2016 -0400

--

--

[8/8] cassandra git commit: Merge branch 'cassandra-3.5' into trunk

[jake]

Merge branch 'cassandra-3.5' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e375a9b1
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e375a9b1
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e375a9b1

Branch: refs/heads/trunk
Commit: e375a9b1bc8ee7319df69e1b074588c6303da3ba
Parents: 204cf34 89bd935
Author: T Jake Luciani 
Authored: Sat Apr 2 08:01:32 2016 -0400
Committer: T Jake Luciani 
Committed: Sat Apr 2 08:01:32 2016 -0400

--

--

[3/8] cassandra git commit: 3.0.5 version bump

[jake]

3.0.5 version bump


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c6e6fa94
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c6e6fa94
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c6e6fa94

Branch: refs/heads/trunk
Commit: c6e6fa94d28c0d23a8154e3743c05b355dba710a
Parents: d3f6f94
Author: T Jake Luciani 
Authored: Sat Apr 2 07:58:13 2016 -0400
Committer: T Jake Luciani 
Committed: Sat Apr 2 07:58:13 2016 -0400

--
 NEWS.txt | 8 
 build.xml| 2 +-
 debian/changelog | 8 +++-
 3 files changed, 16 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6e6fa94/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 5fca578..1b982cb 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,14 @@ restore snapshots created with the previous major version 
using the
 'sstableloader' tool. You can upgrade the file format of your snapshots
 using the provided 'sstableupgrade' tool.
 
+3.0.5
+=
+
+Upgrading
+-
+   - Nothing specific to this release, but please see previous versions 
upgrading section,
+ especially if you are upgrading from 2.2.
+
 3.0.4
 =
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6e6fa94/build.xml
--
diff --git a/build.xml b/build.xml
index 5ece0f7..27de95c 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 
 
 
-
+
 
 
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6e6fa94/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 5e53f1e..7319ce7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,14 @@
+cassandra (3.0.5) unstable; urgency=medium
+
+  * New release
+
+ -- Jake Luciani   Sat, 02 Apr 2016 07:57:16 -0400
+
 cassandra (3.0.4) unstable; urgency=medium
 
   * New release
 
- -- Jake Luciani   Mon, 29 Feb 2016 10:36:33 -0500
+ -- Jake Luciani   Mon, 29 Feb 2016 10:36:33 -0500
 
 cassandra (3.0.3) unstable; urgency=medium
 

[7/8] cassandra git commit: 3.5 version bump

[jake]

3.5 version bump


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/89bd9350
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/89bd9350
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/89bd9350

Branch: refs/heads/cassandra-3.5
Commit: 89bd93502ac141f8cd13f8738bb4314488db2a5a
Parents: a28d6d1
Author: T Jake Luciani 
Authored: Sat Apr 2 08:00:48 2016 -0400
Committer: T Jake Luciani 
Committed: Sat Apr 2 08:00:48 2016 -0400

--
 NEWS.txt | 8 
 debian/changelog | 6 ++
 2 files changed, 14 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/89bd9350/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index d554ac2..4a9fce8 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,14 @@ restore snapshots created with the previous major version 
using the
 'sstableloader' tool. You can upgrade the file format of your snapshots
 using the provided 'sstableupgrade' tool.
 
+3.5
+===
+
+Upgrading
+-
+- Nothing specific to 3.4 but please see previous versions upgrading 
section,
+  especially if you are upgrading from 2.2.
+
 3.4
 ===
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/89bd9350/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index a8d7e7a..21884a4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (3.5) unstable; urgency=medium
+
+  * New release
+
+ -- Jake Luciani   Sat, 02 Apr 2016 07:59:56 -0400
+
 cassandra (3.4) unstable; urgency=medium
 
   * New release

[6/8] cassandra git commit: 3.5 version bump

[jake]

3.5 version bump


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/89bd9350
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/89bd9350
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/89bd9350

Branch: refs/heads/trunk
Commit: 89bd93502ac141f8cd13f8738bb4314488db2a5a
Parents: a28d6d1
Author: T Jake Luciani 
Authored: Sat Apr 2 08:00:48 2016 -0400
Committer: T Jake Luciani 
Committed: Sat Apr 2 08:00:48 2016 -0400

--
 NEWS.txt | 8 
 debian/changelog | 6 ++
 2 files changed, 14 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/89bd9350/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index d554ac2..4a9fce8 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,14 @@ restore snapshots created with the previous major version 
using the
 'sstableloader' tool. You can upgrade the file format of your snapshots
 using the provided 'sstableupgrade' tool.
 
+3.5
+===
+
+Upgrading
+-
+- Nothing specific to 3.4 but please see previous versions upgrading 
section,
+  especially if you are upgrading from 2.2.
+
 3.4
 ===
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/89bd9350/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index a8d7e7a..21884a4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (3.5) unstable; urgency=medium
+
+  * New release
+
+ -- Jake Luciani   Sat, 02 Apr 2016 07:59:56 -0400
+
 cassandra (3.4) unstable; urgency=medium
 
   * New release

[2/8] cassandra git commit: 3.0.5 version bump

[jake]

3.0.5 version bump


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c6e6fa94
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c6e6fa94
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c6e6fa94

Branch: refs/heads/cassandra-3.5
Commit: c6e6fa94d28c0d23a8154e3743c05b355dba710a
Parents: d3f6f94
Author: T Jake Luciani 
Authored: Sat Apr 2 07:58:13 2016 -0400
Committer: T Jake Luciani 
Committed: Sat Apr 2 07:58:13 2016 -0400

--
 NEWS.txt | 8 
 build.xml| 2 +-
 debian/changelog | 8 +++-
 3 files changed, 16 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6e6fa94/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 5fca578..1b982cb 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,14 @@ restore snapshots created with the previous major version 
using the
 'sstableloader' tool. You can upgrade the file format of your snapshots
 using the provided 'sstableupgrade' tool.
 
+3.0.5
+=
+
+Upgrading
+-
+   - Nothing specific to this release, but please see previous versions 
upgrading section,
+ especially if you are upgrading from 2.2.
+
 3.0.4
 =
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6e6fa94/build.xml
--
diff --git a/build.xml b/build.xml
index 5ece0f7..27de95c 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 
 
 
-
+
 
 
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6e6fa94/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 5e53f1e..7319ce7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,14 @@
+cassandra (3.0.5) unstable; urgency=medium
+
+  * New release
+
+ -- Jake Luciani   Sat, 02 Apr 2016 07:57:16 -0400
+
 cassandra (3.0.4) unstable; urgency=medium
 
   * New release
 
- -- Jake Luciani   Mon, 29 Feb 2016 10:36:33 -0500
+ -- Jake Luciani   Mon, 29 Feb 2016 10:36:33 -0500
 
 cassandra (3.0.3) unstable; urgency=medium
 

[4/8] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.5

[jake]

Merge branch 'cassandra-3.0' into cassandra-3.5


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a28d6d18
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a28d6d18
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a28d6d18

Branch: refs/heads/cassandra-3.5
Commit: a28d6d18d3a644aae1c3522795dc3a13f95c6552
Parents: 18f8c2f c6e6fa9
Author: T Jake Luciani 
Authored: Sat Apr 2 07:58:45 2016 -0400
Committer: T Jake Luciani 
Committed: Sat Apr 2 07:58:45 2016 -0400

--

--

[1/8] cassandra git commit: 3.0.5 version bump

[jake]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 d3f6f9438 -> c6e6fa94d
  refs/heads/cassandra-3.5 18f8c2fea -> 89bd93502
  refs/heads/trunk 204cf3478 -> e375a9b1b


3.0.5 version bump


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c6e6fa94
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c6e6fa94
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c6e6fa94

Branch: refs/heads/cassandra-3.0
Commit: c6e6fa94d28c0d23a8154e3743c05b355dba710a
Parents: d3f6f94
Author: T Jake Luciani 
Authored: Sat Apr 2 07:58:13 2016 -0400
Committer: T Jake Luciani 
Committed: Sat Apr 2 07:58:13 2016 -0400

--
 NEWS.txt | 8 
 build.xml| 2 +-
 debian/changelog | 8 +++-
 3 files changed, 16 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6e6fa94/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 5fca578..1b982cb 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,14 @@ restore snapshots created with the previous major version 
using the
 'sstableloader' tool. You can upgrade the file format of your snapshots
 using the provided 'sstableupgrade' tool.
 
+3.0.5
+=
+
+Upgrading
+-
+   - Nothing specific to this release, but please see previous versions 
upgrading section,
+ especially if you are upgrading from 2.2.
+
 3.0.4
 =
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6e6fa94/build.xml
--
diff --git a/build.xml b/build.xml
index 5ece0f7..27de95c 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 
 
 
-
+
 
 
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c6e6fa94/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 5e53f1e..7319ce7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,14 @@
+cassandra (3.0.5) unstable; urgency=medium
+
+  * New release
+
+ -- Jake Luciani   Sat, 02 Apr 2016 07:57:16 -0400
+
 cassandra (3.0.4) unstable; urgency=medium
 
   * New release
 
- -- Jake Luciani   Mon, 29 Feb 2016 10:36:33 -0500
+ -- Jake Luciani   Mon, 29 Feb 2016 10:36:33 -0500
 
 cassandra (3.0.3) unstable; urgency=medium
 

[jira] [Commented] (CASSANDRA-11183) Enable SASI index for static columns

[DOAN DuyHai (JIRA)]

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

DOAN DuyHai commented on CASSANDRA-11183:
-

*Test scenario*

*Schema* & *data*:
{noformat}
CREATE TABLE sensors(
sensor_id int,
sensor_type text static,
date bigint,
value double,
variance int,
PRIMARY KEY(sensor_id, date)
);

INSERT INTO sensors(sensor_id,sensor_type) VALUES(1, 'TEMPERATURE');
INSERT INTO sensors(sensor_id,date,value,variance) VALUES(1, 20160401, 24.46, 
2);
INSERT INTO sensors(sensor_id,date,value,variance) VALUES(1, 20160402, 25.62, 
5);
INSERT INTO sensors(sensor_id,date,value,variance) VALUES(1, 20160403, 24.96, 
4); 

INSERT INTO sensors(sensor_id,sensor_type) VALUES(2, 'PRESSURE');
INSERT INTO sensors(sensor_id,date,value,variance) VALUES(2, 20160401, 1.03, 9);
INSERT INTO sensors(sensor_id,date,value,variance) VALUES(2, 20160402, 1.04, 7);
INSERT INTO sensors(sensor_id,date,value,variance) VALUES(2, 20160403, 1.01, 4);


CREATE CUSTOM INDEX ON test.sensors (sensor_type) USING 
'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS =  {'mode': 'PREFIX', 
'analyzer_class': 
'org.apache.cassandra.index.sasi.analyzer.NonTokenizingAnalyzer', 
'case_sensitive': 'false'};

CREATE CUSTOM INDEX ON test.sensors (variance) USING 
'org.apache.cassandra.index.sasi.SASIIndex';
CREATE CUSTOM INDEX ON test.sensors (value) USING 
'org.apache.cassandra.index.sasi.SASIIndex';
{noformat}

*Tests*:

{noformat}
//All data
SELECT * FROM sensors ;

 sensor_id | date | sensor_type | value | variance
---+--+-+---+--
 1 | 20160401 | TEMPERATURE | 24.46 |2
 1 | 20160402 | TEMPERATURE | 25.62 |5
 1 | 20160403 | TEMPERATURE | 24.96 |4
 2 | 20160401 |PRESSURE |  1.03 |9
 2 | 20160402 |PRESSURE |  1.04 |7
 2 | 20160403 |PRESSURE |  1.01 |4

// Static column only with prefix
SELECT * FROM sensors WHERE sensor_type LIKE 'temp%';

 sensor_id | date | sensor_type | value | variance
---+--+-+---+--
 1 | 20160401 | TEMPERATURE | 24.46 |2
 1 | 20160402 | TEMPERATURE | 25.62 |5
 1 | 20160403 | TEMPERATURE | 24.96 |4

// EQ on static column combined with non static columns
SELECT * FROM sensors WHERE sensor_type='pressure' AND value >= 1.02 AND value 
<= 1.05 AND variance = 7 ALLOW FILTERING;

 sensor_id | date | sensor_type | value | variance
---+--+-+---+--
     2 | 20160402 |PRESSURE |  1.04 |7

// Non static columns only
SELECT * FROM sensors WHERE  value >= 1.02  AND variance <= 7 ALLOW FILTERING;

 sensor_id | date | sensor_type | value | variance
---+--+-+---+--
 1 | 20160401 | TEMPERATURE | 24.46 |    2
 1 | 20160402 | TEMPERATURE | 25.62 |5
 1 | 20160403 | TEMPERATURE | 24.96 |    4
 2 | 20160402 |PRESSURE |  1.04 |7
{noformat}

> Enable SASI index for static columns
> 
>
> Key: CASSANDRA-11183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11183
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: DOAN DuyHai
>Assignee: DOAN DuyHai
>Priority: Minor
> Attachments: patch_SASI_for_Static.txt
>
>
> This is a follow up ticket for post Cassandra 3.4 SASI integration.
> Since [CASSANDRA-8103] it is possible to index static columns, which is 
> *extremely useful* for some scenarios (find all sensors whose characteristics 
> are saved in static columns)
> /cc [~xedin] [~rustyrazorblade] [~jkrupan]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-11183) Enable SASI index for static columns

[DOAN DuyHai (JIRA)]

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

DOAN DuyHai edited comment on CASSANDRA-11183 at 4/2/16 11:18 AM:
--

Attached is the patch for this new feature. I also added a test in 
{{SASIIndexTest}} to ensure that conditions on static columns are working in 
combination with non static columns ...

/cc [~xedin] [~beobal] for review


was (Author: doanduyhai):
Attached is the patch for this new feature. I also added a test in 
{{SASIIndexTest}} to ensure that conditions on static columns are working in 
combination with non static columns ...

> Enable SASI index for static columns
> 
>
> Key: CASSANDRA-11183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11183
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: DOAN DuyHai
>Assignee: DOAN DuyHai
>Priority: Minor
> Attachments: patch_SASI_for_Static.txt
>
>
> This is a follow up ticket for post Cassandra 3.4 SASI integration.
> Since [CASSANDRA-8103] it is possible to index static columns, which is 
> *extremely useful* for some scenarios (find all sensors whose characteristics 
> are saved in static columns)
> /cc [~xedin] [~rustyrazorblade] [~jkrupan]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11183) Enable SASI index for static columns

[DOAN DuyHai (JIRA)]

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

DOAN DuyHai updated CASSANDRA-11183:

Attachment: patch_SASI_for_Static.txt

Attached is the patch for this new feature. I also added a test in 
{{SASIIndexTest}} to ensure that conditions on static columns are working in 
combination with non static columns ...

> Enable SASI index for static columns
> 
>
> Key: CASSANDRA-11183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11183
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: DOAN DuyHai
>Assignee: DOAN DuyHai
>Priority: Minor
> Attachments: patch_SASI_for_Static.txt
>
>
> This is a follow up ticket for post Cassandra 3.4 SASI integration.
> Since [CASSANDRA-8103] it is possible to index static columns, which is 
> *extremely useful* for some scenarios (find all sensors whose characteristics 
> are saved in static columns)
> /cc [~xedin] [~rustyrazorblade] [~jkrupan]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-11443) Prevent (or warn) changing clustering order with ALTER TABLE when data already exists

[Erick Ramirez (JIRA)]

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

Erick Ramirez edited comment on CASSANDRA-11443 at 4/2/16 8:16 AM:
---

[~slebresne] it appears you are right. I just cannot reproduce this either in 
2.0 or 2.1. I am not sure how our customers are running into this problem.

It is happening during compaction similar to what has been reported in 
CASSANDRA-9623. I thought I understood the sequence to get to this situation 
but now I'm at a loss as to how to explain how these AEs get thrown.

I guess we can just close this as "Cannot Reproduce" if it is not possible to 
get into this situation in 2.1+.


was (Author: flightc):
[~slebresne] it appear you are right. I just cannot reproduce this either in 
2.0 or 2.1. I am not sure how our customers are running into this problem.

It is happening during compaction similar to what has been reported in 
CASSANDRA-9623. I thought I understood the sequence to get to this situation 
but now I'm at a loss as to how to explain how these AEs get thrown.

I guess we can just close this as "Cannot Reproduce" if it is not possible to 
get into this situation in 2.1+.

> Prevent (or warn) changing clustering order with ALTER TABLE when data 
> already exists
> -
>
> Key: CASSANDRA-11443
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11443
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction, CQL
>Reporter: Erick Ramirez
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> Inexperienced DBAs get caught out on certain schema changes thinking that 
> Cassandra will automatically retrofit/convert the existing data on disk.
> We should prevent users from changing the clustering order on existing tables 
> or they will run into compaction/read issues such as (example from Cassandra 
> 2.0.14):
> {noformat}
> ERROR [CompactionExecutor:6488] 2015-07-14 19:33:14,247 CassandraDaemon.java 
> (line 258) Exception in thread Thread[CompactionExecutor:6488,1,main] 
> java.lang.AssertionError: Added column does not sort as the last column 
> at 
> org.apache.cassandra.db.ArrayBackedSortedColumns.addColumn(ArrayBackedSortedColumns.java:116)
>  
> at org.apache.cassandra.db.ColumnFamily.addColumn(ColumnFamily.java:121) 
> at org.apache.cassandra.db.ColumnFamily.addAtom(ColumnFamily.java:155) 
> at 
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:186)
>  
> at 
> org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:98)
>  
> at 
> org.apache.cassandra.db.compaction.PrecompactedRow.(PrecompactedRow.java:85)
>  
> at 
> org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:196)
>  
> at 
> org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:74)
>  
> at 
> org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:55)
>  
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:115)
>  
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:98)
>  
> at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>  
> at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) 
> at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:164)
>  
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60)
>  
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>  
> at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:198)
>  
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> At the very least, we should report a warning advising users about possible 
> problems when changing the clustering order if the table is not empty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-11443) Prevent (or warn) changing clustering order with ALTER TABLE when data already exists

[Erick Ramirez (JIRA)]

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

Erick Ramirez edited comment on CASSANDRA-11443 at 4/2/16 8:17 AM:
---

[~slebresne] it appears you are right. I just cannot reproduce this either in 
2.0 or 2.1. I am not sure how our customers are running into this problem.

It is happening during compaction similar to what has been reported in 
CASSANDRA-9623. I thought I understood the sequence to get to this situation 
but now I'm at a loss as to how these AEs get thrown.

I guess we can just close this as "Cannot Reproduce" if it is not possible to 
get into this situation in 2.1+.


was (Author: flightc):
[~slebresne] it appears you are right. I just cannot reproduce this either in 
2.0 or 2.1. I am not sure how our customers are running into this problem.

It is happening during compaction similar to what has been reported in 
CASSANDRA-9623. I thought I understood the sequence to get to this situation 
but now I'm at a loss as to how to explain how these AEs get thrown.

I guess we can just close this as "Cannot Reproduce" if it is not possible to 
get into this situation in 2.1+.

> Prevent (or warn) changing clustering order with ALTER TABLE when data 
> already exists
> -
>
> Key: CASSANDRA-11443
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11443
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction, CQL
>Reporter: Erick Ramirez
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> Inexperienced DBAs get caught out on certain schema changes thinking that 
> Cassandra will automatically retrofit/convert the existing data on disk.
> We should prevent users from changing the clustering order on existing tables 
> or they will run into compaction/read issues such as (example from Cassandra 
> 2.0.14):
> {noformat}
> ERROR [CompactionExecutor:6488] 2015-07-14 19:33:14,247 CassandraDaemon.java 
> (line 258) Exception in thread Thread[CompactionExecutor:6488,1,main] 
> java.lang.AssertionError: Added column does not sort as the last column 
> at 
> org.apache.cassandra.db.ArrayBackedSortedColumns.addColumn(ArrayBackedSortedColumns.java:116)
>  
> at org.apache.cassandra.db.ColumnFamily.addColumn(ColumnFamily.java:121) 
> at org.apache.cassandra.db.ColumnFamily.addAtom(ColumnFamily.java:155) 
> at 
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:186)
>  
> at 
> org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:98)
>  
> at 
> org.apache.cassandra.db.compaction.PrecompactedRow.(PrecompactedRow.java:85)
>  
> at 
> org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:196)
>  
> at 
> org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:74)
>  
> at 
> org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:55)
>  
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:115)
>  
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:98)
>  
> at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>  
> at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) 
> at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:164)
>  
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60)
>  
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>  
> at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:198)
>  
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> At the very least, we should report a warning advising users about possible 
> problems when changing the clustering order if the table is not empty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11443) Prevent (or warn) changing clustering order with ALTER TABLE when data already exists

[Erick Ramirez (JIRA)]

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

Erick Ramirez commented on CASSANDRA-11443:
---

[~slebresne] it appear you are right. I just cannot reproduce this either in 
2.0 or 2.1. I am not sure how our customers are running into this problem.

It is happening during compaction similar to what has been reported in 
CASSANDRA-9623. I thought I understood the sequence to get to this situation 
but now I'm at a loss as to how to explain how these AEs get thrown.

I guess we can just close this as "Cannot Reproduce" if it is not possible to 
get into this situation in 2.1+.

> Prevent (or warn) changing clustering order with ALTER TABLE when data 
> already exists
> -
>
> Key: CASSANDRA-11443
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11443
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction, CQL
>Reporter: Erick Ramirez
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> Inexperienced DBAs get caught out on certain schema changes thinking that 
> Cassandra will automatically retrofit/convert the existing data on disk.
> We should prevent users from changing the clustering order on existing tables 
> or they will run into compaction/read issues such as (example from Cassandra 
> 2.0.14):
> {noformat}
> ERROR [CompactionExecutor:6488] 2015-07-14 19:33:14,247 CassandraDaemon.java 
> (line 258) Exception in thread Thread[CompactionExecutor:6488,1,main] 
> java.lang.AssertionError: Added column does not sort as the last column 
> at 
> org.apache.cassandra.db.ArrayBackedSortedColumns.addColumn(ArrayBackedSortedColumns.java:116)
>  
> at org.apache.cassandra.db.ColumnFamily.addColumn(ColumnFamily.java:121) 
> at org.apache.cassandra.db.ColumnFamily.addAtom(ColumnFamily.java:155) 
> at 
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:186)
>  
> at 
> org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:98)
>  
> at 
> org.apache.cassandra.db.compaction.PrecompactedRow.(PrecompactedRow.java:85)
>  
> at 
> org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:196)
>  
> at 
> org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:74)
>  
> at 
> org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:55)
>  
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:115)
>  
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:98)
>  
> at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>  
> at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) 
> at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:164)
>  
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60)
>  
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>  
> at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:198)
>  
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> At the very least, we should report a warning advising users about possible 
> problems when changing the clustering order if the table is not empty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11443) Prevent (or warn) changing clustering order with ALTER TABLE when data already exists

[Erick Ramirez (JIRA)]

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

Erick Ramirez commented on CASSANDRA-11443:
---

I am just a little overloaded at the moment but I will write up a test for 
this. I believe it's a simple case of:
- create a table with a clustering column
- insert data and flush to disk
- alter the table to change the clustering order
- insert data and flush to disk
- force compaction

> Prevent (or warn) changing clustering order with ALTER TABLE when data 
> already exists
> -
>
> Key: CASSANDRA-11443
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11443
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction, CQL
>Reporter: Erick Ramirez
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> Inexperienced DBAs get caught out on certain schema changes thinking that 
> Cassandra will automatically retrofit/convert the existing data on disk.
> We should prevent users from changing the clustering order on existing tables 
> or they will run into compaction/read issues such as (example from Cassandra 
> 2.0.14):
> {noformat}
> ERROR [CompactionExecutor:6488] 2015-07-14 19:33:14,247 CassandraDaemon.java 
> (line 258) Exception in thread Thread[CompactionExecutor:6488,1,main] 
> java.lang.AssertionError: Added column does not sort as the last column 
> at 
> org.apache.cassandra.db.ArrayBackedSortedColumns.addColumn(ArrayBackedSortedColumns.java:116)
>  
> at org.apache.cassandra.db.ColumnFamily.addColumn(ColumnFamily.java:121) 
> at org.apache.cassandra.db.ColumnFamily.addAtom(ColumnFamily.java:155) 
> at 
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:186)
>  
> at 
> org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:98)
>  
> at 
> org.apache.cassandra.db.compaction.PrecompactedRow.(PrecompactedRow.java:85)
>  
> at 
> org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:196)
>  
> at 
> org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:74)
>  
> at 
> org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:55)
>  
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:115)
>  
> at 
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:98)
>  
> at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>  
> at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) 
> at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:164)
>  
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60)
>  
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>  
> at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:198)
>  
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> At the very least, we should report a warning advising users about possible 
> problems when changing the clustering order if the table is not empty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)