Eclipse Community Forums: Virgo » Random Problem While Booting Virgo

Home » Eclipse Projects » Virgo » Random Problem While Booting Virgo(Uses violation problem with uses conflict for import that occurs randomly when booting the Virgo server.)

Show: Today's Messages :: Show Polls :: Message Navigator

Random Problem While Booting Virgo [message #1044214]

Thu, 18 April 2013 16:13

FreeSpeech Mising name

Messages: 2
Registered: September 2009

Junior Member

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 !!

Report message to a moderator

Re: Random Problem While Booting Virgo [message #1058251 is a reply to message #1044214]

Mon, 13 May 2013 11:11

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

One possibility is that the Equinox resolver is sometimes timing out during its resolution process. I think there is a way to configure the timeout in Equinox, but I can't find the configuration parameter in the public documentation. But see bug 359862 for details.

Report message to a moderator

Previous Topic:	Redeploy / ClassLoader problem
Next Topic:	bundle in ext directory cannot be resolved

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 18:10:46 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter