AnsweredAssumed Answered

Serious startup issue with 4.2.d community

Question asked by smcardle on Oct 23, 2013
Latest reply on Oct 17, 2014 by ivan.plestina
Hi All

We have just upgraded to <strong>4.2.d</strong> and the startup time for the alfresco.war is <strong>REALLY REALLY BAD……</strong>

On our previous version, <strong>Community - v4.1.0 (4180)</strong> (this version was never officially released but we had an early release and got it working properly) the startup time was just a few minutes. This was upgraded from 3.4.x and we had no performance or startup issues with either…..

With this <strong>4.2.d</strong> release the Search subsystem startup is taking about <strong>half an hour!!!!</strong> What gives ???

<blockcode>

2013-10-24 08:50:33,733  INFO  [management.subsystems.ChildApplicationContextFactory] [localhost-startStop-1] Starting 'Authentication' subsystem, ID: [Authentication, managed, alfrescoNtlm1]
2013-10-24 08:50:33,905  INFO  [management.subsystems.ChildApplicationContextFactory] [localhost-startStop-1] Startup of 'Authentication' subsystem, ID: [Authentication, managed, alfrescoNtlm1] complete
2013-10-24 08:51:14,835  INFO  [management.subsystems.ChildApplicationContextFactory] [localhost-startStop-1] Starting 'Search' subsystem, ID: [Search, managed, lucene]
2013-10-24 09:22:26,778  WARN  [cache.node.nodesTransactionalCache] [localhost-startStop-1] Transactional update cache 'org.alfresco.cache.node.nodesTransactionalCache' is full (125000).
2013-10-24 09:22:31,812  WARN  [cache.node.aspectsTransactionalCache] [localhost-startStop-1] Transactional update cache 'org.alfresco.cache.node.aspectsTransactionalCache' is full (65000).
2013-10-24 09:22:31,865  WARN  [cache.node.propertiesTransactionalCache] [localhost-startStop-1] Transactional update cache 'org.alfresco.cache.node.propertiesTransactionalCache' is full (65000).
2013-10-24 09:27:22,344  INFO  [management.subsystems.ChildApplicationContextFactory] [localhost-startStop-1] Startup of 'Search' subsystem, ID: [Search, managed, lucene] complete
2013-10-24 09:27:23,562  INFO  [management.subsystems.ChildApplicationContextFactory] [localhost-startStop-1] Starting 'thirdparty' subsystem, ID: [thirdparty, default]

</blockcode>

As you can see from the above, the time taken to start the Search subsystem is 08:51:14,835 (Starting) to 09:27:22,344 (Complete) <strong>36 minutes !!! HOLY C%$P Batman……</strong> All of our installs have the same JVM settings and have 4gig heap allocated and they all run on Centos 6

We have Lucene configured as the index solution rather than SOLR on all our systems, with the exact same amount of data in each (millions or small records copied from a production instance) and went through a schema upgrade cycle to the new 4.2.d schema that completed successfully.

Because we run SQLServer 2008 as our DB, for each version upgrade I first copy and migrate the upgrade scripts from MySQL to make them SQLServer complient

(By the way, there is an issue in the code regarding upgrades in the ExportDB.java - SQLServer returns "YES " - with a Space when checking the nullability of a column. To fix this change the parseBoolean method to the following - only the trim is really require here)


    private boolean parseBoolean(String nullableString)
    {
        // TODO: what about (from the javadoc):
        // empty string — if the nullability for the parameter is unknown
        if (nullableString.trim().toLowerCase().equals("no"))
        {
            return false;
        }
        if (nullableString.trim().toLowerCase().equals("yes"))
        {
            return true;
        }
       
        throw new IllegalArgumentException("Unsupported term \"" + nullableString +
                    "\", perhaps this database doesn't use YES/NO for booleans?");
       
    }



Some help here please people….. We really can't have a system taking over half an hour to start..


Regards

Steve

Outcomes