[
https://issues.apache.org/jira/browse/HBASE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15836720#comment-15836720
]
Sean Busbey commented on HBASE-12894:
-------------------------------------
{quote}
bq. Possible doublecheck on
org.apache.hadoop.hbase.rest.model.ScannerModel.jsonProvider in
org.apache.hadoop.hbase.rest.model.ScannerModel.getJasonProvider()
It is done that way intentionally to use double checked locking to lazy
initialize the instance.
{quote}
The check as done here is incorrect:
{code}
+ // The singleton <code>JacksonJaxbJsonProvider</code> instance
+ private static JacksonJaxbJsonProvider jsonProvider;
+ private static final Object jsonProviderLock = new Object();
+
+ /**
+ * Get the <code>JacksonJaxbJsonProvider</code> instance;
+ *
+ * @return A <code>JacksonJaxbJsonProvider</code>.
+ */
+ @edu.umd.cs.findbugs.annotations.SuppressWarnings(value="DC",
+ justification="Intentional. Done this way to allow lazy init. See
HBASE-12894")
+ private static JacksonJaxbJsonProvider getJasonProvider() {
+ if (jsonProvider == null) {
+ synchronized (jsonProviderLock) {
+ if (jsonProvider == null) {
+ jsonProvider = new JacksonJaxbJsonProvider();
+ }
+ }
+ }
+ return jsonProvider;
+ }
{code}
You have to make {{jsonProvider}} {{volatile}} in order for this double
checking to work. Otherwise another reader of jsonProvider might use it while
it isn't fully initialized. You should also copy it to a local variable before
checking it, so that you don't have to read the volatile variable twice on the
happy path. (without these two things we have the common antipattern version,
see the [Java Concurrency In Practice code
listings|http://jcip.net.s3-website-us-east-1.amazonaws.com/listings.html],
specifically #16.7
Overall, I believe the preferred approach for doing lazy initialization of a
singleton is to use the "lazy initialization holder class idiom", where you
create an inner class that contains the final static variable. That way you can
safely reference it and the first time it's referenced is when the inner class
and the member will be initialized.
this blog has a decent overview and a microbenchmark:
http://literatejava.com/jvm/fastest-threadsafe-singleton-jvm/
> Upgrade Jetty to 9.2.6
> ----------------------
>
> Key: HBASE-12894
> URL: https://issues.apache.org/jira/browse/HBASE-12894
> Project: HBase
> Issue Type: Improvement
> Components: REST, UI
> Affects Versions: 0.98.0
> Reporter: Rick Hallihan
> Assignee: Guang Yang
> Priority: Critical
> Labels: MicrosoftSupport
> Fix For: 2.0.0
>
> Attachments: dependency_list_after, dependency_list_before,
> HBASE-12894_Jetty9_v0.patch, HBASE-12894_Jetty9_v10.patch,
> HBASE-12894_Jetty9_v1.patch, HBASE-12894_Jetty9_v1.patch,
> HBASE-12894_Jetty9_v2.patch, HBASE-12894_Jetty9_v3.patch,
> HBASE-12894_Jetty9_v4.patch, HBASE-12894_Jetty9_v5.patch,
> HBASE-12894_Jetty9_v6.patch, HBASE-12894_Jetty9_v7.patch,
> HBASE-12894_Jetty9_v8.patch, HBASE-12894.master.001.patch,
> HBASE-12894.master.002.patch, HBASE-12894.master.003.patch,
> HBASE-12894.master.004.patch, HBASE-12894.master.004.patch
>
>
> The Jetty component that is used for the HBase Stargate REST endpoint is
> version 6.1.26 and is fairly outdated. We recently had a customer inquire
> about enabling cross-origin resource sharing (CORS) for the REST endpoint and
> found that this older version does not include the necessary filter or
> configuration options, highlighted at:
> http://wiki.eclipse.org/Jetty/Feature/Cross_Origin_Filter
> The Jetty project has had significant updates through versions 7, 8 and 9,
> including a transition to be an Eclipse subproject, so updating to the latest
> version may be non-trivial. The last update to the Jetty component in
> https://issues.apache.org/jira/browse/HBASE-3377 was a minor version update
> and did not require significant work. This update will include a package
> namespace update so there will likely be a larger number of required changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
