2014-12-11 5 views
0

Я использую версию iTextPDF версии 5.4.2, и у меня возникают проблемы с конфликтом потоков при большой нагрузке. Я использую IBM JDK 6iText PDF - Обсуждение темы

Это проблема, когда есть несколько независимых потоков, пытающихся сгенерировать разные файлы PDF, я вижу конкуренцию на SecureRandom.nextBytes, так как это синхронизировано, все потоки ждут, чтобы заблокировать этот объект. Ниже приведена свалка резьбы

*"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)* 

Помогите избежать этой проблемы?

Sid

+0

Какая платформа работает? –

+0

Это работает на IBM websphere 8.5 на Solaris OS –

+0

PdfPCell.java:123 в версии 5.0.6 не является строкой кода, а конструктор не создает UUID. Вы уверены, что это правильная версия? –

ответ

1

Я ожидаю, что утверждение не для замка, но и для случайных байтов. Мне сложно точно сказать, какую установку вы используете, но я подозреваю, что класс SecureRandom использует (медленные) безопасные случайные службы, предоставляемые ОС, и что вы исчерпываете энтропийный пул. Когда он исчерпан, вызов для чтения случайных данных будет блокироваться до тех пор, пока не будет доступно больше данных. другие потоки, пытающиеся получить случайные данные, застрянут на замке, заставив его выглядеть как проблема блокировки.

Я думаю, что самым простым решением этой проблемы было бы обновление до последней версии iTextPdf. В этой версии идентификатор был изменен с UUID на целое число, сгенерированное из счетчика, который не блокируется.

Еще одно потенциальное исправление, если вы не можете обновить, - это изменить поставщика безопасности, используемый в вашей среде, чтобы обеспечить менее безопасный, но быстрый сервис SecureRandom.

+0

Спасибо, что вам помогли. Я пытался выяснить, почему они удалили это в будущих версиях, есть ли способ найти это. Хотите узнать, удалили ли они это, чтобы решить эту проблему или нет. –

+0

Как вы отметили в своем комментарии выше, оно не было действительно удалено, оно просто изменилось. Если я понимаю его цель, причина, по которой они создавали UUID, заключалась только в том, чтобы однозначно идентифицировать объект. Новая версия может сделать то же самое с целым числом более эффективным способом. –

+0

Спасибо за ваше время –

Смежные вопросы