Krishnaveni Krishnarajah wrote:
Thanks Stuart for the detailed explanation. I completely agree with you.I
followed your suggestion for embedding using simple launcher in the OSGi in
Action examples:
http://code.google.com/p/osgi-in-action/source/browse/trunk/launcher/src/main/java/launcher/Main.java
It works great !!
Just one caveat ..
I did slight modification to
1>capture the elapsed time and
2> to delete the felix-cache directory created when it first runs so as to
get consistent elapsed time.
There is a property to tell Felix to delete the cache on first init,
look in the config.properties file for details.
First time, this runs perfect. However, in the next run, it throws exception
because it could not delete the felix-cache directory. After the first run,
I can not even delete the directory (felix-cache) manually until and unless
I kill the javaw.exe process in Task Manager.
When are you deleting the cache? This shouldn't impact anything as long
as you do it first. Are you doing successive runs? If so, you should
shutdown Felix (like in the hook code you show below) before you delete
the cache.
Looking deeper, I think, the piece of code that is supposed to "register
shutdown hook to make sure OSGi framework is shutdown when VM exits" is not
working correctly.
The irony is, when I commented that piece code that registers the shutdown
hook, Everything started working fine.
The piece of code, I am talking about is as follows:-
Runtime.getRuntime().addShutdownHook(new Thread() {
public void run() {
try {
m_framework.stop();
m_framework.waitForStop(0);
} catch (Exception ex) {
System.err.println("Error stopping framework: " + ex);
}
}
});
Besides this, everything is working great..
Must be something else going on, because I don't see any issues with the
shutdown hook.
-> richard
Additionally, You are right Richard. Felix does not hang. It was my code
that was buggy!
Thanks again ,
Krishnaveni Krishnarajah
On Mon, Feb 23, 2009 at 1:28 AM, Stuart McCulloch <[email protected]> wrote:
2009/2/23 Krishnaveni Krishnarajah <[email protected]>
Hi All,
I am trying to calculate time taken to load the bundles in Felix. I
played
around with some profiler tool such JProfiler but didn't get any easy way
out.
I finally wrote a small program to calculate the time taken. It is
import java.io.BufferedReader;
import java.io.InputStream;
import java.io.InputStreamReader;
public class CalculateTimeTaken {
/**
* @param args
*/
public static void main(String[] args) {
// Get the start time of the process
long start = System.currentTimeMillis();
System.out.println("Start: " + start);
Runtime rt = Runtime.getRuntime();
try {
String command1 = "java -jar
C:\\Users\\KK\\Desktop\\felix-1.4.1\\bin\\felix.jar";
Process pr = rt.exec("cmd /c " + command1);
InputStream is = pr.getErrorStream();
BufferedReader br = new BufferedReader(new InputStreamReader(is));
System.out.println("ERROR STARTS");
String line = null;
while ((line = br.readLine()) != null) {
System.out.println(line);
}
System.out.println("ERROR END");
int exitval = pr.waitFor();
System.out.println("exit status is " + exitval);
} catch (Exception e) {
e.printStackTrace();
}
// Get the end time of the process
long end = System.currentTimeMillis();
System.out.println("End : " + end);
long elapsedTime = end - start;
// Show how long it took to finish the process
System.out.println("The process took approximately: " + elapsedTime
+ " mili seconds");
}
}
However, this fails with following error
Start: 1235369156728
ERROR STARTS
Auto-properties install: org.osgi.framework.BundleException: Unable to
cache
bundle: file:bundle/org.apache.felix.shell-1.0.2.jar
Auto-properties install: org.osgi.framework.BundleException: Unable to
cache
bundle: file:bundle/org.apache.felix.shell.tui-1.0.2.jar
Auto-properties install: org.osgi.framework.BundleException: Unable to
cache
bundle: file:bundle/org.apache.felix.bundlerepository-1.2.1.jar
Auto-properties start: org.osgi.framework.BundleException: Unable to
cache
bundle: file:bundle/org.apache.felix.shell-1.0.2.jar
Auto-properties start: org.osgi.framework.BundleException: Unable to
cache
bundle: file:bundle/org.apache.felix.shell.tui-1.0.2.jar
Auto-properties start: org.osgi.framework.BundleException: Unable to
cache
bundle: file:bundle/org.apache.felix.bundlerepository-1.2.1.jar
Looks like it's picking up the config.properties file from the Felix
installation
(if you look at Main.java in Felix it uses the framework JAR location to
look
for the default configuration)
Unfortunately the default configuration contains relative bundle references
(as you can see in the above warning messages) which means that it can't
find these bundles - this is because we don't have an installer, otherwise
it
could fill in the absolute paths when you first install Felix
Let's say you run your program in C:\Temp...
it launches C:\Users\KK\Desktop\felix-1.4.1\bin\felix.jar
which loads C:\Users\KK\Desktop\felix-1.4.1\conf\config.properties
which refers to the "bundle" directory relative to the current directory
but your CWD is C:\Temp and C:\Temp\bundle does not exist :(
you might think the answer is for the main launcher to "cd" to the
installation
where the property files are so the relative references are ok, but this
would
not work if the installation folder was read-only and is generally a bad
idea.
the real solution is to use the -Dfelix.config.properties setting to point
Felix
to your own config file where you can give the correct bundle references
BUT... there is an even better option for your situation, which is
embedding
which would avoid all the issues with handling external processes, I/O,
etc.
and provide much more accurate benchmarking
take a look at the simple launcher in the OSGi in Action examples:
http://code.google.com/p/osgi-in-action/source/browse/trunk/launcher/src/main/java/launcher/Main.java
this is a single file that embeds Felix and installs (and starts) bundles
from
the given directory. You could easily add instrumentation to time this
startup,
you also might want to use System.nanoTime() (Java 5) for more accuracy
when timing short intervals.
After this, it hangs ...
well for one you're not consuming the output stream which means the process
could block when the output buffer is full - to avoid this sort of issue
and
the
perils of timing one Java process from a different process you should
really
use embedding (see above) which avoids all this forking around :)
but this particular hang is more likely to be because the default behaviour
of
Felix is to keep running until someone stops the main system bundle, or
kills
the process. Again embedding gives you much more control over this, take
a look at the following doc:
http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html
HTH
Any help on what the issue might be?
By the way, is there a better way to calculate the time taken to load
bundles ??
if you use embedding you can calculate the individual time to load each
bundle - but there will be all sorts of factors coming into play such as
the
existing set of loaded bundles, etc. that could potentially skew results
(adding a bundle is not a trivial operation - it can have knock-on effects
on unresolved bundles, etc. - you will probably find individual timings
vary
depending on the order that you install and start bundles, even though the
total time may remain relatively constant)
for a more detailed breakdown of where the time goes I'd strongly suggest
you use a profiler (like YourKit / JProfiler) which you can attach to your
tests
Thanks,
Krishnaveni Krishnarajah
--
Cheers, Stuart
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
