Support #3978
closed
Blocked thread while running saxon transformation
0%
Description
We are seeing the following teace in our thread dumps while running saxon xsl transformation.
priority:5 - threadId:0x000000002f7ef800 - nativeId:0x141c - state:BLOCKED
stackTrace:
java.lang.Thread.State: BLOCKED (on object monitor)
at java.io.PrintStream.flush(PrintStream.java:335)
- waiting to lock <0x0000000555fd2c20> (a java.io.PrintStream)
at net.sf.saxon.serialize.UTF8Writer.flush(UTF8Writer.java:105)
at net.sf.saxon.serialize.XMLEmitter.close(XMLEmitter.java:303)
at net.sf.saxon.serialize.MessageEmitter.close(MessageEmitter.java:39)
at net.sf.saxon.Controller.closeMessageEmitter(Controller.java:2698)
at net.sf.saxon.Controller.transformDocument(Controller.java:2345)
at net.sf.saxon.Controller.transform(Controller.java:1892)
at net.sf.saxon.s9api.XsltTransformer.transform(XsltTransformer.java:579)
at net.sf.saxon.jaxp.TransformerImpl.transform(TransformerImpl.java:185)
at com.adeptia.indigo.services.mapping.MappingTransformation$5.run(MappingTransformation.java:1453)
at java.lang.Thread.run(Thread.java:745)
We are running a transformation and takong the output of transformation in a StreamResult object instantiated with a StringWriter
StringWriter sw=new StringWriter();
StreamResult _result=new StreamResult(sw);
_transformer.transform(new StreamSource(getSourceDataStream()), _result);
String output=sw.toString();
sw.flush();
sw.close();
Our concerns regarding the issue is are:-
-
What is actually being emitted and flushed out to the standard input stream (is it the output of transformation?)
-
If its not the output of transformation then, is it possible to avoid the emission of these messages to standard output stream?
We are on saxon versio 9.8 EE.
Updated by Michael Kay over 5 years ago
I haven't seen this before.
At the point of failure it is trying to close the MessageEmitter, which is used for xsl:message output. I'm not sure what's going on here, but you could try overriding the MessageEmitter.
Updated by Michael Kay over 5 years ago
- Priority changed from High to Normal
Are you able to supply any more information that will help us to resolve this? As it is, without being able to reproduce the problem, there's nothing we can usefully do to investigate it.
Updated by Michael Kay over 5 years ago
- Status changed from New to Closed
I regret I'm going to have to close this as unresolved because there is no further progress we can make without more information. Feel free to re-open the issue if more information becomes available.
Updated by Ansh Sahajpal over 4 years ago
We have faced this issue again and after doing an in depth analysis we were able to find some key info which may be helpful for this issue.
In our application, we are using Log4J api for handling the logging, we write all our log messages to a log file.
We have found out that when there's consistent logs being made from our application (Say an activity logging warning/info messages very frequently). The XSL transformation hangs and we see the trace mentioned in the description and the transformation thread stays blocked at PrintStream object.
It appears that after the XSL transformation is complete, and saxonica is closing the streams, the XMLEmitter flush's the output stream(i.e. the logging stream in case of our application) regardless of XSL:MESSAGE tag being used or not.
From the complete thread dump, we were able trace back the PrintStream object for which the transformation thread is waiting, to another thread which was writing some log messages.
The same XSL Transformation would work fine if the PrintStream object is available for the transformation thread but we don't see any logs being made from saxonica (it seems it flushes blank string to output stream).
Our concerns are:
When we are not using the XSL:MESSAGE tag in our XSL then why is XMLEmitter class trying to flush to the output stream and what would be the correct approach to avoid this from happening. Shouldn't the XMLEmitter be used only when XSL:MESSAGE tag is used? or is it used for some other functionality as well ?
Updated by Michael Kay over 4 years ago
- Status changed from Closed to In Progress
Thanks for that insight. It would certainly be simple enough to ensure that we only flush the message stream if we have actually written anything to it.
Meanwhile if the xsl:message output stream is causing contention, then of course there is a simple workaround for you to write your own message listener that discards the message content.
Updated by Michael Kay over 4 years ago
Are you still using 9.8?
There are considerable differences in xsl:message handling between 9.8 and 9.9, largely caused by the need to handle multi-threading. It's certainly true that 9.8 calls close() on the MessageEmitter at the end of a transformation whether or not any messages have been written. The situation in 9.9 is much more nuanced.
If you are still using 9.8, are there any good reasons for this?
Updated by Michael Kay about 4 years ago
- Status changed from In Progress to Closed
This thread has gone quiet so I'm closing it. If there are still issues, please start a new thread.
Please register to edit this issue
.