I was a little bit busy this week, I am writing my bachelor thesis right now, the dealine is 29 of May, but I have good news about the gsoc project - now I can profile sip-communicator with
All the profilers have own peculiar features concerning the configuration. General rule for profiling sip-communicator is to provide bundles implicit access to stuff on the class path in sip-comm\lib\felix.client.run.properties. This is obligatory because of OGSi architecture - you need to delegate a boot of profiler classes first. Only exclusion was NetBeans, it supports a dynamic profiler attachment for a running application (only with java6 +), but the use of direct invocation is also available.
So if you wish to use sip-communicator with a profiler listed before insert the next a definition in felix.client.run.properties:
- org.osgi.framework.bootdelegation=com.sun.demo.jvmti.hprof.* \
- org.osgi.framework.bootdelegation=org.eclipse.tptp.martini.* \
- org.osgi.framework.bootdelegation=org.netbeans.lib.profiler.server.* \
- org.osgi.framework.bootdelegation=com.jprofiler.agent.*\
If you use another profiler, you will see a missing package in the exception.
As netbeans uses ant for running the sip-communicator, I made an ant task for profiling it.
Next steps:
Read the profilers documentation, see the profiling tutorials (i.e. http://www.ej-technologies.com/products/jprofiler/tutorials.html), try to profile demo applications and sip-communicator - to get some profiling experience for a start.
P.S. Thanks to Thiago Bolaum for the help with working under TPTP. Your information was very essential.
