[jira] [Resolved] (LUCENE-3798) Potential IndexReader leak in SearcherManager and NRTManager
[ https://issues.apache.org/jira/browse/LUCENE-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-3798. Resolution: Invalid Fix Version/s: (was: 3.6) (was: 4.0) Argh, you're right. I didn't 'svn up' before I looked at the code :). Sorry for the noise. Potential IndexReader leak in SearcherManager and NRTManager Key: LUCENE-3798 URL: https://issues.apache.org/jira/browse/LUCENE-3798 Project: Lucene - Java Issue Type: Bug Components: core/search Reporter: Shai Erera Priority: Critical SearcherManager and NRTManager ctors init a new IndexReader and call searcherFactory.newSearcher. The latter can throw IOE,in which case we fail to close the readers. We should wrap the code with a try-finally (success) clause. Opening this issue so we don't forget to fix it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3794) DirectoryTaxonomyWriter can lose the INDEX_CREATE_TIME property, causing DirTaxoReader.refresh() to falsely succeed (or fail)
[ https://issues.apache.org/jira/browse/LUCENE-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-3794. Resolution: Fixed Committed revision 1244960 (3x). Committed revision 1244964 (trunk). DirectoryTaxonomyWriter can lose the INDEX_CREATE_TIME property, causing DirTaxoReader.refresh() to falsely succeed (or fail) - Key: LUCENE-3794 URL: https://issues.apache.org/jira/browse/LUCENE-3794 Project: Lucene - Java Issue Type: Bug Components: modules/facet Reporter: Shai Erera Assignee: Shai Erera Fix For: 3.6, 4.0 Attachments: LUCENE-3794.patch DirTaxoWriter sets createTime to null after it put it in the commit data once. But that's wrong because if one calls commit(Map) twice, the second time doesn't record the creation time. Also, in the ctor, if an index exists and OpenMode is not CREATE, the creation time property is not read. I wrote a couple of unit tests that assert this, and modified DirTaxoWriter to always record the creation time (in every commit) -- that's the only safe way. Will upload a patch shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3760) Cleanup DR.getCurrentVersion/DR.getUserData/DR.getIndexCommit().getUserData()
[ https://issues.apache.org/jira/browse/LUCENE-3760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-3760. Resolution: Fixed Lucene Fields: New,Patch Available (was: New) Resolving back ... looks like I'm the only one that it bothers. Cleanup DR.getCurrentVersion/DR.getUserData/DR.getIndexCommit().getUserData() - Key: LUCENE-3760 URL: https://issues.apache.org/jira/browse/LUCENE-3760 Project: Lucene - Java Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 3.6, 4.0 Attachments: LUCENE-3760.patch, LUCENE-3760.patch Spinoff from Ryan's dev thread DR.getCommitUserData() vs DR.getIndexCommit().getUserData()... these methods are confusing/dups right now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3790) benchmark cannot parse highlight-vs-vector-highlight.alg, but only on 3.x?!
[
https://issues.apache.org/jira/browse/LUCENE-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera resolved LUCENE-3790.
Resolution: Fixed
Assignee: Shai Erera
Committed the fix in rev 1244532.
benchmark cannot parse highlight-vs-vector-highlight.alg, but only on 3.x?!
---
Key: LUCENE-3790
URL: https://issues.apache.org/jira/browse/LUCENE-3790
Project: Lucene - Java
Issue Type: Bug
Components: modules/benchmark
Reporter: Robert Muir
Assignee: Shai Erera
Fix For: 3.6
A new test (TestPerfTasksParse.testParseExamples) was added in LUCENE-3768
that
guarantees all .alg files in the conf/ directory can actually be parsed...
But highlight-vs-vector-highlight.alg cannot be parsed on 3.x
(NumberFormatException),
however it works fine on trunk... and the .alg is exactly the same in both
cases.
{noformat}
[junit] - Standard Error -
[junit] java.lang.NumberFormatException: For input string:
maxFrags[3.0],fields[body]
[junit] at
sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1222)
[junit] at java.lang.Float.parseFloat(Float.java:422)
[junit] at
org.apache.lucene.benchmark.byTask.tasks.SearchTravTask.setParams(SearchTravTask.java:76)
[junit] at
org.apache.lucene.benchmark.byTask.tasks.SearchTravRetVectorHighlightTask.setParams(SearchTravRetVectorHighlightTask.java:124)
[junit] at
org.apache.lucene.benchmark.byTask.utils.Algorithm.init(Algorithm.java:112)
[junit] at
org.apache.lucene.benchmark.byTask.TestPerfTasksParse.testParseExamples(TestPerfTasksParse.java:132)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3761) Generalize SearcherManager
[ https://issues.apache.org/jira/browse/LUCENE-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-3761. Resolution: Fixed Thanks all for your comments. Robert, I added back maybeReopen to SearcherManager as deprecated. Committed rev 1243906 (3x). Ported to trunk 1244000 (trunk). I will open a separate issue for SearcherTaxoManager Generalize SearcherManager -- Key: LUCENE-3761 URL: https://issues.apache.org/jira/browse/LUCENE-3761 Project: Lucene - Java Issue Type: Improvement Components: core/search Reporter: Shai Erera Assignee: Shai Erera Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3761.patch, LUCENE-3761.patch, LUCENE-3761.patch I'd like to generalize SearcherManager to a class which can manage instances of a certain type of interfaces. The reason is that today SearcherManager knows how to handle IndexSearcher instances. I have a SearcherManager which manages a pair of IndexSearcher and TaxonomyReader pair. Recently, few concurrency bugs were fixed in SearcherManager, and I realized that I need to apply them to my version as well. Which led me to think why can't we have an SM version which is generic enough so that both my version and Lucene's can benefit from? The way I see SearcherManager, it can be divided into two parts: (1) the part that manages the logic of acquire/release/maybeReopen (i.e., ensureOpen, protect from concurrency stuff etc.), and (2) the part which handles IndexSearcher, or my SearcherTaxoPair. I'm thinking that if we'll have an interface with incRef/decRef/tryIncRef/maybeRefresh, we can make SearcherManager a generic class which handles this interface. I will post a patch with the initial idea, and we can continue from there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3703) DirectoryTaxonomyReader.refresh misbehaves with ref counts
[ https://issues.apache.org/jira/browse/LUCENE-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-3703. Resolution: Fixed Committed revision 1234450 (3x), 1234451 (trunk). Thanks Doron ! DirectoryTaxonomyReader.refresh misbehaves with ref counts -- Key: LUCENE-3703 URL: https://issues.apache.org/jira/browse/LUCENE-3703 Project: Lucene - Java Issue Type: Bug Components: modules/facet Reporter: Shai Erera Assignee: Shai Erera Fix For: 3.6, 4.0 Attachments: LUCENE-3703.patch, LUCENE-3703.patch DirectoryTaxonomyReader uses the internal IndexReader in order to track its own reference counting. However, when you call refresh(), it reopens the internal IndexReader, and from that point, all previous reference counting gets lost (since the new IndexReader's refCount is 1). The solution is to track reference counting in DTR itself. I wrote a simple unit test which exposes the bug (will be attached with the patch shortly). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3686) EnhancementsPayloadIterator.getCategoryData(CategoryEnhancement) problematic usage of Object.equals()
[ https://issues.apache.org/jira/browse/LUCENE-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-3686. Resolution: Fixed Fix Version/s: 4.0 3.6 Patch looks good (many formatting changes though). I added a CHANGES entry under contrib/CHANGES.txt. Committed revision 1230429 (3x). Committed revision 1230431 (trunk). Thanks Sivan ! EnhancementsPayloadIterator.getCategoryData(CategoryEnhancement) problematic usage of Object.equals() - Key: LUCENE-3686 URL: https://issues.apache.org/jira/browse/LUCENE-3686 Project: Lucene - Java Issue Type: Bug Components: modules/facet Reporter: Sivan Yogev Assignee: Shai Erera Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3686.patch EnhancementsPayloadIterator has an internal list of category enhancemnets, and in getCategoryData(CategoryEnhancement) there is a lookup of the given CategoryEnhancement in the list. In order to make sure this lookup works, CategoryEnhancement must override Object.equals(Object). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3649) Facet userguide link is broken after ant javadocs-all
[ https://issues.apache.org/jira/browse/LUCENE-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-3649. Resolution: Fixed Committed rev 1226235 (3x). Committed rev 1226236 (trunk). Thanks all for the comments. Facet userguide link is broken after ant javadocs-all --- Key: LUCENE-3649 URL: https://issues.apache.org/jira/browse/LUCENE-3649 Project: Lucene - Java Issue Type: Bug Components: modules/facet Reporter: Shai Erera Assignee: Shai Erera Fix For: 3.6, 4.0 Attachments: LUCENE-3649.patch, LUCENE-3649.patch Spinoff from http://mail-archives.apache.org/mod_mbox/lucene-java-user/201112.mbox/%3CCAO9cvUaZePZ3faWo==xx7x8-5+snwlsbdqqjo_n-ycxr0lj...@mail.gmail.com%3E. When javadocs-all is run, the userguide is not copied at all, and therefore the link is broken. Two options: inline the userguide in package/overview.html or fix the Ant target to copy the userguide correctly. Thanks Lukas for reporting this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3635) Allow setting arbitrary objects on PerfRunData
[ https://issues.apache.org/jira/browse/LUCENE-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-3635. Resolution: Fixed Committed revision 1220795, 1220799. Allow setting arbitrary objects on PerfRunData -- Key: LUCENE-3635 URL: https://issues.apache.org/jira/browse/LUCENE-3635 Project: Lucene - Java Issue Type: Improvement Components: modules/benchmark Reporter: Shai Erera Assignee: Shai Erera Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3635.patch PerfRunData is used as the intermediary objects between PerfRunTasks. Just like we can set IndexReader/Writer on it, it will be good if it allows setting other arbitrary objects that are e.g. created by one task and used by another. A recent example is the enhancement to the benchmark package following the addition of the facet module. We had to add TaxoReader/Writer. The proposal is to add a HashMapString, Object that custom PerfTasks can set()/get(). I do not propose to move IR/IW/TR/TW etc. into that map. If however people think that we should, I can do that as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3637) Make IndexReader.decRef() call refCount.decrementAndGet instead of getAndDecrement
[
https://issues.apache.org/jira/browse/LUCENE-3637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera resolved LUCENE-3637.
Resolution: Fixed
Assignee: Shai Erera
Committed rev 1213033 (trunk).
Committed rev 1213036 (3x).
Make IndexReader.decRef() call refCount.decrementAndGet instead of
getAndDecrement
--
Key: LUCENE-3637
URL: https://issues.apache.org/jira/browse/LUCENE-3637
Project: Lucene - Java
Issue Type: Improvement
Components: core/search
Reporter: Shai Erera
Assignee: Shai Erera
Priority: Trivial
Fix For: 3.6, 4.0
Attachments: LUCENE-3637.patch
IndexReader.decRef() has this code:
{code}
final int rc = refCount.getAndDecrement();
if (rc == 1) {
{code}
I think it will be clearer if it was written like this:
{code}
final int rc = refCount.decrementAndGet();
if (rc == 0) {
{code}
It's a very simple change, which makes reading the code (at least IMO)
easier. Will post a patch shortly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3603) jar-src fails if ${build.dir} does not exist
[
https://issues.apache.org/jira/browse/LUCENE-3603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera resolved LUCENE-3603.
Resolution: Fixed
Committed revs 1207024 and 1207026.
jar-src fails if ${build.dir} does not exist
Key: LUCENE-3603
URL: https://issues.apache.org/jira/browse/LUCENE-3603
Project: Lucene - Java
Issue Type: Improvement
Reporter: Shai Erera
Assignee: Shai Erera
Priority: Minor
Fix For: 3.6, 4.0
Attachments: LUCENE-3603.patch
Simple fix -- make jar-src depend on a target which creates the build.dir.
Also, I noticed that build.dir is set in multiple places across our
build.xmls, so I'd like to improve that a bit (minor fixes as well).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3583) benchmark tests always fail on windows because directory cannot be removed
[ https://issues.apache.org/jira/browse/LUCENE-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-3583. Resolution: Fixed Fix Version/s: 4.0 3.6 Assignee: Shai Erera Lucene Fields: New,Patch Available (was: New) Committed rev 1204826 (3x). Ported changes to trunk in rev 1204828. benchmark tests always fail on windows because directory cannot be removed -- Key: LUCENE-3583 URL: https://issues.apache.org/jira/browse/LUCENE-3583 Project: Lucene - Java Issue Type: Bug Affects Versions: 3.5, 4.0 Environment: Only fails for Lucene trunk Reporter: Uwe Schindler Assignee: Shai Erera Fix For: 3.6, 4.0 Attachments: LUCENE-3583.patch, LUCENE-3583.patch, benchmark-test-output.txt, io-event-log.txt This seems to be a bug recently introduced. I have no idea what's wrong. Attached is a log file, reproduces everytime. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3237) FSDirectory.fsync() may not work properly
[ https://issues.apache.org/jira/browse/LUCENE-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-3237. Resolution: Won't Fix Fix Version/s: (was: 3.5) (was: 4.0) Closing. If we ever see that this actually is a problem, we can reopen. FSDirectory.fsync() may not work properly - Key: LUCENE-3237 URL: https://issues.apache.org/jira/browse/LUCENE-3237 Project: Lucene - Java Issue Type: Bug Components: core/store Reporter: Shai Erera Spinoff from LUCENE-3230. FSDirectory.fsync() opens a new RAF, sync() its FileDescriptor and closes RAF. It is not clear that this syncs whatever was written to the file by other FileDescriptors. It would be better if we do this operation on the actual RAF/FileOS which wrote the data. We can add sync() to IndexOutput and FSIndexOutput will do that. Directory-wise, we should stop syncing on file names, and instead sync on the IOs that performed the write operations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3269) Speed up Top-K sampling tests
[ https://issues.apache.org/jira/browse/LUCENE-3269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-3269. Resolution: Fixed Assignee: Shai Erera Lucene Fields: New,Patch Available (was: New) Committed revisions 1201677 (3x) and 1201678 (trunk). Thanks Robert ! Speed up Top-K sampling tests - Key: LUCENE-3269 URL: https://issues.apache.org/jira/browse/LUCENE-3269 Project: Lucene - Java Issue Type: Test Components: modules/facet Reporter: Robert Muir Assignee: Shai Erera Fix For: 3.5, 4.0 Attachments: LUCENE-3269.patch, LUCENE-3269.patch, LUCENE-3269.patch, LUCENE-3269.patch speed up the top-k sampling tests (but make sure they are thorough on nightly etc still) usually we would do this with use of atLeast(), but these tests are somewhat tricky, so maybe a different approach is needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3552) TaxonomyReader/Writer and their Lucene* implementation
[ https://issues.apache.org/jira/browse/LUCENE-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-3552. Resolution: Fixed Thanks Doron, good catch ! I also renamed o.a.l.facet.taxonomy.lucene to *.directory. Committed revision 1196963 (trunk). Committed revision 1196965 (3x). TaxonomyReader/Writer and their Lucene* implementation -- Key: LUCENE-3552 URL: https://issues.apache.org/jira/browse/LUCENE-3552 Project: Lucene - Java Issue Type: Improvement Components: modules/facet Reporter: Shai Erera Assignee: Shai Erera Priority: Trivial Fix For: 3.5, 4.0 Attachments: LUCENE-3552.patch The facet module contains two interfaces TaxonomyWriter and TaxonomyReader, with two implementations Lucene*. We've never actually implemented two TaxonomyWriters/Readers, so I'm not sure if these interfaces are useful anymore. Therefore I'd like to propose that we do either of the following: # Remove the interfaces and remove the Lucene part from the implementation classes (to end up with TW/TR impls). Or, # Keep the interfaces, but rename the Lucene* impls to Directory*. Whatever we do, I'd like to make the impls/interfaces impl also TwoPhaseCommit. Any preferences? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3556) Make DirectoryTaxonomyWriter's indexWriter member private
[ https://issues.apache.org/jira/browse/LUCENE-3556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-3556. Resolution: Fixed Committed revision 1196982 (trunk). Committed revision 1196983 (3x). Make DirectoryTaxonomyWriter's indexWriter member private - Key: LUCENE-3556 URL: https://issues.apache.org/jira/browse/LUCENE-3556 Project: Lucene - Java Issue Type: Improvement Components: modules/facet Reporter: Shai Erera Assignee: Shai Erera Priority: Trivial Fix For: 3.5, 4.0 Attachments: LUCENE-3556.patch DirectoryTaxonomyWriter has a protected indexWriter member. As far as I can tell, for two reasons: # protected openIndexWriter method which lets you open your own IW (e.g. with a custom IndexWriterConfig). # protected closeIndexWriter which is a hook for letting you close the IW you opened in the previous one. The fixes are trivial IMO: # Modify the method to return IW, and have the calling code set DTW's indexWriter member # Eliminate closeIW. DTW already has a protected closeResources() which lets you clean other resources you've allocated, so I think that's enough. I'll post a patch shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3549) Remove DocumentBuilder interface from facet module
[ https://issues.apache.org/jira/browse/LUCENE-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-3549. Resolution: Fixed Committed revision 1196471 (3x). Committed revision 1196474 (trunk). Remove DocumentBuilder interface from facet module -- Key: LUCENE-3549 URL: https://issues.apache.org/jira/browse/LUCENE-3549 Project: Lucene - Java Issue Type: Improvement Components: modules/facet Reporter: Shai Erera Assignee: Shai Erera Priority: Trivial Fix For: 3.5, 4.0 Attachments: LUCENE-3549.patch The facet module contains an interface called DocumentBuilder, which contains a single method, build(Document) (it's a builder API). We use it in my company to standardize how different modules populate a Document object. I've included it with the facet contribution so that things will compile with as few code changes as possible. Now it's time to do some cleanup and I'd like to start with this interface. If people think that this interface is useful to reside in 'core', then I don't mind moving it there. But otherwise, let's remove it from the code. It has only one impl in the facet module: CategoryDocumentBuilder, and we can certainly do without the interface. More so, it's under o.a.l package which is inappropriate IMO. If it's moved to 'core', it should be under o.a.l.document. If people see any problem with that, please speak up. I will do the changes and post a patch here shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3485) LuceneTaxonomyReader .decRef() may close the inner IR, renderring the LTR in a limbo.
[ https://issues.apache.org/jira/browse/LUCENE-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-3485. Resolution: Fixed I removed some copy-paste errors from the test you added, and moved 'closed=true' to after indexReader.close(). Committed revision 1179183 (3x). Committed revision 1179194 (trunk). Thanks Gilad ! LuceneTaxonomyReader .decRef() may close the inner IR, renderring the LTR in a limbo. - Key: LUCENE-3485 URL: https://issues.apache.org/jira/browse/LUCENE-3485 Project: Lucene - Java Issue Type: Bug Components: modules/facet Affects Versions: 3.4 Reporter: Gilad Barkai Assignee: Shai Erera Priority: Minor Fix For: 3.5, 4.0 Attachments: LUCENE-3485.patch, LUCENE-3485.patch TaxonomyReader which supports ref-counting, has a decRef() method which delegates to an inner IndexReader and calls its .decRef(). The latter may close the reader (if the ref is zeroes) but the taxonomy would remain 'open' which will fail many of its method calls. Also, the LTR's .close() method does not work in the same manner as IndexReader's - which calls decRef(), and leaves the real closing logic to the decRef(). I believe this should be the right approach for the fix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
