[
https://issues.apache.org/jira/browse/ABDERA-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596105#action_12596105
]
James M Snell commented on ABDERA-155:
--------------------------------------
We should be able to deal with this by using lazy initialization of the various
fields in Abdera. The only reason we init those early is to move up some of
the initialization load. Using lazy init's, we won't need to require any api
chages.
> Abdera class "this" reference escapes during construction, leading to race
> conditions and NPEs
> ----------------------------------------------------------------------------------------------
>
> Key: ABDERA-155
> URL: https://issues.apache.org/jira/browse/ABDERA-155
> Project: Abdera
> Issue Type: Bug
> Affects Versions: 0.4.0
> Environment: OS X, JVM 1.5, 2 x 2.8 GHz quad-core Xeon
> Reporter: Todd Wells
> Priority: Critical
> Attachments: abdera_singleton.diff
>
>
> I have hit a number of NullPointerExceptions when using Abdera in a very
> generic and straightforward fashion. The same code doesn't cause the NPEs in
> all cases, it seems to depend on the environment in which it's executing,
> which leads to a strong suspicion of a race condition. I've seen an NPE in
> code as simple as this groovy code:
> def abdera = new Abdera()
> Entry entry = abdera.newEntry() /* NPE here, Caused by:
> java.lang.NullPointerException at
> org.apache.abdera.Abdera.newEntry(Abdera.java:114)
> Another example was an NPE when calling ClientResponse.getDocument(), Caused
> by: java.lang.NullPointerException at
> org.apache.abdera.protocol.client.AbstractClientResponse.getDocument(AbstractClientResponse.java:96)
> When I run the code in IDEA (calling from a unit test or executing a custom
> ant task) it works fine. When I'm calling it from inside of a custom ant task
> running at the command line, I get the null pointer exceptions that I've
> described. This supports the notion of it being a race condition -- the
> NPE's are highly squirrelly and environment-specific.
> Digging into the Abdera code, I believe I've found the source of the
> problems. The constructor of the Abdera class calls newFactory(),
> newParser(), newXPath(), newParserFactory() and newWriter(). In every one of
> these methods, a reference to "this" is passed to a different class (or
> multiple classes, as it would appear). The fundamental problem here is since
> this code is being called from the constructor the "this" reference is not
> yet guaranteed to be a completely constructed object. This can result in
> unpredictable behavior, such as the NPE mentioned in this bug. Since the
> classes (ServiceUtil and AbderaConfiguration) that get references to "this"
> appear to be using "this" in a multi-threaded fashion, this can result in
> race conditions.
> For a detailed discussion, I recommend reviewing this article "Safe
> construction techniques" by Brian Goetz:
> http://www.ibm.com/developerworks/java/library/j-jtp0618.html, or he has a
> more detailed discussion of this problem in his book "Java Concurrency in
> Practice". I will quote his article here: "One of the mistakes that can
> introduce a data race into your class is to expose the this reference to
> another thread before the constructor has completed. Sometimes the reference
> is explicit, such as directly storing this in a static field or collection,
> but other times it can be implicit, such as when you publish a reference to
> an instance of a non-static inner class in a constructor. Constructors are
> not ordinary methods -- they have special semantics for initialization
> safety. An object is assumed to be in a predictable, consistent state after
> the constructor has completed, and publishing a reference to an incompletely
> constructed object is dangerous."
> This is a serious set of bugs in the Abdera class and the resultant problems
> will probably become more prevalent as machines become faster.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
