This is all I did (and from what I have read, double checked locking is
works correctly in jdk 5)
private static volatile IndexingFilters INSTANCE;
public static IndexingFilters getInstance(final Configuration configuration)
{
if(INSTANCE == null) {
synchronized(IndexingFilters.class) {
if(INSTANCE == null) {
INSTANCE = new IndexingFilters(configuration);
}
}
}
return INSTANCE;
}
So, I just updated all the code that calls "new IndexingFilters(..)" to call
IndexingFilters.getInstance(...). This works for me, perhaps not everyone.
I think that the filter interface should be refitted to allow the
configuration instance to be passed along the filters too, or allow a way
for the thread to obtain it's current configuration, rather than
instantiating these things over and over again. If a filter is designed to
be thread-safe, there is no need for all this unnecessary object creation.
On 6/6/07, Briggs <[EMAIL PROTECTED]> wrote:
FYI, I ran into the same problem. I wanted my filters to be instantiated
only once, and they not only get instantiated repeatedly, but the
classloading is flawed in that it keeps reloading the classes. So, if you
ever dump the stats from your app (use 'jmap -histo;) you can see all the
classes that have been loaded. You will notice, if you have been running
nutch for a while, classes being loaded thousands of times and never
unloaded. My quick fix was to just edit all the main plugin points (
URLFilters.java, IndexFilters.java etc) and made them all singletons. I
haven't had time to look into the classloading facility. There is a bit of
a bug in there (IMHO), but some people may not want singletons. But, there
needs to be a way of just instantiating a new plugin, and not instantiating
a new classloader everytime a plugin is requested. These seem to never get
garbage collected.
Anyway.. that's all I have to say at the moment.
On 6/5/07, Doğacan Güney <[EMAIL PROTECTED] > wrote:
>
> Hi,
>
> It seems that plugin-loading code is somehow broken. There is some
> discussion going on about this on
> http://www.nabble.com/forum/ViewPost.jtp?post=10844164&framed=y .
>
> On 6/5/07, Enzo Michelangeli < [EMAIL PROTECTED]> wrote:
> > I have a question about the loading mechanism of plugin classes. I'm
> working
> > with a custom URLFilter, and I need a singleton object loaded and
> > initialized by the first instance of the URLFilter, and shared by
> other
> > instances (e.g., instantiated by other threads). I was assuming that
> the
> > URLFilter class was being loaded only once even when the filter is
> used by
> > multiple threads, so I tried to use a static member variable of my
> URLFilter
> > class to hold a reference to the object to be shared: but it appears
> that
> > the supposed singleton, actually, isn't, because the method
> responsible for
> > its instantiation finds the static field initialized to null. So: are
> > URLFilter classes loaded multiple times by their classloader in Nutch?
> The
> > wiki page at
> >
>
http://wiki.apache.org/nutch/WhichTechnicalConceptsAreBehindTheNutchPluginSystem
> > seems to suggest otherwise:
> >
> > Until Nutch runtime, only one instance of such a plugin
> > class is alive in the Java virtual machine.
> >
> > (By the way, what does "Until Nutch runtime" mean here? Before Nutch
> > runtime, no class whatsoever is supposed to be alive in the JVM, is
> it?)
> >
> > Enzo
> >
> >
>
> --
> Doğacan Güney
>
--
"Conscious decisions by conscious minds are what make reality real"
--
"Conscious decisions by conscious minds are what make reality real"
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Nutch-general mailing list
Nutch-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nutch-general
