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
Fix For: 2.0
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.
