[
https://issues.apache.org/jira/browse/ODE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tammo van Lessen resolved ODE-503.
----------------------------------
Resolution: Fixed
perfect, thanks!
> Multithreading issue in ...rtrep.v2.EXTENSIONACTIVITY
> -----------------------------------------------------
>
> Key: ODE-503
> URL: https://issues.apache.org/jira/browse/ODE-503
> Project: ODE
> Issue Type: Bug
> Components: BPEL Runtime
> Affects Versions: 2.0
> Reporter: Jürgen Schumacher
> Assignee: Tammo van Lessen
> Fix For: 2.0
>
> Attachments: ODE-503.patch
>
>
> We have experienced a problem in the execution of extension activities. I
> suppose it's caused by two process instances of the same BPEL process that
> invoke a single extension activity at the same time that has not yet been
> executed since hydration.
> The error stacktrace is something like this:
> java.lang.IllegalArgumentException: type: -1
> at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject(Unknown
> Source)
> at org.apache.xerces.dom.DeferredElementNSImpl.synchronizeData(Unknown
> Source)
> at org.apache.xerces.dom.ElementNSImpl.getNamespaceURI(Unknown Source)
> at org.apache.ode.utils.DOMUtils.getElementQName(DOMUtils.java:691)
> at
> org.apache.ode.bpel.rtrep.v2.EXTENSIONACTIVITY.run(EXTENSIONACTIVITY.java:51)
> ...
> (sometimes it's a NullPointerException instead)
> This line 51 is
> final QName extensionId =
> DOMUtils.getElementQName(_oext.nestedElement.getElement());
> I searched for "java.lang.IllegalArgumentException at
> org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject" and found an older
> message in the xerces mailing list suggesting that the cause for this could
> be that the DOM implementation is not thread-safe. So I did a little patch in
> org.apache.ode.utils.SerializableElement and added a line to readObject(...):
> private void readObject(java.io.ObjectInputStream in)
> throws IOException, ClassNotFoundException {
> try {
> e = DOMUtils.stringToDOM((String)in.readObject());
> DOMUtils.getElementQName(e); // <-- this one is new
> ...
> Now the error doesn't occur anymore (as far as I can tell), because whatever
> is changed in the DOM object during the first access of the element's QName
> has already changed during process hydration and the first invocation does
> only read the DOM object.
> This is probably the most simple way to fix the issue, but there may be
> better possibilities (maybe reading the QName from the nested DOM during
> instance creation/deserialization of EXTENSIONACTIVITY and storing it for
> later access in a member variable? that would be also a small performance
> improvement), but I'll leave this decision to you. I can also provide a
> proper patch if you tell me which way to go.
> Cheers,
> Juergen
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
