The startup times of our server software are often badly affected by Aspose’s slow license checks. The issue occurs due to the fact that Aspose’s license check seems to require sufficient entropy available on the machine. Since many of our deployments are headless servers, sufficient entropy is hard to come by. In future updates, could Aspose please remove the SecureRandom dependency from their license check?
Hi Jamie,
Sure. Write a program to perform license checks using all components under Aspose Total. Thereafter, create a new clean instance of Debian headless server on Amazon/Google Compute/Azure. Without doing too much, run:
The point is on some machine the Aspose license checks are slowing the startup of our server in some cases to an unacceptable 15 minutes.
Do not install the desktop version of Linux, only headless. See linux - How does the kernel entropy pool work? - Stack Overflow for description of how this works.
Hi,
Hi,
Could you please share the specs of your VM with us? e.g. m1, m2 or m4 and instance type (small, medium or large). Please share the CPU and memory specifications with us for our consideration. We’re having some problems establishing environment on the Cloud server and will try to establish a local VM of these specs for investigating the issue further our end.
The size of the VM shouldn’t matter. We installed Headless Ubuntu server 16.04 on Google Compute.
When the OS doesn’t have enough entropy, Aspose takes ages to start. You simply have to create the conditions whereby there is not enough entropy on a machine, such as a clean install of Linux headless.
Hi Jamie,
Hi Jamie,
This is because the entropy is not used up yet. Please adjust your license checks not to use SecureRandom and other algorithms that might require entropy on the machine.
Due Aspose license check problems, I have to implement the below and in fact our server starts up before Aspose is even initialized because Aspose typically takes 2-3 minutes and sometimes 10 minutes to startup on a machine low on entropy.
private static void initAsposeLicense() {
ExecutorService execute = Executors.newCachedThreadPool(ThreadUtil.getFlexibleThreadFactory(“aspose”, false));
execute.execute(new InitAsposeLicense(new com.aspose.cells.License(), ASPOSE_LICENSE_FILENAME));
execute.execute(new InitAsposeLicense(new com.aspose.words.License(), ASPOSE_LICENSE_FILENAME));
execute.execute(new InitAsposeLicense(new com.aspose.email.License(), ASPOSE_EMAIL_LICENSE_FILENAME));
execute.execute(new InitAsposeLicense(new com.aspose.slides.License(), ASPOSE_LICENSE_FILENAME));
//takes a very long time to license & we are not using it.
[//executor.execute](https://executor.execute/)(new InitAsposeLicense(new com.aspose.pdf.License(), ASPOSE_LICENSE_FILENAME));
}
static class InitAsposeLicense extends Thread {
private final String filename;
private final Object license;
InitAsposeLicense(Object license, String filename) {
this.license = license;
this.filename = filename;
setName("initaspose {filename='" + filename + "'");
}
@Override
public void run() {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
try (InputStream is = cl.getResourceAsStream(filename)) {
license.getClass().getDeclaredMethod("setLicense", java.io.InputStream.class).invoke(license, is);
} catch (Exception e) {
logger.error("failed to license aspose:" + e.getMessage() + " {filename='" + filename + "'}", e);
}
}
}
Thank you for getting back to us and sharing your feedback. If we consider this requirement to be fulfilled on your end or do we need to help you further in this regard.
This issue has been brought up on a number of occasions by different Aspose customers, and rather than deal with the issue Aspose chooses to ignore it. It apparently isn’t problematic that the Aspose library would delay the startup of an entire enterprise software product by ten minutes or more due to a licensing check. Its a classic case of working in a bubble and not listening to the real world needs of your customers.
We are sorry for your inconvenience. We are verifying this on our end and an issue with ID EMAILNET-39654 has been created in our issue tracking system to further investigate and resolve the issue. This thread has been linked with the issue so that you may be notified once the issue will be addressed.