[
https://issues.apache.org/jira/browse/HBASE-19920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16365980#comment-16365980
]
Mike Drob commented on HBASE-19920:
-----------------------------------
bq. my intuition is telling me that the two ProtobufUtils should be sharing a
common place for it though
Probably. There's a TODO at the top of one to generate it from the other, I'd
rather leave it until then.
bq. Is there a reason we can't just hide the holder behind something like
DynamicClassloader.getInstance()?
Not all DCLs are created the same. There's one in RemoteWithExtrasException too
that I will update to use this same lazy pattern though.
{quote}
So long as you're changing this up to do lazy init, should we also clean up how
we init?
HBC.create can throw (like if the xml config version is off from library). do
we want that to propagate or should we do a try/catch to set CLASS_LOADER to
null? AFAICT the use of CLASS_LOADER would then default to the bootstrap
classloader, which is probably correct.
Also HBC.create expressly sets the classloader for the Configuration to be
whatever classloader was used to make the HBaseConfiguration instance. Should
it be created with parent?
{quote}
Probably better to do in a follow on?
bq. This feels wrong. I think this variable needs to be volatile or
AtomicBoolean? It doesn't have the same guarantees about visibility since it's
not within the holder, right?
It works currently because it's only accessed by a single thread, but can make
it volatile for future proofing, sure.
bq. Given that, why not also make the fault injection private and/or final and
then use reflection in the test to allow changing it in the test?
private, sure, we can call setAccessible via the reflection. final, i'd rather
not have to deal with manually removing flags though and I don't see much
benefit.
bq. Should specifically check that it's the injected ServiceException. I guess
by text of the message?
can make this explicit setting exception instead of boolean
> TokenUtil.obtainToken unnecessarily creates a local directory
> -------------------------------------------------------------
>
> Key: HBASE-19920
> URL: https://issues.apache.org/jira/browse/HBASE-19920
> Project: HBase
> Issue Type: Bug
> Reporter: Rohini Palaniswamy
> Assignee: Mike Drob
> Priority: Major
> Fix For: 2.0
>
> Attachments: HBASE-19920.patch, HBASE-19920.v2.patch,
> HBASE-19920.v3.patch, HBASE-19920.v4.patch, HBASE-19920.v5.patch,
> HBASE-19920.v6.patch, HBASE-19920.v7.patch, HBASE-19920.v8.patch
>
>
> On client code, when one calls TokenUtil.obtainToken it loads ProtobufUtil
> which in its static block initializes DynamicClassLoader and that creates the
> directory ${hbase.local.dir}/jars/ and also instantiates a filesystem class
> to access hbase.dynamic.jars.dir.
> https://github.com/apache/hbase/blob/master/hbase-common/src/main/java/org/apache/hadoop/hbase/util/DynamicClassLoader.java#L109-L127
> Since this is region server specific code, not expecting this to happen when
> one accesses hbase as a client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
