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
