You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Krishnaveni Krishnarajah <kr...@gmail.com> on 2009/02/23 07:10:09 UTC
Time taken to load OSGi bunlde in Felix
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
After this, it hangs ...
Any help on what the issue might be?
By the way, is there a better way to calculate the time taken to load
bundles ??
Thanks,
Krishnaveni Krishnarajah
Re: Time taken to load OSGi bunlde in Felix
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/2/24 Krishnaveni Krishnarajah <kr...@gmail.com>
> 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 <mc...@gmail.com>
> wrote:
>
> > 2009/2/23 Krishnaveni Krishnarajah <kr...@gmail.com>
> >
> > > 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
Re: Time taken to load OSGi bunlde in Felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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 <mc...@gmail.com> wrote:
>
>
>> 2009/2/23 Krishnaveni Krishnarajah <kr...@gmail.com>
>>
>>
>>> 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Time taken to load OSGi bunlde in Felix
Posted by Krishnaveni Krishnarajah <kr...@gmail.com>.
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.
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..
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 <mc...@gmail.com> wrote:
> 2009/2/23 Krishnaveni Krishnarajah <kr...@gmail.com>
>
> > 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
>
Re: Time taken to load OSGi bunlde in Felix
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/2/23 Krishnaveni Krishnarajah <kr...@gmail.com>
> 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
Re: Time taken to load OSGi bunlde in Felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Krishnaveni Krishnarajah wrote:
> 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
>
>
> After this, it hangs ...
>
Stuart has given a pretty good explanation in another mail...I was just
going to add that it hasn't "hung", it is running fine, but no
interactive shell was installed (because of the errors you mention), so
there is no way to do anything. Felix is running fine, though. :-)
-> richard
> Any help on what the issue might be?
>
>
> By the way, is there a better way to calculate the time taken to load
> bundles ??
>
> Thanks,
> Krishnaveni Krishnarajah
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org