Optimizing ECC Application Startup Performance

An extremely slow ECC startup time, especially 45 minutes or more, often points toward resource starvation or system-level configuration problems. The first and most critical area to check is the ECC server’s resource allocation: please verify the assigned RAM, swap space, and CPU cores/frequency. You need to ensure that the startup process is not forced to utilize excessive swap space due to a lack of physical RAM, as disk-based swapping significantly degrades Java application startup performance.

Yes, a less common but known issue that severely impacts Java programs on newer Linux servers is a lack of sufficient system entropy, which is often needed for cryptographic operations during startup. This specific problem is detailed in Oracle Support Document 1615981.1, ‘Java Programs Are Running Slower In Newer Servers Due To Lack Of Entropy In The System’. Investigating and resolving a low entropy issue can dramatically improve the startup time for Java-based applications like ECC.

Based on the provided example configuration for an ECC Release 12.2 installation, the default heap memory settings were configured as: `ADMIN_HEAP_USER_MEM=1024M` and `MANAGED_HEAP_USER_MEM=2048M`. These are the starting points, but you may need to increase them, especially the Managed Server heap, depending on your data volume and concurrent user load. Ensure you review the memory requirements based on your specific environment size and usage profile.

In a standalone ECC installation, the domain creation script initializes Zookeeper, and the `EccConfig.properties` file sets the `CLUSTER_MODE` to `standalone`. The configuration script also updates the Zookeeper host URL, often pointing to `localhost:2181/solr`. Because it’s standalone, the script also sets the replication factor, updating the property `dataset.num.replicas=1`, confirming that no replication is occurring. Zookeeper management is then started successfully along with the `eccManaged` server.

The error ‘No live SolrServers available to handle this request’ often appears after cloning EBS because the ECC environment loses connection or trust with the new EBS configuration. To resolve this, after cloning, you must recreate the JNDI connection within the ECC instance by following the steps outlined in the documentation, specifically the section on ‘Configuring the JNDI to Connect to Oracle E-Business Suite’. After updating the JNDI, you need to bounce (restart) the ECC services to ensure the changes take effect and connectivity to the new EBS clone is re-established.