ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schumacher (JIRA) <j...@apache.org>
Subject [jira] Created: (ODE-503) Multithreading issue in ...rtrep.v2.EXTENSIONACTIVITY
Date Mon, 02 Feb 2009 08:57:59 GMT
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.


Mime
View raw message