[ 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org