[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [virgo-dev] Classloading & Inner frameworks supportability commands
|
Hi,
We thought about contributing the features to Equinox, but we feel that they don't quite fit there because:
1. we want to expand the value and attractiveness of Virgo as development platform
2. we want a level of supportability that will meet our expectations and the ones of the Virgo users
We think this can be easily done by just adding these commands without integration. Long-term they may become APIs, and automation can be also included (probably integration with the medic module)
3. Equinox should be kept minimalistic
4. The Equinox shell most probably will be RFC-147 compliant
The minimalistic approach of Equinox often leads to the fact that it is mostly used in headless scenarios - no users/developers in front, therefore we do not need commands there. If we need them we can always install a bundle or two to check a problem. In case we have a development environment things change - the common case is that we have a developer that tries different things and needs diagnostics almost constantly.
There are ongoing efforts to split the Equinox shell and framework. Therefore there may not be shell by default and an arbitrary shell may be plugged. Another idea is to have the commands as bundles. For example GoGo offers such implementation with 3 bundles (shell, runtime, commands). GoGo is also the reference RFC147 implementation and this RFC standardizes the split.
In this regard Virgo can be considered as natural extension of Equinox for development so the diagnostics modules fit more than in Equinox. This is especially true for the inner framework commands which are useful in case of a complex scenario ("felix inside equinox" may be "application inside Virgo") and are most of the time useless in the minimalistic Equinox environment.
We agree that the classloading commands may be equally useful in Equinox environment but since the commands will be separated from the shell and not needed most of the time perhaps it makes sense to have them in Virgo.
The javaagent is used to instrument on FrameworkEvent level. If the event is:
- START then a bytecode modification is made in the constructor to register the framework in the library
- STOP - the framework is unregistered from the framework to allow GC
The registration creates a reference to the bundle of the (inner) framework, but this reference is cleared on STOP event via the agent so we expect no memory leaks.
The instrumentation is currently always on to allow gathering of all FrameworkEvent-s from the start of the VM. We did not make measurements for the overhead but it should be pretty small since a transformation is made only in case a new FrameworkEvent is created, which seems to be a rare case. The only negative impact seems to be on installation of lots of new bundles. Are there any plans to change the way that Virgo starts - with installation of all bundles? What about P2?
I uploaded my Virgo (kernel) with running agent and the commands in the pickup folder here:
https://sapmats-de.sap-ag.de/download/download.cgi?id=MVAKNGY7TWT8IHVDQ3TJOMGYM99L4TKNNZQK3E8MVOIXMN3PAP
Since I'm running on Windows you may need to change the dmk.sh the same way as dmk.bat. I added the agent in this way: set KERNEL_JAVA_PARMS=%KERNEL_JAVA_PARMS% -javaagent:C:\tmp\virgo-kernel-2.1.0.M01\inner\FDAgent_1.1.jar
Regards,
Hristo Iliev
-----Original Message-----
From: virgo-dev-bounces@xxxxxxxxxxx [mailto:virgo-dev-bounces@xxxxxxxxxxx] On Behalf Of Glyn Normington
Sent: Tuesday, July 06, 2010 10:55 AM
To: Virgo Project
Subject: Re: [virgo-dev] Classloading & Inner frameworks supportability commands
Hi Hristo
Thanks for bringing forward this contribution! Diagnostics and debug aids are certainly an important area for Virgo.
A basic question first: why do you think this contribution is more applicable to Virgo than to base Equinox?
Next - please could you explain why it is necessary to use a javaagent as that could potentially cause performance issues and it seems to cut across the normal OSGi class loading style?
Are there any parts of the code which hold on to references to class loaders and which may prevent normal garbage collection from occurring?
I'll probably have more questions later, but I thought it would be worth trying the code out so I followed your instructions and, on a Mac, got the following:
>java -version
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)
> ls /Users/glynnormington/contrib/inner_frk/
FDAgent_1.1.jar FDLib.jar FrameworkInfoCommand_1.1.1.jar javassist.jar
> echo $JAVA_OPTS
-javaagent:/Users/glynnormington/contrib/inner_frk/FDAgent_1.1.jar
> bin/startup.sh
Exception in thread "main" java.lang.NoClassDefFoundError: javassist/NotFoundException
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.getMethod0(Class.java:2670)
at java.lang.Class.getMethod(Class.java:1603)
at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:294)
at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:338)
Caused by: java.lang.ClassNotFoundException: javassist.NotFoundException
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
... 6 more
FATAL ERROR in native method: processing of -javaagent failed
/Users/glynnormington/virgo-web-server-2.1.0.M01/bin/dmk.sh: line 228: 5531 Abort trap $JAVA_HOME/bin/java $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=$CONFIG_DIR/org.eclipse.virgo.kernel.authentication.config -Dorg.eclipse.virgo.kernel.authentication.file=$CONFIG_DIR/org.eclipse.virgo.kernel.users.properties -Djava.io.tmpdir=$TMP_DIR -Dorg.eclipse.virgo.kernel.home=$KERNEL_HOME -classpath $CLASSPATH org.eclipse.virgo.osgi.launcher.Launcher -config $KERNEL_HOME/lib/org.eclipse.virgo.kernel.launch.properties -Forg.eclipse.virgo.kernel.home=$KERNEL_HOME -Forg.eclipse.virgo.kernel.config=$CONFIG_DIR -Fosgi.configuration.area=$KERNEL_HOME/work/osgi/configuration -Fosgi.java.profile="file:$KERNEL_HOME/lib/java6-server.profile" $LAUNCH_OPTS $ADDITIONAL_ARGS
Any ideas?
Thanks,
Glyn
On 5 Jul 2010, at 11:40, Iliev, Hristo wrote:
Hi,
We are currently working on some supportability features for OSGi and in particular Equinox. This includes:
* Classloading - by a given class name list all bundles that:
o contain it
o export it
o can load it
* Inner frameworks
o lists all inner frameworks in a tree view
o lists details:
* Start time
* Origin bundle
* System bundle's class
* Startup call stack
o executes certain commands in the inner framework (list, start/stop, install/uninstall/update)
The classloading commands (bundle) can be found here:
https://sapmats-de.sap-ag.de/download/download.cgi?id=CUWKAJZQLCZSTY7Z2185H84U6AAYD0DRXF4AYH91J8HGVL9SD7
The inner framework files can be found inside the zip located here:<https://wiki.wdf.sap.corp/wiki/download/attachments/759500197/inner_frk.zip>
https://sapmats-de.sap-ag.de/download/download.cgi?id=KK9O6JT63JK03W4QTOZMFW6SJGF77VIK9VKNUZMUWKJCBZX8F3
To install the inner framework bundles & agent:
1. Place the three main components in one folder (Java agent(FDAgent), Collector library(FDLib), instrumentation library(javassist))
2. Add the package of the framework collector library (com.sap.osgi.frameworkdetection.lib) to the bootdelegation property (org.osgi.framework.bootdelegation). Before starting the server add -javaagent:<path-to-the-agent>FDAgent_1.1.jar to the command line after the java keyword.
3. Install the Framework Detection Command bundle in the Equinox environment you just launched, start that bundle and use the commands it provides.
We would like to contribute the code to Virgo since we think the commands will make the diagnostics of problems (often needed in server environment) much easier.
What do you about this idea?
Regards,
Hristo Iliev
<ATT00001..txt>
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev
