Bitnami Alfresco Failing to Start

Over the past two days I have been working on getting a very old instance of Bitnami Alfresco Community Server to actually start. Unfortunately for the most parts the logs were not providing anything useful. After a bit of cleanup of Tomcat Caching I was able to finally get proper logging and a solution to the problem without having to upgrade the AWS instance.

First, the ‘alfresco.log’ log was owned by root so the tomcat user could not write to it which prevented much troubleshooting outside of hope, dreams crossing fingers and a bit of strace. But anyone who has ever straced java can tell you it’s almost useless unless of course you have time to scour tens of thousands of lines of system calls; which lets be honest, none of us do.

Moving forward I started seeing logs like:

Caused by: java.lang.OutOfMemoryError: Java heap space
  at java.util.Arrays.copyOfRange(
  at java.lang.String.<init>(
  at java.lang.String.toUpperCase(
  at org.apache.ibatis.executor.resultset.FastResultSetHandler.loadMappedAndUnmappedColumnNames(
  at org.apache.ibatis.executor.resultset.NestedResultSetHandler.getRowValue(
  at org.apache.ibatis.executor.resultset.NestedResultSetHandler.applyNestedResultMappings(
  at org.apache.ibatis.executor.resultset.NestedResultSetHandler.getRowValue(
  at org.apache.ibatis.executor.resultset.NestedResultSetHandler.handleRowValues(
  at org.apache.ibatis.executor.resultset.FastResultSetHandler.handleResultSet(
  at org.apache.ibatis.executor.resultset.FastResultSetHandler.handleResultSets(
  at org.apache.ibatis.executor.statement.PreparedStatementHandler.query(
  at org.apache.ibatis.executor.statement.RoutingStatementHandler.query(
  at org.apache.ibatis.executor.SimpleExecutor.doQuery(
  at org.apache.ibatis.executor.BaseExecutor.query(
  at org.apache.ibatis.executor.CachingExecutor.query(
  at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(
  at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(
  at sun.reflect.GeneratedMethodAccessor214.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(
  at java.lang.reflect.Method.invoke(
  at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(
  at com.sun.proxy.$Proxy6.selectList(Unknown Source)
  at org.mybatis.spring.SqlSessionTemplate.selectList(
  at org.alfresco.repo.domain.node.ibatis.NodeDAOImpl.selectNodesByUuids(
  at org.alfresco.repo.domain.node.AbstractNodeDAOImpl.cacheNodes(
  at org.alfresco.repo.domain.node.AbstractNodeDAOImpl.cacheNodes(
  at org.alfresco.repo.domain.node.AbstractNodeDAOImpl$ChildAssocRefBatchingQueryCallback.done(
  at org.alfresco.repo.domain.node.ibatis.NodeDAOImpl.selectChildAssocs(
  at org.alfresco.repo.domain.node.AbstractNodeDAOImpl.getChildAssocs(
  at org.alfresco.repo.node.db.DbNodeServiceImpl.getChildAssocs(
  at org.alfresco.repo.node.db.DbNodeServiceImpl.getChildAssocs(
  at org.alfresco.repo.node.db.DbNodeServiceImpl.getChildAssocs(

This lead me to an obvious memory issue while troubleshooting the start up of the Alfresco service. Checking the environment variables for the running process I saw it only had 512M allocated to the process shown below:

# cat /proc/$(ps auwx | grep jsvc | head -1 | awk '{print $2}')/environ | sed 's/\x0/\n/g' | grep JAVA_OPTS
JAVA_OPTS=-XX:MaxPermSize=512m -Xms256m -Xmx512m -Djava.awt.headless=true -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

There was nearly 4G of ram available on this box and the only application running was Alfresco on top of Tomcat; so whomever setup the server never actually configured Java to use enough memory to perform properly. So this ended up being a relatively easy fix by just increasing the memory in the JAVA_OPTS variable. You can do this in one of the following files:

  • /opt/bitnami/apache-tomcat/scripts/
  • /opt/bitnami/apache-tomcat/bin/

Write a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.