...
Most of the issues you may find when running Geronimo will be at start up time; and most likely driven by some conflicting resources from the environment where Geronimo is set up.
...
JVM arguments
Apache Geronimo v2.2 is Java EE certified. With that said, it will likely run on different JVM versions however the results may be unpredictable. Whenever possible use jdk 1.5 or above.
...
- startup.sh or geronimo.sh run
- set JAVA_OPTS environment variable:
No Format borderStyle solidjeffchi@Local:~/geronimo-tomcat6-javaee5-2.2-SNAPSHOT$ export JAVA_OPTS="-Xmx256m -XX:MaxPermSize=128m -XX:+HeapDumpOnOutOfMemoryError" jeffchi@Local:~/geronimo-tomcat6-javaee5-2.2-SNAPSHOT$./bin/geronimo.sh run - and/or append the following code to
<Geronimo_Home>/bin/setjavaenv.sh(bat)
file:Code Block if [ -z "$JAVA_OPTS" ]; then JAVA_OPTS="-Xmx256m -XX:MaxPermSize=128m -XX:+HeapDumpOnOutOfMemoryError" fi
- set JAVA_OPTS environment variable:
- start-server or gsh geronimo/start-server
- edit
<Geronimo_Home>/etc/rc.d/start-server,default.groovy
file:Code Block // Append some reasonable java flags if none were configured already if (command.javaFlags.empty) { command.javaFlags << '-Xmx256m' command.javaFlags << '-XX:MaxPermSize=128m' command.javaFlags << '-XX:+HeapDumpOnOutOfMemoryError' } - or use -J flag:
No Format BorderStyle Solidjeffchi@Local:~/geronimo-tomcat6-javaee5-2.2-SNAPSHOT$./bin/gsh geronimo/start-server -J "-Xmx256m -XX:MaxPermSize=128m -XX:+HeapDumpOnOutOfMemoryError"
- edit
Port conflicts
The second most common startup issue is associated to port conflicts, check no other application is using or blocking Geronimo's default ports:
...
If your application contains its own version of Spring you might see some problems deploying or running the application on the Jetty assembly. The Jetty assembly is by default configured with Apache CXF as the JAX-WS provider. Apache CXF uses Spring to configure itself. Sometimes, the Spring version used by CXF conflicts with the Spring version supplied with your application. To prevent these conflicts add the following <hidden-classes> entry to the Geronimo deployment descriptor:
...
...
java.lang.UnsatisfiedLinkError: lic (Library is already loaded in another ClassLoader)
...
To avoid the problem, you may try Adding JARs to the Geronimo repository and define the dependency in your deployment plan.
See Also : https://issues.apache.org/jira/browse/GERONIMO-4629
Enable multicasting for IPv4 network
...
java.io.IOException of remote EJB on Windows
...
One possibility is that the available user port numbers are being exhausted. On Windows, when a socket is closed, it goes into a TIME_WAIT state and isn't actually closed until some delay time. By default, the max user port address is 5000 and the TIME_WAIT delay is 4 minutes. So, it's not too difficult to exhaust all possible user port addresses.
You have to update the Windows Registry to change these values. Here's a Windows 2000 doc on the registry settings – http://technet.microsoft.com/en-us/library/bb726981.aspx
- MaxUserPorts controls the upper range for user ports.
- TcpTimedWaitDelay controls the TIME_WAIT delay.
Increasing MaxUserPorts (e.g. 65534) and decreasing TcpTimedWaitDelay (e.g. 30) may fix the problem.
...
Most likely Geronimo server was not shut down cleanly, which results in ActiveMQ log files to have an unexpected entry. You can avoid this by editing var/activemq/conf/activemq.xml
and adding schedulerSupport="false" if you don't require JobScheduler support:
...
...