[
https://issues.apache.org/jira/browse/NUTCH-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507678
]
Enzo Michelangeli commented on NUTCH-501:
-----------------------------------------
Doğacan Güney - [23/Jun/07 12:11 PM ]:
> Actually, you are right. It is a bug. However, that bug is irrelevant in
> *this* case.
> Notice that PluginRepository runs out of memory not because we have too
> many active configurations at once. We run out of memory, because, for some
> reason that I don't quite understand yet, loaded plugin classes don't get
> 'unloaded'.
It seems to me that implementing plugin loading through class loading presents
some drawbacks. http://java.sun.com/docs/books/jls/unloading-rationale.html
explains that class unloading is just an optimization, and "the semantics of a
program should not depend on whether and how a system chooses to implement an
optimization such as class unloading. To do otherwise would completely
compromise the portability of Java programs. Consequently, whether a class has
been unloaded or not should be transparent to a Java program". However, I'd
like to have some control over plugin loading/unloading. It's not only matter
of memory leaks: sometimes unloading, especially when unexpected, is just
unwelcome. In particular, I'd like have a method (finalize() ?) guaranteed to
be called when the plugin is unloaded in order to perform some cleanup (e.g.,
close open files and/or database connections), and also have an option to make
the plugin "sticky", with the guarantee that it will not be unloaded (in case
the plugin initialization happened to be particularly expensive). But, in the
present implementation, that would require my code to have visibility over
class loading/unloading, which is frowned upon...
> Implement a different caching mechanism for objects cached in configuration
> ---------------------------------------------------------------------------
>
> Key: NUTCH-501
> URL: https://issues.apache.org/jira/browse/NUTCH-501
> Project: Nutch
> Issue Type: Improvement
> Affects Versions: 1.0.0
> Reporter: Doğacan Güney
> Fix For: 1.0.0
>
> Attachments: NUTCH-501.patch, NUTCH-501_draft.patch,
> NUTCH-501_draft_v2.patch
>
>
> As per HADOOP-1343, Configuration.setObject and Configuration.getObject
> (which are used by Nutch to cache arbitrary objects) are deprecated and will
> be removed soon. We have to implement an alternative caching mechanism and
> replace all usages of Configuration.{getObject,setObject} with the new
> mechanism.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-------------------------------------------------------------------------
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-developers mailing list
Nutch-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nutch-developers
