[jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
[
https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14610860#comment-14610860
]
Aleksey Yeschenko commented on CASSANDRA-9560:
--
Thanks. Pushed to 2.0 as {{3504a50bb4bd93edeb2941dccd9444d53a85a1ed}}, merged
with 2.1, 2.2, and trunk, with two unused methods (from the first iteration)
removed:
- {{Schema.updateKeyspaceInstance()}}
- the private {{Keyspace}} constructor
> Changing durable_writes on a keyspace is only applied after restart of node
> ---
>
> Key: CASSANDRA-9560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Single node
>Reporter: Fred A
>Assignee: Carl Yeksigian
> Fix For: 2.1.x, 2.0.x
>
>
> When mutations for a column family is about to be applied, the cached
> instance of the keyspace metadata is read. But the schema mutation for
> durable_writes hasn't been applied to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's
> somehow related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>Keyspace ks = Keyspace.open(keyspaceName);
> ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't
> been updated with the earlier applied durable_writes mutation, since it seems
> that the cached keyspace instance is lazily build at startup but after that,
> never updated. I'm also a little bit concerned if other values in the cached
> keyspace instance suffers from the same issue, e.g. replication_factor...
> I've seen the same issue in 2.1.5 and the only way to resolve this issue is
> to restart the node to let the keyspace instance cache reload from disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
[
https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14610711#comment-14610711
]
Carl Yeksigian commented on CASSANDRA-9560:
---
Scratch that, a patch isn't necessary for trunk; the changes that [~iamaleksey]
made for CASSANDRA-9677 fix this issue in trunk.
> Changing durable_writes on a keyspace is only applied after restart of node
> ---
>
> Key: CASSANDRA-9560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Single node
>Reporter: Fred A
>Assignee: Carl Yeksigian
> Fix For: 2.1.x, 2.0.x
>
>
> When mutations for a column family is about to be applied, the cached
> instance of the keyspace metadata is read. But the schema mutation for
> durable_writes hasn't been applied to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's
> somehow related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>Keyspace ks = Keyspace.open(keyspaceName);
> ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't
> been updated with the earlier applied durable_writes mutation, since it seems
> that the cached keyspace instance is lazily build at startup but after that,
> never updated. I'm also a little bit concerned if other values in the cached
> keyspace instance suffers from the same issue, e.g. replication_factor...
> I've seen the same issue in 2.1.5 and the only way to resolve this issue is
> to restart the node to let the keyspace instance cache reload from disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
[
https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14610671#comment-14610671
]
Carl Yeksigian commented on CASSANDRA-9560:
---
I've just posted a rebased trunk patch and cassci is running the trunk tests
again now.
> Changing durable_writes on a keyspace is only applied after restart of node
> ---
>
> Key: CASSANDRA-9560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Single node
>Reporter: Fred A
>Assignee: Carl Yeksigian
> Fix For: 2.1.x, 2.0.x
>
>
> When mutations for a column family is about to be applied, the cached
> instance of the keyspace metadata is read. But the schema mutation for
> durable_writes hasn't been applied to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's
> somehow related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>Keyspace ks = Keyspace.open(keyspaceName);
> ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't
> been updated with the earlier applied durable_writes mutation, since it seems
> that the cached keyspace instance is lazily build at startup but after that,
> never updated. I'm also a little bit concerned if other values in the cached
> keyspace instance suffers from the same issue, e.g. replication_factor...
> I've seen the same issue in 2.1.5 and the only way to resolve this issue is
> to restart the node to let the keyspace instance cache reload from disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
[
https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608587#comment-14608587
]
Aleksey Yeschenko commented on CASSANDRA-9560:
--
[~carlyeks] Can you please rebase the 3.0 patch on current trunk? Thanks.
> Changing durable_writes on a keyspace is only applied after restart of node
> ---
>
> Key: CASSANDRA-9560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Single node
>Reporter: Fred A
>Assignee: Carl Yeksigian
> Fix For: 2.1.x, 2.0.x
>
>
> When mutations for a column family is about to be applied, the cached
> instance of the keyspace metadata is read. But the schema mutation for
> durable_writes hasn't been applied to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's
> somehow related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>Keyspace ks = Keyspace.open(keyspaceName);
> ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't
> been updated with the earlier applied durable_writes mutation, since it seems
> that the cached keyspace instance is lazily build at startup but after that,
> never updated. I'm also a little bit concerned if other values in the cached
> keyspace instance suffers from the same issue, e.g. replication_factor...
> I've seen the same issue in 2.1.5 and the only way to resolve this issue is
> to restart the node to let the keyspace instance cache reload from disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
[
https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14606374#comment-14606374
]
Carl Yeksigian commented on CASSANDRA-9560:
---
After Aleksey has reviewed and is satisfied with the patch, he'll commit it and
this bug will be resolved as fixed. Then it will be set to be included in the
next release.
> Changing durable_writes on a keyspace is only applied after restart of node
> ---
>
> Key: CASSANDRA-9560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Single node
>Reporter: Fred A
>Assignee: Carl Yeksigian
> Fix For: 2.1.x, 2.0.x
>
>
> When mutations for a column family is about to be applied, the cached
> instance of the keyspace metadata is read. But the schema mutation for
> durable_writes hasn't been applied to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's
> somehow related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>Keyspace ks = Keyspace.open(keyspaceName);
> ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't
> been updated with the earlier applied durable_writes mutation, since it seems
> that the cached keyspace instance is lazily build at startup but after that,
> never updated. I'm also a little bit concerned if other values in the cached
> keyspace instance suffers from the same issue, e.g. replication_factor...
> I've seen the same issue in 2.1.5 and the only way to resolve this issue is
> to restart the node to let the keyspace instance cache reload from disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
[
https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14606366#comment-14606366
]
Fred A commented on CASSANDRA-9560:
---
Thank you, sounds good. I'm not familiar with Cassandra bug fix procedures but
when will the resolution for this Jira become "fixed"? Is that after the
reviewer is satisfied with the patch, or?
> Changing durable_writes on a keyspace is only applied after restart of node
> ---
>
> Key: CASSANDRA-9560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Single node
>Reporter: Fred A
>Assignee: Carl Yeksigian
> Fix For: 2.1.x, 2.0.x
>
>
> When mutations for a column family is about to be applied, the cached
> instance of the keyspace metadata is read. But the schema mutation for
> durable_writes hasn't been applied to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's
> somehow related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>Keyspace ks = Keyspace.open(keyspaceName);
> ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't
> been updated with the earlier applied durable_writes mutation, since it seems
> that the cached keyspace instance is lazily build at startup but after that,
> never updated. I'm also a little bit concerned if other values in the cached
> keyspace instance suffers from the same issue, e.g. replication_factor...
> I've seen the same issue in 2.1.5 and the only way to resolve this issue is
> to restart the node to let the keyspace instance cache reload from disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
[
https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14606114#comment-14606114
]
Carl Yeksigian commented on CASSANDRA-9560:
---
The [initial 2.1
branch|https://github.com/carlyeks/cassandra/tree/ticket/9560/2.1] can be
applied to the 2.1 branch if you want to build it yourself. This will hopefully
get into a 2.1.8 release since we just had the 2.1.7 release.
> Changing durable_writes on a keyspace is only applied after restart of node
> ---
>
> Key: CASSANDRA-9560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Single node
>Reporter: Fred A
>Assignee: Carl Yeksigian
> Fix For: 2.1.x, 2.0.x
>
>
> When mutations for a column family is about to be applied, the cached
> instance of the keyspace metadata is read. But the schema mutation for
> durable_writes hasn't been applied to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's
> somehow related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>Keyspace ks = Keyspace.open(keyspaceName);
> ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't
> been updated with the earlier applied durable_writes mutation, since it seems
> that the cached keyspace instance is lazily build at startup but after that,
> never updated. I'm also a little bit concerned if other values in the cached
> keyspace instance suffers from the same issue, e.g. replication_factor...
> I've seen the same issue in 2.1.5 and the only way to resolve this issue is
> to restart the node to let the keyspace instance cache reload from disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
[
https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14606090#comment-14606090
]
Fred A commented on CASSANDRA-9560:
---
Is it possible to apply this patch to 2.1 or will this fix be included in
2.1.8? I guess fix version for this Jira should also be 2.1.x?
> Changing durable_writes on a keyspace is only applied after restart of node
> ---
>
> Key: CASSANDRA-9560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Single node
>Reporter: Fred A
>Assignee: Carl Yeksigian
> Fix For: 2.0.x
>
>
> When mutations for a column family is about to be applied, the cached
> instance of the keyspace metadata is read. But the schema mutation for
> durable_writes hasn't been applied to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's
> somehow related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>Keyspace ks = Keyspace.open(keyspaceName);
> ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't
> been updated with the earlier applied durable_writes mutation, since it seems
> that the cached keyspace instance is lazily build at startup but after that,
> never updated. I'm also a little bit concerned if other values in the cached
> keyspace instance suffers from the same issue, e.g. replication_factor...
> I've seen the same issue in 2.1.5 and the only way to resolve this issue is
> to restart the node to let the keyspace instance cache reload from disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
[
https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14599665#comment-14599665
]
Carl Yeksigian commented on CASSANDRA-9560:
---
Just pushed a new version to the 2.1/2.2 branches which updates the
{{Keyspace}}'s metadata in place; here's the [2.0
branch|https://github.com/carlyeks/cassandra/tree/ticket/9560/2.0].
> Changing durable_writes on a keyspace is only applied after restart of node
> ---
>
> Key: CASSANDRA-9560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Single node
>Reporter: Fred A
>Assignee: Carl Yeksigian
> Fix For: 2.0.x
>
>
> When mutations for a column family is about to be applied, the cached
> instance of the keyspace metadata is read. But the schema mutation for
> durable_writes hasn't been applied to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's
> somehow related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>Keyspace ks = Keyspace.open(keyspaceName);
> ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't
> been updated with the earlier applied durable_writes mutation, since it seems
> that the cached keyspace instance is lazily build at startup but after that,
> never updated. I'm also a little bit concerned if other values in the cached
> keyspace instance suffers from the same issue, e.g. replication_factor...
> I've seen the same issue in 2.1.5 and the only way to resolve this issue is
> to restart the node to let the keyspace instance cache reload from disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
[
https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14599587#comment-14599587
]
Fred A commented on CASSANDRA-9560:
---
Could this also affect updating the replication factor? It seems like changing
replication factor somehow works anyway.
> Changing durable_writes on a keyspace is only applied after restart of node
> ---
>
> Key: CASSANDRA-9560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Single node
>Reporter: Fred A
>Assignee: Carl Yeksigian
> Fix For: 2.1.x
>
>
> When mutations for a column family is about to be applied, the cached
> instance of the keyspace metadata is read. But the schema mutation for
> durable_writes hasn't been applied to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's
> somehow related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>Keyspace ks = Keyspace.open(keyspaceName);
> ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't
> been updated with the earlier applied durable_writes mutation, since it seems
> that the cached keyspace instance is lazily build at startup but after that,
> never updated. I'm also a little bit concerned if other values in the cached
> keyspace instance suffers from the same issue, e.g. replication_factor...
> I've seen the same issue in 2.1.5 and the only way to resolve this issue is
> to restart the node to let the keyspace instance cache reload from disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
[
https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14599597#comment-14599597
]
Carl Yeksigian commented on CASSANDRA-9560:
---
The replication strategy was stored in the {{Keyspace}} object and was being
updated properly before. This change will update the {{KSMetaData}} stored in
{{Keyspace}} as well.
> Changing durable_writes on a keyspace is only applied after restart of node
> ---
>
> Key: CASSANDRA-9560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Single node
>Reporter: Fred A
>Assignee: Carl Yeksigian
> Fix For: 2.1.x
>
>
> When mutations for a column family is about to be applied, the cached
> instance of the keyspace metadata is read. But the schema mutation for
> durable_writes hasn't been applied to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's
> somehow related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>Keyspace ks = Keyspace.open(keyspaceName);
> ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't
> been updated with the earlier applied durable_writes mutation, since it seems
> that the cached keyspace instance is lazily build at startup but after that,
> never updated. I'm also a little bit concerned if other values in the cached
> keyspace instance suffers from the same issue, e.g. replication_factor...
> I've seen the same issue in 2.1.5 and the only way to resolve this issue is
> to restart the node to let the keyspace instance cache reload from disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
[
https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14599567#comment-14599567
]
Aleksey Yeschenko commented on CASSANDRA-9560:
--
References to {{Keyspace}} are hoisted all over the place (most obviously in
{{ColumnFamilyStore}}), so unfortunately it's not possible to just swap the
{{Keyspace}} instance with an updated one. We must update the reference to
{{KSMetaData}} in {{Keyspace}} in place.
Also, a patch for 2.0 would be handy - we'll likely have one more release, and
this is a relatively serious issue.
> Changing durable_writes on a keyspace is only applied after restart of node
> ---
>
> Key: CASSANDRA-9560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Single node
>Reporter: Fred A
>Assignee: Carl Yeksigian
> Fix For: 2.1.x
>
>
> When mutations for a column family is about to be applied, the cached
> instance of the keyspace metadata is read. But the schema mutation for
> durable_writes hasn't been applied to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's
> somehow related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>Keyspace ks = Keyspace.open(keyspaceName);
> ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't
> been updated with the earlier applied durable_writes mutation, since it seems
> that the cached keyspace instance is lazily build at startup but after that,
> never updated. I'm also a little bit concerned if other values in the cached
> keyspace instance suffers from the same issue, e.g. replication_factor...
> I've seen the same issue in 2.1.5 and the only way to resolve this issue is
> to restart the node to let the keyspace instance cache reload from disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
[
https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14599510#comment-14599510
]
Carl Yeksigian commented on CASSANDRA-9560:
---
Yes, it should be safe to apply; I've tested it locally and it does what's
expected.
> Changing durable_writes on a keyspace is only applied after restart of node
> ---
>
> Key: CASSANDRA-9560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Single node
>Reporter: Fred A
>Assignee: Carl Yeksigian
> Fix For: 2.1.x
>
>
> When mutations for a column family is about to be applied, the cached
> instance of the keyspace metadata is read. But the schema mutation for
> durable_writes hasn't been applied to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's
> somehow related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>Keyspace ks = Keyspace.open(keyspaceName);
> ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't
> been updated with the earlier applied durable_writes mutation, since it seems
> that the cached keyspace instance is lazily build at startup but after that,
> never updated. I'm also a little bit concerned if other values in the cached
> keyspace instance suffers from the same issue, e.g. replication_factor...
> I've seen the same issue in 2.1.5 and the only way to resolve this issue is
> to restart the node to let the keyspace instance cache reload from disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
[
https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14599369#comment-14599369
]
Fred A commented on CASSANDRA-9560:
---
Is this patch safe to apply?
> Changing durable_writes on a keyspace is only applied after restart of node
> ---
>
> Key: CASSANDRA-9560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Single node
>Reporter: Fred A
>Assignee: Carl Yeksigian
> Fix For: 2.1.x
>
>
> When mutations for a column family is about to be applied, the cached
> instance of the keyspace metadata is read. But the schema mutation for
> durable_writes hasn't been applied to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's
> somehow related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>Keyspace ks = Keyspace.open(keyspaceName);
> ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't
> been updated with the earlier applied durable_writes mutation, since it seems
> that the cached keyspace instance is lazily build at startup but after that,
> never updated. I'm also a little bit concerned if other values in the cached
> keyspace instance suffers from the same issue, e.g. replication_factor...
> I've seen the same issue in 2.1.5 and the only way to resolve this issue is
> to restart the node to let the keyspace instance cache reload from disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
[
https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14587505#comment-14587505
]
Fred commented on CASSANDRA-9560:
-
Any news about this one?
> Changing durable_writes on a keyspace is only applied after restart of node
> ---
>
> Key: CASSANDRA-9560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Single node
>Reporter: Fred
>Assignee: Carl Yeksigian
> Fix For: 2.1.x
>
>
> When mutations for a column family is about to be applied, the cached
> instance of the keyspace metadata is read. But the schema mutation for
> durable_writes hasn't been applied to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's
> somehow related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>Keyspace ks = Keyspace.open(keyspaceName);
> ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't
> been updated with the earlier applied durable_writes mutation, since it seems
> that the cached keyspace instance is lazily build at startup but after that,
> never updated. I'm also a little bit concerned if other values in the cached
> keyspace instance suffers from the same issue, e.g. replication_factor...
> I've seen the same issue in 2.1.5 and the only way to resolve this issue is
> to restart the node to let the keyspace instance cache reload from disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
[
https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14580538#comment-14580538
]
Jim Witschey commented on CASSANDRA-9560:
-
We've reproduced the behavior
[here|https://github.com/riptano/cassandra-dtest/commit/ce417ff9f74305260ca1fd75b8f4e2296a865135]
and merged the test into dtest.
> Changing durable_writes on a keyspace is only applied after restart of node
> ---
>
> Key: CASSANDRA-9560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Single node
>Reporter: Fred
> Fix For: 2.1.x
>
>
> When mutations for a column family is about to be applied, the cached
> instance of the keyspace metadata is read. But the schema mutation for
> durable_writes hasn't been applied to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's
> somehow related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>Keyspace ks = Keyspace.open(keyspaceName);
> ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't
> been updated with the earlier applied durable_writes mutation, since it seems
> that the cached keyspace instance is lazily build at startup but after that,
> never updated. I'm also a little bit concerned if other values in the cached
> keyspace instance suffers from the same issue, e.g. replication_factor...
> I've seen the same issue in 2.1.5 and the only way to resolve this issue is
> to restart the node to let the keyspace instance cache reload from disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
[
https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14578864#comment-14578864
]
Fred commented on CASSANDRA-9560:
-
Thx, that's great.
FYI I used cassandra-cli and thrift to update the keyspace for durable writes.
It's strange because when you describe the keyspace from cassandra-cli it looks
like durable_writes are disabled but I've got confused when I saw alot of disk
i/o on commitlog files despite setting durable_writes to false.
Would be great with a patch if that's possible.
> Changing durable_writes on a keyspace is only applied after restart of node
> ---
>
> Key: CASSANDRA-9560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Single node
>Reporter: Fred
> Fix For: 2.1.x
>
>
> When mutations for a column family is about to be applied, the cached
> instance of the keyspace metadata is read. But the schema mutation for
> durable_writes hasn't been applied to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's
> somehow related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>Keyspace ks = Keyspace.open(keyspaceName);
> ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't
> been updated with the earlier applied durable_writes mutation, since it seems
> that the cached keyspace instance is lazily build at startup but after that,
> never updated. I'm also a little bit concerned if other values in the cached
> keyspace instance suffers from the same issue, e.g. replication_factor...
> I've seen the same issue in 2.1.5 and the only way to resolve this issue is
> to restart the node to let the keyspace instance cache reload from disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
[
https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14578828#comment-14578828
]
Philip Thompson commented on CASSANDRA-9560:
[~Fredderf], just an update, we're working on writing some test cases that
reproduce the issue.
> Changing durable_writes on a keyspace is only applied after restart of node
> ---
>
> Key: CASSANDRA-9560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Single node
>Reporter: Fred
> Fix For: 2.1.x
>
>
> When mutations for a column family is about to be applied, the cached
> instance of the keyspace metadata is read. But the schema mutation for
> durable_writes hasn't been applied to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's
> somehow related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>Keyspace ks = Keyspace.open(keyspaceName);
> ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't
> been updated with the earlier applied durable_writes mutation, since it seems
> that the cached keyspace instance is lazily build at startup but after that,
> never updated. I'm also a little bit concerned if other values in the cached
> keyspace instance suffers from the same issue, e.g. replication_factor...
> I've seen the same issue in 2.1.5 and the only way to resolve this issue is
> to restart the node to let the keyspace instance cache reload from disk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
