Am 27.06.2016 um 22:01 schrieb Stahle, Patrick:
Hi Tilman,
How would a call contains?
I meant put this in your software before multithreading starts:
PDType1Font.HELVETICA.getEncoding().contains("space");
Right now I am just doing the following font wise:
font = PDType1Font.HELVETICA;
Yes this is OK.
Should I simply grab the fonts we use during single thread initialization code?
Can't follow you there.
What I also noticed is that each standard 14 font is allocating a
WinAnsiEncoding object despite WinAnsiEncoding.INSTANCE already being
assigned.
Anyway, can you test that workaround? I'm thinking about a code change
like this:
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)
{
synchronized (this)
{
if (names == null)
{
names = new HashSet<String>(codeToName.size());
names.addAll(codeToName.values());
}
}
}
return names.contains(name);
}
This way, there is no performance loss except the very first time.
Tilman
Thanks,
Patrick
-----Original Message-----
From: Stahle, Patrick [mailto:[email protected]]
Sent: Monday, June 27, 2016 3:27 PM
To: [email protected]
Subject: RE: threads using PDFBox getting stuck infinite loop
Hi Tilman,
We are using "PDType1Font.HELVETICA".
Thanks,
Patrick
-----Original Message-----
From: Tilman Hausherr [mailto:[email protected]]
Sent: Monday, June 27, 2016 3:17 PM
To: [email protected]
Subject: Re: threads using PDFBox getting stuck infinite loop
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.jav
a: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.getLongestTextWidt
h(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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
