[
https://issues.apache.org/jira/browse/HBASE-22985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925993#comment-16925993
]
Sean Busbey commented on HBASE-22985:
-------------------------------------
{quote}
bq. Why catch just this instance of a ServiceLoader issue and not others?
Didn't want to open a pandora's box of other things that might go wrong. Was
there something else in particular you had in mind?
{quote}
Just that I don't think this is the only place we use ServiceLoader. i.e. we
use it for security tokens and for the hadoop compatibility stuff.
It'll be surprising in an operational context if I can safely configure garbage
for the metrics system but not others.
> Gracefully handle invalid ServiceLoader entries
> -----------------------------------------------
>
> Key: HBASE-22985
> URL: https://issues.apache.org/jira/browse/HBASE-22985
> Project: HBase
> Issue Type: Bug
> Components: metrics
> Reporter: Josh Elser
> Assignee: Josh Elser
> Priority: Minor
> Attachments: HBASE-22985.001.patch, HBASE-22985.002.patch
>
>
> Just saw this happen: A RegionServer failed to start because, on the
> classpath, there was a {{META-INF/services}} entry in a JAR on the classpath
> that was advertising an implementation of
> {{org.apache.hadoop.hbase.metrics.MetricsRegistries}} but was an
> implementation of a completely different class:
> {noformat}
> Caused by: java.util.ServiceConfigurationError:
> org.apache.hadoop.hbase.metrics.MetricRegistries: Provider
> org.apache.ratis.metrics.impl.MetricRegistriesImpl not a subtype
> at java.util.ServiceLoader.fail(ServiceLoader.java:239)
> at java.util.ServiceLoader.access$300(ServiceLoader.java:185)
> at
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:376)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> at
> org.apache.hadoop.hbase.metrics.MetricRegistriesLoader.getDefinedImplemantations(MetricRegistriesLoader.java:92)
> at
> org.apache.hadoop.hbase.metrics.MetricRegistriesLoader.load(MetricRegistriesLoader.java:50)
> at
> org.apache.hadoop.hbase.metrics.MetricRegistries$LazyHolder.<clinit>(MetricRegistries.java:39)
> at
> org.apache.hadoop.hbase.metrics.MetricRegistries.global(MetricRegistries.java:47)
> at
> org.apache.hadoop.hbase.metrics.BaseSourceImpl.<init>(BaseSourceImpl.java:122)
> at
> org.apache.hadoop.hbase.io.MetricsIOSourceImpl.<init>(MetricsIOSourceImpl.java:46)
> at
> org.apache.hadoop.hbase.io.MetricsIOSourceImpl.<init>(MetricsIOSourceImpl.java:38)
> at
> org.apache.hadoop.hbase.regionserver.MetricsRegionServerSourceFactoryImpl.createIO(MetricsRegionServerSourceFactoryImpl.java:84)
> at org.apache.hadoop.hbase.io.MetricsIO.<init>(MetricsIO.java:35)
> at org.apache.hadoop.hbase.io.hfile.HFile.<clinit>(HFile.java:195)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.<init>(HRegionServer.java:570)
> ... 10 more{noformat}
> Now, we could catch this and gracefully ignore it; however, this would mean
> that we're catching an Error which is typically considered a smell.
> It's a pretty straightforward change, so I'm apt to think that it's OK. What
> do other folks think?
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
