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 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
> > >>>
> > >>>
> > >>
> > >>
> > >> --
> > >>
> > >> Cheers,
> > >> Guillaume Nodet
> > >> ------------------------
> > >> Blog: http://gnodet.blogspot.com/
> > >>
> > >>
> > >
> > >
> > >
> > >
> >
> >
>
>
>
> --
>
>
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
