Serious startup issue with 4.2.d community

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

smcardle

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

eswbitto

We are using 4.2.d on Centos 6.4 (postgresql) and have 4 GB of ram on a VM via proxmox. This server is dedicated to Alfresco only. I will say it does gobble up the entire 4 GB at times. Do you have other services running on yours?

Server start up time is like 15 seconds. Restarting takes a good 2-3 minutes, but that is probably do to the fact open/close all the sockets.

If I were you I would try installing a second instance of alfresco with different service name, but use postgresql from the binary installer to try and rule out some area's.

Have you tried using solr instead of lucene?
Maybe re-indexing?
If you have a test lab setup then maybe try those.