[jira] [Comment Edited] (CASSANDRA-13601) Changes requested to the cassandra's debian + rpm installers packages

[Amitkumar Ghatwal (JIRA)]

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

Amitkumar Ghatwal edited comment on CASSANDRA-13601 at 6/16/17 5:58 AM:


[~mshuler]- Firstly appreciate for updating ticket details. Could you please 
comment on the below as well.

1) Only good explanation can think of is that by increasing stack size to 
"-Xss512k". it  helps to run Cassandra on 'ppc64le' architecture.
Can we introduce the change in "jvm.options/other places" as suggested -  
{noformat}
case `uname -m` in .
{noformat}
..

2)  Also since we now have a CI job already running for ppc64le - thanks to 
jeff ( 
https://builds.apache.org/view/A-D/view/Cassandra/job/cassandra-devbranch-ppc64le-testall/
 ) .Would like to propose adding ppc64le to -  
"src/java/org/apache/cassandra/utils/Architecture.java" .Ideally 
Architecture.java should include ppc64le as one of the platforms supporting 
unaligned memory access. Adding patch here.




was (Author: amitkumar_ghatwal):
[~mshuler]- Firstly appreciate for updating ticket details. Could you please 
comment on the below as well.

1) Only good explanation can think of is that by increasing stack size to 
-Xss512k- it  helps to run Cassandra on 'ppc64le' architecture.
Can we introduce the change in "jvm.options/other places" as suggested -  
{noformat}
case `uname -m` in .
{noformat}
..

2)  Also since we now have a CI job already running for ppc64le - thanks to 
jeff ( 
https://builds.apache.org/view/A-D/view/Cassandra/job/cassandra-devbranch-ppc64le-testall/
 ) .Would like to propose adding ppc64le to -  
"src/java/org/apache/cassandra/utils/Architecture.java" .Ideally 
Architecture.java should include ppc64le as one of the platforms supporting 
unaligned memory access. Adding patch here.



> Changes requested to the cassandra's debian + rpm installers packages
> -
>
> Key: CASSANDRA-13601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13601
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
> Environment: ~$ lscpu
> Architecture:  ppc64le
> Byte Order:Little Endian
>Reporter: Amitkumar Ghatwal
>Priority: Minor
>  Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: ppc64le_unaligned_memory_access.patch
>
>
> Hi All,
> Thanks [~mshuler] for helping in installing cassandra using arch independent 
> installers  for debian + rpm packages from here : 
> http://cassandra.apache.org/download/
> For my architecture - " ppc64le" , the installation process from debian + rpm 
> wasn't straightforward. And needed below configuration level changes.
> For Ubuntu- Cassandra 3.10 release - below changes were needed
> 1) echo "deb [arch=amd64] http://www.apache.org/dist/cassandra/debian 310x 
> main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list 
> 2) sed -i -e s/Xss256/Xss512/g /etc/cassandra/jvm.options
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> For RHEL - Cassandra 3.0.13 release - below changes were needed
> 1) sed -i -e s/Xss256/Xss512/g /etc/cassandra/default.conf/cassandra-env.sh
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> Could you please help in introducing above changes so that cassandra can be 
> installed from the debian + rpm pcakages and will indeed become architecture 
> independent.
> Regards,
> Amit



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13601) Changes requested to the cassandra's debian + rpm installers packages

[Amitkumar Ghatwal (JIRA)]

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

Amitkumar Ghatwal updated CASSANDRA-13601:
--
Attachment: ppc64le_unaligned_memory_access.patch

> Changes requested to the cassandra's debian + rpm installers packages
> -
>
> Key: CASSANDRA-13601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13601
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
> Environment: ~$ lscpu
> Architecture:  ppc64le
> Byte Order:Little Endian
>Reporter: Amitkumar Ghatwal
>Priority: Minor
>  Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: ppc64le_unaligned_memory_access.patch
>
>
> Hi All,
> Thanks [~mshuler] for helping in installing cassandra using arch independent 
> installers  for debian + rpm packages from here : 
> http://cassandra.apache.org/download/
> For my architecture - " ppc64le" , the installation process from debian + rpm 
> wasn't straightforward. And needed below configuration level changes.
> For Ubuntu- Cassandra 3.10 release - below changes were needed
> 1) echo "deb [arch=amd64] http://www.apache.org/dist/cassandra/debian 310x 
> main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list 
> 2) sed -i -e s/Xss256/Xss512/g /etc/cassandra/jvm.options
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> For RHEL - Cassandra 3.0.13 release - below changes were needed
> 1) sed -i -e s/Xss256/Xss512/g /etc/cassandra/default.conf/cassandra-env.sh
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> Could you please help in introducing above changes so that cassandra can be 
> installed from the debian + rpm pcakages and will indeed become architecture 
> independent.
> Regards,
> Amit



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13601) Changes requested to the cassandra's debian + rpm installers packages

[Amitkumar Ghatwal (JIRA)]

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

Amitkumar Ghatwal commented on CASSANDRA-13601:
---

[~mshuler]- Firstly appreciate for updating ticket details. Could you please 
comment on the below as well.

1) Only good explanation can think of is that by increasing stack size to 
-Xss512k- it  helps to run Cassandra on 'ppc64le' architecture.
Can we introduce the change in "jvm.options/other places" as suggested -  
{noformat}
case `uname -m` in .
{noformat}
..

2)  Also since we now have a CI job already running for ppc64le - thanks to 
jeff ( 
https://builds.apache.org/view/A-D/view/Cassandra/job/cassandra-devbranch-ppc64le-testall/
 ) .Would like to propose adding ppc64le to -  
"src/java/org/apache/cassandra/utils/Architecture.java" .Ideally 
Architecture.java should include ppc64le as one of the platforms supporting 
unaligned memory access. Adding patch here.



> Changes requested to the cassandra's debian + rpm installers packages
> -
>
> Key: CASSANDRA-13601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13601
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
> Environment: ~$ lscpu
> Architecture:  ppc64le
> Byte Order:Little Endian
>Reporter: Amitkumar Ghatwal
>Priority: Minor
>  Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Hi All,
> Thanks [~mshuler] for helping in installing cassandra using arch independent 
> installers  for debian + rpm packages from here : 
> http://cassandra.apache.org/download/
> For my architecture - " ppc64le" , the installation process from debian + rpm 
> wasn't straightforward. And needed below configuration level changes.
> For Ubuntu- Cassandra 3.10 release - below changes were needed
> 1) echo "deb [arch=amd64] http://www.apache.org/dist/cassandra/debian 310x 
> main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list 
> 2) sed -i -e s/Xss256/Xss512/g /etc/cassandra/jvm.options
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> For RHEL - Cassandra 3.0.13 release - below changes were needed
> 1) sed -i -e s/Xss256/Xss512/g /etc/cassandra/default.conf/cassandra-env.sh
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> Could you please help in introducing above changes so that cassandra can be 
> installed from the debian + rpm pcakages and will indeed become architecture 
> independent.
> Regards,
> Amit



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13528) nodetool describeclusters shows different snitch info as to what is configured.

[Lerh Chuan Low (JIRA)]

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

Lerh Chuan Low commented on CASSANDRA-13528:


Hell. My bad, I didn't know that existed. I'll look into it, if that already 
exists then definitely we should use it. Thanks for your suggestion. 

> nodetool describeclusters shows different snitch info as to what is 
> configured.
> ---
>
> Key: CASSANDRA-13528
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13528
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Paul Villacorta
>Assignee: Lerh Chuan Low
>Priority: Minor
>  Labels: lhf
> Attachments: 13528-2.1.txt, 13528-trunk.txt, Screen Shot 2017-05-12 
> at 14.15.04.png
>
>
> I couldn't find any similar issue as this one so I'm creating one.
> I noticed that doing nodetool describecluster shows a different Snitch 
> Information as to what is being set in the configuration file.
> My setup is hosted in AWS and I am using Ec2Snitch.
> cassandra@cassandra3$ nodetool describecluster
> Cluster Information:
>   Name: testv3
>   Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
>   Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
>   Schema versions:
>   fc6e8656-ee7a-341b-9782-b569d1fd1a51: 
> [10.0.3.61,10.0.3.62,10.0.3.63]
> I checked via MX4J and it shows the same, I haven't verified tho using a 
> different Snitch and I am using 2.2.6 above and 3.0.X 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (CASSANDRA-13613) Import cassandra-dtest project into it's own repository

[Nate McCall (JIRA)]

Nate McCall created CASSANDRA-13613:
---

 Summary: Import cassandra-dtest project into it's own repository 
 Key: CASSANDRA-13613
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13613
 Project: Cassandra
  Issue Type: Bug
  Components: Testing
Reporter: Nate McCall


Given the completion of CASSANDRA-13584, we can now import {{cassandra-dtest}} 
into ASF infrastructure. This is a top level issue for tracking the bits and 
pieces of this task. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (CASSANDRA-13528) nodetool describeclusters shows different snitch info as to what is configured.

[Jay Zhuang (JIRA)]

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

Jay Zhuang edited comment on CASSANDRA-13528 at 6/16/17 12:27 AM:
--

Not sure if changing the behave of the existing JMX interface is a good idea. I 
would suggest to use 
{{[DynamicEndpointSnitchMBean.getSubsnitchClassName()|https://github.com/apache/cassandra/blob/8b3a60b9a7dbefeecc06bace617279612ec7092d/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java#L362]}},
 which will give you the same information.


was (Author: jay.zhuang):
Not sure if changing the behave of the existing JMX interface is a good idea. I 
would suggest to use {{DynamicEndpointSnitchMBean.getSubsnitchClassName()}}, 
which will give you the same information.

> nodetool describeclusters shows different snitch info as to what is 
> configured.
> ---
>
> Key: CASSANDRA-13528
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13528
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Paul Villacorta
>Assignee: Lerh Chuan Low
>Priority: Minor
>  Labels: lhf
> Attachments: 13528-2.1.txt, 13528-trunk.txt, Screen Shot 2017-05-12 
> at 14.15.04.png
>
>
> I couldn't find any similar issue as this one so I'm creating one.
> I noticed that doing nodetool describecluster shows a different Snitch 
> Information as to what is being set in the configuration file.
> My setup is hosted in AWS and I am using Ec2Snitch.
> cassandra@cassandra3$ nodetool describecluster
> Cluster Information:
>   Name: testv3
>   Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
>   Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
>   Schema versions:
>   fc6e8656-ee7a-341b-9782-b569d1fd1a51: 
> [10.0.3.61,10.0.3.62,10.0.3.63]
> I checked via MX4J and it shows the same, I haven't verified tho using a 
> different Snitch and I am using 2.2.6 above and 3.0.X 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13528) nodetool describeclusters shows different snitch info as to what is configured.

[Jay Zhuang (JIRA)]

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

Jay Zhuang commented on CASSANDRA-13528:


Not sure if changing the behave of the existing JMX interface is a good idea. I 
would suggest to use {{DynamicEndpointSnitchMBean.getSubsnitchClassName()}}, 
which will give you the same information.

> nodetool describeclusters shows different snitch info as to what is 
> configured.
> ---
>
> Key: CASSANDRA-13528
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13528
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Paul Villacorta
>Assignee: Lerh Chuan Low
>Priority: Minor
>  Labels: lhf
> Attachments: 13528-2.1.txt, 13528-trunk.txt, Screen Shot 2017-05-12 
> at 14.15.04.png
>
>
> I couldn't find any similar issue as this one so I'm creating one.
> I noticed that doing nodetool describecluster shows a different Snitch 
> Information as to what is being set in the configuration file.
> My setup is hosted in AWS and I am using Ec2Snitch.
> cassandra@cassandra3$ nodetool describecluster
> Cluster Information:
>   Name: testv3
>   Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
>   Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
>   Schema versions:
>   fc6e8656-ee7a-341b-9782-b569d1fd1a51: 
> [10.0.3.61,10.0.3.62,10.0.3.63]
> I checked via MX4J and it shows the same, I haven't verified tho using a 
> different Snitch and I am using 2.2.6 above and 3.0.X 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (CASSANDRA-13612) Hints file 608MB even though max_hints_file_size_in_mb=128

[Tania S Engel (JIRA)]

Tania S Engel created CASSANDRA-13612:
-

 Summary: Hints file 608MB even though max_hints_file_size_in_mb=128
 Key: CASSANDRA-13612
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13612
 Project: Cassandra
  Issue Type: Bug
  Components: Configuration
 Environment: Cassandra 3.10 following a JOIN on replica node 
Reporter: Tania S Engel
Priority: Trivial
 Attachments: Cassandra 3.10 bug hint log size.mht

C:\Cassandra\data\hints has a file of size 608MB but my Cassandra.yaml has a 
max_hints_file_size_in_mb=128. I have confirmed in the debug logs that the 
setting is picked up.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-10130) Node failure during 2i update after streaming can have incomplete 2i when restarted

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10130:
-

The current version looks good to me, except for the following minor stylistic 
nits that I found that could be improved during review (feel free to take it or 
disregard):
* [Update queryableIndexes only on markIndexBuilt and 
markIndexRemoved|https://github.com/pauloricardomg/cassandra/commit/74f3eea2d7aa89b644f1ddbc96f9f6d987a27f73]
* [Rename failedIndexes list to 
needsFullRebuild|https://github.com/pauloricardomg/cassandra/commit/07be39d7db7030bb5616344074c1c96d27c90d15]
 (this is mostly because failed index gives the impression the index is not 
queryable, while in reality the index can be queryable but only needs full 
rebuild)
* [Remove unnecessary marking of index in need of full rebuild on index 
creation|https://github.com/pauloricardomg/cassandra/commit/856ec08d24f615399b0d4a4b063fc96259f60be4]
* [Warn user to run full rebuild after index failure and log failure stack 
trace if 
present|https://github.com/pauloricardomg/cassandra/commit/19b6f3c68d1b00895de2d3da5aec54102b44ce9f]

Great job guys! :)

> Node failure during 2i update after streaming can have incomplete 2i when 
> restarted
> ---
>
> Key: CASSANDRA-10130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10130
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Yuki Morishita
>Assignee: Andrés de la Peña
>Priority: Minor
>
> Since MV/2i update happens after SSTables are received, node failure during 
> MV/2i update can leave received SSTables live when restarted while MV/2i are 
> partially up to date.
> We can add some kind of tracking mechanism to automatically rebuild at the 
> startup, or at least warn user when the node restarts.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (CASSANDRA-13004) Corruption while adding/removing a column to/from the table

[Alex Petrov (JIRA)]

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

Alex Petrov edited comment on CASSANDRA-13004 at 6/15/17 11:33 PM:
---

Unfortunately, my commit on 3.11 broke serveral tests (which did not show up on 
my branch, and is not always failing locally). 

It all is an result of static initialisation. When {{current_version}} was a 
constant, it was getting initialised just fine, but loading a boolean from 
system property introduced a race. 

Once again, this is not a runtime issue, this is only an issue with tests.

|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...ifesdjeen:13004-followup-3.11]|[testall|https://cassci.datastax.com/job/ifesdjeen-13004-3.11-followup-testall/]|

UPDATE: More information (and isolated repro) 
[here|https://github.com/ifesdjeen/static-initialisers]: accessing a {{static 
final}} field (as it was previously) did not trigger all static initialisers. 
Bytecode inspection showed that having the code execution ({{getProperty}} and 
ternary operator)  has moved the initialiser to {{static}} block, kind of like 
that: 

{code}
static {
FORCE_3_0_PROTOCOL_VERSION = 
Boolean.getBoolean("cassandra.force_3_0_protocol_version");
current_version = (MessagingService.FORCE_3_0_PROTOCOL_VERSION ? 10 : 
11);
ONE_BYTE = new byte[1];
verbValues = MessagingService.Verb.values();
/// etc...
}
{code}


was (Author: ifesdjeen):
Unfortunately, my commit on 3.11 broke serveral tests (which did not show up on 
my branch, and is not always failing locally). 

It all is an result of static initialisation. When {{current_version}} was a 
constant, it was getting initialised just fine, but loading a boolean from 
system property introduced a race. 

Once again, this is not a runtime issue, this is only an issue with tests.

|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...ifesdjeen:13004-followup-3.11]|[testall|https://cassci.datastax.com/job/ifesdjeen-13004-3.11-followup-testall/]|

UPDATE: More information (and isolated repro) 
[here|https://github.com/ifesdjeen/static-initialisers]: accessing a {{static 
final}} field (as it was previously) did not trigger all static initialisers. 
Bytecode inspection showed that having the code execution ({{getProperty}} and 
ternary operator)  has moved the initialiser to {{static}} block, kind of like 
that: 

{code}
static {
FORCE_3_0_PROTOCOL_VERSION = 
Boolean.getBoolean("cassandra.force_3_0_protocol_version");
current_version = (MessagingService.FORCE_3_0_PROTOCOL_VERSION ? 10 : 
11);
ONE_BYTE = new byte[1];
verbValues = MessagingService.Verb.values();
verbStages = (EnumMap)new 
MessagingService.MessagingService$1((Class)MessagingService.Verb.class);
verbSerializers = (EnumMap)new 
MessagingService.MessagingService$2((Class)MessagingService.Verb.class);
callbackDeserializers = (EnumMap)new 
MessagingService.MessagingService$3((Class)MessagingService.Verb.class);
logger = LoggerFactory.getLogger((Class)MessagingService.class);
DROPPABLE_VERBS = EnumSet.of(MessagingService.Verb._TRACE, 
MessagingService.Verb.MUTATION, MessagingService.Verb.COUNTER_MUTATION, 
MessagingService.Verb.HINT, MessagingService.Verb.READ_REPAIR, 
MessagingService.Verb.READ, MessagingService.Verb.RANGE_SLICE, 
MessagingService.Verb.PAGED_RANGE, MessagingService.Verb.REQUEST_RESPONSE, 
MessagingService.Verb.BATCH_STORE, MessagingService.Verb.BATCH_REMOVE);
idGen = new AtomicInteger(0);
}
{code}

> Corruption while adding/removing a column to/from the table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Stanislav Vishnevskiy
>Assignee: Alex Petrov
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map>,
> permission_overwrites map>,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {cod

[jira] [Comment Edited] (CASSANDRA-13004) Corruption while adding/removing a column to/from the table

[Alex Petrov (JIRA)]

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

Alex Petrov edited comment on CASSANDRA-13004 at 6/15/17 11:33 PM:
---

Unfortunately, my commit on 3.11 broke serveral tests (which did not show up on 
my branch, and is not always failing locally). 

It all is an result of static initialisation. When {{current_version}} was a 
constant, it was getting initialised just fine, but loading a boolean from 
system property introduced a race. 

Once again, this is not a runtime issue, this is only an issue with tests.

|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...ifesdjeen:13004-followup-3.11]|[testall|https://cassci.datastax.com/job/ifesdjeen-13004-3.11-followup-testall/]|

UPDATE: More information (and isolated repro) 
[here|https://github.com/ifesdjeen/static-initialisers]: accessing a {{static 
final}} field (as it was previously) did not trigger all static initialisers. 
Bytecode inspection showed that having the code execution ({{getProperty}} and 
ternary operator)  has moved the initialiser to {{static}} block, kind of like 
that: 

{code}
static {
FORCE_3_0_PROTOCOL_VERSION = 
Boolean.getBoolean("cassandra.force_3_0_protocol_version");
current_version = (MessagingService.FORCE_3_0_PROTOCOL_VERSION ? 10 : 
11);
ONE_BYTE = new byte[1];
verbValues = MessagingService.Verb.values();
verbStages = (EnumMap)new 
MessagingService.MessagingService$1((Class)MessagingService.Verb.class);
verbSerializers = (EnumMap)new 
MessagingService.MessagingService$2((Class)MessagingService.Verb.class);
callbackDeserializers = (EnumMap)new 
MessagingService.MessagingService$3((Class)MessagingService.Verb.class);
logger = LoggerFactory.getLogger((Class)MessagingService.class);
DROPPABLE_VERBS = EnumSet.of(MessagingService.Verb._TRACE, 
MessagingService.Verb.MUTATION, MessagingService.Verb.COUNTER_MUTATION, 
MessagingService.Verb.HINT, MessagingService.Verb.READ_REPAIR, 
MessagingService.Verb.READ, MessagingService.Verb.RANGE_SLICE, 
MessagingService.Verb.PAGED_RANGE, MessagingService.Verb.REQUEST_RESPONSE, 
MessagingService.Verb.BATCH_STORE, MessagingService.Verb.BATCH_REMOVE);
idGen = new AtomicInteger(0);
}
{code}


was (Author: ifesdjeen):
Unfortunately, my commit on 3.11 broke serveral tests (which did not show up on 
my branch, and is not always failing locally). 

It all is an result of static initialisation. When {{current_version}} was a 
constant, it was getting initialised just fine, but loading a boolean from 
system property introduced a race. 

Once again, this is not a runtime issue, this is only an issue with tests.

|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...ifesdjeen:13004-followup-3.11]|[testall|https://cassci.datastax.com/job/ifesdjeen-13004-3.11-followup-testall/]|

> Corruption while adding/removing a column to/from the table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Stanislav Vishnevskiy
>Assignee: Alex Petrov
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map>,
> permission_overwrites map>,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {code:none}
> ALTER TABLE discord_channels.channels ADD application_id bigint;
> {code}
> And one row (that we can tell) got corrupted at the same time and could no 
> longer be read from the Python driver. 
> {code:none}
> [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. 
> ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: 
> '\x84\x00\x00\x1b\x08\x00\x00\x03w\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x0f\x00\x10discord_channels\x00\x08channels\x00\x02id\x00\x02\x00\x0eapplication_id\x00\x02\x00\x07bitrate\x00\t\x00\x08guild_id\x00\x02\x00\ticon_hash\x00\r\x00\x0flast_message_id\x00\x02\x00\x12last_pin_timestamp\x00\x0b\x00\x04name\x00\r\

[jira] [Updated] (CASSANDRA-13172) compaction_large_partition_warning_threshold_mb not working properly when set to high value

[Kurt Greaves (JIRA)]

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

Kurt Greaves updated CASSANDRA-13172:
-
Description: 
compaction_large_partition_warning_threshold_mb has been set either by mistake 
or as an attempt to disable warnings completely to high value 512000
However system started to produce warning no matter what the partition size is:

 Compacting large partition 
system/compactions_in_progress:e631fe20-e488-11e6-bcd7-bf6151c7fa28 (32 bytes)

When looking into the code:
{code}
 public static int getCompactionLargePartitionWarningThreshold() { return 
conf.compaction_large_partition_warning_threshold_mb * 1024 * 1024; }
{code}
which is called in 
{code}
private void maybeLogLargePartitionWarning(DecoratedKey key, long rowSize)
{
if (rowSize > 
DatabaseDescriptor.getCompactionLargePartitionWarningThreshold())
{
String keyString = 
metadata().partitionKeyType.getString(key.getKey());
logger.warn("Writing large partition {}/{}:{} ({}) to sstable {}", 
metadata.keyspace, metadata.name, keyString, 
FBUtilities.prettyPrintMemory(rowSize), getFilename());
}
}
{code}
it looks like 512000 is multiplied by 1M and returned as int so being out of 
range... Maybe it would be better to use long  as it is used for rowSize




  was:
compaction_large_partition_warning_threshold_mb has been set either by mistake 
or as an attempt to disable warnings completely to high value 512000
However system started to produce warning no matter what the partition size is:

 Compacting large partition 
system/compactions_in_progress:e631fe20-e488-11e6-bcd7-bf6151c7fa28 (32 bytes)

When looking into the code:

 public static int getCompactionLargePartitionWarningThreshold() { return 
conf.compaction_large_partition_warning_threshold_mb * 1024 * 1024; }

which is called in 

private void maybeLogLargePartitionWarning(DecoratedKey key, long rowSize)
{
if (rowSize > 
DatabaseDescriptor.getCompactionLargePartitionWarningThreshold())
{
String keyString = 
metadata().partitionKeyType.getString(key.getKey());
logger.warn("Writing large partition {}/{}:{} ({}) to sstable {}", 
metadata.keyspace, metadata.name, keyString, 
FBUtilities.prettyPrintMemory(rowSize), getFilename());
}
}

it looks like 512000 is multiplied by 1M and returned as int so being out of 
range... Maybe it would be better to use long  as it is used for rowSize





> compaction_large_partition_warning_threshold_mb not working properly when set 
> to high value
> ---
>
> Key: CASSANDRA-13172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13172
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Vladimir Vavro
>Assignee: Kurt Greaves
>Priority: Minor
> Attachments: 13172.patch
>
>
> compaction_large_partition_warning_threshold_mb has been set either by 
> mistake or as an attempt to disable warnings completely to high value 512000
> However system started to produce warning no matter what the partition size 
> is:
>  Compacting large partition 
> system/compactions_in_progress:e631fe20-e488-11e6-bcd7-bf6151c7fa28 (32 bytes)
> When looking into the code:
> {code}
>  public static int getCompactionLargePartitionWarningThreshold() { return 
> conf.compaction_large_partition_warning_threshold_mb * 1024 * 1024; }
> {code}
> which is called in 
> {code}
> private void maybeLogLargePartitionWarning(DecoratedKey key, long rowSize)
> {
> if (rowSize > 
> DatabaseDescriptor.getCompactionLargePartitionWarningThreshold())
> {
> String keyString = 
> metadata().partitionKeyType.getString(key.getKey());
> logger.warn("Writing large partition {}/{}:{} ({}) to sstable 
> {}", metadata.keyspace, metadata.name, keyString, 
> FBUtilities.prettyPrintMemory(rowSize), getFilename());
> }
> }
> {code}
> it looks like 512000 is multiplied by 1M and returned as int so being out of 
> range... Maybe it would be better to use long  as it is used for rowSize



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13172) compaction_large_partition_warning_threshold_mb not working properly when set to high value

[Kurt Greaves (JIRA)]

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

Kurt Greaves updated CASSANDRA-13172:
-
Attachment: 13172.patch

> compaction_large_partition_warning_threshold_mb not working properly when set 
> to high value
> ---
>
> Key: CASSANDRA-13172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13172
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Vladimir Vavro
>Assignee: Kurt Greaves
>Priority: Minor
> Attachments: 13172.patch
>
>
> compaction_large_partition_warning_threshold_mb has been set either by 
> mistake or as an attempt to disable warnings completely to high value 512000
> However system started to produce warning no matter what the partition size 
> is:
>  Compacting large partition 
> system/compactions_in_progress:e631fe20-e488-11e6-bcd7-bf6151c7fa28 (32 bytes)
> When looking into the code:
>  public static int getCompactionLargePartitionWarningThreshold() { return 
> conf.compaction_large_partition_warning_threshold_mb * 1024 * 1024; }
> which is called in 
> private void maybeLogLargePartitionWarning(DecoratedKey key, long rowSize)
> {
> if (rowSize > 
> DatabaseDescriptor.getCompactionLargePartitionWarningThreshold())
> {
> String keyString = 
> metadata().partitionKeyType.getString(key.getKey());
> logger.warn("Writing large partition {}/{}:{} ({}) to sstable 
> {}", metadata.keyspace, metadata.name, keyString, 
> FBUtilities.prettyPrintMemory(rowSize), getFilename());
> }
> }
> it looks like 512000 is multiplied by 1M and returned as int so being out of 
> range... Maybe it would be better to use long  as it is used for rowSize



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (CASSANDRA-13172) compaction_large_partition_warning_threshold_mb not working properly when set to high value

[Kurt Greaves (JIRA)]

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

Kurt Greaves edited comment on CASSANDRA-13172 at 6/15/17 11:05 PM:


Should be fine to just make the calculation as a long and return it. 
{{DatabaseDescriptor.getCompactionLargePartitionWarningThreshold()}} only gets 
called in one place where it won't matter if given a long.

On that note this isn't the first time I've seen this issue, and it seems there 
are a few other config properties that will suffer from the same problem. Not 
that it's ever a good idea to set these settings that high, however I have 
found use for some in the past, and I suspect others would too. Regardless, in 
my opinion if we are going to let users tune these things we should make them 
work as expected.

Patch is attached (against 3.0, but should be the same in all branches I 
believe)


was (Author: kurtg):
Should be fine to just make the calculation as a long and return it. 
{{DatabaseDescriptor.getCompactionLargePartitionWarningThreshold()}} only gets 
called in one place where it won't matter if given a long.

On that note this isn't the first time I've seen this issue, and it seems there 
are a few other config properties that will suffer from the same problem. Not 
that it's ever a good idea to set these settings that high, however I have 
found use for some in the past, and I suspect others would too. Regardless, in 
my opinion if we are going to let users tune these things we should make them 
work as expected.

> compaction_large_partition_warning_threshold_mb not working properly when set 
> to high value
> ---
>
> Key: CASSANDRA-13172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13172
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Vladimir Vavro
>Assignee: Kurt Greaves
>Priority: Minor
> Attachments: 13172.patch
>
>
> compaction_large_partition_warning_threshold_mb has been set either by 
> mistake or as an attempt to disable warnings completely to high value 512000
> However system started to produce warning no matter what the partition size 
> is:
>  Compacting large partition 
> system/compactions_in_progress:e631fe20-e488-11e6-bcd7-bf6151c7fa28 (32 bytes)
> When looking into the code:
>  public static int getCompactionLargePartitionWarningThreshold() { return 
> conf.compaction_large_partition_warning_threshold_mb * 1024 * 1024; }
> which is called in 
> private void maybeLogLargePartitionWarning(DecoratedKey key, long rowSize)
> {
> if (rowSize > 
> DatabaseDescriptor.getCompactionLargePartitionWarningThreshold())
> {
> String keyString = 
> metadata().partitionKeyType.getString(key.getKey());
> logger.warn("Writing large partition {}/{}:{} ({}) to sstable 
> {}", metadata.keyspace, metadata.name, keyString, 
> FBUtilities.prettyPrintMemory(rowSize), getFilename());
> }
> }
> it looks like 512000 is multiplied by 1M and returned as int so being out of 
> range... Maybe it would be better to use long  as it is used for rowSize



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13172) compaction_large_partition_warning_threshold_mb not working properly when set to high value

[Kurt Greaves (JIRA)]

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

Kurt Greaves updated CASSANDRA-13172:
-
 Assignee: Kurt Greaves
Reproduced In: 3.0.13, 2.2.9, 2.1.15  (was: 2.1.15)
   Status: Patch Available  (was: Open)

Should be fine to just make the calculation as a long and return it. 
{{DatabaseDescriptor.getCompactionLargePartitionWarningThreshold()}} only gets 
called in one place where it won't matter if given a long.

On that note this isn't the first time I've seen this issue, and it seems there 
are a few other config properties that will suffer from the same problem. Not 
that it's ever a good idea to set these settings that high, however I have 
found use for some in the past, and I suspect others would too. Regardless, in 
my opinion if we are going to let users tune these things we should make them 
work as expected.

> compaction_large_partition_warning_threshold_mb not working properly when set 
> to high value
> ---
>
> Key: CASSANDRA-13172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13172
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Vladimir Vavro
>Assignee: Kurt Greaves
>Priority: Minor
>
> compaction_large_partition_warning_threshold_mb has been set either by 
> mistake or as an attempt to disable warnings completely to high value 512000
> However system started to produce warning no matter what the partition size 
> is:
>  Compacting large partition 
> system/compactions_in_progress:e631fe20-e488-11e6-bcd7-bf6151c7fa28 (32 bytes)
> When looking into the code:
>  public static int getCompactionLargePartitionWarningThreshold() { return 
> conf.compaction_large_partition_warning_threshold_mb * 1024 * 1024; }
> which is called in 
> private void maybeLogLargePartitionWarning(DecoratedKey key, long rowSize)
> {
> if (rowSize > 
> DatabaseDescriptor.getCompactionLargePartitionWarningThreshold())
> {
> String keyString = 
> metadata().partitionKeyType.getString(key.getKey());
> logger.warn("Writing large partition {}/{}:{} ({}) to sstable 
> {}", metadata.keyspace, metadata.name, keyString, 
> FBUtilities.prettyPrintMemory(rowSize), getFilename());
> }
> }
> it looks like 512000 is multiplied by 1M and returned as int so being out of 
> range... Maybe it would be better to use long  as it is used for rowSize



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (CASSANDRA-13004) Corruption while adding/removing a column to/from the table

[Alex Petrov (JIRA)]

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

Alex Petrov edited comment on CASSANDRA-13004 at 6/15/17 9:38 PM:
--

Unfortunately, my commit on 3.11 broke serveral tests (which did not show up on 
my branch, and is not always failing locally). 

It all is an result of static initialisation. When {{current_version}} was a 
constant, it was getting initialised just fine, but loading a boolean from 
system property introduced a race. 

Once again, this is not a runtime issue, this is only an issue with tests.

|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...ifesdjeen:13004-followup-3.11]|[testall|https://cassci.datastax.com/job/ifesdjeen-13004-3.11-followup-testall/]|


was (Author: ifesdjeen):
Unfortunately, my commit on 3.11 broke serveral tests. 

It all is an result of static initialisation. When {{current_version}} was a 
constant, it was getting initialised just fine, but loading a boolean from 
system property introduced a race. 

Once again, this is not a runtime issue, this is only an issue with tests.

|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...ifesdjeen:13004-followup-3.11]|[testall|https://cassci.datastax.com/job/ifesdjeen-13004-3.11-followup-testall/]|

> Corruption while adding/removing a column to/from the table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Stanislav Vishnevskiy
>Assignee: Alex Petrov
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map>,
> permission_overwrites map>,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {code:none}
> ALTER TABLE discord_channels.channels ADD application_id bigint;
> {code}
> And one row (that we can tell) got corrupted at the same time and could no 
> longer be read from the Python driver. 
> {code:none}
> [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. 
> ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: 
> '\x84\x00\x00\x1b\x08\x00\x00\x03w\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x0f\x00\x10discord_channels\x00\x08channels\x00\x02id\x00\x02\x00\x0eapplication_id\x00\x02\x00\x07bitrate\x00\t\x00\x08guild_id\x00\x02\x00\ticon_hash\x00\r\x00\x0flast_message_id\x00\x02\x00\x12last_pin_timestamp\x00\x0b\x00\x04name\x00\r\x00\x08owner_id\x00\x02\x00\x15permission_overwrites\x00!\x00\x02\x000\x00\x10discord_channels\x00\x1cchannel_permission_overwrite\x00\x04\x00\x02id\x00\x02\x00\x04type\x00\t\x00\x06allow_\x00\t\x00\x04deny\x00\t\x00\x08position\x00\t\x00\nrecipients\x00!\x00\x02\x000\x00\x10discord_channels\x00\x11channel_recipient\x00\x01\x00\x04nick\x00\r\x00\x05topic\x00\r\x00\x04type\x00\x14\x00\nuser_limit\x00\t\x00\x00\x00\x01\x00\x00\x00\x08\x03\x8a\x19\x8e\xf8\x82\x00\x01\xff\xff\xff\xff\x00\x00\x00\x04\x00\x00\xfa\x00\x00\x00\x00\x08\x00\x00\xfa\x00\x00\xf8G\xc5\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8b\xc0\xb5nB\x00\x02\x00\x00\x00\x08G\xc5\xffI\x98\xc4\xb4(\x00\x00\x00\x03\x8b\xc0\xa8\xff\xff\xff\xff\x00\x00\x01<\x00\x00\x00\x06\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x040\x07\xf8Q\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x07\xf8Q\x00\x00\x00\x04\x10\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x05\xe8A\x00\x00\x00\x04\x10\x02\x00\x00\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00\x04\

[jira] [Comment Edited] (CASSANDRA-13004) Corruption while adding/removing a column to/from the table

[Alex Petrov (JIRA)]

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

Alex Petrov edited comment on CASSANDRA-13004 at 6/15/17 9:36 PM:
--

Unfortunately, my commit on 3.11 broke serveral tests. 

It all is an result of static initialisation. When {{current_version}} was a 
constant, it was getting initialised just fine, but loading a boolean from 
system property introduced a race. 

Once again, this is not a runtime issue, this is only an issue with tests.

|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...ifesdjeen:13004-followup-3.11]|[testall|https://cassci.datastax.com/job/ifesdjeen-13004-3.11-followup-testall/]|


was (Author: ifesdjeen):
Unfortunately, my commit on 3.11 broke serveral tests. 

It all is an result of static initialisation. When {{current_version}} was a 
constant, it was getting initialised just fine, but loading a boolean from 
system property requires a complete static initialisation now. 

Once again, this is not a runtime issue, this is only an issue with tests.

|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...ifesdjeen:13004-followup-3.11]|[testall|https://cassci.datastax.com/job/ifesdjeen-13004-3.11-followup-testall/]|

> Corruption while adding/removing a column to/from the table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Stanislav Vishnevskiy
>Assignee: Alex Petrov
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map>,
> permission_overwrites map>,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {code:none}
> ALTER TABLE discord_channels.channels ADD application_id bigint;
> {code}
> And one row (that we can tell) got corrupted at the same time and could no 
> longer be read from the Python driver. 
> {code:none}
> [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. 
> ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: 
> '\x84\x00\x00\x1b\x08\x00\x00\x03w\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x0f\x00\x10discord_channels\x00\x08channels\x00\x02id\x00\x02\x00\x0eapplication_id\x00\x02\x00\x07bitrate\x00\t\x00\x08guild_id\x00\x02\x00\ticon_hash\x00\r\x00\x0flast_message_id\x00\x02\x00\x12last_pin_timestamp\x00\x0b\x00\x04name\x00\r\x00\x08owner_id\x00\x02\x00\x15permission_overwrites\x00!\x00\x02\x000\x00\x10discord_channels\x00\x1cchannel_permission_overwrite\x00\x04\x00\x02id\x00\x02\x00\x04type\x00\t\x00\x06allow_\x00\t\x00\x04deny\x00\t\x00\x08position\x00\t\x00\nrecipients\x00!\x00\x02\x000\x00\x10discord_channels\x00\x11channel_recipient\x00\x01\x00\x04nick\x00\r\x00\x05topic\x00\r\x00\x04type\x00\x14\x00\nuser_limit\x00\t\x00\x00\x00\x01\x00\x00\x00\x08\x03\x8a\x19\x8e\xf8\x82\x00\x01\xff\xff\xff\xff\x00\x00\x00\x04\x00\x00\xfa\x00\x00\x00\x00\x08\x00\x00\xfa\x00\x00\xf8G\xc5\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8b\xc0\xb5nB\x00\x02\x00\x00\x00\x08G\xc5\xffI\x98\xc4\xb4(\x00\x00\x00\x03\x8b\xc0\xa8\xff\xff\xff\xff\x00\x00\x01<\x00\x00\x00\x06\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x040\x07\xf8Q\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x07\xf8Q\x00\x00\x00\x04\x10\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x05\xe8A\x00\x00\x00\x04\x10\x02\x00\x00\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x08\x

[jira] [Comment Edited] (CASSANDRA-13004) Corruption while adding/removing a column to/from the table

[Alex Petrov (JIRA)]

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

Alex Petrov edited comment on CASSANDRA-13004 at 6/15/17 9:36 PM:
--

Unfortunately, my commit on 3.11 broke a bunch of tests. 

It all is an result of static initialisation. When {{current_version}} was a 
constant, it was getting initialised just fine, but loading a boolean from 
system property requires a complete static initialisation now. 

Once again, this is not a runtime issue, this is only an issue with tests.

|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...ifesdjeen:13004-followup-3.11]|[testall|https://cassci.datastax.com/job/ifesdjeen-13004-3.11-followup-testall/]|


was (Author: ifesdjeen):
Unfortunately, my commit on 3.11 broke a bunch of tests. 

It all is an result of static initialisation. When {{current_version}} was a 
constant, it was getting initialised just fine, but loading a boolean from 
system property requires a complete static initialisation now. 

Once again, this is not a runtime issue, this is only an issue with tests.

> Corruption while adding/removing a column to/from the table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Stanislav Vishnevskiy
>Assignee: Alex Petrov
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map>,
> permission_overwrites map>,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {code:none}
> ALTER TABLE discord_channels.channels ADD application_id bigint;
> {code}
> And one row (that we can tell) got corrupted at the same time and could no 
> longer be read from the Python driver. 
> {code:none}
> [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. 
> ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: 
> '\x84\x00\x00\x1b\x08\x00\x00\x03w\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x0f\x00\x10discord_channels\x00\x08channels\x00\x02id\x00\x02\x00\x0eapplication_id\x00\x02\x00\x07bitrate\x00\t\x00\x08guild_id\x00\x02\x00\ticon_hash\x00\r\x00\x0flast_message_id\x00\x02\x00\x12last_pin_timestamp\x00\x0b\x00\x04name\x00\r\x00\x08owner_id\x00\x02\x00\x15permission_overwrites\x00!\x00\x02\x000\x00\x10discord_channels\x00\x1cchannel_permission_overwrite\x00\x04\x00\x02id\x00\x02\x00\x04type\x00\t\x00\x06allow_\x00\t\x00\x04deny\x00\t\x00\x08position\x00\t\x00\nrecipients\x00!\x00\x02\x000\x00\x10discord_channels\x00\x11channel_recipient\x00\x01\x00\x04nick\x00\r\x00\x05topic\x00\r\x00\x04type\x00\x14\x00\nuser_limit\x00\t\x00\x00\x00\x01\x00\x00\x00\x08\x03\x8a\x19\x8e\xf8\x82\x00\x01\xff\xff\xff\xff\x00\x00\x00\x04\x00\x00\xfa\x00\x00\x00\x00\x08\x00\x00\xfa\x00\x00\xf8G\xc5\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8b\xc0\xb5nB\x00\x02\x00\x00\x00\x08G\xc5\xffI\x98\xc4\xb4(\x00\x00\x00\x03\x8b\xc0\xa8\xff\xff\xff\xff\x00\x00\x01<\x00\x00\x00\x06\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x040\x07\xf8Q\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x07\xf8Q\x00\x00\x00\x04\x10\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x05\xe8A\x00\x00\x00\x04\x10\x02\x00\x00\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00\x04\

[jira] [Comment Edited] (CASSANDRA-13004) Corruption while adding/removing a column to/from the table

[Alex Petrov (JIRA)]

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

Alex Petrov edited comment on CASSANDRA-13004 at 6/15/17 9:36 PM:
--

Unfortunately, my commit on 3.11 broke serveral tests. 

It all is an result of static initialisation. When {{current_version}} was a 
constant, it was getting initialised just fine, but loading a boolean from 
system property requires a complete static initialisation now. 

Once again, this is not a runtime issue, this is only an issue with tests.

|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...ifesdjeen:13004-followup-3.11]|[testall|https://cassci.datastax.com/job/ifesdjeen-13004-3.11-followup-testall/]|


was (Author: ifesdjeen):
Unfortunately, my commit on 3.11 broke a bunch of tests. 

It all is an result of static initialisation. When {{current_version}} was a 
constant, it was getting initialised just fine, but loading a boolean from 
system property requires a complete static initialisation now. 

Once again, this is not a runtime issue, this is only an issue with tests.

|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...ifesdjeen:13004-followup-3.11]|[testall|https://cassci.datastax.com/job/ifesdjeen-13004-3.11-followup-testall/]|

> Corruption while adding/removing a column to/from the table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Stanislav Vishnevskiy
>Assignee: Alex Petrov
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map>,
> permission_overwrites map>,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {code:none}
> ALTER TABLE discord_channels.channels ADD application_id bigint;
> {code}
> And one row (that we can tell) got corrupted at the same time and could no 
> longer be read from the Python driver. 
> {code:none}
> [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. 
> ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: 
> '\x84\x00\x00\x1b\x08\x00\x00\x03w\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x0f\x00\x10discord_channels\x00\x08channels\x00\x02id\x00\x02\x00\x0eapplication_id\x00\x02\x00\x07bitrate\x00\t\x00\x08guild_id\x00\x02\x00\ticon_hash\x00\r\x00\x0flast_message_id\x00\x02\x00\x12last_pin_timestamp\x00\x0b\x00\x04name\x00\r\x00\x08owner_id\x00\x02\x00\x15permission_overwrites\x00!\x00\x02\x000\x00\x10discord_channels\x00\x1cchannel_permission_overwrite\x00\x04\x00\x02id\x00\x02\x00\x04type\x00\t\x00\x06allow_\x00\t\x00\x04deny\x00\t\x00\x08position\x00\t\x00\nrecipients\x00!\x00\x02\x000\x00\x10discord_channels\x00\x11channel_recipient\x00\x01\x00\x04nick\x00\r\x00\x05topic\x00\r\x00\x04type\x00\x14\x00\nuser_limit\x00\t\x00\x00\x00\x01\x00\x00\x00\x08\x03\x8a\x19\x8e\xf8\x82\x00\x01\xff\xff\xff\xff\x00\x00\x00\x04\x00\x00\xfa\x00\x00\x00\x00\x08\x00\x00\xfa\x00\x00\xf8G\xc5\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8b\xc0\xb5nB\x00\x02\x00\x00\x00\x08G\xc5\xffI\x98\xc4\xb4(\x00\x00\x00\x03\x8b\xc0\xa8\xff\xff\xff\xff\x00\x00\x01<\x00\x00\x00\x06\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x040\x07\xf8Q\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x07\xf8Q\x00\x00\x00\x04\x10\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x05\xe8A\x00\x00\x00\x04\x10\x02\x00\x00\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00\x04\x00\x00\x00\x00

[jira] [Commented] (CASSANDRA-13004) Corruption while adding/removing a column to/from the table

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-13004:
-

Another (minor problem was with a trunk patch, that was decoding not checking 
backward compatibility properly:

|[trunk|https://github.com/apache/cassandra/compare/trunk...ifesdjeen:13004-trunk-followup]|[testall|https://cassci.datastax.com/job/ifesdjeen-13004-trunk-followup-testall/]|

> Corruption while adding/removing a column to/from the table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Stanislav Vishnevskiy
>Assignee: Alex Petrov
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map>,
> permission_overwrites map>,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {code:none}
> ALTER TABLE discord_channels.channels ADD application_id bigint;
> {code}
> And one row (that we can tell) got corrupted at the same time and could no 
> longer be read from the Python driver. 
> {code:none}
> [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. 
> ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: 
> '\x84\x00\x00\x1b\x08\x00\x00\x03w\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x0f\x00\x10discord_channels\x00\x08channels\x00\x02id\x00\x02\x00\x0eapplication_id\x00\x02\x00\x07bitrate\x00\t\x00\x08guild_id\x00\x02\x00\ticon_hash\x00\r\x00\x0flast_message_id\x00\x02\x00\x12last_pin_timestamp\x00\x0b\x00\x04name\x00\r\x00\x08owner_id\x00\x02\x00\x15permission_overwrites\x00!\x00\x02\x000\x00\x10discord_channels\x00\x1cchannel_permission_overwrite\x00\x04\x00\x02id\x00\x02\x00\x04type\x00\t\x00\x06allow_\x00\t\x00\x04deny\x00\t\x00\x08position\x00\t\x00\nrecipients\x00!\x00\x02\x000\x00\x10discord_channels\x00\x11channel_recipient\x00\x01\x00\x04nick\x00\r\x00\x05topic\x00\r\x00\x04type\x00\x14\x00\nuser_limit\x00\t\x00\x00\x00\x01\x00\x00\x00\x08\x03\x8a\x19\x8e\xf8\x82\x00\x01\xff\xff\xff\xff\x00\x00\x00\x04\x00\x00\xfa\x00\x00\x00\x00\x08\x00\x00\xfa\x00\x00\xf8G\xc5\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8b\xc0\xb5nB\x00\x02\x00\x00\x00\x08G\xc5\xffI\x98\xc4\xb4(\x00\x00\x00\x03\x8b\xc0\xa8\xff\xff\xff\xff\x00\x00\x01<\x00\x00\x00\x06\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x040\x07\xf8Q\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x07\xf8Q\x00\x00\x00\x04\x10\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x05\xe8A\x00\x00\x00\x04\x10\x02\x00\x00\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00
>  
> \x08\x01\x00\x00\x00\x04\xc4\xb4(\x00\xff\xff\xff\xff\x00\x00\x00O[f\x80Q\x07general\x05\xf8G\xc5\xffI\x98\xc4\xb4(\x00\xf8O[f\x80Q\x00\x00\x00\x02\x04\xf8O[f\x80Q\x00\xf8G\xc5\xffI\x98\x01\x00\x00\xf8O[f\x80Q\x00\x00\x00\x00\xf8G\xc5\xffI\x97\xc4\xb4(\x06\x00\xf8O\x7fe\x1fm\x08\x03\x00\x00\x00\x01\x00\x00\x00\x00\x04\x00\x00\x00\x00'
> {code}
> And then in cqlsh when trying to read the row we got this. 
> {code:none}
> /usr/bin/cqlsh.py:632: DateOverFlowWarning: Some timestamps are larger than 
> Python datetime can represent. Timestamps are displayed in milliseconds from 
> epoch.
> Traceback 

[jira] [Comment Edited] (CASSANDRA-13004) Corruption while adding/removing a column to/from the table

[Alex Petrov (JIRA)]

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

Alex Petrov edited comment on CASSANDRA-13004 at 6/15/17 9:33 PM:
--

Another (minor problem) was with a trunk patch, that was decoding not checking 
backward compatibility properly:

|[trunk|https://github.com/apache/cassandra/compare/trunk...ifesdjeen:13004-trunk-followup]|[testall|https://cassci.datastax.com/job/ifesdjeen-13004-trunk-followup-testall/]|


was (Author: ifesdjeen):
Another (minor problem was with a trunk patch, that was decoding not checking 
backward compatibility properly:

|[trunk|https://github.com/apache/cassandra/compare/trunk...ifesdjeen:13004-trunk-followup]|[testall|https://cassci.datastax.com/job/ifesdjeen-13004-trunk-followup-testall/]|

> Corruption while adding/removing a column to/from the table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Stanislav Vishnevskiy
>Assignee: Alex Petrov
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map>,
> permission_overwrites map>,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {code:none}
> ALTER TABLE discord_channels.channels ADD application_id bigint;
> {code}
> And one row (that we can tell) got corrupted at the same time and could no 
> longer be read from the Python driver. 
> {code:none}
> [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. 
> ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: 
> '\x84\x00\x00\x1b\x08\x00\x00\x03w\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x0f\x00\x10discord_channels\x00\x08channels\x00\x02id\x00\x02\x00\x0eapplication_id\x00\x02\x00\x07bitrate\x00\t\x00\x08guild_id\x00\x02\x00\ticon_hash\x00\r\x00\x0flast_message_id\x00\x02\x00\x12last_pin_timestamp\x00\x0b\x00\x04name\x00\r\x00\x08owner_id\x00\x02\x00\x15permission_overwrites\x00!\x00\x02\x000\x00\x10discord_channels\x00\x1cchannel_permission_overwrite\x00\x04\x00\x02id\x00\x02\x00\x04type\x00\t\x00\x06allow_\x00\t\x00\x04deny\x00\t\x00\x08position\x00\t\x00\nrecipients\x00!\x00\x02\x000\x00\x10discord_channels\x00\x11channel_recipient\x00\x01\x00\x04nick\x00\r\x00\x05topic\x00\r\x00\x04type\x00\x14\x00\nuser_limit\x00\t\x00\x00\x00\x01\x00\x00\x00\x08\x03\x8a\x19\x8e\xf8\x82\x00\x01\xff\xff\xff\xff\x00\x00\x00\x04\x00\x00\xfa\x00\x00\x00\x00\x08\x00\x00\xfa\x00\x00\xf8G\xc5\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8b\xc0\xb5nB\x00\x02\x00\x00\x00\x08G\xc5\xffI\x98\xc4\xb4(\x00\x00\x00\x03\x8b\xc0\xa8\xff\xff\xff\xff\x00\x00\x01<\x00\x00\x00\x06\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x040\x07\xf8Q\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x07\xf8Q\x00\x00\x00\x04\x10\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x05\xe8A\x00\x00\x00\x04\x10\x02\x00\x00\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00
>  
> \x08\x01\x00\x00\x00\x04\xc4\xb4(\x00\xff\xff\xff\xff\x00\x00\x00O[f\x80Q\x07general\x05\xf8G\xc5\xffI\x98\xc4\xb4(\x00\xf8O[f\x80Q\x00\x00\x00\x02\x04\xf8O[f\x80Q\x00\xf8G\xc5\xffI\x98\x01\x00\x00\xf8O[f\x80Q\x00\x00\x00\x00\xf8G\xc5\xf

[jira] [Comment Edited] (CASSANDRA-13601) Changes requested to the cassandra's debian + rpm installers packages

[Michael Shuler (JIRA)]

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

Michael Shuler edited comment on CASSANDRA-13601 at 6/15/17 9:24 PM:
-

Do we have a good explanation of why {{-Xss512k}} is needed for ppc64le? This 
is not something we would change the default for, I don't think, so 
understanding the need for this change would help. There are quite a few places 
that we may need to {{case `uname -m` in ...}} and set when appropriate.


was (Author: mshuler):
Do we have a good explanation of why {{-Xss256k}} is needed for ppc64le? This 
is not something we would change the default for, I don't think, so 
understanding the need for this change would help. There are quite a few places 
that we may need to {{case `uname -m` in ...}} and set when appropriate.

> Changes requested to the cassandra's debian + rpm installers packages
> -
>
> Key: CASSANDRA-13601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13601
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
> Environment: ~$ lscpu
> Architecture:  ppc64le
> Byte Order:Little Endian
>Reporter: Amitkumar Ghatwal
>Priority: Minor
>  Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Hi All,
> Thanks [~mshuler] for helping in installing cassandra using arch independent 
> installers  for debian + rpm packages from here : 
> http://cassandra.apache.org/download/
> For my architecture - " ppc64le" , the installation process from debian + rpm 
> wasn't straightforward. And needed below configuration level changes.
> For Ubuntu- Cassandra 3.10 release - below changes were needed
> 1) echo "deb [arch=amd64] http://www.apache.org/dist/cassandra/debian 310x 
> main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list 
> 2) sed -i -e s/Xss256/Xss512/g /etc/cassandra/jvm.options
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> For RHEL - Cassandra 3.0.13 release - below changes were needed
> 1) sed -i -e s/Xss256/Xss512/g /etc/cassandra/default.conf/cassandra-env.sh
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> Could you please help in introducing above changes so that cassandra can be 
> installed from the debian + rpm pcakages and will indeed become architecture 
> independent.
> Regards,
> Amit



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13601) Changes requested to the cassandra's debian + rpm installers packages

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-13601:


(update all the ticket meta - this is not critical, since there are workarounds 
and configurations that work as-is; fix versions are set to specific values 
when committed)

> Changes requested to the cassandra's debian + rpm installers packages
> -
>
> Key: CASSANDRA-13601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13601
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
> Environment: ~$ lscpu
> Architecture:  ppc64le
> Byte Order:Little Endian
>Reporter: Amitkumar Ghatwal
>Priority: Minor
>  Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Hi All,
> Thanks [~mshuler] for helping in installing cassandra using arch independent 
> installers  for debian + rpm packages from here : 
> http://cassandra.apache.org/download/
> For my architecture - " ppc64le" , the installation process from debian + rpm 
> wasn't straightforward. And needed below configuration level changes.
> For Ubuntu- Cassandra 3.10 release - below changes were needed
> 1) echo "deb [arch=amd64] http://www.apache.org/dist/cassandra/debian 310x 
> main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list 
> 2) sed -i -e s/Xss256/Xss512/g /etc/cassandra/jvm.options
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> For RHEL - Cassandra 3.0.13 release - below changes were needed
> 1) sed -i -e s/Xss256/Xss512/g /etc/cassandra/default.conf/cassandra-env.sh
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> Could you please help in introducing above changes so that cassandra can be 
> installed from the debian + rpm pcakages and will indeed become architecture 
> independent.
> Regards,
> Amit



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13601) Changes requested to the cassandra's debian + rpm installers packages

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-13601:
---
Labels: lhf  (was: easyfix)

> Changes requested to the cassandra's debian + rpm installers packages
> -
>
> Key: CASSANDRA-13601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13601
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
> Environment: ~$ lscpu
> Architecture:  ppc64le
> Byte Order:Little Endian
>Reporter: Amitkumar Ghatwal
>Priority: Critical
>  Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Hi All,
> Thanks [~mshuler] for helping in installing cassandra using arch independent 
> installers  for debian + rpm packages from here : 
> http://cassandra.apache.org/download/
> For my architecture - " ppc64le" , the installation process from debian + rpm 
> wasn't straightforward. And needed below configuration level changes.
> For Ubuntu- Cassandra 3.10 release - below changes were needed
> 1) echo "deb [arch=amd64] http://www.apache.org/dist/cassandra/debian 310x 
> main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list 
> 2) sed -i -e s/Xss256/Xss512/g /etc/cassandra/jvm.options
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> For RHEL - Cassandra 3.0.13 release - below changes were needed
> 1) sed -i -e s/Xss256/Xss512/g /etc/cassandra/default.conf/cassandra-env.sh
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> Could you please help in introducing above changes so that cassandra can be 
> installed from the debian + rpm pcakages and will indeed become architecture 
> independent.
> Regards,
> Amit



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13601) Changes requested to the cassandra's debian + rpm installers packages

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-13601:
---
Fix Version/s: (was: 3.0.14)
   (was: 3.11.0)
   (was: 4.0)
   4.x
   3.11.x
   3.0.x

> Changes requested to the cassandra's debian + rpm installers packages
> -
>
> Key: CASSANDRA-13601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13601
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
> Environment: ~$ lscpu
> Architecture:  ppc64le
> Byte Order:Little Endian
>Reporter: Amitkumar Ghatwal
>Priority: Critical
>  Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Hi All,
> Thanks [~mshuler] for helping in installing cassandra using arch independent 
> installers  for debian + rpm packages from here : 
> http://cassandra.apache.org/download/
> For my architecture - " ppc64le" , the installation process from debian + rpm 
> wasn't straightforward. And needed below configuration level changes.
> For Ubuntu- Cassandra 3.10 release - below changes were needed
> 1) echo "deb [arch=amd64] http://www.apache.org/dist/cassandra/debian 310x 
> main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list 
> 2) sed -i -e s/Xss256/Xss512/g /etc/cassandra/jvm.options
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> For RHEL - Cassandra 3.0.13 release - below changes were needed
> 1) sed -i -e s/Xss256/Xss512/g /etc/cassandra/default.conf/cassandra-env.sh
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> Could you please help in introducing above changes so that cassandra can be 
> installed from the debian + rpm pcakages and will indeed become architecture 
> independent.
> Regards,
> Amit



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13601) Changes requested to the cassandra's debian + rpm installers packages

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-13601:
---
Priority: Minor  (was: Critical)

> Changes requested to the cassandra's debian + rpm installers packages
> -
>
> Key: CASSANDRA-13601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13601
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
> Environment: ~$ lscpu
> Architecture:  ppc64le
> Byte Order:Little Endian
>Reporter: Amitkumar Ghatwal
>Priority: Minor
>  Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Hi All,
> Thanks [~mshuler] for helping in installing cassandra using arch independent 
> installers  for debian + rpm packages from here : 
> http://cassandra.apache.org/download/
> For my architecture - " ppc64le" , the installation process from debian + rpm 
> wasn't straightforward. And needed below configuration level changes.
> For Ubuntu- Cassandra 3.10 release - below changes were needed
> 1) echo "deb [arch=amd64] http://www.apache.org/dist/cassandra/debian 310x 
> main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list 
> 2) sed -i -e s/Xss256/Xss512/g /etc/cassandra/jvm.options
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> For RHEL - Cassandra 3.0.13 release - below changes were needed
> 1) sed -i -e s/Xss256/Xss512/g /etc/cassandra/default.conf/cassandra-env.sh
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> Could you please help in introducing above changes so that cassandra can be 
> installed from the debian + rpm pcakages and will indeed become architecture 
> independent.
> Regards,
> Amit



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13601) Changes requested to the cassandra's debian + rpm installers packages

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-13601:


Do we have a good explanation of why {{-Xss256k}} is needed for ppc64le? This 
is not something we would change the default for, I don't think, so 
understanding the need for this change would help. There are quite a few places 
that we may need to {{case `uname -m` in ...}} and set when appropriate.

> Changes requested to the cassandra's debian + rpm installers packages
> -
>
> Key: CASSANDRA-13601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13601
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
> Environment: ~$ lscpu
> Architecture:  ppc64le
> Byte Order:Little Endian
>Reporter: Amitkumar Ghatwal
>Priority: Critical
>  Labels: easyfix
> Fix For: 3.0.14, 3.11.0, 4.0
>
>
> Hi All,
> Thanks [~mshuler] for helping in installing cassandra using arch independent 
> installers  for debian + rpm packages from here : 
> http://cassandra.apache.org/download/
> For my architecture - " ppc64le" , the installation process from debian + rpm 
> wasn't straightforward. And needed below configuration level changes.
> For Ubuntu- Cassandra 3.10 release - below changes were needed
> 1) echo "deb [arch=amd64] http://www.apache.org/dist/cassandra/debian 310x 
> main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list 
> 2) sed -i -e s/Xss256/Xss512/g /etc/cassandra/jvm.options
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> For RHEL - Cassandra 3.0.13 release - below changes were needed
> 1) sed -i -e s/Xss256/Xss512/g /etc/cassandra/default.conf/cassandra-env.sh
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> Could you please help in introducing above changes so that cassandra can be 
> installed from the debian + rpm pcakages and will indeed become architecture 
> independent.
> Regards,
> Amit



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (CASSANDRA-13004) Corruption while adding/removing a column to/from the table

[Alex Petrov (JIRA)]

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

Alex Petrov edited comment on CASSANDRA-13004 at 6/15/17 9:06 PM:
--

Unfortunately, my commit on 3.11 broke a bunch of tests. 

It all is an result of static initialisation. When {{current_version}} was a 
constant, it was getting initialised just fine, but loading a boolean from 
system property requires a complete static initialisation now. 

Once again, this is not a runtime issue, this is only an issue with tests.


was (Author: ifesdjeen):
Unfortunately, my commit on 3.11 broke a bunch of tests. 

It all is an result of static initialisation. When {{current_version}} was a 
constant, it was getting initialised just fine, but loading a boolean requires 
a complete static initialisation now. 

Reproduced it locally in a simpler setting, seems to be caused by static map 
initialisers.

Once again, this is not a runtime issue, this is only an issue with tests.

> Corruption while adding/removing a column to/from the table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Stanislav Vishnevskiy
>Assignee: Alex Petrov
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map>,
> permission_overwrites map>,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {code:none}
> ALTER TABLE discord_channels.channels ADD application_id bigint;
> {code}
> And one row (that we can tell) got corrupted at the same time and could no 
> longer be read from the Python driver. 
> {code:none}
> [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. 
> ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: 
> '\x84\x00\x00\x1b\x08\x00\x00\x03w\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x0f\x00\x10discord_channels\x00\x08channels\x00\x02id\x00\x02\x00\x0eapplication_id\x00\x02\x00\x07bitrate\x00\t\x00\x08guild_id\x00\x02\x00\ticon_hash\x00\r\x00\x0flast_message_id\x00\x02\x00\x12last_pin_timestamp\x00\x0b\x00\x04name\x00\r\x00\x08owner_id\x00\x02\x00\x15permission_overwrites\x00!\x00\x02\x000\x00\x10discord_channels\x00\x1cchannel_permission_overwrite\x00\x04\x00\x02id\x00\x02\x00\x04type\x00\t\x00\x06allow_\x00\t\x00\x04deny\x00\t\x00\x08position\x00\t\x00\nrecipients\x00!\x00\x02\x000\x00\x10discord_channels\x00\x11channel_recipient\x00\x01\x00\x04nick\x00\r\x00\x05topic\x00\r\x00\x04type\x00\x14\x00\nuser_limit\x00\t\x00\x00\x00\x01\x00\x00\x00\x08\x03\x8a\x19\x8e\xf8\x82\x00\x01\xff\xff\xff\xff\x00\x00\x00\x04\x00\x00\xfa\x00\x00\x00\x00\x08\x00\x00\xfa\x00\x00\xf8G\xc5\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8b\xc0\xb5nB\x00\x02\x00\x00\x00\x08G\xc5\xffI\x98\xc4\xb4(\x00\x00\x00\x03\x8b\xc0\xa8\xff\xff\xff\xff\x00\x00\x01<\x00\x00\x00\x06\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x040\x07\xf8Q\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x07\xf8Q\x00\x00\x00\x04\x10\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x05\xe8A\x00\x00\x00\x04\x10\x02\x00\x00\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00
>  
> \x08\x01\x00\x00\x00\x04\xc4\xb4(\x0

[jira] [Comment Edited] (CASSANDRA-13004) Corruption while adding/removing a column to/from the table

[Alex Petrov (JIRA)]

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

Alex Petrov edited comment on CASSANDRA-13004 at 6/15/17 8:58 PM:
--

Unfortunately, my commit on 3.11 broke a bunch of tests. 

It all is an result of static initialisation. When {{current_version}} was a 
constant, it was getting initialised just fine, but loading a boolean requires 
a complete static initialisation now. 

Reproduced it locally in a simpler setting, seems to be caused by static map 
initialisers.

Once again, this is not a runtime issue, this is only an issue with tests.


was (Author: ifesdjeen):
Unfortunately, my commit on 3.11 broke a bunch of tests. 

It all is an result of static initialisation. When {{current_version}} was a 
constant, it was getting initialised just fine, but loading a boolean requires 
a complete static initialisation now. 

There are two possible solutions: running 
{{DatabaseDescriptor.daemonInitialization();}} in all the failing tests 
_before_ we try accessing the {{MessagingService#current_version}} or putting a 
{{current_version}} into the separate class which can statically initialise 
without DD dependency, but it results into a lot of changes everywhere: 
[example 
patch|https://github.com/apache/cassandra/compare/trunk...ifesdjeen:13004-followup-3.11#diff-206de6c7f2b0c2963ab8af7312e2a01aR21].
 

Once again, this is not a runtime issue, this is only an issue with tests.

> Corruption while adding/removing a column to/from the table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Stanislav Vishnevskiy
>Assignee: Alex Petrov
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map>,
> permission_overwrites map>,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {code:none}
> ALTER TABLE discord_channels.channels ADD application_id bigint;
> {code}
> And one row (that we can tell) got corrupted at the same time and could no 
> longer be read from the Python driver. 
> {code:none}
> [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. 
> ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: 
> '\x84\x00\x00\x1b\x08\x00\x00\x03w\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x0f\x00\x10discord_channels\x00\x08channels\x00\x02id\x00\x02\x00\x0eapplication_id\x00\x02\x00\x07bitrate\x00\t\x00\x08guild_id\x00\x02\x00\ticon_hash\x00\r\x00\x0flast_message_id\x00\x02\x00\x12last_pin_timestamp\x00\x0b\x00\x04name\x00\r\x00\x08owner_id\x00\x02\x00\x15permission_overwrites\x00!\x00\x02\x000\x00\x10discord_channels\x00\x1cchannel_permission_overwrite\x00\x04\x00\x02id\x00\x02\x00\x04type\x00\t\x00\x06allow_\x00\t\x00\x04deny\x00\t\x00\x08position\x00\t\x00\nrecipients\x00!\x00\x02\x000\x00\x10discord_channels\x00\x11channel_recipient\x00\x01\x00\x04nick\x00\r\x00\x05topic\x00\r\x00\x04type\x00\x14\x00\nuser_limit\x00\t\x00\x00\x00\x01\x00\x00\x00\x08\x03\x8a\x19\x8e\xf8\x82\x00\x01\xff\xff\xff\xff\x00\x00\x00\x04\x00\x00\xfa\x00\x00\x00\x00\x08\x00\x00\xfa\x00\x00\xf8G\xc5\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8b\xc0\xb5nB\x00\x02\x00\x00\x00\x08G\xc5\xffI\x98\xc4\xb4(\x00\x00\x00\x03\x8b\xc0\xa8\xff\xff\xff\xff\x00\x00\x01<\x00\x00\x00\x06\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x040\x07\xf8Q\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x07\xf8Q\x00\x00\x00\x04\x10\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00\x04\x00\x00\x00\x00\x00\x

[jira] [Reopened] (CASSANDRA-13004) Corruption while adding/removing a column to/from the table

[Alex Petrov (JIRA)]

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

Alex Petrov reopened CASSANDRA-13004:
-
Reproduced In: 3.10, 3.0.9  (was: 3.0.9, 3.10)

Unfortunately, my commit on 3.11 broke a bunch of tests. 

It all is an result of static initialisation. When {{current_version}} was a 
constant, it was getting initialised just fine, but loading a boolean requires 
a complete static initialisation now. 

There are two possible solutions: running 
{{DatabaseDescriptor.daemonInitialization();}} in all the failing tests 
_before_ we try accessing the {{MessagingService#current_version}} or putting a 
{{current_version}} into the separate class which can statically initialise 
without DD dependency, but it results into a lot of changes everywhere: 
[example 
patch|https://github.com/apache/cassandra/compare/trunk...ifesdjeen:13004-followup-3.11#diff-206de6c7f2b0c2963ab8af7312e2a01aR21].
 

Once again, this is not a runtime issue, this is only an issue with tests.

> Corruption while adding/removing a column to/from the table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Stanislav Vishnevskiy
>Assignee: Alex Petrov
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map>,
> permission_overwrites map>,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {code:none}
> ALTER TABLE discord_channels.channels ADD application_id bigint;
> {code}
> And one row (that we can tell) got corrupted at the same time and could no 
> longer be read from the Python driver. 
> {code:none}
> [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. 
> ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: 
> '\x84\x00\x00\x1b\x08\x00\x00\x03w\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x0f\x00\x10discord_channels\x00\x08channels\x00\x02id\x00\x02\x00\x0eapplication_id\x00\x02\x00\x07bitrate\x00\t\x00\x08guild_id\x00\x02\x00\ticon_hash\x00\r\x00\x0flast_message_id\x00\x02\x00\x12last_pin_timestamp\x00\x0b\x00\x04name\x00\r\x00\x08owner_id\x00\x02\x00\x15permission_overwrites\x00!\x00\x02\x000\x00\x10discord_channels\x00\x1cchannel_permission_overwrite\x00\x04\x00\x02id\x00\x02\x00\x04type\x00\t\x00\x06allow_\x00\t\x00\x04deny\x00\t\x00\x08position\x00\t\x00\nrecipients\x00!\x00\x02\x000\x00\x10discord_channels\x00\x11channel_recipient\x00\x01\x00\x04nick\x00\r\x00\x05topic\x00\r\x00\x04type\x00\x14\x00\nuser_limit\x00\t\x00\x00\x00\x01\x00\x00\x00\x08\x03\x8a\x19\x8e\xf8\x82\x00\x01\xff\xff\xff\xff\x00\x00\x00\x04\x00\x00\xfa\x00\x00\x00\x00\x08\x00\x00\xfa\x00\x00\xf8G\xc5\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8b\xc0\xb5nB\x00\x02\x00\x00\x00\x08G\xc5\xffI\x98\xc4\xb4(\x00\x00\x00\x03\x8b\xc0\xa8\xff\xff\xff\xff\x00\x00\x01<\x00\x00\x00\x06\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x040\x07\xf8Q\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x07\xf8Q\x00\x00\x00\x04\x10\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x05\xe8A\x00\x00\x00\x04\x10\x02\x00\x00\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00
>  
> \x08\x01\x00\x00\x00\x04\xc4\xb4(\x00\xff\xff\xff\xff\x00\x00\x00O[f\x8

[jira] [Created] (CASSANDRA-13611) Digest mismatch in Quorum read

[Dikang Gu (JIRA)]

Dikang Gu created CASSANDRA-13611:
-

 Summary: Digest mismatch in Quorum read
 Key: CASSANDRA-13611
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13611
 Project: Cassandra
  Issue Type: Improvement
  Components: Coordination
Reporter: Dikang Gu
Assignee: Dikang Gu


In current implementation, when we issue a quorum read, C* will send full data 
request to one replica, and send digest requests to other replicas. If the 
digest mismatch, C* will send another round of full data request to all 
replicas. 

In our environment, we find in P99 case, digest are always mismatch, so we are 
doing 2 round trips of requests in P99, which hurts our P99 latency a lot.

We propose that in quorum read case, we send full data replicas to the quorum 
replicas directly, reconcile them and send back to client. In our experiment , 
it reduced the P99 latency by 20% ~ 30%.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13611) Digest mismatch in Quorum read

[Dikang Gu (JIRA)]

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

Dikang Gu updated CASSANDRA-13611:
--
Fix Version/s: 4.x

> Digest mismatch in Quorum read
> --
>
> Key: CASSANDRA-13611
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13611
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Coordination
>Reporter: Dikang Gu
>Assignee: Dikang Gu
> Fix For: 4.x
>
>
> In current implementation, when we issue a quorum read, C* will send full 
> data request to one replica, and send digest requests to other replicas. If 
> the digest mismatch, C* will send another round of full data request to all 
> replicas. 
> In our environment, we find in P99 case, digest are always mismatch, so we 
> are doing 2 round trips of requests in P99, which hurts our P99 latency a lot.
> We propose that in quorum read case, we send full data replicas to the quorum 
> replicas directly, reconcile them and send back to client. In our experiment 
> , it reduced the P99 latency by 20% ~ 30%.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (CASSANDRA-13610) Add the ability to only scrub one file in Cassandra

[Dikang Gu (JIRA)]

Dikang Gu created CASSANDRA-13610:
-

 Summary: Add the ability to only scrub one file in Cassandra
 Key: CASSANDRA-13610
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13610
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Dikang Gu
Assignee: Dikang Gu
Priority: Minor
 Fix For: 4.x


In our production clusters, we see several corrupted files on C* severs some 
times. And we use `Nodetool scrub` to rebuild the tables.

However, out of the 1000+ sstables, usually, just a few are corrupted (less 
than 10). It will be useful to enhance the `Nodetool scrub` to only scrub 
certain sstable files. So it will be much efficient than rebuilding the whole 
table.

One engineer in my team is working on this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-10130) Node failure during 2i update after streaming can have incomplete 2i when restarted

[JIRA]

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

Andrés de la Peña updated CASSANDRA-10130:
--
Status: Patch Available  (was: Awaiting Feedback)

> Node failure during 2i update after streaming can have incomplete 2i when 
> restarted
> ---
>
> Key: CASSANDRA-10130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10130
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Yuki Morishita
>Assignee: Andrés de la Peña
>Priority: Minor
>
> Since MV/2i update happens after SSTables are received, node failure during 
> MV/2i update can leave received SSTables live when restarted while MV/2i are 
> partially up to date.
> We can add some kind of tracking mechanism to automatically rebuild at the 
> startup, or at least warn user when the node restarts.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[mshuler]

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/5b8ae9f0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5b8ae9f0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5b8ae9f0

Branch: refs/heads/trunk
Commit: 5b8ae9f03943f167932b896c657f25b0d9c3448d
Parents: 1f54aa4 13e153b
Author: Michael Shuler 
Authored: Thu Jun 15 14:06:30 2017 -0500
Committer: Michael Shuler 
Committed: Thu Jun 15 14:06:30 2017 -0500

--
 build.properties.default | 2 +-
 build.xml| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5b8ae9f0/build.xml
--


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

[1/5] cassandra git commit: Switch MAT to fetch jars from repo.maven.apache.org

[mshuler]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 32b60592c -> e0eac5264


Switch MAT to fetch jars from repo.maven.apache.org


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

Branch: refs/heads/trunk
Commit: fdb8c96108f9d8d72bc3a6a56d35e708f371a995
Parents: b0db519
Author: Michael Shuler 
Authored: Thu Jun 15 14:03:06 2017 -0500
Committer: Michael Shuler 
Committed: Thu Jun 15 14:03:06 2017 -0500

--
 build.properties.default | 2 +-
 build.xml| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fdb8c961/build.properties.default
--
diff --git a/build.properties.default b/build.properties.default
index 45d65d9..5291659 100644
--- a/build.properties.default
+++ b/build.properties.default
@@ -1,4 +1,4 @@
 # Maven2 Repository Locations (you can override these in "build.properties" to 
point to a local proxy, e.g. Nexus)
 artifact.remoteRepository.central: http://repo1.maven.org/maven2
-artifact.remoteRepository.apache:  
https://repository.apache.org/content/repositories/releases
+artifact.remoteRepository.apache:  http://repo.maven.apache.org/maven2
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/fdb8c961/build.xml
--
diff --git a/build.xml b/build.xml
index 6d64025..6619bfd 100644
--- a/build.xml
+++ b/build.xml
@@ -251,6 +251,8 @@
 
 
 
+
+
 
 
 


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

[4/5] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[mshuler]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/trunk
Commit: 5ea7f7c6f2f3abf4faf5d91a046239806ee010a4
Parents: 2a0890d 5b8ae9f
Author: Michael Shuler 
Authored: Thu Jun 15 14:06:45 2017 -0500
Committer: Michael Shuler 
Committed: Thu Jun 15 14:06:45 2017 -0500

--
 build.properties.default | 2 +-
 build.xml| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5ea7f7c6/build.xml
--


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

[5/5] cassandra git commit: Merge branch 'cassandra-3.11' into trunk

[mshuler]

Merge branch 'cassandra-3.11' into trunk


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

Branch: refs/heads/trunk
Commit: e0eac52640cd407f3b3595704052a2d2b4f74b48
Parents: 32b6059 5ea7f7c
Author: Michael Shuler 
Authored: Thu Jun 15 14:09:20 2017 -0500
Committer: Michael Shuler 
Committed: Thu Jun 15 14:09:20 2017 -0500

--
 build.properties.default | 2 +-
 build.xml| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e0eac526/build.xml
--


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

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

[mshuler]

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/13e153b0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/13e153b0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/13e153b0

Branch: refs/heads/trunk
Commit: 13e153b090cdebd549d0d1a224c231e9fc1abbe1
Parents: f49579d fdb8c96
Author: Michael Shuler 
Authored: Thu Jun 15 14:06:17 2017 -0500
Committer: Michael Shuler 
Committed: Thu Jun 15 14:06:17 2017 -0500

--
 build.properties.default | 2 +-
 build.xml| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/13e153b0/build.xml
--


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

[07/10] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[mshuler]

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/13e153b0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/13e153b0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/13e153b0

Branch: refs/heads/cassandra-3.11
Commit: 13e153b090cdebd549d0d1a224c231e9fc1abbe1
Parents: f49579d fdb8c96
Author: Michael Shuler 
Authored: Thu Jun 15 14:06:17 2017 -0500
Committer: Michael Shuler 
Committed: Thu Jun 15 14:06:17 2017 -0500

--
 build.properties.default | 2 +-
 build.xml| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/13e153b0/build.xml
--


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

[03/10] cassandra git commit: Switch MAT to fetch jars from repo.maven.apache.org

[mshuler]

Switch MAT to fetch jars from repo.maven.apache.org


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

Branch: refs/heads/cassandra-3.0
Commit: fdb8c96108f9d8d72bc3a6a56d35e708f371a995
Parents: b0db519
Author: Michael Shuler 
Authored: Thu Jun 15 14:03:06 2017 -0500
Committer: Michael Shuler 
Committed: Thu Jun 15 14:03:06 2017 -0500

--
 build.properties.default | 2 +-
 build.xml| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fdb8c961/build.properties.default
--
diff --git a/build.properties.default b/build.properties.default
index 45d65d9..5291659 100644
--- a/build.properties.default
+++ b/build.properties.default
@@ -1,4 +1,4 @@
 # Maven2 Repository Locations (you can override these in "build.properties" to 
point to a local proxy, e.g. Nexus)
 artifact.remoteRepository.central: http://repo1.maven.org/maven2
-artifact.remoteRepository.apache:  
https://repository.apache.org/content/repositories/releases
+artifact.remoteRepository.apache:  http://repo.maven.apache.org/maven2
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/fdb8c961/build.xml
--
diff --git a/build.xml b/build.xml
index 6d64025..6619bfd 100644
--- a/build.xml
+++ b/build.xml
@@ -251,6 +251,8 @@
 
 
 
+
+
 
 
 


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

[09/10] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[mshuler]

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/5b8ae9f0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5b8ae9f0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5b8ae9f0

Branch: refs/heads/cassandra-3.11
Commit: 5b8ae9f03943f167932b896c657f25b0d9c3448d
Parents: 1f54aa4 13e153b
Author: Michael Shuler 
Authored: Thu Jun 15 14:06:30 2017 -0500
Committer: Michael Shuler 
Committed: Thu Jun 15 14:06:30 2017 -0500

--
 build.properties.default | 2 +-
 build.xml| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5b8ae9f0/build.xml
--


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

[10/10] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[mshuler]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/cassandra-3.11
Commit: 5ea7f7c6f2f3abf4faf5d91a046239806ee010a4
Parents: 2a0890d 5b8ae9f
Author: Michael Shuler 
Authored: Thu Jun 15 14:06:45 2017 -0500
Committer: Michael Shuler 
Committed: Thu Jun 15 14:06:45 2017 -0500

--
 build.properties.default | 2 +-
 build.xml| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5ea7f7c6/build.xml
--


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

[08/10] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[mshuler]

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/5b8ae9f0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5b8ae9f0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5b8ae9f0

Branch: refs/heads/cassandra-3.0
Commit: 5b8ae9f03943f167932b896c657f25b0d9c3448d
Parents: 1f54aa4 13e153b
Author: Michael Shuler 
Authored: Thu Jun 15 14:06:30 2017 -0500
Committer: Michael Shuler 
Committed: Thu Jun 15 14:06:30 2017 -0500

--
 build.properties.default | 2 +-
 build.xml| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5b8ae9f0/build.xml
--


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

[06/10] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[mshuler]

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/13e153b0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/13e153b0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/13e153b0

Branch: refs/heads/cassandra-2.2
Commit: 13e153b090cdebd549d0d1a224c231e9fc1abbe1
Parents: f49579d fdb8c96
Author: Michael Shuler 
Authored: Thu Jun 15 14:06:17 2017 -0500
Committer: Michael Shuler 
Committed: Thu Jun 15 14:06:17 2017 -0500

--
 build.properties.default | 2 +-
 build.xml| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/13e153b0/build.xml
--


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

[05/10] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[mshuler]

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/13e153b0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/13e153b0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/13e153b0

Branch: refs/heads/cassandra-3.0
Commit: 13e153b090cdebd549d0d1a224c231e9fc1abbe1
Parents: f49579d fdb8c96
Author: Michael Shuler 
Authored: Thu Jun 15 14:06:17 2017 -0500
Committer: Michael Shuler 
Committed: Thu Jun 15 14:06:17 2017 -0500

--
 build.properties.default | 2 +-
 build.xml| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/13e153b0/build.xml
--


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

[01/10] cassandra git commit: Switch MAT to fetch jars from repo.maven.apache.org

[mshuler]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 b0db519b7 -> fdb8c9610
  refs/heads/cassandra-2.2 f49579df3 -> 13e153b09
  refs/heads/cassandra-3.0 1f54aa424 -> 5b8ae9f03
  refs/heads/cassandra-3.11 2a0890d0f -> 5ea7f7c6f


Switch MAT to fetch jars from repo.maven.apache.org


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

Branch: refs/heads/cassandra-2.1
Commit: fdb8c96108f9d8d72bc3a6a56d35e708f371a995
Parents: b0db519
Author: Michael Shuler 
Authored: Thu Jun 15 14:03:06 2017 -0500
Committer: Michael Shuler 
Committed: Thu Jun 15 14:03:06 2017 -0500

--
 build.properties.default | 2 +-
 build.xml| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fdb8c961/build.properties.default
--
diff --git a/build.properties.default b/build.properties.default
index 45d65d9..5291659 100644
--- a/build.properties.default
+++ b/build.properties.default
@@ -1,4 +1,4 @@
 # Maven2 Repository Locations (you can override these in "build.properties" to 
point to a local proxy, e.g. Nexus)
 artifact.remoteRepository.central: http://repo1.maven.org/maven2
-artifact.remoteRepository.apache:  
https://repository.apache.org/content/repositories/releases
+artifact.remoteRepository.apache:  http://repo.maven.apache.org/maven2
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/fdb8c961/build.xml
--
diff --git a/build.xml b/build.xml
index 6d64025..6619bfd 100644
--- a/build.xml
+++ b/build.xml
@@ -251,6 +251,8 @@
 
 
 
+
+
 
 
 


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

[04/10] cassandra git commit: Switch MAT to fetch jars from repo.maven.apache.org

[mshuler]

Switch MAT to fetch jars from repo.maven.apache.org


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

Branch: refs/heads/cassandra-3.11
Commit: fdb8c96108f9d8d72bc3a6a56d35e708f371a995
Parents: b0db519
Author: Michael Shuler 
Authored: Thu Jun 15 14:03:06 2017 -0500
Committer: Michael Shuler 
Committed: Thu Jun 15 14:03:06 2017 -0500

--
 build.properties.default | 2 +-
 build.xml| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fdb8c961/build.properties.default
--
diff --git a/build.properties.default b/build.properties.default
index 45d65d9..5291659 100644
--- a/build.properties.default
+++ b/build.properties.default
@@ -1,4 +1,4 @@
 # Maven2 Repository Locations (you can override these in "build.properties" to 
point to a local proxy, e.g. Nexus)
 artifact.remoteRepository.central: http://repo1.maven.org/maven2
-artifact.remoteRepository.apache:  
https://repository.apache.org/content/repositories/releases
+artifact.remoteRepository.apache:  http://repo.maven.apache.org/maven2
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/fdb8c961/build.xml
--
diff --git a/build.xml b/build.xml
index 6d64025..6619bfd 100644
--- a/build.xml
+++ b/build.xml
@@ -251,6 +251,8 @@
 
 
 
+
+
 
 
 


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

[02/10] cassandra git commit: Switch MAT to fetch jars from repo.maven.apache.org

[mshuler]

Switch MAT to fetch jars from repo.maven.apache.org


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

Branch: refs/heads/cassandra-2.2
Commit: fdb8c96108f9d8d72bc3a6a56d35e708f371a995
Parents: b0db519
Author: Michael Shuler 
Authored: Thu Jun 15 14:03:06 2017 -0500
Committer: Michael Shuler 
Committed: Thu Jun 15 14:03:06 2017 -0500

--
 build.properties.default | 2 +-
 build.xml| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fdb8c961/build.properties.default
--
diff --git a/build.properties.default b/build.properties.default
index 45d65d9..5291659 100644
--- a/build.properties.default
+++ b/build.properties.default
@@ -1,4 +1,4 @@
 # Maven2 Repository Locations (you can override these in "build.properties" to 
point to a local proxy, e.g. Nexus)
 artifact.remoteRepository.central: http://repo1.maven.org/maven2
-artifact.remoteRepository.apache:  
https://repository.apache.org/content/repositories/releases
+artifact.remoteRepository.apache:  http://repo.maven.apache.org/maven2
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/fdb8c961/build.xml
--
diff --git a/build.xml b/build.xml
index 6d64025..6619bfd 100644
--- a/build.xml
+++ b/build.xml
@@ -251,6 +251,8 @@
 
 
 
+
+
 
 
 


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

cassandra git commit: Ninja: Update README with link to instructions for contributing

[jjirsa]

Repository: cassandra
Updated Branches:
  refs/heads/trunk a07d327be -> 32b60592c


Ninja: Update README with link to instructions for contributing


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

Branch: refs/heads/trunk
Commit: 32b60592c81ff7a1a3c4566a7754d44891f2bdcb
Parents: a07d327
Author: Jeff Jirsa 
Authored: Thu Jun 15 12:01:40 2017 -0700
Committer: Jeff Jirsa 
Committed: Thu Jun 15 12:01:40 2017 -0700

--
 README.asc | 1 +
 1 file changed, 1 insertion(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/32b60592/README.asc
--
diff --git a/README.asc b/README.asc
index 910fb64..910f399 100644
--- a/README.asc
+++ b/README.asc
@@ -88,3 +88,4 @@ Wondering where to go from here?
   * Subscribe to the Users mailing list by sending a mail to
 user-subscr...@cassandra.apache.org
   * Visit the http://cassandra.apache.org/community/[community section] of the 
Cassandra website for more information on getting involved.
+  * Visit the 
http://cassandra.apache.org/doc/latest/development/index.html[development 
section] of the Cassandra website for more information on how to contribute.


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

[jira] [Updated] (CASSANDRA-13004) Corruption while adding/removing a column to/from the table

[Alex Petrov (JIRA)]

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

Alex Petrov updated CASSANDRA-13004:

   Resolution: Fixed
Reproduced In: 3.10, 3.0.9  (was: 3.0.9, 3.10)
   Status: Resolved  (was: Patch Available)

I've incorporated Aleksey's final comments on commit (CHANGES.TXT, 3.11 flag 
and getBoolean). 

Committed in 3.0 with 
[1f54aa424fd8a79089f76951a93560e6bca9d459|https://github.com/apache/cassandra/commit/1f54aa424fd8a79089f76951a93560e6bca9d459],
 merged up to 
[3.11|https://github.com/apache/cassandra/commit/2a0890d0fc5eaaf88d0a2d610a5f500fe943fb92]
 and 
[trunk|https://github.com/apache/cassandra/commit/a07d327be86783137b7ae46a7722ac41cbebdc31].



> Corruption while adding/removing a column to/from the table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Stanislav Vishnevskiy
>Assignee: Alex Petrov
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map>,
> permission_overwrites map>,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {code:none}
> ALTER TABLE discord_channels.channels ADD application_id bigint;
> {code}
> And one row (that we can tell) got corrupted at the same time and could no 
> longer be read from the Python driver. 
> {code:none}
> [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. 
> ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: 
> '\x84\x00\x00\x1b\x08\x00\x00\x03w\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x0f\x00\x10discord_channels\x00\x08channels\x00\x02id\x00\x02\x00\x0eapplication_id\x00\x02\x00\x07bitrate\x00\t\x00\x08guild_id\x00\x02\x00\ticon_hash\x00\r\x00\x0flast_message_id\x00\x02\x00\x12last_pin_timestamp\x00\x0b\x00\x04name\x00\r\x00\x08owner_id\x00\x02\x00\x15permission_overwrites\x00!\x00\x02\x000\x00\x10discord_channels\x00\x1cchannel_permission_overwrite\x00\x04\x00\x02id\x00\x02\x00\x04type\x00\t\x00\x06allow_\x00\t\x00\x04deny\x00\t\x00\x08position\x00\t\x00\nrecipients\x00!\x00\x02\x000\x00\x10discord_channels\x00\x11channel_recipient\x00\x01\x00\x04nick\x00\r\x00\x05topic\x00\r\x00\x04type\x00\x14\x00\nuser_limit\x00\t\x00\x00\x00\x01\x00\x00\x00\x08\x03\x8a\x19\x8e\xf8\x82\x00\x01\xff\xff\xff\xff\x00\x00\x00\x04\x00\x00\xfa\x00\x00\x00\x00\x08\x00\x00\xfa\x00\x00\xf8G\xc5\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8b\xc0\xb5nB\x00\x02\x00\x00\x00\x08G\xc5\xffI\x98\xc4\xb4(\x00\x00\x00\x03\x8b\xc0\xa8\xff\xff\xff\xff\x00\x00\x01<\x00\x00\x00\x06\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x040\x07\xf8Q\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x07\xf8Q\x00\x00\x00\x04\x10\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x05\xe8A\x00\x00\x00\x04\x10\x02\x00\x00\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00
>  
> \x08\x01\x00\x00\x00\x04\xc4\xb4(\x00\xff\xff\xff\xff\x00\x00\x00O[f\x80Q\x07general\x05\xf8G\xc5\xffI\x98\xc4\xb4(\x00\xf8O[f\x80Q\x00\x00\x00\x02\x04\xf8O[f\x80Q\x00\xf8G\xc5\xffI\x98\x01\x00\x00\xf8O[f\x80Q\x00\x00\x00\x00\xf8G\xc5\xffI\x97\xc4\xb4(\x06\x00\xf8O\x7fe\x1fm\x08\x03\x00\x00\x00\x01\x00\x00\x00\x00\x04\x00\x00\x00\x00'
> {code}
> And then in cqls

[6/6] cassandra git commit: Merge branch 'cassandra-3.11' into trunk

[ifesdjeen]

Merge branch 'cassandra-3.11' into trunk


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

Branch: refs/heads/trunk
Commit: a07d327be86783137b7ae46a7722ac41cbebdc31
Parents: f5531e1 2a0890d
Author: Alex Petrov 
Authored: Thu Jun 15 19:36:30 2017 +0200
Committer: Alex Petrov 
Committed: Thu Jun 15 19:36:30 2017 +0200

--
 CHANGES.txt |   1 +
 .../cassandra/db/filter/ColumnFilter.java   | 121 +++
 .../apache/cassandra/net/MessagingService.java  |   3 +-
 .../cassandra/db/filter/ColumnFilterTest.java   |  83 +
 4 files changed, 182 insertions(+), 26 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a07d327b/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a07d327b/src/java/org/apache/cassandra/db/filter/ColumnFilter.java
--
diff --cc src/java/org/apache/cassandra/db/filter/ColumnFilter.java
index b568704,37da86a..dcd93e8
--- a/src/java/org/apache/cassandra/db/filter/ColumnFilter.java
+++ b/src/java/org/apache/cassandra/db/filter/ColumnFilter.java
@@@ -20,8 -20,6 +20,9 @@@ package org.apache.cassandra.db.filter
  import java.io.IOException;
  import java.util.*;
  
++import com.google.common.annotations.VisibleForTesting;
 +import com.google.common.collect.Iterables;
 +import com.google.common.collect.Iterators;
  import com.google.common.collect.SortedSetMultimap;
  import com.google.common.collect.TreeMultimap;
  
@@@ -66,25 -63,23 +67,59 @@@ public class ColumnFilte
  {
  public static final Serializer serializer = new Serializer();
  
 -// True if _fetched_ is all the columns, in which case metadata must not 
be null. If false,
 -// then _fetched_ == _queried_ and we only store _queried_.
 -private final boolean isFetchAll;
 +// True if _fetched_ includes all regular columns (and any static in 
_queried_), in which case metadata must not be
 +// null. If false, then _fetched_ == _queried_ and we only store 
_queried_.
- private final boolean fetchAllRegulars;
- 
- private final TableMetadata metadata; // can be null if !isFetchAll
++public final boolean fetchAllRegulars;
  
 -private final PartitionColumns fetched;
 -private final PartitionColumns queried; // can be null if isFetchAll and 
_fetched_ == _queried_
++private final RegularAndStaticColumns fetched;
 +private final RegularAndStaticColumns queried; // can be null if 
fetchAllRegulars, to represent a wildcard query (all
- // static and regular columns are 
both _fetched_ and _queried_).
++   // static and regular 
columns are both _fetched_ and _queried_).
  private final SortedSetMultimap 
subSelections; // can be null
  
 -private ColumnFilter(boolean isFetchAll,
 - PartitionColumns fetched,
 - PartitionColumns queried,
 +private ColumnFilter(boolean fetchAllRegulars,
 + TableMetadata metadata,
 + RegularAndStaticColumns queried,
   SortedSetMultimap subSelections)
  {
 -assert !isFetchAll || fetched != null;
 -assert isFetchAll || queried != null;
 -this.isFetchAll = isFetchAll;
 -this.fetched = isFetchAll ? fetched : queried;
 +assert !fetchAllRegulars || metadata != null;
 +assert fetchAllRegulars || queried != null;
 +this.fetchAllRegulars = fetchAllRegulars;
- this.metadata = metadata;
++
++if (fetchAllRegulars)
++{
++RegularAndStaticColumns all = metadata.regularAndStaticColumns();
++if (queried == null)
++{
++this.fetched = this.queried = all;
++}
++else
++{
++this.fetched = all.statics.isEmpty()
++   ? all
++   : new RegularAndStaticColumns(queried.statics, 
all.regulars);
++this.queried = queried;
++}
++}
++else
++{
++this.fetched = this.queried = queried;
++}
++
++this.subSelections = subSelections;
++}
++
++/**
++ * Used on replica for deserialisation
++ */
++private ColumnFilter(boolean fetchAllRegulars,
++ RegularAndStaticColumns fetched,
++ RegularAndStaticColumns queried,
++   

[5/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[ifesdjeen]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/cassandra-3.11
Commit: 2a0890d0fc5eaaf88d0a2d610a5f500fe943fb92
Parents: 3f725c9 1f54aa4
Author: Alex Petrov 
Authored: Thu Jun 15 19:35:07 2017 +0200
Committer: Alex Petrov 
Committed: Thu Jun 15 19:35:07 2017 +0200

--
 CHANGES.txt |  1 +
 NEWS.txt| 28 
 .../org/apache/cassandra/db/ReadResponse.java   |  9 +--
 .../db/commitlog/CommitLogDescriptor.java   |  2 +-
 .../cassandra/db/filter/ColumnFilter.java   | 70 
 .../apache/cassandra/net/MessagingService.java  |  7 +-
 .../cassandra/service/MigrationManager.java | 13 +++-
 .../cassandra/db/filter/ColumnFilterTest.java   | 70 
 8 files changed, 178 insertions(+), 22 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2a0890d0/CHANGES.txt
--
diff --cc CHANGES.txt
index 1058c9c,528bbcd..0047c55
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,42 -1,5 +1,43 @@@
 -3.0.14
 +3.11.0
 + * Replace string comparison with regex/number checks in MessagingService 
test (CASSANDRA-13216)
 + * Fix formatting of duration columns in CQLSH (CASSANDRA-13549)
 + * Fix the problem with duplicated rows when using paging with SASI 
(CASSANDRA-13302)
 + * Allow CONTAINS statements filtering on the partition key and it’s parts 
(CASSANDRA-13275)
 + * Fall back to even ranges calculation in clusters with vnodes when tokens 
are distributed unevenly (CASSANDRA-13229)
 + * Fix duration type validation to prevent overflow (CASSANDRA-13218)
 + * Forbid unsupported creation of SASI indexes over partition key columns 
(CASSANDRA-13228)
 + * Reject multiple values for a key in CQL grammar. (CASSANDRA-13369)
 + * UDA fails without input rows (CASSANDRA-13399)
 + * Fix compaction-stress by using daemonInitialization (CASSANDRA-13188)
 + * V5 protocol flags decoding broken (CASSANDRA-13443)
 + * Use write lock not read lock for removing sstables from compaction 
strategies. (CASSANDRA-13422)
 + * Use corePoolSize equal to maxPoolSize in JMXEnabledThreadPoolExecutors 
(CASSANDRA-13329)
 + * Avoid rebuilding SASI indexes containing no values (CASSANDRA-12962)
 + * Add charset to Analyser input stream (CASSANDRA-13151)
 + * Fix testLimitSSTables flake caused by concurrent flush (CASSANDRA-12820)
 + * cdc column addition strikes again (CASSANDRA-13382)
 + * Fix static column indexes (CASSANDRA-13277)
 + * DataOutputBuffer.asNewBuffer broken (CASSANDRA-13298)
 + * unittest CipherFactoryTest failed on MacOS (CASSANDRA-13370)
 + * Forbid SELECT restrictions and CREATE INDEX over non-frozen UDT columns 
(CASSANDRA-13247)
 + * Default logging we ship will incorrectly print "?:?" for "%F:%L" pattern 
(CASSANDRA-13317)
 + * Possible AssertionError in UnfilteredRowIteratorWithLowerBound 
(CASSANDRA-13366)
 + * Support unaligned memory access for AArch64 (CASSANDRA-13326)
 + * Improve SASI range iterator efficiency on intersection with an empty range 
(CASSANDRA-12915).
 + * Fix equality comparisons of columns using the duration type 
(CASSANDRA-13174)
 + * Obfuscate password in stress-graphs (CASSANDRA-12233)
 + * Move to FastThreadLocalThread and FastThreadLocal (CASSANDRA-13034)
 + * nodetool stopdaemon errors out (CASSANDRA-13030)
 + * Tables in system_distributed should not use gcgs of 0 (CASSANDRA-12954)
 + * Fix primary index calculation for SASI (CASSANDRA-12910)
 + * More fixes to the TokenAllocator (CASSANDRA-12990)
 + * NoReplicationTokenAllocator should work with zero replication factor 
(CASSANDRA-12983)
 + * Address message coalescing regression (CASSANDRA-12676)
 + * Delete illegal character from StandardTokenizerImpl.jflex (CASSANDRA-13417)
 + * Fix cqlsh automatic protocol downgrade regression (CASSANDRA-13307)
 + * Tracing payload not passed from QueryMessage to tracing session 
(CASSANDRA-12835)
 +Merged from 3.0:
+  * Ensure consistent view of partition columns between coordinator and 
replica in ColumnFilter (CASSANDRA-13004)
   * Failed unregistering mbean during drop keyspace (CASSANDRA-13346)
   * nodetool scrub/cleanup/upgradesstables exit code is wrong (CASSANDRA-13542)
   * Fix the reported number of sstable data files accessed per read 
(CASSANDRA-13120)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/2a0890d0/NEWS.txt
--
diff --cc NEWS.txt
index a56ced6,00ec48d..6bc3388
--- a/NEWS.txt
+++ b/NEWS.txt
@@@ -18,6 -18,

[3/6] cassandra git commit: Ensure consistent view of partition columns between coordinator and replica in ColumnFilter

[ifesdjeen]

Ensure consistent view of partition columns between coordinator and replica in 
ColumnFilter

Patch by Alex Petrov; reviewed by Aleksey Yeschenko for CASSANDRA-13004

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

Branch: refs/heads/trunk
Commit: 1f54aa424fd8a79089f76951a93560e6bca9d459
Parents: 7b9868c
Author: Alex Petrov 
Authored: Wed May 31 17:01:14 2017 +0200
Committer: Alex Petrov 
Committed: Thu Jun 15 19:03:58 2017 +0200

--
 CHANGES.txt |   1 +
 NEWS.txt|  23 +
 .../org/apache/cassandra/db/ReadResponse.java   |   9 +-
 .../db/commitlog/CommitLogDescriptor.java   |   2 +-
 .../cassandra/db/filter/ColumnFilter.java   | 102 ++-
 .../apache/cassandra/net/MessagingService.java  |   7 +-
 .../cassandra/service/MigrationManager.java |  13 ++-
 .../cassandra/db/filter/ColumnFilterTest.java   |  70 +
 8 files changed, 192 insertions(+), 35 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1f54aa42/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 26462db..528bbcd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.14
+ * Ensure consistent view of partition columns between coordinator and replica 
in ColumnFilter (CASSANDRA-13004)
  * Failed unregistering mbean during drop keyspace (CASSANDRA-13346)
  * nodetool scrub/cleanup/upgradesstables exit code is wrong (CASSANDRA-13542)
  * Fix the reported number of sstable data files accessed per read 
(CASSANDRA-13120)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1f54aa42/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 6790e6b..00ec48d 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -18,6 +18,29 @@ using the provided 'sstableupgrade' tool.
 
 Upgrading
 -
+   - ALTER TABLE (ADD/DROP COLUMN) operations concurrent with a read might
+ result into data corruption (see CASSANDRA-13004 for more details).
+ Fixing this bug required a messaging protocol version bump. By default,
+ Cassandra 3.0.14 will use 3014 version for messaging.
+
+ Since Schema Migrations rely the on exact messaging protocol version
+ match between nodes, if you need schema changes during the upgrade
+ process, you have to start your nodes with 
`-Dcassandra.force_3_0_protocol_version=true`
+ first, in order to temporarily force a backwards compatible protocol.
+ After the whole cluster is upgraded to 3.0.14, do a rolling
+ restart of the cluster without setting that flag.
+
+ 3.0.14 nodes with and withouot the flag set will be able to do schema
+ migrations with other 3.x and 3.0.x releases.
+
+ While running the cluster with the flag set to true on 3.0.14 (in
+ compatibility mode), avoid adding or removing any columns to/from
+ existing tables.
+
+ If your cluster can do without schema migrations during the upgrade
+ time, just start the cluster normally without setting aforementioned
+ flag.
+
- If performing a rolling upgrade from 3.0.13, there will be a schema 
mismatch caused
  by a bug with the schema digest calculation in 3.0.13. This will cause 
unnecessary
  but otherwise harmless schema updates, see CASSANDRA-13559 for more 
details.

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1f54aa42/src/java/org/apache/cassandra/db/ReadResponse.java
--
diff --git a/src/java/org/apache/cassandra/db/ReadResponse.java 
b/src/java/org/apache/cassandra/db/ReadResponse.java
index 12f0b15..693b52b 100644
--- a/src/java/org/apache/cassandra/db/ReadResponse.java
+++ b/src/java/org/apache/cassandra/db/ReadResponse.java
@@ -378,7 +378,7 @@ public abstract class ReadResponse
 if (digest.hasRemaining())
 return new DigestResponse(digest);
 
-assert version == MessagingService.VERSION_30;
+assert version >= MessagingService.VERSION_30;
 ByteBuffer data = ByteBufferUtil.readWithVIntLength(in);
 return new RemoteDataResponse(data);
 }
@@ -413,9 +413,10 @@ public abstract class ReadResponse
 long size = ByteBufferUtil.serializedSizeWithVIntLength(digest);
 if (!isDigest)
 {
-// Note that we can only get there if version == 3.0, which is 
the current_version. When we'll change the
-// version, we'll have to deserialize/re-serialize the data to 
be in

[2/6] cassandra git commit: Ensure consistent view of partition columns between coordinator and replica in ColumnFilter

[ifesdjeen]

Ensure consistent view of partition columns between coordinator and replica in 
ColumnFilter

Patch by Alex Petrov; reviewed by Aleksey Yeschenko for CASSANDRA-13004

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

Branch: refs/heads/cassandra-3.11
Commit: 1f54aa424fd8a79089f76951a93560e6bca9d459
Parents: 7b9868c
Author: Alex Petrov 
Authored: Wed May 31 17:01:14 2017 +0200
Committer: Alex Petrov 
Committed: Thu Jun 15 19:03:58 2017 +0200

--
 CHANGES.txt |   1 +
 NEWS.txt|  23 +
 .../org/apache/cassandra/db/ReadResponse.java   |   9 +-
 .../db/commitlog/CommitLogDescriptor.java   |   2 +-
 .../cassandra/db/filter/ColumnFilter.java   | 102 ++-
 .../apache/cassandra/net/MessagingService.java  |   7 +-
 .../cassandra/service/MigrationManager.java |  13 ++-
 .../cassandra/db/filter/ColumnFilterTest.java   |  70 +
 8 files changed, 192 insertions(+), 35 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1f54aa42/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 26462db..528bbcd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.14
+ * Ensure consistent view of partition columns between coordinator and replica 
in ColumnFilter (CASSANDRA-13004)
  * Failed unregistering mbean during drop keyspace (CASSANDRA-13346)
  * nodetool scrub/cleanup/upgradesstables exit code is wrong (CASSANDRA-13542)
  * Fix the reported number of sstable data files accessed per read 
(CASSANDRA-13120)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1f54aa42/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 6790e6b..00ec48d 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -18,6 +18,29 @@ using the provided 'sstableupgrade' tool.
 
 Upgrading
 -
+   - ALTER TABLE (ADD/DROP COLUMN) operations concurrent with a read might
+ result into data corruption (see CASSANDRA-13004 for more details).
+ Fixing this bug required a messaging protocol version bump. By default,
+ Cassandra 3.0.14 will use 3014 version for messaging.
+
+ Since Schema Migrations rely the on exact messaging protocol version
+ match between nodes, if you need schema changes during the upgrade
+ process, you have to start your nodes with 
`-Dcassandra.force_3_0_protocol_version=true`
+ first, in order to temporarily force a backwards compatible protocol.
+ After the whole cluster is upgraded to 3.0.14, do a rolling
+ restart of the cluster without setting that flag.
+
+ 3.0.14 nodes with and withouot the flag set will be able to do schema
+ migrations with other 3.x and 3.0.x releases.
+
+ While running the cluster with the flag set to true on 3.0.14 (in
+ compatibility mode), avoid adding or removing any columns to/from
+ existing tables.
+
+ If your cluster can do without schema migrations during the upgrade
+ time, just start the cluster normally without setting aforementioned
+ flag.
+
- If performing a rolling upgrade from 3.0.13, there will be a schema 
mismatch caused
  by a bug with the schema digest calculation in 3.0.13. This will cause 
unnecessary
  but otherwise harmless schema updates, see CASSANDRA-13559 for more 
details.

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1f54aa42/src/java/org/apache/cassandra/db/ReadResponse.java
--
diff --git a/src/java/org/apache/cassandra/db/ReadResponse.java 
b/src/java/org/apache/cassandra/db/ReadResponse.java
index 12f0b15..693b52b 100644
--- a/src/java/org/apache/cassandra/db/ReadResponse.java
+++ b/src/java/org/apache/cassandra/db/ReadResponse.java
@@ -378,7 +378,7 @@ public abstract class ReadResponse
 if (digest.hasRemaining())
 return new DigestResponse(digest);
 
-assert version == MessagingService.VERSION_30;
+assert version >= MessagingService.VERSION_30;
 ByteBuffer data = ByteBufferUtil.readWithVIntLength(in);
 return new RemoteDataResponse(data);
 }
@@ -413,9 +413,10 @@ public abstract class ReadResponse
 long size = ByteBufferUtil.serializedSizeWithVIntLength(digest);
 if (!isDigest)
 {
-// Note that we can only get there if version == 3.0, which is 
the current_version. When we'll change the
-// version, we'll have to deserialize/re-serialize the data 

[4/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[ifesdjeen]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/trunk
Commit: 2a0890d0fc5eaaf88d0a2d610a5f500fe943fb92
Parents: 3f725c9 1f54aa4
Author: Alex Petrov 
Authored: Thu Jun 15 19:35:07 2017 +0200
Committer: Alex Petrov 
Committed: Thu Jun 15 19:35:07 2017 +0200

--
 CHANGES.txt |  1 +
 NEWS.txt| 28 
 .../org/apache/cassandra/db/ReadResponse.java   |  9 +--
 .../db/commitlog/CommitLogDescriptor.java   |  2 +-
 .../cassandra/db/filter/ColumnFilter.java   | 70 
 .../apache/cassandra/net/MessagingService.java  |  7 +-
 .../cassandra/service/MigrationManager.java | 13 +++-
 .../cassandra/db/filter/ColumnFilterTest.java   | 70 
 8 files changed, 178 insertions(+), 22 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2a0890d0/CHANGES.txt
--
diff --cc CHANGES.txt
index 1058c9c,528bbcd..0047c55
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,42 -1,5 +1,43 @@@
 -3.0.14
 +3.11.0
 + * Replace string comparison with regex/number checks in MessagingService 
test (CASSANDRA-13216)
 + * Fix formatting of duration columns in CQLSH (CASSANDRA-13549)
 + * Fix the problem with duplicated rows when using paging with SASI 
(CASSANDRA-13302)
 + * Allow CONTAINS statements filtering on the partition key and it’s parts 
(CASSANDRA-13275)
 + * Fall back to even ranges calculation in clusters with vnodes when tokens 
are distributed unevenly (CASSANDRA-13229)
 + * Fix duration type validation to prevent overflow (CASSANDRA-13218)
 + * Forbid unsupported creation of SASI indexes over partition key columns 
(CASSANDRA-13228)
 + * Reject multiple values for a key in CQL grammar. (CASSANDRA-13369)
 + * UDA fails without input rows (CASSANDRA-13399)
 + * Fix compaction-stress by using daemonInitialization (CASSANDRA-13188)
 + * V5 protocol flags decoding broken (CASSANDRA-13443)
 + * Use write lock not read lock for removing sstables from compaction 
strategies. (CASSANDRA-13422)
 + * Use corePoolSize equal to maxPoolSize in JMXEnabledThreadPoolExecutors 
(CASSANDRA-13329)
 + * Avoid rebuilding SASI indexes containing no values (CASSANDRA-12962)
 + * Add charset to Analyser input stream (CASSANDRA-13151)
 + * Fix testLimitSSTables flake caused by concurrent flush (CASSANDRA-12820)
 + * cdc column addition strikes again (CASSANDRA-13382)
 + * Fix static column indexes (CASSANDRA-13277)
 + * DataOutputBuffer.asNewBuffer broken (CASSANDRA-13298)
 + * unittest CipherFactoryTest failed on MacOS (CASSANDRA-13370)
 + * Forbid SELECT restrictions and CREATE INDEX over non-frozen UDT columns 
(CASSANDRA-13247)
 + * Default logging we ship will incorrectly print "?:?" for "%F:%L" pattern 
(CASSANDRA-13317)
 + * Possible AssertionError in UnfilteredRowIteratorWithLowerBound 
(CASSANDRA-13366)
 + * Support unaligned memory access for AArch64 (CASSANDRA-13326)
 + * Improve SASI range iterator efficiency on intersection with an empty range 
(CASSANDRA-12915).
 + * Fix equality comparisons of columns using the duration type 
(CASSANDRA-13174)
 + * Obfuscate password in stress-graphs (CASSANDRA-12233)
 + * Move to FastThreadLocalThread and FastThreadLocal (CASSANDRA-13034)
 + * nodetool stopdaemon errors out (CASSANDRA-13030)
 + * Tables in system_distributed should not use gcgs of 0 (CASSANDRA-12954)
 + * Fix primary index calculation for SASI (CASSANDRA-12910)
 + * More fixes to the TokenAllocator (CASSANDRA-12990)
 + * NoReplicationTokenAllocator should work with zero replication factor 
(CASSANDRA-12983)
 + * Address message coalescing regression (CASSANDRA-12676)
 + * Delete illegal character from StandardTokenizerImpl.jflex (CASSANDRA-13417)
 + * Fix cqlsh automatic protocol downgrade regression (CASSANDRA-13307)
 + * Tracing payload not passed from QueryMessage to tracing session 
(CASSANDRA-12835)
 +Merged from 3.0:
+  * Ensure consistent view of partition columns between coordinator and 
replica in ColumnFilter (CASSANDRA-13004)
   * Failed unregistering mbean during drop keyspace (CASSANDRA-13346)
   * nodetool scrub/cleanup/upgradesstables exit code is wrong (CASSANDRA-13542)
   * Fix the reported number of sstable data files accessed per read 
(CASSANDRA-13120)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/2a0890d0/NEWS.txt
--
diff --cc NEWS.txt
index a56ced6,00ec48d..6bc3388
--- a/NEWS.txt
+++ b/NEWS.txt
@@@ -18,6 -18,41 +18,34

[1/6] cassandra git commit: Ensure consistent view of partition columns between coordinator and replica in ColumnFilter

[ifesdjeen]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 7b9868ce2 -> 1f54aa424
  refs/heads/cassandra-3.11 3f725c9e8 -> 2a0890d0f
  refs/heads/trunk f5531e120 -> a07d327be


Ensure consistent view of partition columns between coordinator and replica in 
ColumnFilter

Patch by Alex Petrov; reviewed by Aleksey Yeschenko for CASSANDRA-13004

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

Branch: refs/heads/cassandra-3.0
Commit: 1f54aa424fd8a79089f76951a93560e6bca9d459
Parents: 7b9868c
Author: Alex Petrov 
Authored: Wed May 31 17:01:14 2017 +0200
Committer: Alex Petrov 
Committed: Thu Jun 15 19:03:58 2017 +0200

--
 CHANGES.txt |   1 +
 NEWS.txt|  23 +
 .../org/apache/cassandra/db/ReadResponse.java   |   9 +-
 .../db/commitlog/CommitLogDescriptor.java   |   2 +-
 .../cassandra/db/filter/ColumnFilter.java   | 102 ++-
 .../apache/cassandra/net/MessagingService.java  |   7 +-
 .../cassandra/service/MigrationManager.java |  13 ++-
 .../cassandra/db/filter/ColumnFilterTest.java   |  70 +
 8 files changed, 192 insertions(+), 35 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1f54aa42/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 26462db..528bbcd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.14
+ * Ensure consistent view of partition columns between coordinator and replica 
in ColumnFilter (CASSANDRA-13004)
  * Failed unregistering mbean during drop keyspace (CASSANDRA-13346)
  * nodetool scrub/cleanup/upgradesstables exit code is wrong (CASSANDRA-13542)
  * Fix the reported number of sstable data files accessed per read 
(CASSANDRA-13120)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1f54aa42/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 6790e6b..00ec48d 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -18,6 +18,29 @@ using the provided 'sstableupgrade' tool.
 
 Upgrading
 -
+   - ALTER TABLE (ADD/DROP COLUMN) operations concurrent with a read might
+ result into data corruption (see CASSANDRA-13004 for more details).
+ Fixing this bug required a messaging protocol version bump. By default,
+ Cassandra 3.0.14 will use 3014 version for messaging.
+
+ Since Schema Migrations rely the on exact messaging protocol version
+ match between nodes, if you need schema changes during the upgrade
+ process, you have to start your nodes with 
`-Dcassandra.force_3_0_protocol_version=true`
+ first, in order to temporarily force a backwards compatible protocol.
+ After the whole cluster is upgraded to 3.0.14, do a rolling
+ restart of the cluster without setting that flag.
+
+ 3.0.14 nodes with and withouot the flag set will be able to do schema
+ migrations with other 3.x and 3.0.x releases.
+
+ While running the cluster with the flag set to true on 3.0.14 (in
+ compatibility mode), avoid adding or removing any columns to/from
+ existing tables.
+
+ If your cluster can do without schema migrations during the upgrade
+ time, just start the cluster normally without setting aforementioned
+ flag.
+
- If performing a rolling upgrade from 3.0.13, there will be a schema 
mismatch caused
  by a bug with the schema digest calculation in 3.0.13. This will cause 
unnecessary
  but otherwise harmless schema updates, see CASSANDRA-13559 for more 
details.

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1f54aa42/src/java/org/apache/cassandra/db/ReadResponse.java
--
diff --git a/src/java/org/apache/cassandra/db/ReadResponse.java 
b/src/java/org/apache/cassandra/db/ReadResponse.java
index 12f0b15..693b52b 100644
--- a/src/java/org/apache/cassandra/db/ReadResponse.java
+++ b/src/java/org/apache/cassandra/db/ReadResponse.java
@@ -378,7 +378,7 @@ public abstract class ReadResponse
 if (digest.hasRemaining())
 return new DigestResponse(digest);
 
-assert version == MessagingService.VERSION_30;
+assert version >= MessagingService.VERSION_30;
 ByteBuffer data = ByteBufferUtil.readWithVIntLength(in);
 return new RemoteDataResponse(data);
 }
@@ -413,9 +413,10 @@ public abstract class ReadResponse
 long size = ByteBufferUtil.serializedSizeWithVIntLength(digest);
 if (!isDigest)
 {
-

[jira] [Comment Edited] (CASSANDRA-13004) Corruption while adding/removing a column to/from the table

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko edited comment on CASSANDRA-13004 at 6/15/17 5:07 PM:


Changes look good to me, though,

1. CHANGES.txt could be a bit more verbose here: "After the whole cluster is 
upgraded to 3.0.14, do a rolling restart of the cluster" - specify that this 
rolling restart shouldn't set the flag.
2. 
Boolean.parseBoolean(System.getProperty("cassandra.force_3_0_protocol_version", 
"false")) can usually be replaced with 
Boolean.getBoolean("cassandra.force_3_0_protocol_version"), though you might 
have a reason not to?
3. Since we are adapting the flag version, there is no reason not to make MS 
version conditional on the 3.11 branch as well, to allow for a rolling upgrade 
with no interruptions for those on 3.X. It's cheap to do so might as well go 
for it.

Everything else LGTM.


was (Author: iamaleksey):
Changes look good to me, though,

1. CHANGES.txt could be a bit more verbose here: "After the whole cluster is 
upgraded to 3.0.14, do a rolling restart of the cluster" - specify that this 
rolling restart shouldn't set the flag.
2. 
Boolean.parseBoolean(System.getProperty("cassandra.force_3_0_protocol_version", 
"false")) can usually be replaced with 
Boolean.getBoolean("cassandra.force_3_0_protocol_version"), though you might 
have a reason not to?
3. Since we are adapting the flag version, there is no reason to make MS 
version conditional on the 3.11 branch as well, to allow for a rolling upgrade 
with no interruptions for those on 3.X. It's cheap to do so might as well go 
for it.

Everything else LGTM.

> Corruption while adding/removing a column to/from the table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Stanislav Vishnevskiy
>Assignee: Alex Petrov
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map>,
> permission_overwrites map>,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {code:none}
> ALTER TABLE discord_channels.channels ADD application_id bigint;
> {code}
> And one row (that we can tell) got corrupted at the same time and could no 
> longer be read from the Python driver. 
> {code:none}
> [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. 
> ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: 
> '\x84\x00\x00\x1b\x08\x00\x00\x03w\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x0f\x00\x10discord_channels\x00\x08channels\x00\x02id\x00\x02\x00\x0eapplication_id\x00\x02\x00\x07bitrate\x00\t\x00\x08guild_id\x00\x02\x00\ticon_hash\x00\r\x00\x0flast_message_id\x00\x02\x00\x12last_pin_timestamp\x00\x0b\x00\x04name\x00\r\x00\x08owner_id\x00\x02\x00\x15permission_overwrites\x00!\x00\x02\x000\x00\x10discord_channels\x00\x1cchannel_permission_overwrite\x00\x04\x00\x02id\x00\x02\x00\x04type\x00\t\x00\x06allow_\x00\t\x00\x04deny\x00\t\x00\x08position\x00\t\x00\nrecipients\x00!\x00\x02\x000\x00\x10discord_channels\x00\x11channel_recipient\x00\x01\x00\x04nick\x00\r\x00\x05topic\x00\r\x00\x04type\x00\x14\x00\nuser_limit\x00\t\x00\x00\x00\x01\x00\x00\x00\x08\x03\x8a\x19\x8e\xf8\x82\x00\x01\xff\xff\xff\xff\x00\x00\x00\x04\x00\x00\xfa\x00\x00\x00\x00\x08\x00\x00\xfa\x00\x00\xf8G\xc5\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8b\xc0\xb5nB\x00\x02\x00\x00\x00\x08G\xc5\xffI\x98\xc4\xb4(\x00\x00\x00\x03\x8b\xc0\xa8\xff\xff\xff\xff\x00\x00\x01<\x00\x00\x00\x06\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x040\x07\xf8Q\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00\x04\x00\x0

[jira] [Commented] (CASSANDRA-10130) Node failure during 2i update after streaming can have incomplete 2i when restarted

[JIRA]

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

Andrés de la Peña commented on CASSANDRA-10130:
---

Here is another version of the patch:

||[trunk|https://github.com/apache/cassandra/compare/trunk...adelapena:10130-trunk]|[utests|http://cassci.datastax.com/view/Dev/view/adelapena/job/adelapena-10130-trunk-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/adelapena/job/adelapena-10130-trunk-dtest/]|

bq. I mistakenly removed {{queryableIndexes]] in my refactor (as noted); 
[this|https://github.com/adelapena/cassandra/commit/c5604ffd5ae36cc34d13af6c4c4eadba98458fa3]
 commit added it back, but it's unfortunately not enough, as if the 
initialization task fails, the index will never be made queryable: we need to 
fix this, and we need a test for such failure case.

[Here|https://github.com/adelapena/cassandra/commit/2994aece1e936b81ad507f2e9baf0092e79edce0]
 a successful full rebuild adds the index to the set of queryable indexes. I 
have also added [some 
tests|https://github.com/adelapena/cassandra/blob/2994aece1e936b81ad507f2e9baf0092e79edce0/test/unit/org/apache/cassandra/index/SecondaryIndexManagerTest.java#L386-L456]
 to check the behaviour. Note that a partial build doesn't set the index as 
queryable.

bq. Nit/OCD: I would change the 
[rebuildFromSSTablesBlocking|https://github.com/adelapena/cassandra/commit/a945358a36f97632e94e9103650d72c04735354d#diff-3f2c8994c4ff8748c3faf7e70958520dR306]
 signature to have the {{sstables}} first, consistently with 
{{buildIndexesBlocking}}.

Initially done 
[here|https://github.com/adelapena/cassandra/commit/7dfc959703231c9f90f53a3b474cf7f66b240213],
 but see three quotes below.

bq. In {{buildIndexesBlocking}}, any exceptions thrown by 
{{flushIndexesBlocking}} in the {{finally}} block will hide previous 
exceptions: we should accumulate them.

Done 
[here|https://github.com/adelapena/cassandra/commit/fbce3657132a8b87d2ff2446504634f5efdf2b59].

bq. Nit/OCD: In buildIndexesBlocking, we should put an additional comment 
before invoking flushIndexesBlocking.

Done 
[here|https://github.com/adelapena/cassandra/commit/b7bf81acd66c3bdac66ba86117e07cac251ca312].

bq. If {{rebuildFromSSTablesBlocking}} is not used elsewhere, I would strongly 
recommend to make it private/protected and move its comment to 
{{rebuildIndexesBlocking}}: the [general 
rule|https://image.slidesharecdn.com/effectivejava-2ndedition-chapter4-151203200429-lva1-app6891/95/effective-java-chapter-4-classes-and-interfaces-4-638.jpg?cb=1449173201]
 is methods (as well as attributes) should have the most restricted visibility 
allowed by working code.

Actually {{rebuildFromSSTablesBlocking}} is only called by full rebuilds, so we 
can eve get rid of this method and move its content and doc to 
{{rebuildIndexesBlocking}}, as it is done 
[here|https://github.com/adelapena/cassandra/commit/cdd32e54f86bd831faa4463489bad153520e2754].
 Tests still have access to partial builds through 
[{{handleNotification}}|https://github.com/adelapena/cassandra/blob/fbce3657132a8b87d2ff2446504634f5efdf2b59/test/unit/org/apache/cassandra/index/SecondaryIndexManagerTest.java#L115].

bq. Regarding the {{test_standalone_scrub failure}}, I believe it's due to the 
fact we only manage counters in our marking methods when 
{{DatabaseDescriptor.isDaemonInitialized()}}, which is obviously not the case 
with the scrubber; if so, it's probably an easy fix.

Right, it's fixed 
[here|https://github.com/adelapena/cassandra/commit/a2744560b2d3262b1872c5f989d1baee645b7c5c].

Apart form this, 
[here|https://github.com/adelapena/cassandra/commit/70b477bc4c83613474756d39ac36c1301c4a54b2]
 I have restored {{CassandraIndexTest#indexCorrectlyMarkedAsBuildAndRemoved}} 
to its initial shape because all the added cases are (better) covered by 
{{SecondaryIndexManagerTest}}. The reason to preserve the test is that it uses 
a real index implementation instead of a mocked one, which can be useful 
although the difficulties to simulate failures, blocking, etc.

I have also removed some unused imports.

> Node failure during 2i update after streaming can have incomplete 2i when 
> restarted
> ---
>
> Key: CASSANDRA-10130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10130
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Yuki Morishita
>Assignee: Andrés de la Peña
>Priority: Minor
>
> Since MV/2i update happens after SSTables are received, node failure during 
> MV/2i update can leave received SSTables live when restarted while MV/2i are 
> partially up to date.
> We can add some kind of tracking mechanism to automatically rebuild at the 
> startup, or at leas

[jira] [Updated] (CASSANDRA-13600) sstabledump possible problem

[a8775 (JIRA)]

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

a8775 updated CASSANDRA-13600:
--
Environment: Official cassandra docker image (last) under Win10
Summary: sstabledump possible problem  (was: sstabledump posisible 
problem)

> sstabledump possible problem
> 
>
> Key: CASSANDRA-13600
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13600
> Project: Cassandra
>  Issue Type: Bug
> Environment: Official cassandra docker image (last) under Win10
>Reporter: a8775
> Fix For: 3.10
>
>
> h2. Possible bug in sstabledump
> {noformat}
> cqlsh> show version
> [cqlsh 5.0.1 | Cassandra 3.10 | CQL spec 3.4.4 | Native protocol v4]
> {noformat}
> h2. Execute script in cqlsh in new keyspace
> {noformat}
> CREATE TABLE IF NOT EXISTS test_data (   
> // partitioning key
> PK TEXT, 
> // data
> Data TEXT,
> 
> PRIMARY KEY (PK)
> );
> insert into test_data(PK,Data) values('0','');
> insert into test_data(PK,Data) values('1','');
> insert into test_data(PK,Data) values('2','');
> delete from test_data where PK='1';
> insert into test_data(PK,Data) values('1','');
> {noformat}
> h2. Execute the following commands
> {noformat}
> nodetool flush
> nodetool compact
> sstabledump mc-2-big-Data.db
> sstabledump -d mc-2-big-Data.db
> {noformat}
> h3. default dump - missing data for partiotion key = "1"
> {noformat}
> [
>   {
> "partition" : {
>   "key" : [ "0" ],
>   "position" : 0
> },
> "rows" : [
>   {
> "type" : "row",
> "position" : 15,
> "liveness_info" : { "tstamp" : "2017-06-14T12:23:13.529389Z" },
> "cells" : [
>   { "name" : "data", "value" : "" }
> ]
>   }
> ]
>   },
>   {
> "partition" : {
>   "key" : [ "2" ],
>   "position" : 26
> },
> "rows" : [
>   {
> "type" : "row",
> "position" : 41,
> "liveness_info" : { "tstamp" : "2017-06-14T12:23:13.544132Z" },
> "cells" : [
>   { "name" : "data", "value" : "" }
> ]
>   }
> ]
>   },
>   {
> "partition" : {
>   "key" : [ "1" ],
>   "position" : 53,
>   "deletion_info" : { "marked_deleted" : "2017-06-14T12:23:13.545988Z", 
> "local_delete_time" : "2017-06-14T12:23:13Z" }
> }
>   }
> ]
> {noformat}
> h3. dump with -d option - correct data for partiotion key = "1"
> {noformat}
> [0]@0 Row[info=[ts=1497442993529389] ]:  | [data= ts=1497442993529389]
> [2]@26 Row[info=[ts=1497442993544132] ]:  | [data= ts=1497442993544132]
> [1]@53 deletedAt=1497442993545988, localDeletion=1497442993
> [1]@53 Row[info=[ts=1497442993550159] ]:  | [data= ts=1497442993550159]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (CASSANDRA-13609) COPY FROM not handling newlines within field

[David Sturrock (JIRA)]

David Sturrock created CASSANDRA-13609:
--

 Summary: COPY FROM not handling newlines within field
 Key: CASSANDRA-13609
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13609
 Project: Cassandra
  Issue Type: Bug
  Components: CQL
 Environment: CQL 5.0.1

Reporter: David Sturrock
Priority: Minor
 Fix For: 3.0.9


When using Copy From to import data from a CSV file, if it comes across a row 
like like this:

10.0, 10.0, 0.0, "UX JSY AIO PETE 
10% off Toys Catalogue 10.00% -1.00 ", "Canterbury"
10.0, 10.0,..

It will treat the newline after PETE as the end of the first row

While this makes sense since it's treating each line as a new row, it's also 
supposed to treat content between "s as a field but instead finishes  half way 
through a field. Shouldn't the fact that it's inside a field take precedence 
here and have it continue reading until it finds a closing "?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (CASSANDRA-13004) Corruption while adding/removing a column to/from the table

[Alex Petrov (JIRA)]

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

Alex Petrov updated CASSANDRA-13004:

Summary: Corruption while adding/removing a column to/from the table  (was: 
Corruption while adding a column to a table)

> Corruption while adding/removing a column to/from the table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Stanislav Vishnevskiy
>Assignee: Alex Petrov
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map>,
> permission_overwrites map>,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {code:none}
> ALTER TABLE discord_channels.channels ADD application_id bigint;
> {code}
> And one row (that we can tell) got corrupted at the same time and could no 
> longer be read from the Python driver. 
> {code:none}
> [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. 
> ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: 
> '\x84\x00\x00\x1b\x08\x00\x00\x03w\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x0f\x00\x10discord_channels\x00\x08channels\x00\x02id\x00\x02\x00\x0eapplication_id\x00\x02\x00\x07bitrate\x00\t\x00\x08guild_id\x00\x02\x00\ticon_hash\x00\r\x00\x0flast_message_id\x00\x02\x00\x12last_pin_timestamp\x00\x0b\x00\x04name\x00\r\x00\x08owner_id\x00\x02\x00\x15permission_overwrites\x00!\x00\x02\x000\x00\x10discord_channels\x00\x1cchannel_permission_overwrite\x00\x04\x00\x02id\x00\x02\x00\x04type\x00\t\x00\x06allow_\x00\t\x00\x04deny\x00\t\x00\x08position\x00\t\x00\nrecipients\x00!\x00\x02\x000\x00\x10discord_channels\x00\x11channel_recipient\x00\x01\x00\x04nick\x00\r\x00\x05topic\x00\r\x00\x04type\x00\x14\x00\nuser_limit\x00\t\x00\x00\x00\x01\x00\x00\x00\x08\x03\x8a\x19\x8e\xf8\x82\x00\x01\xff\xff\xff\xff\x00\x00\x00\x04\x00\x00\xfa\x00\x00\x00\x00\x08\x00\x00\xfa\x00\x00\xf8G\xc5\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8b\xc0\xb5nB\x00\x02\x00\x00\x00\x08G\xc5\xffI\x98\xc4\xb4(\x00\x00\x00\x03\x8b\xc0\xa8\xff\xff\xff\xff\x00\x00\x01<\x00\x00\x00\x06\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x040\x07\xf8Q\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x07\xf8Q\x00\x00\x00\x04\x10\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x05\xe8A\x00\x00\x00\x04\x10\x02\x00\x00\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00
>  
> \x08\x01\x00\x00\x00\x04\xc4\xb4(\x00\xff\xff\xff\xff\x00\x00\x00O[f\x80Q\x07general\x05\xf8G\xc5\xffI\x98\xc4\xb4(\x00\xf8O[f\x80Q\x00\x00\x00\x02\x04\xf8O[f\x80Q\x00\xf8G\xc5\xffI\x98\x01\x00\x00\xf8O[f\x80Q\x00\x00\x00\x00\xf8G\xc5\xffI\x97\xc4\xb4(\x06\x00\xf8O\x7fe\x1fm\x08\x03\x00\x00\x00\x01\x00\x00\x00\x00\x04\x00\x00\x00\x00'
> {code}
> And then in cqlsh when trying to read the row we got this. 
> {code:none}
> /usr/bin/cqlsh.py:632: DateOverFlowWarning: Some timestamps are larger than 
> Python datetime can represent. Timestamps are displayed in milliseconds from 
> epoch.
> Traceback (most recent call last):
>   File "/usr/bin/cqlsh.py", line 1301, in perform_simple_statement
> result = future.result()
>   File 
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.5.0.post0-d8d0456.zip/ca

[jira] [Created] (CASSANDRA-13608) Connection closed/reopened during join causes Cassandra stream to close

[Tania S Engel (JIRA)]

Tania S Engel created CASSANDRA-13608:
-

 Summary: Connection closed/reopened during join causes Cassandra 
stream to close
 Key: CASSANDRA-13608
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13608
 Project: Cassandra
  Issue Type: Bug
  Components: Streaming and Messaging
 Environment: Cassandra 3.10. Windows Server 2016, 32GB ram, 2TB hard 
disk, RAID10 with 4 spindles, 8 Cores
Reporter: Tania S Engel
 Fix For: 3.10
 Attachments: Cassandra 3.10 Join with lots GC collection leads to 
socket closure and join hang.mht

We start a JOIN bootstrap. Primary seed node streams to the replica. The 
replica requires some GC cleanup and experiences frequent pauses including a 12 
second old gen cleanup following a memTable flush. Both replica and primary 
show _MessagingService IOException: An existing connection was forcibly closed 
by the remote host_. The replica MessagingService-Outgoing reestablishes the 
connection immediately but the primary StreamKeepAliveExecutor throws a 
_java.RuntimeException: Outgoing stream handler has been closed_. From that 
point forward, the replica stays in JOIN mode, sending keeping alive to the 
primary. The primary receives the keep alive, but does not send its own and it 
repeatedly fails to send a hints file to the replica. It seems this limping 
condition would continue indefinitely, but stops as we stop the replica 
Cassandra. If we restart the replica Cassandra the JOIN picks up again but 
fails with _java.io.IOException: Corrupt value length 355151036 encountered, as 
it exceeds the maximum of 268435456, which is set via max_value_size_in_mb in 
cassandra.yaml_. We have not increased this value as we do not have values that 
large in our data so we presume it is indeed corrupt and moving past it would 
not be a good idea. Please see the attachment for details.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[3/3] cassandra git commit: Merge branch 'cassandra-3.11' into trunk

[jasobrown]

Merge branch 'cassandra-3.11' into trunk


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

Branch: refs/heads/trunk
Commit: f5531e12060b225ff9c0b2bb58222154a7f08692
Parents: 74e3f15 3f725c9
Author: Jason Brown 
Authored: Thu Jun 15 07:30:16 2017 -0700
Committer: Jason Brown 
Committed: Thu Jun 15 07:30:46 2017 -0700

--
 build.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f5531e12/build.xml
--
diff --cc build.xml
index d085495,3b2f0ce..64872f8
--- a/build.xml
+++ b/build.xml
@@@ -1253,8 -1392,8 +1253,8 @@@

  

 -
 +
-   
+   
  
  



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

[2/3] cassandra git commit: ninja-fix the build script make test-compression depend on stress-build. needed due to CASSANDRA-13188

[jasobrown]

ninja-fix the build script make test-compression depend on stress-build. needed 
due to CASSANDRA-13188


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

Branch: refs/heads/trunk
Commit: 3f725c9e8450ab6eac0ad5ffec463e72789176cc
Parents: d8fb934
Author: Jason Brown 
Authored: Thu Jun 15 07:29:27 2017 -0700
Committer: Jason Brown 
Committed: Thu Jun 15 07:29:27 2017 -0700

--
 build.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f725c9e/build.xml
--
diff --git a/build.xml b/build.xml
index 8723313..3b2f0ce 100644
--- a/build.xml
+++ b/build.xml
@@ -1393,7 +1393,7 @@
 
   
 
-  
+  
 
 
   


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

[1/3] cassandra git commit: ninja-fix the build script make test-compression depend on stress-build. needed due to CASSANDRA-13188

[jasobrown]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.11 d8fb9349d -> 3f725c9e8
  refs/heads/trunk 74e3f1522 -> f5531e120


ninja-fix the build script make test-compression depend on stress-build. needed 
due to CASSANDRA-13188


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

Branch: refs/heads/cassandra-3.11
Commit: 3f725c9e8450ab6eac0ad5ffec463e72789176cc
Parents: d8fb934
Author: Jason Brown 
Authored: Thu Jun 15 07:29:27 2017 -0700
Committer: Jason Brown 
Committed: Thu Jun 15 07:29:27 2017 -0700

--
 build.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f725c9e/build.xml
--
diff --git a/build.xml b/build.xml
index 8723313..3b2f0ce 100644
--- a/build.xml
+++ b/build.xml
@@ -1393,7 +1393,7 @@
 
   
 
-  
+  
 
 
   


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

[jira] [Commented] (CASSANDRA-13569) Schedule schema pulls just once per endpoint

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-13569:
---

Good call.

I think the patch is ok, but I personally prefer tracking cleanup to be 
performed by the runnables themselves in such cases. Also use computeIfAbsent() 
on CHMs.

An untested branch with a follow-up commit pushed to 
https://github.com/iamaleksey/cassandra/tree/13569-3.0. Please lmk what you 
think.

> Schedule schema pulls just once per endpoint
> 
>
> Key: CASSANDRA-13569
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13569
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Distributed Metadata
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Schema mismatches detected through gossip will get resolved by calling 
> {{MigrationManager.maybeScheduleSchemaPull}}. This method may decide to 
> schedule execution of {{MigrationTask}}, but only after using a 
> {{MIGRATION_DELAY_IN_MS = 6}} delay (for reasons unclear to me). 
> Meanwhile, as long as the migration task hasn't been executed, we'll continue 
> to have schema mismatches reported by gossip and will have corresponding 
> {{maybeScheduleSchemaPull}} calls, which will schedule further tasks with the 
> mentioned delay. Some local testing shows that dozens of tasks for the same 
> endpoint will eventually be executed and causing the same, stormy behavior 
> for this very endpoints.
> My proposal would be to simply not schedule new tasks for the same endpoint, 
> in case we still have pending tasks waiting for execution after 
> {{MIGRATION_DELAY_IN_MS}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-13004) Corruption while adding a column to a table

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-13004:
---

Oh, also I'm pretty sure that this is a problem not just for adding columns, 
but for dropping them too. Any change to the columns set.

So we should rename the ticket, CHANGES.txt entry, and elaborate in NEWS.txt 
that DROP is also affected.

> Corruption while adding a column to a table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Stanislav Vishnevskiy
>Assignee: Alex Petrov
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map>,
> permission_overwrites map>,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {code:none}
> ALTER TABLE discord_channels.channels ADD application_id bigint;
> {code}
> And one row (that we can tell) got corrupted at the same time and could no 
> longer be read from the Python driver. 
> {code:none}
> [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. 
> ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: 
> '\x84\x00\x00\x1b\x08\x00\x00\x03w\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x0f\x00\x10discord_channels\x00\x08channels\x00\x02id\x00\x02\x00\x0eapplication_id\x00\x02\x00\x07bitrate\x00\t\x00\x08guild_id\x00\x02\x00\ticon_hash\x00\r\x00\x0flast_message_id\x00\x02\x00\x12last_pin_timestamp\x00\x0b\x00\x04name\x00\r\x00\x08owner_id\x00\x02\x00\x15permission_overwrites\x00!\x00\x02\x000\x00\x10discord_channels\x00\x1cchannel_permission_overwrite\x00\x04\x00\x02id\x00\x02\x00\x04type\x00\t\x00\x06allow_\x00\t\x00\x04deny\x00\t\x00\x08position\x00\t\x00\nrecipients\x00!\x00\x02\x000\x00\x10discord_channels\x00\x11channel_recipient\x00\x01\x00\x04nick\x00\r\x00\x05topic\x00\r\x00\x04type\x00\x14\x00\nuser_limit\x00\t\x00\x00\x00\x01\x00\x00\x00\x08\x03\x8a\x19\x8e\xf8\x82\x00\x01\xff\xff\xff\xff\x00\x00\x00\x04\x00\x00\xfa\x00\x00\x00\x00\x08\x00\x00\xfa\x00\x00\xf8G\xc5\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8b\xc0\xb5nB\x00\x02\x00\x00\x00\x08G\xc5\xffI\x98\xc4\xb4(\x00\x00\x00\x03\x8b\xc0\xa8\xff\xff\xff\xff\x00\x00\x01<\x00\x00\x00\x06\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x040\x07\xf8Q\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x07\xf8Q\x00\x00\x00\x04\x10\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x05\xe8A\x00\x00\x00\x04\x10\x02\x00\x00\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00
>  
> \x08\x01\x00\x00\x00\x04\xc4\xb4(\x00\xff\xff\xff\xff\x00\x00\x00O[f\x80Q\x07general\x05\xf8G\xc5\xffI\x98\xc4\xb4(\x00\xf8O[f\x80Q\x00\x00\x00\x02\x04\xf8O[f\x80Q\x00\xf8G\xc5\xffI\x98\x01\x00\x00\xf8O[f\x80Q\x00\x00\x00\x00\xf8G\xc5\xffI\x97\xc4\xb4(\x06\x00\xf8O\x7fe\x1fm\x08\x03\x00\x00\x00\x01\x00\x00\x00\x00\x04\x00\x00\x00\x00'
> {code}
> And then in cqlsh when trying to read the row we got this. 
> {code:none}
> /usr/bin/cqlsh.py:632: DateOverFlowWarning: Some timestamps are larger than 
> Python datetime can represent. Timestamps are displayed in milliseconds from 
> epoch.
> Traceback (most recent call last):
>   File "/usr/bin/cqlsh.py", line 1301,

[jira] [Commented] (CASSANDRA-13004) Corruption while adding a column to a table

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-13004:
---

Changes look good to me, though,

1. CHANGES.txt could be a bit more verbose here: "After the whole cluster is 
upgraded to 3.0.14, do a rolling restart of the cluster" - specify that this 
rolling restart shouldn't set the flag.
2. 
Boolean.parseBoolean(System.getProperty("cassandra.force_3_0_protocol_version", 
"false")) can usually be replaced with 
Boolean.getBoolean("cassandra.force_3_0_protocol_version"), though you might 
have a reason not to?
3. Since we are adapting the flag version, there is no reason to make MS 
version conditional on the 3.11 branch as well, to allow for a rolling upgrade 
with no interruptions for those on 3.X. It's cheap to do so might as well go 
for it.

Everything else LGTM.

> Corruption while adding a column to a table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Stanislav Vishnevskiy
>Assignee: Alex Petrov
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map>,
> permission_overwrites map>,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {code:none}
> ALTER TABLE discord_channels.channels ADD application_id bigint;
> {code}
> And one row (that we can tell) got corrupted at the same time and could no 
> longer be read from the Python driver. 
> {code:none}
> [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. 
> ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: 
> '\x84\x00\x00\x1b\x08\x00\x00\x03w\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x0f\x00\x10discord_channels\x00\x08channels\x00\x02id\x00\x02\x00\x0eapplication_id\x00\x02\x00\x07bitrate\x00\t\x00\x08guild_id\x00\x02\x00\ticon_hash\x00\r\x00\x0flast_message_id\x00\x02\x00\x12last_pin_timestamp\x00\x0b\x00\x04name\x00\r\x00\x08owner_id\x00\x02\x00\x15permission_overwrites\x00!\x00\x02\x000\x00\x10discord_channels\x00\x1cchannel_permission_overwrite\x00\x04\x00\x02id\x00\x02\x00\x04type\x00\t\x00\x06allow_\x00\t\x00\x04deny\x00\t\x00\x08position\x00\t\x00\nrecipients\x00!\x00\x02\x000\x00\x10discord_channels\x00\x11channel_recipient\x00\x01\x00\x04nick\x00\r\x00\x05topic\x00\r\x00\x04type\x00\x14\x00\nuser_limit\x00\t\x00\x00\x00\x01\x00\x00\x00\x08\x03\x8a\x19\x8e\xf8\x82\x00\x01\xff\xff\xff\xff\x00\x00\x00\x04\x00\x00\xfa\x00\x00\x00\x00\x08\x00\x00\xfa\x00\x00\xf8G\xc5\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8b\xc0\xb5nB\x00\x02\x00\x00\x00\x08G\xc5\xffI\x98\xc4\xb4(\x00\x00\x00\x03\x8b\xc0\xa8\xff\xff\xff\xff\x00\x00\x01<\x00\x00\x00\x06\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x81L\xea\xfc\x82\x00\n\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1e\xe6\x8b\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x040\x07\xf8Q\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1f\x1b{\x82\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x07\xf8Q\x00\x00\x00\x04\x10\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x1fH6\x82\x00\x01\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x05\xe8A\x00\x00\x00\x04\x10\x02\x00\x00\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a+=\xca\xc0\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x08\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00$\x00\x00\x00\x08\x03\x8a\x8f\x979\x80\x00\n\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x04\x00
>  
> \x08\x01\x00\x00\x00\x04\xc4\xb4(\x00\xff\xff\xff\xff\x00\x00\x00O[f\x80Q\x07general\x05\xf8G\xc5\xffI\x98\xc4\xb4(\x00\xf8O[f\x80Q\x00\x00\x00\x02\x04\xf8O[f\x80Q\x00\xf8G\xc5\xffI\x98\x01\x0

[jira] [Updated] (CASSANDRA-13426) Make all DDL statements idempotent and not dependent on global state

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-13426:
--
Reviewer: Sam Tunnicliffe

> Make all DDL statements idempotent and not dependent on global state
> 
>
> Key: CASSANDRA-13426
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13426
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Distributed Metadata
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
> Fix For: 4.0
>
>
> A follow-up to CASSANDRA-9425 and a pre-requisite for CASSANDRA-10699.
> It's necessary for the latter to be able to apply any DDL statement several 
> times without side-effects. As part of the ticket I think we should also 
> clean up validation logic and our error texts. One example is varying 
> treatment of missing keyspace for DROP TABLE/INDEX/etc. statements with IF 
> EXISTS.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (CASSANDRA-13607) InvalidRequestException: Key may not be empty

[anuragh (JIRA)]

anuragh created CASSANDRA-13607:
---

 Summary: InvalidRequestException: Key may not be empty
 Key: CASSANDRA-13607
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13607
 Project: Cassandra
  Issue Type: Bug
Reporter: anuragh
 Fix For: 2.1.7


Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  AddressLoad   Tokens  OwnsHost ID   
Rack
UN  10.146.80.71   175.01 GB  256 ?   
2a926f37-9b37-4915-9739-d04befec4f6b  rack1
UN  10.146.81.149  105.71 GB  256 ?   
79b06413-fad7-4d23-aafa-28e8f2b54400  rack1
UN  10.146.80.56   180.43 GB  256 ?   
b5eb237f-9edf-4963-9f2c-4e39d6af0f0a  rack1
UN  10.146.80.62   174.89 GB  256 ?   
a7ba177f-0f21-4f24-b6fe-77937d005498  rack1

Here adding this node(10.146.81.149) to the ring and the seed node is 
10.146.80.56.
This new node is not JMX enabled but all the other 3 are JMX enabled.
Is the below error is due to JMX?

RROR [SharedPool-Worker-11] 2017-06-15 07:15:46,939 Message.java:538 - 
Unexpected exception during request; channel = [id: 0x57764a3b, 
/10.146.144.86:47336 => /10.146.81.149:9042]
java.lang.AssertionError: 
org.apache.cassandra.exceptions.InvalidRequestException: Key may not be empty
at 
org.apache.cassandra.auth.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:125)
 ~[apache-cassandra-2.1.7.jar:2.1.7]
at 
org.apache.cassandra.auth.PasswordAuthenticator$PlainTextSaslAuthenticator.getAuthenticatedUser(PasswordAuthenticator.java:291)
 ~[apache-cassandra-2.1.7.jar:2.1.7]
at 
org.apache.cassandra.transport.messages.AuthResponse.execute(AuthResponse.java:81)
 ~[apache-cassandra-2.1.7.jar:2.1.7]
at 
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
 [apache-cassandra-2.1.7.jar:2.1.7]
at 
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
 [apache-cassandra-2.1.7.jar:2.1.7]
at 
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
 [netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
 [netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
 [netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
 [netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_60]
at 
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
 [apache-cassandra-2.1.7.jar:2.1.7]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
[apache-cassandra-2.1.7.jar:2.1.7]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
Caused by: org.apache.cassandra.exceptions.InvalidRequestException: Key may not 
be empty
at 
org.apache.cassandra.cql3.QueryProcessor.validateKey(QueryProcessor.java:197) 
~[apache-cassandra-2.1.7.jar:2.1.7]
at 
org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:360)
 ~[apache-cassandra-2.1.7.jar:2.1.7]
at 
org.apache.cassandra.cql3.statements.SelectStatement.getPageableCommand(SelectStatement.java:253)
 ~[apache-cassandra-2.1.7.jar:2.1.7]
at 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:213)
 ~[apache-cassandra-2.1.7.jar:2.1.7]
at 
org.apache.cassandra.auth.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:118)
 ~[apache-cassandra-2.1.7.jar:2.1.7]
... 12 common frames omitted




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-10130) Node failure during 2i update after streaming can have incomplete 2i when restarted

[Sergio Bossa (JIRA)]

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

Sergio Bossa commented on CASSANDRA-10130:
--

Also, a style note about indentation for lambdas and anonymous classes; I see 
[some|https://github.com/adelapena/cassandra/blob/eb0316d651bbdec70896be041ab1981cc9349a18/src/java/org/apache/cassandra/index/SecondaryIndexManager.java#L453]
 are deeply indented, but I think that makes the code harder to read, and I 
prefer [standard 4 spaces 
indent|https://github.com/adelapena/cassandra/blob/eb0316d651bbdec70896be041ab1981cc9349a18/src/java/org/apache/cassandra/index/SecondaryIndexManager.java#L492]:
 thoughts? Whatever the choice, we should make the patch consistent (but 
possibly avoid to change other untouched code)

> Node failure during 2i update after streaming can have incomplete 2i when 
> restarted
> ---
>
> Key: CASSANDRA-10130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10130
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Yuki Morishita
>Assignee: Andrés de la Peña
>Priority: Minor
>
> Since MV/2i update happens after SSTables are received, node failure during 
> MV/2i update can leave received SSTables live when restarted while MV/2i are 
> partially up to date.
> We can add some kind of tracking mechanism to automatically rebuild at the 
> startup, or at least warn user when the node restarts.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-10130) Node failure during 2i update after streaming can have incomplete 2i when restarted

[Sergio Bossa (JIRA)]

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

Sergio Bossa commented on CASSANDRA-10130:
--

As a side note, I opened CASSANDRA-13606 to further improve initialization 
failures handling.

> Node failure during 2i update after streaming can have incomplete 2i when 
> restarted
> ---
>
> Key: CASSANDRA-10130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10130
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Yuki Morishita
>Assignee: Andrés de la Peña
>Priority: Minor
>
> Since MV/2i update happens after SSTables are received, node failure during 
> MV/2i update can leave received SSTables live when restarted while MV/2i are 
> partially up to date.
> We can add some kind of tracking mechanism to automatically rebuild at the 
> startup, or at least warn user when the node restarts.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (CASSANDRA-13606) Improve handling of 2i initialization failures

[Sergio Bossa (JIRA)]

Sergio Bossa created CASSANDRA-13606:


 Summary: Improve handling of 2i initialization failures
 Key: CASSANDRA-13606
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13606
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sergio Bossa
Assignee: Sergio Bossa
 Fix For: 4.0


CASSANDRA-10130 fixes the 2i build management, but initialization failures are 
still not properly handled, most notably because:
* Initialization failures make the index non-queryable, but it can still be 
written to.
* Initialization failures can be recovered via full rebuilds.

Both points above are probably suboptimal because the initialization logic 
could be more complex than just an index build, hence it shouldn't be made 
recoverable via a simple rebuild, and could cause the index to be fully 
unavailable not just for reads, but for writes as well.

So, we should better handle initialization failures by:
* Allowing the index implementation to specify if unavailable for reads, 
writes, or both. 
* Providing a proper method to recover, distinct from index rebuilds.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-10130) Node failure during 2i update after streaming can have incomplete 2i when restarted

[Sergio Bossa (JIRA)]

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

Sergio Bossa commented on CASSANDRA-10130:
--

[~adelapena], [~pauloricardomg], excellent additions overall, just a few 
comments:

* I mistakenly removed {{queryableIndexes}} in my refactor (as noted); 
[this|https://github.com/adelapena/cassandra/commit/c5604ffd5ae36cc34d13af6c4c4eadba98458fa3]
 commit added it back, but it's unfortunately not enough, as if the 
initialization task fails, the index will never be made queryable: we need to 
fix this, and we need a test for such failure case.
* Nit/OCD: I would change the 
[rebuildFromSSTablesBlocking|https://github.com/adelapena/cassandra/commit/a945358a36f97632e94e9103650d72c04735354d#diff-3f2c8994c4ff8748c3faf7e70958520dR306]
 signature to have the {{sstables}} first, consistently with 
{{buildIndexesBlocking}}.
* In {{buildIndexesBlocking}}, any exceptions thrown by 
{{flushIndexesBlocking}} in the {{finally}} block will hide previous 
exceptions: we should accumulate them.
* Nit/OCD: In {{buildIndexesBlocking}}, we should put an additional comment 
before invoking {{flushIndexesBlocking}}.
* If {{rebuildFromSSTablesBlocking}} is not used elsewhere, I would strongly 
recommend to make it private/protected and move its comment to 
{{rebuildIndexesBlocking}}: the [general 
rule|https://image.slidesharecdn.com/effectivejava-2ndedition-chapter4-151203200429-lva1-app6891/95/effective-java-chapter-4-classes-and-interfaces-4-638.jpg?cb=1449173201]
 is methods (as well as attributes) should have the most restricted visibility 
allowed by working code.
* Regarding the {{test_standalone_scrub}} failure, I _believe_ it's due to the 
fact we only manage counters in our marking methods when 
{{DatabaseDescriptor.isDaemonInitialized()}}, which is obviously not the case 
with the scrubber; if so, it's probably an easy fix.

> Node failure during 2i update after streaming can have incomplete 2i when 
> restarted
> ---
>
> Key: CASSANDRA-10130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10130
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Yuki Morishita
>Assignee: Andrés de la Peña
>Priority: Minor
>
> Since MV/2i update happens after SSTables are received, node failure during 
> MV/2i update can leave received SSTables live when restarted while MV/2i are 
> partially up to date.
> We can add some kind of tracking mechanism to automatically rebuild at the 
> startup, or at least warn user when the node restarts.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-10403) Consider reverting to CMS GC on 3.0

[Spiros Ioannou (JIRA)]

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

Spiros Ioannou commented on CASSANDRA-10403:


[~ostefano] We reverted to G1 and everything is fine since, no performance hit, 
all repairs work fine since.

> Consider reverting to CMS GC on 3.0
> ---
>
> Key: CASSANDRA-10403
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10403
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Joshua McKenzie
>Assignee: Paulo Motta
> Fix For: 3.0.0 rc2
>
>
> Reference discussion on CASSANDRA-7486.
> For smaller heap sizes G1 appears to have some throughput/latency issues when 
> compared to CMS. With our default max heap size at 8G on 3.0, there's a 
> strong argument to be made for having CMS as the default for the 3.0 release.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (CASSANDRA-10130) Node failure during 2i update after streaming can have incomplete 2i when restarted

[JIRA]

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

Andrés de la Peña commented on CASSANDRA-10130:
---

I also think that the lockless version is cleaner. I have pulled it and made 
some changes [here|https://github.com/adelapena/cassandra/tree/10130-trunk]:
\\
\\
* 
[Set|https://github.com/adelapena/cassandra/commit/ffc328e7af8f32c0f6027338ec3fb503ce75f983]
 the {{SettableFuture}} in {{createIndex}} callback after marking the index to 
be sure that the marking is done when the returned future finishes.
* 
[Fix|https://github.com/adelapena/cassandra/commit/c5604ffd5ae36cc34d13af6c4c4eadba98458fa3]
 {{SIM#isIndexQueryable}} to ensure that the indexes are not queryable while 
they are been initialized, which was making [this 
test|https://github.com/apache/cassandra/blob/69aa1737d17089278c725cffeca3f69fb25f0aa0/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java#L1065]
 
[fail|http://cassci.datastax.com/view/Dev/view/adelapena/job/adelapena-10130-trunk-sergio-testall/lastCompletedBuild/testReport/].
* 
[Update|https://github.com/adelapena/cassandra/commit/e075b42e4a7c3a8fcc11ca51388e38ebcbd075b4]
 {{CassandraIndexTest#indexCorrectlyMarkedAsBuildAndRemoved}} again to the 
check new expected behaviour. 

It seems that new lockless version is making 
[{{scrub_test.TestScrubIndexes.test_standalone_scrub}}|https://github.com/riptano/cassandra-dtest/blob/4031157a28bbefa068820c757457f340f4b77fa0/scrub_test.py#L391]
 to 
[fail|http://cassci.datastax.com/view/Dev/view/adelapena/job/adelapena-10130-trunk-dtest/lastCompletedBuild/testReport/scrub_test/TestScrubIndexes/test_standalone_scrub/],
 I'm still diving into it.

bq. I'm not sure if we should keep the rebuildFromSSTablesBlocking protected or 
make it public, I can see if being useful to rebuild a subset of the SSTables 
but It's not currently used anywhere, but it could maybe used by extensions.

I think it's a good idea to make it public to allow extensions to use it, and 
it is used in 
[{{CassandraIndexTest#indexCorrectlyMarkedAsBuildAndRemoved}}|https://github.com/adelapena/cassandra/blob/eb0316d651bbdec70896be041ab1981cc9349a18/test/unit/org/apache/cassandra/index/internal/CassandraIndexTest.java#L542].

bq. On a side note, I noticed that [this 
statement|https://github.com/adelapena/cassandra/blob/c5604ffd5ae36cc34d13af6c4c4eadba98458fa3/test/unit/org/apache/cassandra/index/SecondaryIndexManagerTest.java#L369]
 is wrong (missing table name) but it's not throwing exception? Should we 
create a ticket for this?

I think it isn't wrong. The {{%%s}} is transformed into {{%s}} by the first 
{{String#format}}. Then, {{CQLTest#createIndex}} 
[applies|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/CQLTester.java#L650]
 another {{String#format}} call to set the name of the current table.







> Node failure during 2i update after streaming can have incomplete 2i when 
> restarted
> ---
>
> Key: CASSANDRA-10130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10130
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Yuki Morishita
>Assignee: Andrés de la Peña
>Priority: Minor
>
> Since MV/2i update happens after SSTables are received, node failure during 
> MV/2i update can leave received SSTables live when restarted while MV/2i are 
> partially up to date.
> We can add some kind of tracking mechanism to automatically rebuild at the 
> startup, or at least warn user when the node restarts.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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