[
https://jira.codehaus.org/browse/MINDEXER-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297698#comment-297698
]
Jesse Glick commented on MINDEXER-52:
-------------------------------------
Assuming the "bottle warmer" is intended to preload Lucene indices for quick
response times, this seems quite inappropriate to be called by default by a
library like Maven Indexer, and probably should not even be present there in
code. While it makes sense for a server like Nexus, which can take its time
starting up but needs to be responsive thereafter, it makes no sense for a CLI
utility embedding the library which only needs to do a handful of operations
and then exit; nor does it make sense for embedding in a desktop app like an
IDE, which may well perform warmup operations but likely has its own carefully
tuned schedule for doing so (and likely cannot afford to waste a native thread
sitting on each Maven repository).
> reentrant locking in DefaultIndexingContent flawed
> --------------------------------------------------
>
> Key: MINDEXER-52
> URL: https://jira.codehaus.org/browse/MINDEXER-52
> Project: Maven Indexer
> Issue Type: Bug
> Affects Versions: 4.1.2
> Reporter: Milos Kleint
> Priority: Critical
>
> DefaultIndexingContent.java contains the following pattern:
> {code:java}
> public IndexReader getIndexReader()
> throws IOException
> {
> lock();
> try
> {
> return indexReader;
> }
> finally
> {
> unlock();
> }
> }
> {code}
> together with installBottleWarmer() method that spawns a concurrent thread
> that performs "warmup" operations, it makes it impossible to access the
> indexReader instance safely. A correct approach would be to wrap the entire
> operation with the indexreader in the mutex lock, not the the accessor method.
> please see http://netbeans.org/bugzilla/show_bug.cgi?id=204706 and
> http://statistics.netbeans.org/exceptions/detail.do?id=180712 for examples
> when this approach is failing. it's fairly rare but keeps on reoccuring, all
> access (searching, indexing) from netbeans is protected by a mutex and
> happens exclusively. I'm assuming that the installBottleWarmer() thread is
> the one iterfering with our access occasionally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira