Yes, our previous version (for Xalan 1), cached StylesheetRoot objects and
created new XSLTProcessor instances. Our new version (for Xalan 2) now
caches Templates objects and creates new Transformer objs as needed...
We have turned off cacheing of these objects and experience the same
deadlock, although more slowly ;-)
-Steve
"Gunnlaugur
Thor Briem" To: <[EMAIL PROTECTED]>
<gthb cc:
@dimon.is> Subject: RE: Xalan 1.2.2 ElemNumber
deadlock
08/20/2001
12:26 PM
Please
respond to
xalan-dev
Just as a sanity check ... you do realize that
only the Templates object can be shared between
concurrent processing contexts, and that you
must use separate Transformer instances, right?
(on Xalan 1.x I guess this translates to a shared
StylesheetRoot instance and distinct XSLTProcessor
instances)
- Gulli
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 20. agust 2001 16:54
To: [EMAIL PROTECTED]
Subject: Re: Xalan 1.2.2 ElemNumber deadlock
We are experiencing this exact scenario. Our multi-threaded application
may perform several transformations at once and will hang with a stack
trace as shown below. This is a serious problem for us and we may resort
to single-threading our calls to Xalan (fortunately it's all in one spot).
We have duplicated this w/Xalan 1.2.2 and w/Xalan 2.0.1 and Xalan 2.1_D9.
Steve Dunham
<dunham To: [EMAIL PROTECTED]
@cse.msu.edu> cc:
Subject: Xalan 1.2.2
ElemNumber
deadlock
08/18/2001
11:11 AM
Please
respond to
xalan-dev
FYI, I got a deadlock with Xalan 1.2.2 on one of our production
systems. (I know Xalan 1.2.2 isn't supported anymore, but we use
cocoon.) This is with Sun's Java 1.3.1 on a 4-way Solaris box.
Basically, the issue is:
* xalan synchronizes on locale before calling NumberFormat.getInstance().
* NumberFormat has a synchronizes on a hash, then calls Locale.hashCode()
which synchronizes on the locale object.
So if somebody else calls NumberFormat.getInstance() while xalan has
the lock on the locale but before it gets the lock on NumberFormat's
hash.
Relevent portions of the thread dump:
"Thread-29" prio=5 tid=0x501ae0 nid=0x53 waiting for monitor entry
[0xe6480000..0xe6481a28]
at java.util.Locale.hashCode(Locale.java:862)
at java.util.Hashtable.get(Hashtable.java:320)
at
java.text.DecimalFormatSymbols.initialize(DecimalFormatSymbols.java:338)
at
java.text.DecimalFormatSymbols.<init>(DecimalFormatSymbols.java:60)
at java.text.NumberFormat.getInstance(NumberFormat.java:570)
at java.text.NumberFormat.getInstance(NumberFormat.java:329)
at java.text.SimpleDateFormat.initialize(SimpleDateFormat.java:332)
at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:281)
at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:269)
"Thread-27" prio=5 tid=0x500520 nid=0x51 waiting for monitor entry
[0xe667d000..0xe6681a28]
at java.util.Hashtable.get(Hashtable.java:319)
at
java.text.DecimalFormatSymbols.initialize(DecimalFormatSymbols.java:338)
at
java.text.DecimalFormatSymbols.<init>(DecimalFormatSymbols.java:60)
at java.text.NumberFormat.getInstance(NumberFormat.java:570)
at java.text.NumberFormat.getNumberInstance(NumberFormat.java:343)
at
org.apache.xalan.xslt.ElemNumber.getNumberFormatter(ElemNumber.java:663)
at
org.apache.xalan.xslt.ElemNumber.getFormattedNumber(ElemNumber.java:841)
at
org.apache.xalan.xslt.ElemNumber.formatNumberList(ElemNumber.java:803)
