[ 
https://issues.apache.org/jira/browse/OFBIZ-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adrian Crum closed OFBIZ-5204.
------------------------------

       Resolution: Fixed
    Fix Version/s: Release Branch 13.07
                   SVN trunk

> Concurrent access to GenericEngineFactory causes exceptions
> -----------------------------------------------------------
>
>                 Key: OFBIZ-5204
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-5204
>             Project: OFBiz
>          Issue Type: Bug
>          Components: framework
>    Affects Versions: SVN trunk
>            Reporter: Christoph Neuroth
>            Priority: Critical
>             Fix For: SVN trunk, Release Branch 13.07
>
>         Attachments: GenericEngineFactoryTests.java, 
> OFBIZ-5204-2013-05-31.patch, OFBIZ-5204-2013-05-31.patch, 
> OFBIZ-5204-2013-06-04.patch, ofbiz-serviceengine.patch
>
>
> Several users (see e.g. OFBIZ-2807, OFBIZ-2793) have reported sometimes 
> getting the following exception, especially during startup or after clearing 
> the cache:
> {quote}Cannot find a service engine definition for the engine name [" + 
> engineName + "] in the serviceengine.xml file{quote}
> By including some debug logging we found that when this happens, one or more 
> of the nodes in the DOM lose attribute values, so for example this node from 
> the serviceengine.xml file:
> {code}<engine name="java" 
> class="org.ofbiz.service.engine.StandardJavaEngine"/>{code}
> might look like this to the calling code:
> {code}<engine name="java" class=""/>{code}
> As usual with multi-threading problems this occurs very randomly and depends 
> on a lot of factors out of control, so to test the behavior we included a 
> test case which emulates lots of concurrent accesses and fails most of the 
> time, see GenericEngineFactoryTests.java.
> The reason for this bug is that OFBiz reuses and concurrently accesses Xerces 
> DOM objects which are not thread-safe (not even for read access).
> ResourceLoader.java#getXmlDocument also states that:
> {quote}
>     // This method should be avoided. DOM object trees take a lot of memory, 
> so they should
>     // not be cached.
> {quote}
> Therefore we would like to propose to refactor ServiceConfigUtil (and other 
> places) so that it never returns Xerces dom objects and instead internally 
> binds the XML to POJOs.
> We implemented an example which fixes this particular issue.
> Apply the attached patch and generate the POJOs:
> {code}
> $ patch < ofbiz-serviceengine.patch
> $ xjc ./framework/service/dtd/service-config.xsd -p 
> org.ofbiz.service.config.generated -d framework/service/src
> {code}
> This fixed this particular issue for us, but we think there might be others 
> issues like this wherever Document/Element objects are passed around.
> If you are okay with this implementation we could do some more work on this, 
> implementing the xjc stuff in the ant build and potentially fix other places 
> where the DOM objects are used as well, but we wanted to get your opinion 
> first.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to