[
https://issues.apache.org/jira/browse/OFBIZ-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13674278#comment-13674278
]
Christoph Neuroth commented on OFBIZ-5204:
------------------------------------------
Heh me neither. But it does "exist", in some way, as the code tells us ;) So
we'll have to do something about it. Some options I can think of:
a) Remove the whole ServiceMca thing as it seems to be unused and undocumented
b) Adapt the XSD file, then have xjc generate the model
c) Create the models manually by looking at the parsing code in ServiceMcaUtil
c1) and keep the XSD as it is (wrong, because it doesn't now about service-mca)
c2) and delete the XSD because it is wrong
c3) and adapt the XSD to reflect reality
d) keep exposing the XML Document just not to break that McaUtil class
(eeeew...)
Of course, this really has nothing to do with the original problem anymore -
but I'd like to finish the refactoring properly and get rid of the methods that
expose Xerces objects from ServiceConfigUtil to prevent further problems.
> 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-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 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
