[
https://issues.apache.org/jira/browse/OFBIZ-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13671373#comment-13671373
]
Christoph Neuroth commented on OFBIZ-5204:
------------------------------------------
Oops, sorry, forgot some svn adds.
> 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
> Attachments: GenericEngineFactoryTests.java,
> OFBIZ-5204-2013-05-31.patch, OFBIZ-5204-2013-05-31.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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
