[
https://issues.apache.org/jira/browse/CASSANDRA-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14640602#comment-14640602
]
Benedict edited comment on CASSANDRA-6477 at 7/24/15 3:37 PM:
--------------------------------------------------------------
OK, so we have deadlock in that case. The apply of the batchlog happens on a
separate writeOrder group. The earlier group could be marked as "blocking" in
which case it is permitted to take any necessary action to terminate, but a
later (or even simply different keyspace) group is _not_ marked blocking and we
depend on it, then the system will lock up.
We could also do with some comments around things like:
{code}
if (stage != Stage.MATERIALIZED_VIEW_MUTATION)
{
for (WriteResponseHandlerWrapper wrapper : wrappers)
wrapper.handler.get();
}
{code}
Without any context, it's kind of hard to spot let alone understand the
important semantic difference and why it is there.
In general, I'd prefer more comments around this feature.
was (Author: benedict):
OK, so we have deadlock in that case. The apply of the batchlog happens on a
separate writeOrder group. The earlier group could be marked as "blocking" in
which case it is permitted to take any necessary action to terminate, but a
later (or even simply different keyspace) group is _not_ marked blocking and we
depend on it, then the system will lock up. In fact, we have this twice: once
for batchlog, once for the MV mutation (if local).
We could also do with some comments around things like:
{code}
if (stage != Stage.MATERIALIZED_VIEW_MUTATION)
{
for (WriteResponseHandlerWrapper wrapper : wrappers)
wrapper.handler.get();
}
{code}
Without any context, it's kind of hard to spot let alone understand the
important semantic difference and why it is there.
In general, I'd prefer more comments around this feature.
> Materialized Views (was: Global Indexes)
> ----------------------------------------
>
> Key: CASSANDRA-6477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6477
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
> Reporter: Jonathan Ellis
> Assignee: Carl Yeksigian
> Labels: cql
> Fix For: 3.0 beta 1
>
> Attachments: test-view-data.sh, users.yaml
>
>
> Local indexes are suitable for low-cardinality data, where spreading the
> index across the cluster is a Good Thing. However, for high-cardinality
> data, local indexes require querying most nodes in the cluster even if only a
> handful of rows is returned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
