-
Notifications
You must be signed in to change notification settings - Fork 779
reuse IndexReader objects for multi-project searches #1186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Another problem is partial reindex - usually it is done from the |
|
||
/** | ||
* Unit tests for the {@code SearchHelper} class. | ||
*/ | ||
public class SearchHelperTest { | ||
TestRepository repository; | ||
private final String ctagsProperty = "org.opensolaris.opengrok.analysis.Ctags"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dup?
can we take it from a final variable from code instead of redeclaring?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
filed #1198 to track this
|
||
@Before | ||
public void setUp() throws IOException { | ||
repository = new TestRepository(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we also duplicate this on quite a few places, dedup might be nice (but for this dup not in this changeset, just for future)
ship it! |
I tried to address the |
This fixes #1132 and speeds up multi-project search by doing the right thing w.r.t. IndexSearcher object reuse as stressed in just every book about Lucene.
There are 2 problems with this change:
destroy()
method should be called after each SearchHelper or SearchEngine is used for searching, ideally intry-finally
block. However, this is not easy to do, namely insearch.jsp
where the code is interspersed withinclude
blocks etc. It is important to calldestroy
to make sure allIndexSearcher
objects are properly returned to their correspondingSearcherManager
objects. I briefly considered to use Finalizer however all references dissuade everyone from using it so I chickened out.destroy()
. Also, invalidating SearcherManager objects when corresponding project disappears after configuration change is not done to keep things simple. As a result, the map grows unbounded.