Saxon

From the line numbers in the stack trace, it looks as if this might be Saxon 9.2. If I'm correct on that, could you try moving to a more recent release?

I can't immediately see what's wrong, but trying to reproduce it in a later version would be a good start. The current version is 9.4.0.7.

Thanks for your answer. Unfortunately it is not so easy to migrate to the latest version of the saxon library as it is part of a release deployed on our customer site.

By the way, is your library thread-safe ? can it be linked to a multi-thread issue ? here is the source code calling your library:

private String xmlElementToString(Element pElement) throws TransformerException {
    Source source = new DOMSource(pElement);
    StringWriter stringWriter = new StringWriter();
    Result result = new StreamResult(stringWriter);
    TransformerFactory factory = TransformerFactory.newInstance();
    Transformer transformer = factory.newTransformer();
    transformer.transform(source, result);
    return stringWriter.getBuffer().toString();
}

Thanks,

Yann.

Given that code, it seems very unlikely to be a multithreading issue. A Transformer shouldn't be used in more than one thread, but you're creating a new Transformer for each transformation, which is fine. (Incidentally, instantiating the TransformerFactory using JAXP mechanisms is an expensive operation, but that's not really relevant to the bug).

Your code looks pretty straightforward. Saxon sometimes has problems with DOM instances that are either (a) constructed using a DOM implementation other than one of the common implementations we test against, or (b) constructed programmatically rather than by parsing XML. However, the NPE in this stack trace doesn't seem related to the DOM contents in any way.

Could you confirm what Saxon version you are using? (Simple test: run "java net.sf.saxon.Version" from the command line with the relevant JAR on the classpath). I'm afraid we aren't always able to help people when they are using an old Saxon release; even if we can diagnose the cause of the problem, fixing it will inevitably involve a new release.

Hello Michael,

The version we are using is the 9.2.1.1.

I was asking about multi threading issue because if we execute the same call (with exactly the same xml) using your library a bit later, it succeed without any error or NPE.

So, as far as you know, you do not share any resource between calls to the TransformerFactory/IndentityTransformer instances ?

Yann.

I've got another time the same issue with another stack trace:

2013-03-20 15:43:25,223 ERROR [pool-13-thread-1] [STDERR] java.lang.NullPointerException 2013-03-20 15:43:25,223 ERROR [pool-13-thread-1] [STDERR] at net.sf.saxon.dom.DOMSender.walkNode(DOMSender.java:155) 2013-03-20 15:43:25,223 ERROR [pool-13-thread-1] [STDERR] at net.sf.saxon.dom.DOMSender.outputElement(DOMSender.java:249) 2013-03-20 15:43:25,223 ERROR [pool-13-thread-1] [STDERR] at net.sf.saxon.dom.DOMSender.sendElement(DOMSender.java:139) 2013-03-20 15:43:25,223 ERROR [pool-13-thread-1] [STDERR] at net.sf.saxon.dom.DOMSender.send(DOMSender.java:100) 2013-03-20 15:43:25,223 ERROR [pool-13-thread-1] [STDERR] at net.sf.saxon.dom.DOMObjectModel.sendSource(DOMObjectModel.java:216) 2013-03-20 15:43:25,223 ERROR [pool-13-thread-1] [STDERR] at net.sf.saxon.event.Sender.send(Sender.java:231) 2013-03-20 15:43:25,223 ERROR [pool-13-thread-1] [STDERR] at net.sf.saxon.IdentityTransformer.transform(IdentityTransformer.java:32) 2013-03-20 15:43:25,223 ERROR [pool-13-thread-1] [STDERR] at com.lysis.soa.esb.utils.EsbUtils.xmlElementToString(EsbUtils.java:86) 2013-03-20 15:43:25,223 ERROR [pool-13-thread-1] [STDERR] at com.lysis.idtv3.esb.actions.ConvertStringToDocumentAction.process(ConvertStringToDocumentAction.java:53) 2013-03-20 15:43:25,223 ERROR [pool-13-thread-1] [STDERR] at sun.reflect.GeneratedMethodAccessor235.invoke(Unknown Source) 2013-03-20 15:43:25,224 ERROR [pool-13-thread-1] [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 2013-03-20 15:43:25,224 ERROR [pool-13-thread-1] [STDERR] at java.lang.reflect.Method.invoke(Method.java:597) 2013-03-20 15:43:25,224 ERROR [pool-13-thread-1] [STDERR] at org.jboss.soa.esb.listeners.message.ActionProcessorMethodInfo.processMethods(ActionProcessorMethodInfo.java:102) 2013-03-20 15:43:25,224 ERROR [pool-13-thread-1] [STDERR] at org.jboss.soa.esb.listeners.message.OverriddenActionLifecycleProcessor.process(OverriddenActionLifecycleProcessor.java:74) 2013-03-20 15:43:25,224 ERROR [pool-13-thread-1] [STDERR] at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:615) 2013-03-20 15:43:25,224 ERROR [pool-13-thread-1] [STDERR] at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:574) 2013-03-20 15:43:25,224 ERROR [pool-13-thread-1] [STDERR] at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:408) 2013-03-20 15:43:25,224 ERROR [pool-13-thread-1] [STDERR] at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:540) 2013-03-20 15:43:25,224 ERROR [pool-13-thread-1] [STDERR] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) 2013-03-20 15:43:25,224 ERROR [pool-13-thread-1] [STDERR] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) 2013-03-20 15:43:25,224 ERROR [pool-13-thread-1] [STDERR] at java.lang.Thread.run(Thread.java:662)

and here is the com.lysis.soa.esb.utils.EsbUtils.xmlElementToString method:

    public static String xmlElementToString(Element pElement) throws TransformerException {
        Source source = new DOMSource(pElement);
        StringWriter stringWriter = new StringWriter();
        Result result = new StreamResult(stringWriter);
        TransformerFactory factory = TransformerFactory.newInstance();
        Transformer transformer = factory.newTransformer();
        transformer.transform(source, result);
        return stringWriter.getBuffer().toString();
    }

It is the same code as before, but in a static method. Adding a "final" to the created "source" variable may help maybe ?

It just that I'm a bit lost here and for the two exceptions, the same code is called.

regards,

Yann.

The second stack trace looks like the same problem at first glance.

Is it completely repeatable - i.e. always fails the first time, always succeeds the second time? If so, that doesn't sound like a multi-threading problem.

Are you aware that the DOM itself is not thread-safe - you mustn't execute this code in parallel with any other code that is using the same Element node.

The latest maintenance release on the 9.2 branch is 9.2.1.5, so you should at least move forward to that.

Unfortunately the issue occurs randomly and we cannot define a reproducible test case for it. With the same data, we can have or not the issue, pointing me to this multi-threading possibility...

As far as I know, there is no possibility to have another thread modifying the Element node object during the transformation, that is why I'm asking about the saxon library robustness.

Do you know if something has been done in that direction between the 9.2.1.1 and the 9.2.1.5 release ?

regards,

Yann.

I've taken a look at the 9.2 source. Line 155 of DOMSender is the last line of the following extract:

      if (node.hasChildNodes()) {
            NodeList nit = node.getChildNodes();
            final int len = nit.getLength();
            for (int i=0; i
So "child" is null, which is not permitted by the DOM specification. Assuming you aren't using a buggy DOM implementation, the most likely explanation for this is a threading problem on the DOM. Note that the DOM isn't even thread-safe for multiple concurrent read operations, because in some DOM implementations (such as the one in the JDK) read operations have updating side-effects (lazy evaluation).