Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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.)
Random Problem While Booting Virgo [message #1044214] Thu, 18 April 2013 12:13 Go to next message
FreeSpeech Mising name is currently offline 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 !!
Re: Random Problem While Booting Virgo [message #1058251 is a reply to message #1044214] Mon, 13 May 2013 07:11 Go to previous message
Glyn Normington is currently offline 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.
Previous Topic:Redeploy / ClassLoader problem
Next Topic:Creating test - doesn't reach to the point where tests are executed
Goto Forum:
  


Current Time: Thu Apr 24 14:43:42 EDT 2014

Powered by FUDForum. Page generated in 0.02373 seconds