[
https://issues.apache.org/jira/browse/ODE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673192#action_12673192
]
Jürgen Schumacher commented on ODE-503:
---------------------------------------
Hi Tammo,
I've not yet been able to reproduce the problem (and therefore could not test
your patch), but I'm working on it. Howver, I'm a bit concerned about the
performance implications of this patch. We are using extension activities quite
heavily and have also some more content inside the extension element (see
http://wiki.eclipse.org/SMILA/Documentation/BPEL_Workflow_Processor#Pipelet_invocations
for an example) and cloning all this for each invocation in a synchronized
block might become a problem, especially as I do not access this element any
further in the extension implementation, because I have extracted all necessary
information already during deployment using an extension validator (it might be
a bit of a misuse, but it works fine ;-). If you really want to be safe, maybe
it would be enough to put the final QName extensionId =
DOMUtils.getElementQName(_oext.nestedElement.getElement()); inside a
synchronized block (or to extract it only once and to store the QName in a
member of EXTENSIONACTIVITY/ASSIGN so that we can save the synchronization on
further accesses?) and put a hint in the documentation for extension
implementors that they should access the passed element only in a synchronized
way?
> 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.
