Hullo;
(Apologies, this is going to be a wide email, thanks to some JVM
dumps.. suggest you stretch the window a bit.=)
Background I, version info:
Name : batik Relocations: (not
relocatable)
Version : 1.6 Vendor: JPackage Project
Release : 3.svn495214.3 Build Date: Mon 15 Jan
2007 07:35:39 PM EET
Background II:
I load and initialize an SVG document, and ultimately render it:
// public initializeDocument( ctx, svgDoc )
UserAgent userAgent = new UserAgentAdapter();
DocumentLoader loader = new DocumentLoader(userAgent);
BridgeContext ctx = new BridgeContext(userAgent, loader);
ctx.setDynamicState(BridgeContext.DYNAMIC);
GVTBuilder builder = new GVTBuilder();
GraphicsNode rootGN = builder.build(ctx, svgDoc);
return rootGN
...
// Elsewhere:
// m_template = initializeDocument( ctx, someSVGTextDoc );
// I do dynamic modifications to the SVG, so I clone the node,
// do a bunch of stuff, and finally render:
SVGDocument copy = (SVGDocument)m_template.cloneNode( true );
GraphicsNode gvtRoot = initializeDocument( copy );
Element root = copy.getRootElement();
doABunchOfStuff( root );
// ...and, finally, our goal:
gvtRoot.paint( ctx );
All this works fine in my test environment. Now that I recently
deployed it on a server with some load, I ran into weird rendering
server hang-ups. Looks like when we get enough requests to render an
SVG document at the same time, something inside Batik hangs on a
block, and never recovers. The documents themselves should be
different in each case; the only thing I can imagine is that the
builder.build(...) call shares resources somewhere deep underneath.
Below is some JVM state dump that might help with this.
First a bit from a jammed server that may or not may be normal - I
haven't been able to capture this in the case where nothing odd occurs:
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - "SocketListener0-12" prio=10
tid=0x0000002b0a09f000 nid=0x7058 runnable [0x000000004a\
9cf000..0x000000004a9d1e30]
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - java.lang.Thread.State: RUNNABLE
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at
java.io.FileOutputStream.writeBytes(Native Method)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at
java.io.FileOutputStream.write(FileOutputStream.java:260)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at
java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - - locked
<0x0000002a9f2f5288> (a java.io.BufferedOutputStream)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at java.io.PrintStream.write
(PrintStream.java:432)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - - locked
<0x0000002a9f2f5250> (a java.io.PrintStream)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at
sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at
sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:272)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at
sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:85)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - - locked
<0x0000002a9f2f53d0> (a java.io.OutputStreamWriter)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at
java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:168)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at java.io.PrintStream.write
(PrintStream.java:477)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - - locked
<0x0000002a9f2f5250> (a java.io.PrintStream)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at java.io.PrintStream.print
(PrintStream.java:619)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at
java.io.PrintStream.println(PrintStream.java:756)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - - locked
<0x0000002a9f2f5250> (a java.io.PrintStream)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at
org.apache.batik.ext.awt.image.GraphicsUtil.getDestination(Unknown
Source)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at
org.apache.batik.ext.awt.image.GraphicsUtil.getDestinationBounds
(Unknown Source)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at
org.apache.batik.ext.awt.image.GraphicsUtil.drawImage(Unknown Source)
2007-02-23 13:15:43,884 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at
org.apache.batik.ext.awt.image.GraphicsUtil.drawImage(Unknown Source)
...
Then an example of one of several blocked threads, waiting on the
same outputstream (0x0000002a9f2f5288, as locked above):
2007-02-23 13:15:43,886 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - "SocketListener0-10" prio=10
tid=0x0000002b0a09ec00 nid=0x7055 waiting for monitor en\
try [0x000000004a8ce000..0x000000004a8d0d30]
2007-02-23 13:15:43,886 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - java.lang.Thread.State: BLOCKED
(on object monitor)
2007-02-23 13:15:43,886 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at
java.io.PrintStream.println(PrintStream.java:756)
2007-02-23 13:15:43,886 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - - waiting to lock
<0x0000002a9f2f5250> (a java.io.PrintStream)
2007-02-23 13:15:43,886 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at
org.apache.batik.ext.awt.image.GraphicsUtil.getDestination(Unknown
Source)
2007-02-23 13:15:43,886 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at
org.apache.batik.ext.awt.image.GraphicsUtil.getDestinationColorModel
(Unknown Source)
2007-02-23 13:15:43,886 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at
org.apache.batik.ext.awt.image.GraphicsUtil.drawImage(Unknown Source)
2007-02-23 13:15:43,886 [dig.defaultdig output] DEBUG
net.basen.appctl.ProcessRunner - at
org.apache.batik.ext.awt.image.GraphicsUtil.drawImage(Unknown Source)
...
There are several of these last waiting in line, so obviously our
rendering server will stop processing these requests.
Seems to me that for some reason, Batik wants to internally use a
certain PrintStream.
Now, I can synchronize my calls to all SVG renders, but this doesn't
really seem like the optimal solution, and happens to defeat the
purpose of our whole rendering server farm concept. =)
So...
Is there something the Batik code might do to avoid this deadlock?
Is this something that might have been fixed in code since January?
Is there any further information anyone would like? Will gladly oblige.
Should I rather send this over to the developer list?
Thanks; would really appreciate your input.
//ebu
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
