Alfresco Will Not Start Using 64-bit JVM

[tommorris]

Hello,

Outline:
I'm installing alfresco in a 64-bit environment,
and I *can* get alfresco to start,
but only if the start-up batch file is tweaked.

Environment:
Multiprocessor/Dual core Intel Xeon, 4GB RAM.
MS Windows Server 2003 R2, Standard x64 Edition, Service Pack 2.
Using 64-bit JVM 1.6u3 (jdk-6u3-windows-amd64)
Using Alfresco 2.1.1 enterprise

The Problem:
A StackOverflowError stack-trace terminates the start-up of tomcat,
meaning no web-app server, no webapp, so no alfresco.

Mitigation:
It appears that 64KB is too small a thread stack size to use for the start-up script, so I changed the parameter "-Xss64k" to "-Xss128k" and alfresco then starts normally.

Summary:
I hope this is helpful to other people, but I'm not sure I really understand the issue.

Why does this work in a 32-bit but not a 64-bit environment?
(I guess the larger addressable space simply consumes more memory)

Does this happen for everyone in a similar scenario?

If so, should alfresco record this as part of the installation documentation?

Can I expect further memory-management issues, because of this change?
(for a web-app, I can see that keeping the thread-stack smallish is preferable)

One more thing. Does anyone know if there is any different between these two JVM options?
-Xss128k    …and…    -XX:ThreadStackSize=128k


Many thanks,
Tom Morris
http://www.ixxus.com
Alfresco Partner.


Diagnostic Info:
I removed the "start" prefix to capture the stack-trace, shown below.

E:\Alfresco>"C:\Java\jdk1.6.0_03\bin\java" -Xms128m -Xmx512m -Xss64k -server -XX:CompileCommand=exclude,org/ap
ache/lucene/index/IndexReader$1,doBody -XX:CompileCommand=exclude,org/alfresco/repo/search/impl/lucene/index/I
ndexInfo$Merger,mergeIndexes -XX:CompileCommand=exclude,org/alfresco/repo/search/impl/lucene/index/IndexInfo$M
erger,mergeDeletions  -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.co
nfig.file="E:\Alfresco\tomcat\conf\logging.properties"   -Djava.endorsed.dirs="E:\Alfresco\tomcat\common\endor
sed" -classpath "C:\Java\jdk1.6.0_03\lib\tools.jar;E:\Alfresco\tomcat\bin\bootstrap.jar" -Dcatalina.base="E:\A
lfresco\tomcat" -Dcatalina.home="E:\Alfresco\tomcat" -Djava.io.tmpdir="E:\Alfresco\tomcat\temp" org.apache.cat
alina.startup.Bootstrap  start
CompilerOracle: exclude org/apache/lucene/index/IndexReader$1 doBody
CompilerOracle: exclude org/alfresco/repo/search/impl/lucene/index/IndexInfo$Merger mergeIndexes
CompilerOracle: exclude org/alfresco/repo/search/impl/lucene/index/IndexInfo$Merger mergeDeletions
java.lang.StackOverflowError
        at java.lang.String.startsWith(String.java:1420)
        at java.lang.String.startsWith(String.java:1451)
        at sun.misc.MetaIndex.mayContain(MetaIndex.java:225)
        at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:744)
        at sun.misc.URLClassPath.getResource(URLClassPath.java:168)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:192)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
        at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
        at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
        at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:222)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:410)

[tommorris]

This appears to be more complicated than I first thought.
Getting it to work as a service is tricky since the tomcat distribution only comes with a 32-bit service wrapper and not a 64-bit wrapper.
(from what I gathered elsewhere in the forums). Customer installations will of course need to run as services.

You can get some appropriate compilations to manually replace the 32-bit executables for 64-bit substitutes, for example at this location: http://svn.apache.org/viewvc/tomcat/connectors/tags/tc5.5.x/TOMCAT_5_5_25/procrun/bin/ia64/

This obviously doesn't seem to be out-of-the-box support for a 64-bit environment.
(I've noticed that some of Alfresco's benchmarks are based on a 64-bit platform, which perhaps isn't completely fair…)

I thought about using Tomcat 6, but this is not supported by Alfresco either.      
Supported stack can be seen here: http://88.208.218.102/services/support/stacks/2.1/

Could Alfresco provide more detail for the supported-stack page please?
It doesn't provide recommended point-release version numbers, nothing for java version, an no 32/64-bit details.

Could Alfresco respond to clarify this issue? Perhaps I'm misunderstanding things.

In the mean time, we're going to revert to using a 32-bit JVM instead.

Many thanks.

[steve]

Hi Tom,

We support 64bit versions of Linux - and it was on a 64bit Linux that our benchmarks are run on.

Since Tomcat5 doesn't supply 64bit executables for Windows we can't test with them therefore we don't support them.

We are looking into running on and supporting Tomcat 6 soon - we have to make some config changes to get it to work.

Since 64bit support is much more mature in Linux than in Windows we'd recommend that you use a 32bit stack in a Windows environment, and if you want to use a 64bit stack switch to Linux.

Steve

[tommorris]

Thanks Steve. That's nice and clear.

I hope you can arrange modification of the supported-stack wiki-page to provide this info (and the other info I mentioned). This would be helpful to the community.

Thanks again.