2009/2/24 Krishnaveni Krishnarajah <[email protected]>
> 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. > 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. as Richard says, there's an option to clear the cache on startup (btw, the cache issue is related to the process hanging around because Windows won't let you delete files that being used by an existing process) > 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. could you post your modified launcher (or email it directly to me) I think I might be able to fix it once I see what changes you made to the original code 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.. > > 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 > > > -- Cheers, Stuart
