Am 27.06.2016 um 20:55 schrieb Stahle, Patrick:
Hi,
We have a relatively heavily threaded application which is calling pdfbox to
stamp certain pdf files. We have been in production for a little over a week
and have run into a few threads getting stuck. The stack trace is the following:
### Thread id=34, name="dispatch_2_20160626211454_1064"
# ThreadInfo: "dispatch_2_20160626211454_1064" Id=34 RUNNABLE
# CPU: threadCpuTime=49,541,548.824 ms, threadUserTime=49,538,533.066 ms
# Contention: blockedCount=33 , blockedTime=123 ms
# Contention: lockName=null , lockOwnerId=-1, lockOwnerName=null
java.util.HashMap.put(HashMap.java:473)
java.util.HashSet.add(HashSet.java:217)
java.util.AbstractCollection.addAll(AbstractCollection.java:334)
org.apache.pdfbox.pdmodel.font.encoding.Encoding.contains(Encoding.java:109)
org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:343)
org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:286)
org.apache.pdfbox.pdmodel.font.PDFont.getStringWidth(PDFont.java:315)
com.tycoelectronics.emcs.stamppdf.StampEnginePDFBox.getLongestTextWidth(StampEnginePDFBox.java:1369)
:
:
We seem to be getting stuck in PDFont classes HashMap which is unsynchronized
class.
Any suggestions?
We are using PDFBox 2.0.0 release...
Update to 2.0.2. What PDFont are you using? One of the predefined
"standard 14"? If yes, then this code
public boolean contains(String name)
{
// we have to wait until all add() calls are done before
building the name cache
// otherwise /Differences won't be accounted for
if (names == null)
{
names = new HashSet<String>(codeToName.size());
names.addAll(codeToName.values());
}
return names.contains(name);
}
might be risky :-( Workaround idea: call contains("space") for the fonts
you're using before the real business starts.
Tilman
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
