| Random Problem While Booting Virgo [message #1044214] |
Thu, 18 April 2013 12:13  |
Eclipse User |
|
|
|
Hi all,
The problem seems to be random since I can boot the server multiple times and in about one third of the booting it will be successful. Otherwise, I will always get the error :
BundleDependenciesException: Unable to satisfy dependencies of bundle 'com.omnimed.healthrecord.webapp' at version '9.0.0': Cannot resolve: com.omnimed.healthrecord.webapp
Resolver report:
Uses violation: <Import-Package: org.apache.myfaces.application; version="0.0.0"> in bundle <com.webapp_9.0.0[1366218801653]>
Resolver reported uses conflict for import constrained to bundle <org.apache.myfaces.core.impl> constrained bundle version range "[2.1.7,2.1.7]"
Uses violation: <Import-Package: org.apache.myfaces.config; version="0.0.0"> in bundle <com.webapp_9.0.0[1366218801653]>
Resolver reported uses conflict for import constrained to bundle <org.apache.myfaces.core.impl> constrained bundle version range "[2.1.7,2.1.7]"
at org.eclipse.virgo.kernel.install.pipeline.stage.resolve.internal.QuasiResolveStage.process(QuasiResolveStage.java:46)
at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessGraph(StandardPipeline.java:62)
at org.eclipse.virgo.kernel.install.pipeline.internal.CompensatingPipeline.doProcessGraph(CompensatingPipeline.java:73)
at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(AbstractPipelineStage.java:41)
at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessGraph(StandardPipeline.java:62)
at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(AbstractPipelineStage.java:41)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.driveInstallPipeline(PipelinedApplicationDeployer.java:359)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.doInstall(PipelinedApplicationDeployer.java:185)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.install(PipelinedApplicationDeployer.java:140)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.deploy(PipelinedApplicationDeployer.java:253)
at org.eclipse.virgo.nano.deployer.hot.HotDeploymentFileSystemListener.deploy(HotDeployerFileSystemListener.java:225)
at org.eclipse.virgo.nano.deployer.hot.HotDeploymentFileSystemListener.deployIfNotDeployed(HotDeployerFileSystemListener.java:237)
at org.eclipse.virgo.nano.deployer.hot.HotDeploymentFileSystemListener.onChange(HotDeployerFileSystemListener.java:88)
at org.eclipse.virgo.util.io.FileSystemChecker.notifyListeners(FileSystemChecker.java:373)
at org.eclipse.virgo.util.io.FileSystemChecker.check(FileSystemChecker.java:282)
at org.eclipse.virgo.nano.deployer.hot.WatchTask.run(WatchTask.java:48)
at java.lang.Thread.run(Thread.java:662)
The following settings have been tried to give more time to the server to boot in a effort to diagnose that possibility :
org.eclipse.virgo.kernel.startup.wait.limit from 300 (default) to 1000
deployer.timeout from 0 to 300 (default)
The testing environment consist of the Virgo Server 3.6.0 watching the repositories of a remote Virgo Server 2.1.1. We also configured the server to auto-start when the OS reboots by creating an entry in the /etc/init.d that uses a setenv.sh file in the bin folder of the server and adding the configuration in the dmk.sh file to ensure that the arguments we want are used instead of the default one. We tried impacting the configuration files in a minimal way.
Here's the setenv.sh :
MY_ARGS="-Dsun.security.ssl.allowUnsafeRenegotiation=true \
-Dorg.apache.el.parser.COERCE_TO_ZERO=false \
-Djava.rmi.server.hostname=id.adress.of.server \
-Xverify:none \
-server \
-Xms128m \
-Xmx2048m \
-Xss192k \
-XX:NewRatio=2 \
-XX:PermSize=512m \
-XX:MaxPermSize=728m \
-XX:MaxGCPauseMillis=10 \
-XX:+CMSIncrementalPacing \
-XX:CMSIncrementalDutyCycleMin=0 \
-XX:+UseParallelGC \
-XX:+UseFastAccessorMethods \
-XX:+UseStringCache \
-XX:+OptimizeStringConcat \
-XX:+UseCompressedStrings \
-Dcom.sun.management.jmxremote.ssl=false";
Here's the change to the dmk.sh :
[...]
# If we get here we have the correct Java version.
if [ -z "$NO_START_FLAG" ]
then
TMP_DIR=$KERNEL_HOME/work/tmp
# Ensure that the tmp directory exists
mkdir -p $TMP_DIR
JAVA_OPTS="$JAVA_OPTS \
-Xmx512m \
-XX:MaxPermSize=512m"
cd $KERNEL_HOME; exec $JAVA_EXECUTABLE \
$JAVA_OPTS \
$DEBUG_OPTS \
$JMX_OPTS \
-XX:+HeapDumpOnOutOfMemoryError \
-XX:ErrorFile=$KERNEL_HOME/serviceability/error.log \
-XX:HeapDumpPath=$KERNEL_HOME/serviceability/heap_dump.hprof \
-Djava.security.auth.login.config=$AUTH_LOGIN \
-Dorg.eclipse.virgo.kernel.authentication.file=$AUTH_FILE \
-Djava.io.tmpdir=$TMP_DIR \
-Dorg.eclipse.virgo.kernel.home=$KERNEL_HOME \
-Dorg.eclipse.virgo.kernel.config=$CONFIG_DIR \
-Dosgi.java.profile="file:$JAVA_PROFILE" \
-Declipse.ignoreApp=true \
-Dosgi.install.area=$KERNEL_HOME \
-Dosgi.configuration.area=$CONFIG_AREA \
-Dssh.server.keystore="$CONFIG_DIR/hostkey.ser" \
-Dosgi.frameworkClassPath=$FWCLASSPATH \
-Djava.endorsed.dirs="$KERNEL_HOME/lib/endorsed" \
-classpath $CLASSPATH \
$MY_ARGS \ <-------------------------------------------------------OUR MODIF !!!!!
org.eclipse.equinox.launcher.Main \
-noExit \
$LAUNCH_OPTS \
$ADDITIONAL_ARGS
fi
[...]
In our development environment, everything works fine. Is it a booting sequence problem when the server gets the remotely hosted jars ? By this I 'suppose' that the server tries to resolve the dependencies while loading them, which seems kind of weird, but I just ask ! Maybe it could affect the content of the remote-xyz.descriptors ?! Maybe there's not enough memory, but JConsole shows differently or I'm missing something !
Thanks in advance for your help and I'm open to test many configurations !!
|
|
|
|
Powered by
FUDForum. Page generated in 0.04817 seconds
Home