I’am testing aspose.pdf java version (19.6) with a temporally license.
it takes more then 239 seconds (~4 minutes) just to apply the license.
code :
com.aspose.pdf.License license = new com.aspose.pdf.License();
license.setLicense(“Aspose.Pdf.lic”);
if (com.aspose.pdf.Document.isLicensed())
{
System.out.println(“License is Set!”);
}
long endTime = System.nanoTime();
long timeElapsed = endTime - startTime;
System.out.println("Execution time in seconds : " + timeElapsed / 1000000000);
System.exit(0);
Output :
License is Set!
Execution time in seconds : 239
The result is that it not usable, is this because i use a temporarly license ?
NB: with version 19.5 it takes “just” ~ one second.
Thank you for contacting support.
Please note that the API works in its full capacity when evaluation license is set so this is not any limitation. Therefore, you may try to clean and build the project if that works. Otherwise please share a sample project containing SSCCE code so that we may try to reproduce and investigate it in our environment.
We too just upgraded to 19.6 and we were seeing the set license take up to 20 minutes on our Linux servers.
SSCCE:
new com.aspose.email.License().setLicense(asposeLicense);
new com.aspose.imaging.License().setLicense(asposeLicense);
new com.aspose.cells.License().setLicense(asposeLicense);
new com.aspose.pdf.License().setLicense(asposeLicense);
We get through all the other libraries that we use just fine but when it gets to pdf just hangs.
build.gradle:
compile group: ‘com.aspose’, name: ‘aspose-email’, version: ‘19.6’, classifier: ‘jdk16’
compile group: ‘com.aspose’, name: ‘aspose-imaging’, version: ‘19.6’, classifier: ‘jdk16’
compile group: ‘com.aspose’, name: ‘aspose-cells’, version: ‘19.6’
compile group: ‘com.aspose’, name: ‘aspose-pdf’, version: ‘19.6’
Thanks,
Mike
Here is the jstack of the process thats hung.
Thread 8743: (state = IN_NATIVE)
- java.io.FileInputStream.readBytes(byte[], int, int) @bci=0 (Interpreted frame)
- java.io.FileInputStream.read(byte[], int, int) @bci=4, line=255 (Interpreted frame)
- sun.security.provider.NativePRNG$RandomIO.readFully(java.io.InputStream, byte[]) @bci=13, line=424 (Interpreted frame)
- sun.security.provider.NativePRNG$RandomIO.implGenerateSeed(int) @bci=16, line=441 (Interpreted frame)
- sun.security.provider.NativePRNG$RandomIO.access$500(sun.security.provider.NativePRNG$RandomIO, int) @bci=2, line=331 (Interpreted frame)
- sun.security.provider.NativePRNG.engineGenerateSeed(int) @bci=4, line=226 (Interpreted frame)
- java.security.SecureRandom.generateSeed(int) @bci=5, line=533 (Interpreted frame)
- com.aspose.pdf.internal.l85if.lf.lf() @bci=85 (Interpreted frame)
- com.aspose.pdf.internal.l83n.lh.lf() @bci=28 (Interpreted frame)
- com.aspose.pdf.internal.l83n.l14h.ld() @bci=4 (Interpreted frame)
- com.aspose.pdf.internal.l83n.l14h.lI(com.aspose.pdf.internal.l83f.l0t, int, com.aspose.pdf.internal.l83h.l0y, byte[], byte[]) @bci=76 (Interpreted frame)
- com.aspose.pdf.internal.l83n.l14h.(com.aspose.pdf.internal.l83f.l0t, int, com.aspose.pdf.internal.l83h.l0y, byte[], byte[]) @bci=12 (Interpreted frame)
- com.aspose.pdf.internal.l83n.l4v$lk.lI(com.aspose.pdf.internal.l83h.l0y) @bci=21 (Interpreted frame)
- com.aspose.pdf.internal.l83n.ly.lj() @bci=16 (Interpreted frame)
- com.aspose.pdf.internal.l83n.ly.lI(byte[], byte[], boolean) @bci=6 (Interpreted frame)
- com.aspose.pdf.internal.l83n.l12y$lf.engineNextBytes(byte[]) @bci=36 (Interpreted frame)
- java.security.SecureRandom.nextBytes(byte[]) @bci=5, line=468 (Interpreted frame)
- java.math.BigInteger.randomBits(int, java.util.Random) @bci=36, line=634 (Interpreted frame)
- java.math.BigInteger.(int, java.util.Random) @bci=4, line=623 (Interpreted frame)
- com.aspose.pdf.internal.l87f.lf.lI(java.math.BigInteger, java.math.BigInteger, java.security.SecureRandom) @bci=76 (Interpreted frame)
- com.aspose.pdf.internal.l86j.l0if.lI(java.math.BigInteger, java.security.SecureRandom, int) @bci=113 (Interpreted frame)
- com.aspose.pdf.internal.l83y.l4p.lI(java.math.BigInteger) @bci=137 (Interpreted frame)
- com.aspose.pdf.internal.l83y.l4p.lI(java.math.BigInteger, java.math.BigInteger) @bci=20 (Interpreted frame)
- com.aspose.pdf.internal.l83y.l0y.(com.aspose.pdf.internal.l83h.lb, java.math.BigInteger, java.math.BigInteger) @bci=4 (Interpreted frame)
- com.aspose.pdf.internal.l85f.l40p.(com.aspose.pdf.internal.l83h.lb, java.security.spec.RSAPublicKeySpec) @bci=18 (Interpreted frame)
- com.aspose.pdf.internal.l85f.l36k$lh.engineGeneratePublic(java.security.spec.KeySpec) @bci=18 (Interpreted frame)
- java.security.KeyFactory.generatePublic(java.security.spec.KeySpec) @bci=12, line=328 (Interpreted frame)
- com.aspose.pdf.l9v.lI(java.lang.String, java.lang.String) @bci=65 (Interpreted frame)
- com.aspose.pdf.l9v.lI(org.w3c.dom.Node, org.w3c.dom.Node) @bci=2470 (Interpreted frame)
- com.aspose.pdf.l9v.lI(org.w3c.dom.Document) @bci=26 (Interpreted frame)
- com.aspose.pdf.l9v.lI(java.io.InputStream) @bci=224 (Interpreted frame)
- com.aspose.pdf.l9v.lI(java.lang.String) @bci=147 (Interpreted frame)
- com.aspose.pdf.License.setLicense(java.lang.String) @bci=208 (Interpreted frame)
… (our code that calls the set license)
this is running on ubuntu 16.04 if that matters/helps.
ubuntu@ip-172-51-2-81:~$ cat /etc/os-release
NAME=“Ubuntu”
VERSION=“16.04.5 LTS (Xenial Xerus)”
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME=“Ubuntu 16.04.5 LTS”
VERSION_ID=“16.04”
HOME_URL=“http://www.ubuntu.com/”
SUPPORT_URL=“http://help.ubuntu.com/”
BUG_REPORT_URL=“Bugs : Ubuntu”
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
I found some posts around slowness to the NativePRNG random number generator.
Found that adding this jvm option seems to bring it down to ~40 seconds, which I guess is better than 20 minutes.
-Djava.security.egd=file:/dev/./urandom
I have questions though:
- Why does Aspose need a random number generator at this point? I would assume its doing some decryption of the license file, not encrypting anything?
- What is different in the pdf library that it takes substantially longer than the other libraries we use cells/imaging/email?
- We run a containerized type of service that spins up on demand. Its not acceptable to have 20 minutes or even 40 extra seconds added to our spin up time.
- Why cant I set the license once, its the same license there is no reason to decrypt it n+ times, per the number of aspose libraries that we use.
@Farhan.Raza, please let me know asap as this is causing crippling performance in all of our environments currently.
Thank you for your worthy contributions towards investigations of this problem.
We have logged a ticket with ID PDFJAVA-38740 in our issue management for detailed investigations and after investigations, we will be addressing the concerns raised by you. Please be patient and spare us some time.
@Farhan.Raza Appreciate the response please let us know as soon as something is available. In the meantime we are taking a look at downgrading to see if it helps.
Thank you for being patient.
We have investigated this ticket and would like to update you that, according to JVM securerandom algorithm, on some operating systems /dev/random waits for a certain amount of “noise” to be generated on the host machine before returning a result.
The library used for random number generation in Oracle’s JVM relies on /dev/random by default for UNIX platforms. Although /dev/random is more secure, it is recommended to use /dev/urandom if the default JVM configuration have delays. Or add devices that generate entropy for /dev/random by following steps:
- Open the $JAVA_HOME/jre/lib/security/java.security file in a text editor.
- Change the line “securerandom.source=file:/dev/random” to read: securerandom.source=file:/dev/./urandom
- Save your change and exit the text editor.
You can also set up system property “java.security.egd” which will override the securerandom.source setting.
-Djava.security.egd=file:/dev/./urandom
We will also be adding this information in a readme.txt file, inside zip archive with next release.
Can you answer my original questions above? I am not sure I agree that I should have to comprise my applications security for yours. Especially, since I do not understand the needed to generate a random number during decryption of the license file. Please note your proposed solution is what I already suggested above that drops the original 20 minute wait down to 40 seconds, which I do not believe is acceptable given the reasons.
We are recorded your recent comments under the same ticket and will share further feedback with you soon.
Any update? Its been about a month, we are still blocked from taking any future upgrades until this is resolved.
Please note that the random numbers are not generated by Aspose code, but by embedded Bouncy Castle provider compatible with FIPS. This is necessary for the reason of using the library in some specific environments with customized or overridden security where problem with license validation can occur.
However, we will continue investigating this issue for upcoming release and will try to find some way to identify those configurations and use Bouncy Castle provider only if there is no other choice.
The issues you have found earlier (filed as PDFJAVA-38740) have been fixed in Aspose.PDF for Java 19.10.