[
https://issues.apache.org/jira/browse/CASSANDRA-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16015087#comment-16015087
]
Lerh Chuan Low commented on CASSANDRA-13346:
--------------------------------------------
Hi Chris,
Looking into it a little bit more, this is another way to do it - just retain
enough information in {{allTableMetrics}} so we know what metrics are held by
which CF. Or, at least, we can iterate through it to find the metrics that are
held for a particular CF, and release all of them. In this case, the changes
will look something like this:
https://github.com/apache/cassandra/compare/trunk...juiceblender:cassandra-13346
Then {{allTableMetrics}} becomes something we keep in sync with the
{{MetricsRegistry}}. In fact it's more or less identical or isomorphic to
{{MetricsRegistry}}. Just with the way we currently register metrics, we use
this method:
{code}
public String getMetricName()
{
return MetricRegistry.name(group, type, name, scope);
}
{code}
which adds a {{.}} in between each value.
So that eventually, an entry in my branch's {{allTableMetrics}} looks like so:
{{org.apache.cassandra.metrics:type=Table,keyspace=system_distributed,scope=repair_history,name=TotalDiskSpaceUsed
-> The actual metric}}
While {{Metrics.getMetrics()}} looks like so:
{{org.apache.cassandra.metrics.Table.BloomFilterFalsePositives.system.built_views
-> The actual metric}}
>From here, there are a few options forward:
i) We stick with the original patch
ii) We go ahead with what's in the branch, the dtest still works for it.
iii) We totally get rid of {{allTableMetrics}} and just use the existing
{{MetricsRegistry}}. To make it really safe for the aggregating metrics, I feel
we would need some way to construct (or parse) a {{MetricName}} object from the
String returned from {{Metrics.getMetrics()}} (It's a Map<String, Metric>
unfortunately). In this case we will have to iterate over every metric that we
ever registered compared to just the table metrics in {{allTableMetrics}}, but
it should be relatively fine because we don't release metrics often
iv) We try and have each CFStore keep a local copy of its TableMetric. When
constructing TableMetric for a CFStore, we will have to get a list of CFStores
(I would need some guidance on this, from a viewManager somewhere?) and get all
their respective gauges and aggregate them that way. Something like iii).
I'm for either i) or iii), any thoughts?
> Failed unregistering mbean during drop keyspace
> -----------------------------------------------
>
> Key: CASSANDRA-13346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13346
> Project: Cassandra
> Issue Type: Bug
> Components: Materialized Views
> Environment: Cassandra 3.9
> Reporter: Gábor Auth
> Assignee: Lerh Chuan Low
> Priority: Minor
> Labels: lhf
> Fix For: 3.0.x, 3.11.x
>
> Attachments: 13346-3.0.X.txt, 13346-3.X.txt
>
>
> All node throw exceptions about materialized views during drop keyspace:
> {code}
> WARN [MigrationStage:1] 2017-03-16 16:54:25,016 ColumnFamilyStore.java:535 -
> Failed unregistering mbean:
> org.apache.cassandra.db:type=Tables,keyspace=test20160810,table=unit_by_account
> java.lang.NullPointerException: null
> at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
> ~[na:1.8.0_121]
> at
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> ~[na:1.8.0_121]
> at
> java.util.concurrent.ConcurrentHashMap$KeySetView.remove(ConcurrentHashMap.java:4569)
> ~[na:1.8.0_121]
> at
> org.apache.cassandra.metrics.TableMetrics.release(TableMetrics.java:712)
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at
> org.apache.cassandra.db.ColumnFamilyStore.unregisterMBean(ColumnFamilyStore.java:570)
> [apache-cassandra-3.9.0.jar:3.9.0]
> at
> org.apache.cassandra.db.ColumnFamilyStore.invalidate(ColumnFamilyStore.java:527)
> [apache-cassandra-3.9.0.jar:3.9.0]
> at
> org.apache.cassandra.db.ColumnFamilyStore.invalidate(ColumnFamilyStore.java:517)
> [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.db.Keyspace.unloadCf(Keyspace.java:365)
> [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.db.Keyspace.dropCf(Keyspace.java:358)
> [apache-cassandra-3.9.0.jar:3.9.0]
> at org.apache.cassandra.config.Schema.dropView(Schema.java:744)
> [apache-cassandra-3.9.0.jar:3.9.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.lambda$mergeSchema$373(SchemaKeyspace.java:1287)
> [apache-cassandra-3.9.0.jar:3.9.0]
> at java.lang.Iterable.forEach(Iterable.java:75) ~[na:1.8.0_121]
> at
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1287)
> [apache-cassandra-3.9.0.jar:3.9.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1256)
> [apache-cassandra-3.9.0.jar:3.9.0]
> at
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:51)
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_121]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_121]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_121]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> ~[na:1.8.0_121]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
