Re: [Vote] release maven-bundle-plugin 1.4.0

2008-02-25 Thread Karl Pauls 
   Hi folks,
  
   I'd like to start a vote for the 1.4.0 release of the maven-bundle-plugin,
   which now has complete integration of the OBR goals with the bundle
   life-cycle (plus a couple of improvements made possible by this work)
   along with support for attaching bundles with different classifiers.
  
   I've built and signed the release candidate and made it available here:
  
 http://people.apache.org/~mcculls/releases/felix/maven-bundle-plugin
  
   You can also find the KEYS file for verifying the signature in this
   directory.
   Please check the release and cast your votes!   (vote will run for 72hrs)


  guess I shouldn't start a vote late on Friday ;)
  anyone else have time to check this release?

Yes, it's kind of tricky to go with the 72 hours rule and start
counting on Friday :-)

I'll have some time tonight

regards,

Karl

  --
   Cheers, Stuart
  

  --
  Thanks, Stuart




-- 
Karl Pauls
[EMAIL PROTECTED]

Re: [Vote] release maven-bundle-plugin 1.4.0

2008-02-25 Thread Carsten Ziegeler 

Karl Pauls wrote:

   Hi folks,

 
  I'd like to start a vote for the 1.4.0 release of the maven-bundle-plugin,
  which now has complete integration of the OBR goals with the bundle
  life-cycle (plus a couple of improvements made possible by this work)
  along with support for attaching bundles with different classifiers.
 
  I've built and signed the release candidate and made it available here:
 
http://people.apache.org/~mcculls/releases/felix/maven-bundle-plugin
 
  You can also find the KEYS file for verifying the signature in this
  directory.
  Please check the release and cast your votes!   (vote will run for 72hrs)


 guess I shouldn't start a vote late on Friday ;)
 anyone else have time to check this release?


Yes, it's kind of tricky to go with the 72 hours rule and start
counting on Friday :-)

I'll have some time tonight


Same here :)

Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]

Performance problems in classloading

2008-02-25 Thread Guillaume Nodet 
I'm currently working on ServiceMix 4 which uses Felix.\

I have some really important performance problems in classloading.
When loading JBI applications (they have some very specific
classloading architecture
that must be implemented to be JBI compliant), 95% of the time  is
spent in the following method:
   R4SearchPolicyCore.diagnoseClassLoadError()
which is not really acceptable.

The problem is that the classloader is built dynamically and does not
completely rely on
OSGi.  For this reason, the classloader of JBI artifacts delegates to
the parent classloader,
then looks inside its own jar.  This means there will be lots of
ClassNotFoundException thrown
by the parents classloader (ultimately by Felix).

Is there any way to maybe speed / disable the diagnoseClassLoadError
method call which
is purely informative ?

I know the design of the JBI classloaders is not really a good fit in
OSGi, so I will investigate
a better solution (leveraging more of OSGi classloaders) anyway, but I
still wanted to report
the problem.

-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: Performance problems in classloading

2008-02-25 Thread Stuart McCulloch 
On 25/02/2008, Guillaume Nodet [EMAIL PROTECTED] wrote:

 I'm currently working on ServiceMix 4 which uses Felix.\

 I have some really important performance problems in classloading.
 When loading JBI applications (they have some very specific
 classloading architecture
 that must be implemented to be JBI compliant), 95% of the time  is
 spent in the following method:
R4SearchPolicyCore.diagnoseClassLoadError()
 which is not really acceptable.

 The problem is that the classloader is built dynamically and does not
 completely rely on
 OSGi.  For this reason, the classloader of JBI artifacts delegates to
 the parent classloader,
 then looks inside its own jar.  This means there will be lots of
 ClassNotFoundException thrown
 by the parents classloader (ultimately by Felix).

 Is there any way to maybe speed / disable the diagnoseClassLoadError
 method call which
 is purely informative ?


we could try a lazy-load approach (ie. only construct the string in the
getMessage method)
for example, you might want to see if the following patch helps, based on
the current trunk:

Index:
src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
===
---
src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
(revision 630859)
+++
src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
(working copy)
@@ -178,7 +178,7 @@
 return null;
 }

-public Class findClass(IModule module, String name)
+public Class findClass(final IModule module, final String name)
 throws ClassNotFoundException
 {
 try
@@ -191,8 +191,14 @@
 }
 catch (ClassNotFoundException ex)
 {
-String msg = diagnoseClassLoadError(module, name);
-throw new ClassNotFoundException(msg, ex);
+// lazy construction of exception message
+throw new ClassNotFoundException(, ex)
+{
+public String getMessage()
+{
+return diagnoseClassLoadError(module, name);
+}
+};
 }

 // We should never reach this point.
@@ -3272,4 +3278,4 @@

 return sb.toString();
 }
-}
\ No newline at end of file
+}

although lazy construction might cause problems if people hold onto
the exception for a long time, but I don't think this is usually the case

I know the design of the JBI classloaders is not really a good fit in
 OSGi, so I will investigate
 a better solution (leveraging more of OSGi classloaders) anyway, but I
 still wanted to report
 the problem.


 --
 Cheers,
 Guillaume Nodet
 
 Blog: http://gnodet.blogspot.com/




-- 
Cheers, Stuart

Re: Performance problems in classloading

2008-02-25 Thread Guillaume Nodet 
Thanks Stuart.  The exception was catched and the getMessage method
called, so I've
hacked a bit more, but the following patch seems to work great for me.

Index: src/main/java/org/apache/felix/moduleloader/ModuleImpl.java
===
--- src/main/java/org/apache/felix/moduleloader/ModuleImpl.java
(revision 630863)
+++ src/main/java/org/apache/felix/moduleloader/ModuleImpl.java (working copy)
@@ -147,10 +147,17 @@
 }
 catch (ClassNotFoundException ex)
 {
-m_logger.log(
-Logger.LOG_WARNING,
-ex.getMessage(),
-ex);
+// Diagnosing the class loader error is very costly, so only
+// perform this call (indirectly through ex.getMessage())
+// if necessary.
+// See R4SearchPolicyCore#findClass
+if (m_logger.getLogLevel() = Logger.LOG_WARNING)
+{
+m_logger.log(
+Logger.LOG_WARNING,
+ex.getMessage(),
+ex);
+}
 }
 return null;
 }
Index: 
src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
===
--- 
src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
  (revision 630863)
+++ 
src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
  (working copy)
@@ -178,7 +178,7 @@
 return null;
 }

-public Class findClass(IModule module, String name)
+public Class findClass(final IModule module, final String name)
 throws ClassNotFoundException
 {
 try
@@ -191,8 +191,13 @@
 }
 catch (ClassNotFoundException ex)
 {
-String msg = diagnoseClassLoadError(module, name);
-throw new ClassNotFoundException(msg, ex);
+throw new ClassNotFoundException(, ex)
+{
+public String getMessage()
+{
+return diagnoseClassLoadError(module, name);
+}
+};
 }

 // We should never reach this point.


On Mon, Feb 25, 2008 at 3:37 PM, Stuart McCulloch
[EMAIL PROTECTED] wrote:
 On 25/02/2008, Guillaume Nodet [EMAIL PROTECTED] wrote:
  
   I'm currently working on ServiceMix 4 which uses Felix.\
  
   I have some really important performance problems in classloading.
   When loading JBI applications (they have some very specific
   classloading architecture
   that must be implemented to be JBI compliant), 95% of the time  is
   spent in the following method:
  R4SearchPolicyCore.diagnoseClassLoadError()
   which is not really acceptable.
  
   The problem is that the classloader is built dynamically and does not
   completely rely on
   OSGi.  For this reason, the classloader of JBI artifacts delegates to
   the parent classloader,
   then looks inside its own jar.  This means there will be lots of
   ClassNotFoundException thrown
   by the parents classloader (ultimately by Felix).
  
   Is there any way to maybe speed / disable the diagnoseClassLoadError
   method call which
   is purely informative ?


  we could try a lazy-load approach (ie. only construct the string in the
  getMessage method)
  for example, you might want to see if the following patch helps, based on
  the current trunk:

  Index:
  src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
  ===
  ---
  src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
  (revision 630859)
  +++
  src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
  (working copy)
  @@ -178,7 +178,7 @@
  return null;
  }

  -public Class findClass(IModule module, String name)
  +public Class findClass(final IModule module, final String name)
  throws ClassNotFoundException
  {
  try
  @@ -191,8 +191,14 @@
  }
  catch (ClassNotFoundException ex)
  {
  -String msg = diagnoseClassLoadError(module, name);
  -throw new ClassNotFoundException(msg, ex);
  +// lazy construction of exception message
  +throw new ClassNotFoundException(, ex)
  +{
  +public String getMessage()
  +{
  +return diagnoseClassLoadError(module, name);
  +}
  +};
  }

  // We should never reach this point.
  @@ -3272,4 +3278,4 @@

  return sb.toString();
  }
  -}
  \ No newline at end of file
  +}

  although lazy construction might cause problems if people hold onto
  the exception for a long time, but I don't think this is usually the case



  I know the design of the JBI classloaders is not really a good fit in
   OSGi, so I

Re: Performance problems in classloading

2008-02-25 Thread Stuart McCulloch 
On 25/02/2008, Guillaume Nodet [EMAIL PROTECTED] wrote:

 Thanks Stuart.  The exception was catched and the getMessage method
 called, so I've
 hacked a bit more, but the following patch seems to work great for me.


cool, could you raise a JIRA issue and attach the combined patch - thanks

Index: src/main/java/org/apache/felix/moduleloader/ModuleImpl.java
 ===
 --- src/main/java/org/apache/felix/moduleloader/ModuleImpl.java
 (revision 630863)
 +++ src/main/java/org/apache/felix/moduleloader/ModuleImpl.java (working
 copy)
 @@ -147,10 +147,17 @@
  }
  catch (ClassNotFoundException ex)
  {
 -m_logger.log(
 -Logger.LOG_WARNING,
 -ex.getMessage(),
 -ex);
 +// Diagnosing the class loader error is very costly, so only
 +// perform this call (indirectly through ex.getMessage())
 +// if necessary.
 +// See R4SearchPolicyCore#findClass
 +if (m_logger.getLogLevel() = Logger.LOG_WARNING)
 +{
 +m_logger.log(
 +Logger.LOG_WARNING,
 +ex.getMessage(),
 +ex);
 +}
  }
  return null;

  }
 Index:
 src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
 ===
 ---
 src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java

   (revision 630863)

 +++
 src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
   (working copy)
 @@ -178,7 +178,7 @@
  return null;
  }

 -public Class findClass(IModule module, String name)
 +public Class findClass(final IModule module, final String name)
  throws ClassNotFoundException
  {
  try

 @@ -191,8 +191,13 @@

  }
  catch (ClassNotFoundException ex)
  {
 -String msg = diagnoseClassLoadError(module, name);
 -throw new ClassNotFoundException(msg, ex);

 +throw new ClassNotFoundException(, ex)

 +{
 +public String getMessage()
 +{
 +return diagnoseClassLoadError(module, name);
 +}
 +};
  }

  // We should never reach this point.



 On Mon, Feb 25, 2008 at 3:37 PM, Stuart McCulloch
 [EMAIL PROTECTED] wrote:
  On 25/02/2008, Guillaume Nodet [EMAIL PROTECTED] wrote:
   
I'm currently working on ServiceMix 4 which uses Felix.\
   
I have some really important performance problems in classloading.
When loading JBI applications (they have some very specific
classloading architecture
that must be implemented to be JBI compliant), 95% of the time  is
spent in the following method:
   R4SearchPolicyCore.diagnoseClassLoadError()
which is not really acceptable.
   
The problem is that the classloader is built dynamically and does not
completely rely on
OSGi.  For this reason, the classloader of JBI artifacts delegates to
the parent classloader,
then looks inside its own jar.  This means there will be lots of
ClassNotFoundException thrown
by the parents classloader (ultimately by Felix).
   
Is there any way to maybe speed / disable the diagnoseClassLoadError
method call which
is purely informative ?
 
 
   we could try a lazy-load approach (ie. only construct the string in the
   getMessage method)
   for example, you might want to see if the following patch helps, based
 on
   the current trunk:
 
   Index:

   
  src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
   ===
   ---

   
  src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
   (revision 630859)
   +++

   
  src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
   (working copy)
   @@ -178,7 +178,7 @@
   return null;
   }
 
   -public Class findClass(IModule module, String name)
   +public Class findClass(final IModule module, final String name)
   throws ClassNotFoundException
   {
   try
   @@ -191,8 +191,14 @@
   }
   catch (ClassNotFoundException ex)
   {
   -String msg = diagnoseClassLoadError(module, name);
   -throw new ClassNotFoundException(msg, ex);
   +// lazy construction of exception message
   +throw new ClassNotFoundException(, ex)
   +{
   +public String getMessage()
   +{
   +return diagnoseClassLoadError(module, name);
   +}
   +};
   }
 
   // We should never reach this point.
   @@ -3272,4 +3278,4 @@
 
   return sb.toString();

Re: Performance problems in classloading

2008-02-25 Thread Dale Peakall 
These patches do have the problem that exceptions are supposed to be 
Serializable - and IModule is not Serializable.  I don't know if the 
information necessary to construct the message is Serializable and can 
be quickly extracted from the module definition - given the apparent 
run-time cost of the method I suspect not.


Stuart McCulloch wrote:

On 25/02/2008, Guillaume Nodet [EMAIL PROTECTED] wrote:
  

Thanks Stuart.  The exception was catched and the getMessage method
called, so I've
hacked a bit more, but the following patch seems to work great for me.




cool, could you raise a JIRA issue and attach the combined patch - thanks

Index: src/main/java/org/apache/felix/moduleloader/ModuleImpl.java
  

===
--- src/main/java/org/apache/felix/moduleloader/ModuleImpl.java
(revision 630863)
+++ src/main/java/org/apache/felix/moduleloader/ModuleImpl.java (working
copy)
@@ -147,10 +147,17 @@
 }
 catch (ClassNotFoundException ex)
 {
-m_logger.log(
-Logger.LOG_WARNING,
-ex.getMessage(),
-ex);
+// Diagnosing the class loader error is very costly, so only
+// perform this call (indirectly through ex.getMessage())
+// if necessary.
+// See R4SearchPolicyCore#findClass
+if (m_logger.getLogLevel() = Logger.LOG_WARNING)
+{
+m_logger.log(
+Logger.LOG_WARNING,
+ex.getMessage(),
+ex);
+}
 }
 return null;

 }
Index:
src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
===
---
src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java

  (revision 630863)

+++
src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
  (working copy)
@@ -178,7 +178,7 @@
 return null;
 }

-public Class findClass(IModule module, String name)
+public Class findClass(final IModule module, final String name)
 throws ClassNotFoundException
 {
 try

@@ -191,8 +191,13 @@

 }
 catch (ClassNotFoundException ex)
 {
-String msg = diagnoseClassLoadError(module, name);
-throw new ClassNotFoundException(msg, ex);

+throw new ClassNotFoundException(, ex)

+{
+public String getMessage()
+{
+return diagnoseClassLoadError(module, name);
+}
+};
 }

 // We should never reach this point.



On Mon, Feb 25, 2008 at 3:37 PM, Stuart McCulloch
[EMAIL PROTECTED] wrote:


On 25/02/2008, Guillaume Nodet [EMAIL PROTECTED] wrote:
 
  I'm currently working on ServiceMix 4 which uses Felix.\
 
  I have some really important performance problems in classloading.
  When loading JBI applications (they have some very specific
  classloading architecture
  that must be implemented to be JBI compliant), 95% of the time  is
  spent in the following method:
 R4SearchPolicyCore.diagnoseClassLoadError()
  which is not really acceptable.
 
  The problem is that the classloader is built dynamically and does not
  completely rely on
  OSGi.  For this reason, the classloader of JBI artifacts delegates to
  the parent classloader,
  then looks inside its own jar.  This means there will be lots of
  ClassNotFoundException thrown
  by the parents classloader (ultimately by Felix).
 
  Is there any way to maybe speed / disable the diagnoseClassLoadError
  method call which
  is purely informative ?


 we could try a lazy-load approach (ie. only construct the string in the
 getMessage method)
 for example, you might want to see if the following patch helps, based
  

on


 the current trunk:

 Index:
  
 src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java

 ===
 ---
  
 src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java

 (revision 630859)
 +++
  
 src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java

 (working copy)
 @@ -178,7 +178,7 @@
 return null;
 }

 -public Class findClass(IModule module, String name)
 +public Class findClass(final IModule module, final String name)
 throws ClassNotFoundException
 {
 try
 @@ -191,8 +191,14 @@
 }
 catch (ClassNotFoundException ex)
 {
 -String msg = diagnoseClassLoadError(module, name);
 -throw new ClassNotFoundException(msg, ex);
 +// lazy construction of exception message
 +throw new ClassNotFoundException(, ex)
 +{
 +public String getMessage()
 +{
 +

[jira] Created: (FELIX-500) Performance problems when using the OSGi classloaders in a certain way

2008-02-25 Thread Guillaume Nodet (JIRA) 
Performance problems when using the OSGi classloaders in a certain way
--

 Key: FELIX-500
 URL: https://issues.apache.org/jira/browse/FELIX-500
 Project: Felix
  Issue Type: Improvement
  Components: Framework
Affects Versions: 1.0.3
Reporter: Guillaume Nodet
Priority: Critical


As discussed on the mailing list, there is a big performance problems when lots 
of CNFE are thrown from the framework.
The main reason is that the creation of the diagnosis message is very time 
consuming.
This patch aims to fix the problem by lazy creating the message only when 
needed (when the exception is actually displayed
or serialized).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Performance problems in classloading

2008-02-25 Thread Karl Pauls 
I agree that we will have to fix this. I will look into it. Thanks for
the patch.

regards,

Karl

 I've raised a JIRA with a patch that should accomodate this problem.
  I must admit this is not the cleanest thing, but given a 95%
  performance boost in my case
  I'd be happy it it is included :-)
  See https://issues.apache.org/jira/browse/FELIX-500



  On Mon, Feb 25, 2008 at 5:05 PM, Guillaume Nodet [EMAIL PROTECTED] wrote:
   I suppose we could make the ClassNotFoundException class a static class, 
 give it
a transient reference to the IModule and make sure the message is 
 extracted when
the Exception is serialized.
Thoughts ?
  
  
  
On Mon, Feb 25, 2008 at 4:47 PM, Dale Peakall [EMAIL PROTECTED] wrote:
 These patches do have the problem that exceptions are supposed to be
  Serializable - and IModule is not Serializable.  I don't know if the
  information necessary to construct the message is Serializable and can
  be quickly extracted from the module definition - given the apparent
  run-time cost of the method I suspect not.



  Stuart McCulloch wrote:
   On 25/02/2008, Guillaume Nodet [EMAIL PROTECTED] wrote:
  
   Thanks Stuart.  The exception was catched and the getMessage method
   called, so I've
   hacked a bit more, but the following patch seems to work great for 
 me.
  
  
  
   cool, could you raise a JIRA issue and attach the combined patch - 
 thanks
  
   Index: src/main/java/org/apache/felix/moduleloader/ModuleImpl.java
  
   ===
   --- src/main/java/org/apache/felix/moduleloader/ModuleImpl.java
   (revision 630863)
   +++ src/main/java/org/apache/felix/moduleloader/ModuleImpl.java 
 (working
   copy)
   @@ -147,10 +147,17 @@
}
catch (ClassNotFoundException ex)
{
   -m_logger.log(
   -Logger.LOG_WARNING,
   -ex.getMessage(),
   -ex);
   +// Diagnosing the class loader error is very costly, 
 so only
   +// perform this call (indirectly through 
 ex.getMessage())
   +// if necessary.
   +// See R4SearchPolicyCore#findClass
   +if (m_logger.getLogLevel() = Logger.LOG_WARNING)
   +{
   +m_logger.log(
   +Logger.LOG_WARNING,
   +ex.getMessage(),
   +ex);
   +}
}
return null;
  
}
   Index:
   
 src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
   ===
   ---
   
 src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
  
 (revision 630863)
  
   +++
   
 src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
 (working copy)
   @@ -178,7 +178,7 @@
return null;
}
  
   -public Class findClass(IModule module, String name)
   +public Class findClass(final IModule module, final String name)
throws ClassNotFoundException
{
try
  
   @@ -191,8 +191,13 @@
  
}
catch (ClassNotFoundException ex)
{
   -String msg = diagnoseClassLoadError(module, name);
   -throw new ClassNotFoundException(msg, ex);
  
   +throw new ClassNotFoundException(, ex)
  
   +{
   +public String getMessage()
   +{
   +return diagnoseClassLoadError(module, name);
   +}
   +};
}
  
// We should never reach this point.
  
  
  
   On Mon, Feb 25, 2008 at 3:37 PM, Stuart McCulloch
   [EMAIL PROTECTED] wrote:
  
   On 25/02/2008, Guillaume Nodet [EMAIL PROTECTED] wrote:

 I'm currently working on ServiceMix 4 which uses Felix.\

 I have some really important performance problems in 
 classloading.
 When loading JBI applications (they have some very specific
 classloading architecture
 that must be implemented to be JBI compliant), 95% of the time  
 is
 spent in the following method:
R4SearchPolicyCore.diagnoseClassLoadError()
 which is not really acceptable.

 The problem is that the classloader is built dynamically and 
 does not
 completely rely on
 OSGi.  For this reason, the classloader of JBI artifacts 
 delegates to
 the parent classloader,
 then looks inside