2014-12-11 2 views
0

iTextPDF 버전 5.4.2를 사용하고 있으며 부하가 많은 경우 스레드 경쟁 문제가 있습니다. 나는 IBM JDK 6을 사용하고있다.iText 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)* 

이 문제를 피할 수 있습니까?

시드

+0

실행중인 플랫폼은 무엇입니까? –

+0

Solaris OS의 IBM websphere 8.5에서 실행 중임 –

+0

버전 5.0.6의 PdfPCell.java:123은 코드 라인이 아니며 생성자가 UUID를 생성하지 않습니다. 이것이 올바른 버전입니까? –

답변

1

나는 경합 잠금위한 것이 아니라 임의 바이트 기대합니다. 어떤 설정을 사용하고 있는지 정확하게 말하기는 어렵지만, SecureRandom 클래스는 OS가 제공하는 (느린) 안전한 무작위 서비스를 사용하고 있으며 엔트로피 풀을 고갈시키고 있다고 생각됩니다. 소진되면 더 많은 데이터를 사용할 수있을 때까지 무작위 데이터 읽기 호출이 차단됩니다. 임의의 데이터를 얻으려고 시도하는 다른 스레드는 잠금 장치에 걸려 잠금 장치가 문제가되는 것처럼 보입니다.

이 문제의 가장 간단한 해결 방법은 iTextPdf의 최신 버전으로 업그레이드하는 것입니다. 이 버전에서는 ID가 UUID에서 차단하지 않는 카운터에서 생성 된 정수로 변경되었습니다.

업그레이드 할 수없는 경우 잠재적으로 덜 안전하지만 더 빠른 SecureRandom 서비스를 제공하기 위해 사용자 환경에서 사용되는 보안 공급자를 변경하는 것이 좋습니다.

+0

도와 줘서 고마워. 나는 왜 그들이 이것을 미래 버전에서 제거했는지 알아 내려고 노력했다. 그것을 발견 할 수있는 방법이있다. 이 특정 문제를 해결하기 위해 제거했는지 여부를 알고 싶습니다. –

+0

위의 의견에 언급했듯이 실제로 제거되지는 않았지만 방금 변경되었습니다. 그 목적을 이해한다면 UUID를 만드는 이유는 객체를 유일하게 식별하기 위해서였습니다. 새 버전은보다 효율적인 방법으로 정수와 동일하게 처리 할 수 ​​있습니다. –

+0

시간 내 주셔서 감사합니다 –