0

I am using iTextPDF version 5.4.2 and i am having thread contention issues when there is heavy load. I am using IBM JDK 6

This is the problem, when there are multiple independent threads trying to generate different pdf files i see a contention on SecureRandom.nextBytes , since this is synchronized all the threads are waiting to lock this object. Below is the Thread dump

*"WebContainer : 0" daemon prio=3 tid=0x007ffc00 nid=0x91 waiting for monitor entry [0xc823d000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at java.security.SecureRandom.nextBytes(SecureRandom.java:433)
    - waiting to lock <0xdf4b7430> (a java.security.SecureRandom)
    at java.util.UUID.randomUUID(UUID.java:162)
    at com.itextpdf.text.pdf.PdfPCell.<init>(PdfPCell.java:123)
    at com.itextpdf.text.pdf.PdfPRow.<init>(PdfPRow.java:136)
    at com.itextpdf.text.pdf.PdfPTable.<init>(PdfPTable.java:260)
    at com.itextpdf.text.pdf.PdfPCell.<init>(PdfPCell.java:251)
    at com.itextpdf.text.pdf.PdfPRow.<init>(PdfPRow.java:136)
    at com.itextpdf.text.pdf.PdfPTable.<init>(PdfPTable.java:260)
    at com.itextpdf.text.pdf.PdfPCell.<init>(PdfPCell.java:251)
    at com.itextpdf.text.pdf.PdfPRow.<init>(PdfPRow.java:136)
    at com.itextpdf.text.pdf.PdfPTable.<init>(PdfPTable.java:260)
    at com.itextpdf.text.pdf.PdfPCell.<init>(PdfPCell.java:251)
    at com.itextpdf.text.pdf.PdfPRow.<init>(PdfPRow.java:136)
    at com.itextpdf.text.pdf.PdfPTable.adjustCellsInRow(PdfPTable.java:1377)
    at com.itextpdf.text.pdf.PdfPTable.getRows(PdfPTable.java:1364)
    at com.itextpdf.text.pdf.ColumnText.goComposite(ColumnText.java:1702)
    at com.itextpdf.text.pdf.ColumnText.go(ColumnText.java:881)
    at com.itextpdf.text.pdf.ColumnText.go(ColumnText.java:876)
    at com.itextpdf.text.pdf.ColumnText.go(ColumnText.java:865)
    at com.itextpdf.text.pdf.PdfDocument.addPTable(PdfDocument.java:2566)
    at com.itextpdf.text.pdf.PdfDocument.add(PdfDocument.java:723)
    at com.itextpdf.text.Document.add(Document.java:278)* 

Can you please help in avoiding this issue ?

Sid

Joe
  • 33
  • 8

1 Answers1

1

I expect the contention is not for the lock, but for random bytes. It is hard for me to tell exactly what setup you're using, but I suspect that the SecureRandom class utilizes the (slow) secure random services provided by the OS and that you are exhausting the entropy pool. When it is exhausted, the call to read random data will block until more data is available. the other threads attempting to get random data will get stuck on the lock, making it look like the lock is the problem.

I think the simplest fix for this problem would be to upgrade to the latest version of iTextPdf. In this version, the ID has been changed from a UUID to an integer generated from a counter which doesn't block.

Another potential fix if you cannot upgrade would be to change the security provider used in your environment to provide a less secure but faster SecureRandom service.

Dark Falcon
  • 43,592
  • 5
  • 83
  • 98
  • Thanks a bunch for helping out . I was trying to find out why they removed this in future versions , is there a way to find that out. Want to know if they removed this to address this specific issue or not. – Joe Dec 11 '14 at 16:18
  • As you noted in your comment above, it was not really removed, it was just changed. If I understand its purpose, the reason they were creating a UUID was only to uniquely identify the object. The new version can do the same with the integer in a more efficient way. – Dark Falcon Dec 11 '14 at 16:19