[jira] [Commented] (LUCENE-7833) Calculating minimum score instead of maximum score in ToParentBlockJoinQuery.BlockJoinScorer.setScoreAndFreq
[ https://issues.apache.org/jira/browse/LUCENE-7833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16015757#comment-16015757 ] selckin commented on LUCENE-7833: - Original poster found it and talked about it on irc with a few of us, i just wanted to highlight it would be an easy fix so it doesn't get lost I believe he said he was interested in creating a test for it > Calculating minimum score instead of maximum score in > ToParentBlockJoinQuery.BlockJoinScorer.setScoreAndFreq > > > Key: LUCENE-7833 > URL: https://issues.apache.org/jira/browse/LUCENE-7833 > Project: Lucene - Core > Issue Type: Bug >Reporter: Bernhard Altendorfer > > We recently upgraded our Elasticsearch cluster from 5.3 to 5.4 and found a > bug when we score nested documents. > I spent some time to check the code from Elasticsearch and Lucene and I found > a problem in ToParentBlockJoinQuery.BlockJoinScorer.setScoreAndFreq. > In the switch statement for the scoreMode in the case "Max" the function > Math.min is used and I guess it should be Math.max. > This would explain our problem in Elasticsearch because we see exactly the > problem that instead of the maximum the minimum is returned. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7833) Calculating minimum score instead of maximum score in ToParentBlockJoinQuery.BlockJoinScorer.setScoreAndFreq
[ https://issues.apache.org/jira/browse/LUCENE-7833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16015375#comment-16015375 ] selckin commented on LUCENE-7833: - [~jpountz] https://github.com/apache/lucene-solr/blob/master/lucene/join/src/java/org/apache/lucene/search/join/ToParentBlockJoinQuery.java#L315 > Calculating minimum score instead of maximum score in > ToParentBlockJoinQuery.BlockJoinScorer.setScoreAndFreq > > > Key: LUCENE-7833 > URL: https://issues.apache.org/jira/browse/LUCENE-7833 > Project: Lucene - Core > Issue Type: Bug >Reporter: Bernhard Altendorfer > > We recently upgraded our Elasticsearch cluster from 5.3 to 5.4 and found a > bug when we score nested documents. > I spent some time to check the code from Elasticsearch and Lucene and I found > a problem in ToParentBlockJoinQuery.BlockJoinScorer.setScoreAndFreq. > In the switch statement for the scoreMode in the case "Max" the function > Math.min is used and I guess it should be Math.max. > This would explain our problem in Elasticsearch because we see exactly the > problem that instead of the maximum the minimum is returned. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6259) Remove dependencies from binary releases
[ https://issues.apache.org/jira/browse/LUCENE-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14328725#comment-14328725 ] selckin commented on LUCENE-6259: - I understand maven isn't very popular, but putting a pom somewhere that downloads all the deps when you execute 'mvn' would be very simple Remove dependencies from binary releases Key: LUCENE-6259 URL: https://issues.apache.org/jira/browse/LUCENE-6259 Project: Lucene - Core Issue Type: Improvement Reporter: Ryan Ernst Attachments: Fetch.java, dependencies.txt In LUCENE-6247, one idea discussed to decrease the size of release artifacts was to remove the inclusion of dependencies from binary releases. These jar files increase the size of the binary releases a lot, and the size is mostly in a couple modules (eg benchmark and spatial). I think most people consume lucene through maven. For those that do use the binary release, we can still make pulling the dependencies for these modules easy. We can add a generated README file in each module that has dependencies, with instructions indicating they need to download the dependencies, and then give the list of jar files they need to download, with exact links to maven (which we can extract from ivy?). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4876) IndexWriterConfig.clone should clone the MergeScheduler
[ https://issues.apache.org/jira/browse/LUCENE-4876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720518#comment-13720518 ] selckin commented on LUCENE-4876: - This is also encouraging to just 'return this' from clone() in DeletionPolicy, it is how i fixed my app, how solr fixed it, and elasticsearch does it as well, so for future changes you can't even assume the clone is being done, not to mention how cruel it is to expose clone semantics on end-users IndexWriterConfig.clone should clone the MergeScheduler --- Key: LUCENE-4876 URL: https://issues.apache.org/jira/browse/LUCENE-4876 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Assignee: Adrien Grand Fix For: 4.3 Attachments: LUCENE-4876.patch, LUCENE-4876.patch, LUCENE-4876.patch ConcurrentMergeScheduler has a ListMergeThread member to track the running merging threads, so IndexWriterConfig.clone should clone the merge scheduler so that both IndexWriterConfig instances are independant. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Commented] (LUCENE-4583) StraightBytesDocValuesField fails if bytes 32k
[
https://issues.apache.org/jira/browse/LUCENE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13687730#comment-13687730
]
selckin commented on LUCENE-4583:
-
A few comments up someone asked for a use case, shouldn't something like
http://www.elasticsearch.org/guide/reference/mapping/source-field/ be a perfect
thing to use BinaryDocValues for?
I was trying to store something similar using DiskDocValuesFormat and hit the
32k limit
StraightBytesDocValuesField fails if bytes 32k
Key: LUCENE-4583
URL: https://issues.apache.org/jira/browse/LUCENE-4583
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Affects Versions: 4.0, 4.1, 5.0
Reporter: David Smiley
Priority: Critical
Fix For: 4.4
Attachments: LUCENE-4583.patch, LUCENE-4583.patch, LUCENE-4583.patch,
LUCENE-4583.patch, LUCENE-4583.patch
I didn't observe any limitations on the size of a bytes based DocValues field
value in the docs. It appears that the limit is 32k, although I didn't get
any friendly error telling me that was the limit. 32k is kind of small IMO;
I suspect this limit is unintended and as such is a bug.The following
test fails:
{code:java}
public void testBigDocValue() throws IOException {
Directory dir = newDirectory();
IndexWriter writer = new IndexWriter(dir, writerConfig(false));
Document doc = new Document();
BytesRef bytes = new BytesRef((4+4)*4097);//4096 works
bytes.length = bytes.bytes.length;//byte data doesn't matter
doc.add(new StraightBytesDocValuesField(dvField, bytes));
writer.addDocument(doc);
writer.commit();
writer.close();
DirectoryReader reader = DirectoryReader.open(dir);
DocValues docValues = MultiDocValues.getDocValues(reader, dvField);
//FAILS IF BYTES IS BIG!
docValues.getSource().getBytes(0, bytes);
reader.close();
dir.close();
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Commented] (LUCENE-4583) StraightBytesDocValuesField fails if bytes 32k
[
https://issues.apache.org/jira/browse/LUCENE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13687894#comment-13687894
]
selckin commented on LUCENE-4583:
-
Ok, from the talks i watched on them other info gathered it seemed like it
would be a good fit, guess i really missed the point somewhere, can't find much
info in the javadocs either, but guess this is for the user list and i
shouldn't pollute this issue
StraightBytesDocValuesField fails if bytes 32k
Key: LUCENE-4583
URL: https://issues.apache.org/jira/browse/LUCENE-4583
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Affects Versions: 4.0, 4.1, 5.0
Reporter: David Smiley
Priority: Critical
Fix For: 4.4
Attachments: LUCENE-4583.patch, LUCENE-4583.patch, LUCENE-4583.patch,
LUCENE-4583.patch, LUCENE-4583.patch
I didn't observe any limitations on the size of a bytes based DocValues field
value in the docs. It appears that the limit is 32k, although I didn't get
any friendly error telling me that was the limit. 32k is kind of small IMO;
I suspect this limit is unintended and as such is a bug.The following
test fails:
{code:java}
public void testBigDocValue() throws IOException {
Directory dir = newDirectory();
IndexWriter writer = new IndexWriter(dir, writerConfig(false));
Document doc = new Document();
BytesRef bytes = new BytesRef((4+4)*4097);//4096 works
bytes.length = bytes.bytes.length;//byte data doesn't matter
doc.add(new StraightBytesDocValuesField(dvField, bytes));
writer.addDocument(doc);
writer.commit();
writer.close();
DirectoryReader reader = DirectoryReader.open(dir);
DocValues docValues = MultiDocValues.getDocValues(reader, dvField);
//FAILS IF BYTES IS BIG!
docValues.getSource().getBytes(0, bytes);
reader.close();
dir.close();
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Commented] (LUCENE-4876) IndexWriterConfig.clone should clone the MergeScheduler
[ https://issues.apache.org/jira/browse/LUCENE-4876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13685638#comment-13685638 ] selckin commented on LUCENE-4876: - The new requirement to implement clone() is not very well documented in the release notes or in the javadoc, and can silently break things on upgrading IndexWriterConfig.clone should clone the MergeScheduler --- Key: LUCENE-4876 URL: https://issues.apache.org/jira/browse/LUCENE-4876 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Assignee: Adrien Grand Fix For: 4.3 Attachments: LUCENE-4876.patch, LUCENE-4876.patch ConcurrentMergeScheduler has a ListMergeThread member to track the running merging threads, so IndexWriterConfig.clone should clone the merge scheduler so that both IndexWriterConfig instances are independant. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Commented] (SOLR-4169) The test suite should consistently pass
[ https://issues.apache.org/jira/browse/SOLR-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13530065#comment-13530065 ] selckin commented on SOLR-4169: --- Also see issues like SOLR-2608 that are ignored, i've been running lucene tests in a loop on and off for periods, and basically gave up on solr tests aswel, they randomly fail all the time The test suite should consistently pass --- Key: SOLR-4169 URL: https://issues.apache.org/jira/browse/SOLR-4169 Project: Solr Issue Type: Bug Components: Tests Reporter: Robert Muir Priority: Blocker Fix For: 4.1 I'm at the end of my rope. Last week I tried to help with this: but its already wednesday and solr tests are 20x worse. Users are complaining that they cannot get snapshots and test them, because the tests fail all the time. Maven dependencies are wrong, but we never knew, because the tests never succeeded so the validation task hasn't actually run in months. I think fixing this situation is a blocker to release: I can't imagine a bigger blocker actually. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Commented] (LUCENE-4566) SearcherManager.afterRefresh() issues
[ https://issues.apache.org/jira/browse/LUCENE-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501836#comment-13501836 ] selckin commented on LUCENE-4566: - Tried to make simple patch but changing (1) breaks NRTManager tests for me and don't really have time to try to figure out how all that works SearcherManager.afterRefresh() issues - Key: LUCENE-4566 URL: https://issues.apache.org/jira/browse/LUCENE-4566 Project: Lucene - Core Issue Type: Bug Reporter: selckin Priority: Minor 1) ReferenceManager.doMaybeRefresh seems to call afterRefresh even if it didn't refresh/swap, (when newReference == null) 2) It would be nice if users were allowed to override SearcherManager.afterRefresh() to get notified when a new searcher is in action. But SearcherManager and ReaderManager are final, while NRTManager is not. The only way to currently hook into when a new searched is created is using the factory, but if you wish to do some async task then, there are no guarantees that acquire() will return the new searcher, so you have to pass it around and incRef manually. While if allowed to hook into afterRefresh you can just rely on acquire() existing infra you have around it to give you the latest one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Updated] (LUCENE-4566) SearcherManager.afterRefresh() issues
[ https://issues.apache.org/jira/browse/LUCENE-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] selckin updated LUCENE-4566: Attachment: LUCENE-4566.patch - add extra afterMaybeRefresh to replace afterRefresh() - afterRefresh() only called when swapped as in javadoc - adds listener for afterRefresh afterClose SearcherManager.afterRefresh() issues - Key: LUCENE-4566 URL: https://issues.apache.org/jira/browse/LUCENE-4566 Project: Lucene - Core Issue Type: Bug Reporter: selckin Priority: Minor Attachments: LUCENE-4566.patch 1) ReferenceManager.doMaybeRefresh seems to call afterRefresh even if it didn't refresh/swap, (when newReference == null) 2) It would be nice if users were allowed to override SearcherManager.afterRefresh() to get notified when a new searcher is in action. But SearcherManager and ReaderManager are final, while NRTManager is not. The only way to currently hook into when a new searched is created is using the factory, but if you wish to do some async task then, there are no guarantees that acquire() will return the new searcher, so you have to pass it around and incRef manually. While if allowed to hook into afterRefresh you can just rely on acquire() existing infra you have around it to give you the latest one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Commented] (LUCENE-4566) SearcherManager.afterRefresh() issues
[ https://issues.apache.org/jira/browse/LUCENE-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501882#comment-13501882 ] selckin commented on LUCENE-4566: - against trunk r1411996 bq. * Why do you need both afterRefresh() and afterMaybeRefresh()? Is it because NRTManager tests failures, or was there a different reason? Yes only reason, not very clean :(, not sure if NRT actually needs to be able to call something after every maybeRefresh or if its a test/impl restriction (probably latter?) bq. * Why did you add the same test to both NRTManager and SearcherManager tests? Isn't it enough to test it once on e.g. a dummy ReferenceManager extension? The test only verifies that the listeners are called. True but there wasn't an existing ReferenceManager test, and it verifies they both call super.* in the override, but as stated in one of your next points, this can be done differently if the classes should be final. bq. * Should Listener be renamed to RefreshListener? Thought of that aswel, but then it felt strange to have the afterClose in there too. bq. * Now that you have the listener, is there a reason for a protected afterRefresh() and afterMaybeRefresh()? Aren't the listeners enough? ** On that note, I kinda like the listeners approach, so maybe we should add a RefreshListener and CloseListener and get rid of the protected methods? The listeners also allow us to keep the classes final, yet still have some sort of extension point. No reason bq. * Is it really necessary to use CopyOnWriteArrayList? Do we really expect an application will install a listener after the manager has already started and serviced calls? ** It seems like a setup method to me, and I'm fine if we document that you should call these methods before any other method of the class is called. Yeah, its a bit of a trade of, i agree it's a setup method, but i didn't like the constructor explosion with adding it as an optional constructor parameter, and then just having a setter with no thread visibility guarantees in a class that's made to be used multithreaded felt wrong too, so opted for the CopyOnWrite list, there are already other listeners this way in NRTManager. Other option is maybe to piggy back on the refresh lock in the setter maybe. Or just document it as you say SearcherManager.afterRefresh() issues - Key: LUCENE-4566 URL: https://issues.apache.org/jira/browse/LUCENE-4566 Project: Lucene - Core Issue Type: Bug Reporter: selckin Priority: Minor Attachments: LUCENE-4566.patch 1) ReferenceManager.doMaybeRefresh seems to call afterRefresh even if it didn't refresh/swap, (when newReference == null) 2) It would be nice if users were allowed to override SearcherManager.afterRefresh() to get notified when a new searcher is in action. But SearcherManager and ReaderManager are final, while NRTManager is not. The only way to currently hook into when a new searched is created is using the factory, but if you wish to do some async task then, there are no guarantees that acquire() will return the new searcher, so you have to pass it around and incRef manually. While if allowed to hook into afterRefresh you can just rely on acquire() existing infra you have around it to give you the latest one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Updated] (LUCENE-4566) SearcherManager.afterRefresh() issues
[ https://issues.apache.org/jira/browse/LUCENE-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] selckin updated LUCENE-4566: Attachment: LUCENE-4566-double-listeners.patch Simpler patch, extra Refresh CloseListener, no changes on current afterRefresh() (no tests) SearcherManager.afterRefresh() issues - Key: LUCENE-4566 URL: https://issues.apache.org/jira/browse/LUCENE-4566 Project: Lucene - Core Issue Type: Bug Reporter: selckin Priority: Minor Attachments: LUCENE-4566-double-listeners.patch, LUCENE-4566.patch 1) ReferenceManager.doMaybeRefresh seems to call afterRefresh even if it didn't refresh/swap, (when newReference == null) 2) It would be nice if users were allowed to override SearcherManager.afterRefresh() to get notified when a new searcher is in action. But SearcherManager and ReaderManager are final, while NRTManager is not. The only way to currently hook into when a new searched is created is using the factory, but if you wish to do some async task then, there are no guarantees that acquire() will return the new searcher, so you have to pass it around and incRef manually. While if allowed to hook into afterRefresh you can just rely on acquire() existing infra you have around it to give you the latest one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Created] (LUCENE-4566) SearcherManager.afterRefresh() issues
selckin created LUCENE-4566: --- Summary: SearcherManager.afterRefresh() issues Key: LUCENE-4566 URL: https://issues.apache.org/jira/browse/LUCENE-4566 Project: Lucene - Core Issue Type: Bug Reporter: selckin Priority: Minor 1) ReferenceManager.doMaybeRefresh seems to call afterRefresh even if it didn't refresh/swap, (when newReference == null) 2) It would be nice if users were allowed to override SearcherManager.afterRefresh() to get notified when a new searcher is in action. But SearcherManager and ReaderManager are final, while NRTManager is not. The only way to currently hook into when a new searched is created is using the factory, but if you wish to do some async task then, there are no guarantees that acquire() will return the new searcher, so you have to pass it around and incRef manually. While if allowed to hook into afterRefresh you can just rely on acquire() existing infra you have around it to give you the latest one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Created] (LUCENE-4567) WFSTCompletionLookup.lookup() NPE when empty fst
selckin created LUCENE-4567: --- Summary: WFSTCompletionLookup.lookup() NPE when empty fst Key: LUCENE-4567 URL: https://issues.apache.org/jira/browse/LUCENE-4567 Project: Lucene - Core Issue Type: Bug Reporter: selckin Attachments: LUCENE-4567.patch the fst Builder.finish() returns null when nothing is accepted, this then results in NPE in lookup(), see patch for extra nullchecks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Updated] (LUCENE-4566) SearcherManager.afterRefresh() issues
[ https://issues.apache.org/jira/browse/LUCENE-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] selckin updated LUCENE-4566: Attachment: (was: LUCENE-4566.patch) SearcherManager.afterRefresh() issues - Key: LUCENE-4566 URL: https://issues.apache.org/jira/browse/LUCENE-4566 Project: Lucene - Core Issue Type: Bug Reporter: selckin Priority: Minor 1) ReferenceManager.doMaybeRefresh seems to call afterRefresh even if it didn't refresh/swap, (when newReference == null) 2) It would be nice if users were allowed to override SearcherManager.afterRefresh() to get notified when a new searcher is in action. But SearcherManager and ReaderManager are final, while NRTManager is not. The only way to currently hook into when a new searched is created is using the factory, but if you wish to do some async task then, there are no guarantees that acquire() will return the new searcher, so you have to pass it around and incRef manually. While if allowed to hook into afterRefresh you can just rely on acquire() existing infra you have around it to give you the latest one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Updated] (LUCENE-4567) WFSTCompletionLookup.lookup() NPE when empty fst
[ https://issues.apache.org/jira/browse/LUCENE-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] selckin updated LUCENE-4567: Attachment: LUCENE-4567.patch WFSTCompletionLookup.lookup() NPE when empty fst Key: LUCENE-4567 URL: https://issues.apache.org/jira/browse/LUCENE-4567 Project: Lucene - Core Issue Type: Bug Reporter: selckin Attachments: LUCENE-4567.patch the fst Builder.finish() returns null when nothing is accepted, this then results in NPE in lookup(), see patch for extra nullchecks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Updated] (LUCENE-4566) SearcherManager.afterRefresh() issues
[ https://issues.apache.org/jira/browse/LUCENE-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] selckin updated LUCENE-4566: Attachment: LUCENE-4566.patch SearcherManager.afterRefresh() issues - Key: LUCENE-4566 URL: https://issues.apache.org/jira/browse/LUCENE-4566 Project: Lucene - Core Issue Type: Bug Reporter: selckin Priority: Minor 1) ReferenceManager.doMaybeRefresh seems to call afterRefresh even if it didn't refresh/swap, (when newReference == null) 2) It would be nice if users were allowed to override SearcherManager.afterRefresh() to get notified when a new searcher is in action. But SearcherManager and ReaderManager are final, while NRTManager is not. The only way to currently hook into when a new searched is created is using the factory, but if you wish to do some async task then, there are no guarantees that acquire() will return the new searcher, so you have to pass it around and incRef manually. While if allowed to hook into afterRefresh you can just rely on acquire() existing infra you have around it to give you the latest one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Commented] (LUCENE-4472) Add setting that prevents merging on updateDocument
[ https://issues.apache.org/jira/browse/LUCENE-4472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13473264#comment-13473264 ] selckin commented on LUCENE-4472: - +1, if you have a lot of indexes and they all start merging at the same time it can be quite taxing I think ES has dedicated configurable thread pool where for each index a maybeMerge() is scheduled on an interval. (Size of thread pool limits number of concurrent merges) Add setting that prevents merging on updateDocument --- Key: LUCENE-4472 URL: https://issues.apache.org/jira/browse/LUCENE-4472 Project: Lucene - Core Issue Type: Improvement Components: core/index Affects Versions: 4.0 Reporter: Simon Willnauer Fix For: 4.1, 5.0 Attachments: LUCENE-4472.patch Currently we always call maybeMerge if a segment was flushed after updateDocument. Some apps and in particular ElasticSearch uses some hacky workarounds to disable that ie for merge throttling. It should be easier to enable this kind of behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Updated] (LUCENE-4465) ConstantScoreQuery's scorer does not return child scorers
[ https://issues.apache.org/jira/browse/LUCENE-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] selckin updated LUCENE-4465: Attachment: constant-score-children.patch ConstantScoreQuery's scorer does not return child scorers - Key: LUCENE-4465 URL: https://issues.apache.org/jira/browse/LUCENE-4465 Project: Lucene - Core Issue Type: Bug Reporter: selckin Attachments: constant-score-children.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Created] (LUCENE-4465) ConstantScoreQuery's scorer does not return child scorers
selckin created LUCENE-4465: --- Summary: ConstantScoreQuery's scorer does not return child scorers Key: LUCENE-4465 URL: https://issues.apache.org/jira/browse/LUCENE-4465 Project: Lucene - Core Issue Type: Bug Reporter: selckin Attachments: constant-score-children.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447628#comment-13447628 ] selckin commented on LUCENE-4354: - If you add '-DincludeScope=runtime' to the copy call, quite a few disappear, one hamcrest still there, probably from test-framework ? Also ant clean doesn't remove the copied jars add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447633#comment-13447633 ] selckin commented on LUCENE-4354: - Well only things from the runtime scope will end up in the war, and i thought i saw other issues where the policy was to ignore license and other checks for build only jars. But i guess it can't hurt to force all the deps to be the same, so ignore me add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Updated] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] selckin updated LUCENE-4354: Attachment: LUCENE-4354-dep-fix.patch fixes some deps (ran with runtime scope) - servlet-api is confusing me - warns about common-compress in some solr contribs but it is the correct version add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447712#comment-13447712 ] selckin commented on LUCENE-4354: - Since transitive dependencies are ignored so aggressively, how about the reverse? dependencies present in lucene but not in maven? Tests should catch mosts of them i guess? add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Commented] (LUCENE-4309) Not obvious how to find mailing lists
[ https://issues.apache.org/jira/browse/LUCENE-4309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13436743#comment-13436743 ] selckin commented on LUCENE-4309: - If you're taking suggestions, i always love it when projects puts a copy pasteable maven dependency snippets on the download page. I think most people use maven/ivy/.. now instead of archive downloads? (I could be hugely mistaken tho) Cheers Not obvious how to find mailing lists - Key: LUCENE-4309 URL: https://issues.apache.org/jira/browse/LUCENE-4309 Project: Lucene - Core Issue Type: Bug Components: general/website Reporter: Sebb Attachments: LUCENE-4309.patch The website hides mailing lists under the heading Discussion, which is not at all obvious. -- 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] [Commented] (LUCENE-4190) IndexWriter deletes non-Lucene files
[ https://issues.apache.org/jira/browse/LUCENE-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13406879#comment-13406879 ] selckin commented on LUCENE-4190: - what if you accidentally call deleteAll() on your production index, maybe old commit points should not be deleted until after a period of 30 days IndexWriter deletes non-Lucene files Key: LUCENE-4190 URL: https://issues.apache.org/jira/browse/LUCENE-4190 Project: Lucene - Java Issue Type: Bug Reporter: Michael McCandless Assignee: Robert Muir Fix For: 4.0, 5.0 Attachments: LUCENE-4190.patch, LUCENE-4190.patch Carl Austin raised a good issue in a comment on my Lucene 4.0.0 alpha blog post: http://blog.mikemccandless.com/2012/07/lucene-400-alpha-at-long-last.html IndexWriter will now (as of 4.0) delete all foreign files from the index directory. We made this change because Codecs are free to write to any files now, so the space of filenames is hard to bound. But if the user accidentally uses the wrong directory (eg c:/) then we will in fact delete important stuff. I think we can at least use some simple criteria (must start with _, maybe must fit certain pattern eg _base36(_X).Y), so we are much less likely to delete a non-Lucene file -- 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] [Comment Edited] (LUCENE-4190) IndexWriter deletes non-Lucene files
[ https://issues.apache.org/jira/browse/LUCENE-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13406879#comment-13406879 ] selckin edited comment on LUCENE-4190 at 7/5/12 6:54 AM: - edit: remove unhelpful sarcasm, sorry was (Author: selckin): what if you accidentally call deleteAll() on your production index, maybe old commit points should not be deleted until after a period of 30 days IndexWriter deletes non-Lucene files Key: LUCENE-4190 URL: https://issues.apache.org/jira/browse/LUCENE-4190 Project: Lucene - Java Issue Type: Bug Reporter: Michael McCandless Assignee: Robert Muir Fix For: 4.0, 5.0 Attachments: LUCENE-4190.patch, LUCENE-4190.patch Carl Austin raised a good issue in a comment on my Lucene 4.0.0 alpha blog post: http://blog.mikemccandless.com/2012/07/lucene-400-alpha-at-long-last.html IndexWriter will now (as of 4.0) delete all foreign files from the index directory. We made this change because Codecs are free to write to any files now, so the space of filenames is hard to bound. But if the user accidentally uses the wrong directory (eg c:/) then we will in fact delete important stuff. I think we can at least use some simple criteria (must start with _, maybe must fit certain pattern eg _base36(_X).Y), so we are much less likely to delete a non-Lucene file -- 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] [Created] (LUCENE-4140) IndexWriterConfig has setFlushPolicy but the class is package private
selckin created LUCENE-4140: --- Summary: IndexWriterConfig has setFlushPolicy but the class is package private Key: LUCENE-4140 URL: https://issues.apache.org/jira/browse/LUCENE-4140 Project: Lucene - Java Issue Type: Bug Reporter: selckin 4.0 -- 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] [Updated] (LUCENE-4106) StopFillCacheException is defined twice and the one is actually thrown is private and not catchable
[
https://issues.apache.org/jira/browse/LUCENE-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
selckin updated LUCENE-4106:
Description:
{code}
lucene/core/src/java/org/apache/lucene/search/FieldCacheImpl.java
145: static final class StopFillCacheException extends RuntimeException {
383:} catch (StopFillCacheException stop) {
456:} catch (StopFillCacheException stop) {
560:} catch (StopFillCacheException stop) {
710:} catch (StopFillCacheException stop) {
798:} catch (StopFillCacheException stop) {
887:} catch (StopFillCacheException stop) {
lucene/core/src/java/org/apache/lucene/search/FieldCache.java
57: public static final class StopFillCacheException extends RuntimeException {
216:throw new FieldCacheImpl.StopFillCacheException();
232:throw new FieldCacheImpl.StopFillCacheException();
248:throw new FieldCacheImpl.StopFillCacheException();
264:throw new FieldCacheImpl.StopFillCacheException();
{code}
was:
lucene/core/src/java/org/apache/lucene/search/FieldCacheImpl.java
145: static final class StopFillCacheException extends RuntimeException {
383:} catch (StopFillCacheException stop) {
456:} catch (StopFillCacheException stop) {
560:} catch (StopFillCacheException stop) {
710:} catch (StopFillCacheException stop) {
798:} catch (StopFillCacheException stop) {
887:} catch (StopFillCacheException stop) {
lucene/core/src/java/org/apache/lucene/search/FieldCache.java
57: public static final class StopFillCacheException extends RuntimeException {
216:throw new FieldCacheImpl.StopFillCacheException();
232:throw new FieldCacheImpl.StopFillCacheException();
248:throw new FieldCacheImpl.StopFillCacheException();
264:throw new FieldCacheImpl.StopFillCacheException();
StopFillCacheException is defined twice and the one is actually thrown is
private and not catchable
---
Key: LUCENE-4106
URL: https://issues.apache.org/jira/browse/LUCENE-4106
Project: Lucene - Java
Issue Type: Bug
Reporter: selckin
{code}
lucene/core/src/java/org/apache/lucene/search/FieldCacheImpl.java
145: static final class StopFillCacheException extends RuntimeException {
383:} catch (StopFillCacheException stop) {
456:} catch (StopFillCacheException stop) {
560:} catch (StopFillCacheException stop) {
710:} catch (StopFillCacheException stop) {
798:} catch (StopFillCacheException stop) {
887:} catch (StopFillCacheException stop) {
lucene/core/src/java/org/apache/lucene/search/FieldCache.java
57: public static final class StopFillCacheException extends
RuntimeException {
216:throw new FieldCacheImpl.StopFillCacheException();
232:throw new FieldCacheImpl.StopFillCacheException();
248:throw new FieldCacheImpl.StopFillCacheException();
264:throw new FieldCacheImpl.StopFillCacheException();
{code}
--
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] [Created] (LUCENE-4106) StopFillCacheException is defined twice and the one is actually thrown is private and not catchable
selckin created LUCENE-4106:
---
Summary: StopFillCacheException is defined twice and the one is
actually thrown is private and not catchable
Key: LUCENE-4106
URL: https://issues.apache.org/jira/browse/LUCENE-4106
Project: Lucene - Java
Issue Type: Bug
Reporter: selckin
lucene/core/src/java/org/apache/lucene/search/FieldCacheImpl.java
145: static final class StopFillCacheException extends RuntimeException {
383:} catch (StopFillCacheException stop) {
456:} catch (StopFillCacheException stop) {
560:} catch (StopFillCacheException stop) {
710:} catch (StopFillCacheException stop) {
798:} catch (StopFillCacheException stop) {
887:} catch (StopFillCacheException stop) {
lucene/core/src/java/org/apache/lucene/search/FieldCache.java
57: public static final class StopFillCacheException extends RuntimeException {
216:throw new FieldCacheImpl.StopFillCacheException();
232:throw new FieldCacheImpl.StopFillCacheException();
248:throw new FieldCacheImpl.StopFillCacheException();
264:throw new FieldCacheImpl.StopFillCacheException();
--
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] [Commented] (LUCENE-4106) StopFillCacheException is defined twice and the one is actually thrown is private and not catchable
[
https://issues.apache.org/jira/browse/LUCENE-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13288460#comment-13288460
]
selckin commented on LUCENE-4106:
-
But then if you wish to loop over all DoubleField values you need to know to do
that check yourself?
{{code}}
Terms terms = reader.terms(field);
TermsEnum termsEnum = terms.iterator(null);
BytesRef term = termsEnum.next();
if (term != null) {
double min = FieldCache.NUMERIC_UTILS_DOUBLE_PARSER.parseDouble(term);
double max = min;
try {
while ((term = termsEnum.next()) != null) {
max = FieldCache.NUMERIC_UTILS_DOUBLE_PARSER.parseDouble(term);
}
} catch (StopFillCacheException ignored) {
}
doSomething(min, max);
}
{{code}}
Or am i indexing something wrong to hit that exception? (i don't think i am)
StopFillCacheException is defined twice and the one is actually thrown is
private and not catchable
---
Key: LUCENE-4106
URL: https://issues.apache.org/jira/browse/LUCENE-4106
Project: Lucene - Java
Issue Type: Bug
Reporter: selckin
Assignee: Uwe Schindler
{code}
lucene/core/src/java/org/apache/lucene/search/FieldCacheImpl.java
145: static final class StopFillCacheException extends RuntimeException {
383:} catch (StopFillCacheException stop) {
456:} catch (StopFillCacheException stop) {
560:} catch (StopFillCacheException stop) {
710:} catch (StopFillCacheException stop) {
798:} catch (StopFillCacheException stop) {
887:} catch (StopFillCacheException stop) {
lucene/core/src/java/org/apache/lucene/search/FieldCache.java
57: public static final class StopFillCacheException extends
RuntimeException {
216:throw new FieldCacheImpl.StopFillCacheException();
232:throw new FieldCacheImpl.StopFillCacheException();
248:throw new FieldCacheImpl.StopFillCacheException();
264:throw new FieldCacheImpl.StopFillCacheException();
{code}
--
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] [Comment Edited] (LUCENE-4106) StopFillCacheException is defined twice and the one is actually thrown is private and not catchable
[
https://issues.apache.org/jira/browse/LUCENE-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13288460#comment-13288460
]
selckin edited comment on LUCENE-4106 at 6/4/12 9:58 AM:
-
But then if you wish to loop over all DoubleField values you need to know to do
that check yourself?
{code}
Terms terms = reader.terms(field);
TermsEnum termsEnum = terms.iterator(null);
BytesRef term = termsEnum.next();
if (term != null) {
double min = FieldCache.NUMERIC_UTILS_DOUBLE_PARSER.parseDouble(term);
double max = min;
try {
while ((term = termsEnum.next()) != null) {
max = FieldCache.NUMERIC_UTILS_DOUBLE_PARSER.parseDouble(term);
}
} catch (StopFillCacheException ignored) {
}
doSomething(min, max);
}
{code}
Or am i indexing something wrong to hit that exception? (i don't think i am)
was (Author: selckin):
But then if you wish to loop over all DoubleField values you need to know
to do that check yourself?
{{code}}
Terms terms = reader.terms(field);
TermsEnum termsEnum = terms.iterator(null);
BytesRef term = termsEnum.next();
if (term != null) {
double min = FieldCache.NUMERIC_UTILS_DOUBLE_PARSER.parseDouble(term);
double max = min;
try {
while ((term = termsEnum.next()) != null) {
max = FieldCache.NUMERIC_UTILS_DOUBLE_PARSER.parseDouble(term);
}
} catch (StopFillCacheException ignored) {
}
doSomething(min, max);
}
{{code}}
Or am i indexing something wrong to hit that exception? (i don't think i am)
StopFillCacheException is defined twice and the one is actually thrown is
private and not catchable
---
Key: LUCENE-4106
URL: https://issues.apache.org/jira/browse/LUCENE-4106
Project: Lucene - Java
Issue Type: Bug
Reporter: selckin
Assignee: Uwe Schindler
{code}
lucene/core/src/java/org/apache/lucene/search/FieldCacheImpl.java
145: static final class StopFillCacheException extends RuntimeException {
383:} catch (StopFillCacheException stop) {
456:} catch (StopFillCacheException stop) {
560:} catch (StopFillCacheException stop) {
710:} catch (StopFillCacheException stop) {
798:} catch (StopFillCacheException stop) {
887:} catch (StopFillCacheException stop) {
lucene/core/src/java/org/apache/lucene/search/FieldCache.java
57: public static final class StopFillCacheException extends
RuntimeException {
216:throw new FieldCacheImpl.StopFillCacheException();
232:throw new FieldCacheImpl.StopFillCacheException();
248:throw new FieldCacheImpl.StopFillCacheException();
264:throw new FieldCacheImpl.StopFillCacheException();
{code}
--
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] [Created] (LUCENE-3372) TestIndexWriterOnDiskFull.testAddDocumentOnDiskFull seed failure
TestIndexWriterOnDiskFull.testAddDocumentOnDiskFull seed failure
Key: LUCENE-3372
URL: https://issues.apache.org/jira/browse/LUCENE-3372
Project: Lucene - Java
Issue Type: Bug
Reporter: selckin
version: trunk r1155278
reproduce-able: always
{code}
[junit] Testsuite: org.apache.lucene.index.TestIndexWriterOnDiskFull
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.847 sec
[junit]
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestIndexWriterOnDiskFull
-Dtestmethod=testAddDocumentOnDiskFull
-Dtests.seed=-3cc23002ebad518d:70ae722281b31c9f:57406021f8789a22
[junit] NOTE: test params are: codec=RandomCodecProvider:
{content=MockFixedIntBlock(blockSize=1081)}, locale=hr_HR,
timezone=Atlantic/Jan_Mayen
[junit] NOTE: all tests run in this JVM:
[junit] [TestIndexWriterOnDiskFull]
[junit] NOTE: Linux 2.6.39-gentoo amd64/Sun Microsystems Inc. 1.6.0_26
(64-bit)/cpus=8,threads=1,free=85252968,total=125632512
[junit] - ---
[junit] Testcase:
testAddDocumentOnDiskFull(org.apache.lucene.index.TestIndexWriterOnDiskFull):
Caused an ERROR
[junit] no segments* file found in
MockDirWrapper(org.apache.lucene.store.RAMDirectory@65dcc2a3
lockFactory=MockLockFactoryWrapper(org.apache.lucene.store.SingleInstanceLockFactory@6e8f94)):
files: [_1.cfs, _1.cfe, _0.cfe, _0.cfs]
[junit] org.apache.lucene.index.IndexNotFoundException: no segments* file
found in MockDirWrapper(org.apache.lucene.store.RAMDirectory@65dcc2a3
lockFactory=MockLockFactoryWrapper(org.apache.lucene.store.SingleInstanceLockFactory@6e8f94)):
files: [_1.cfs, _1.cfe, _0.cfe, _0.cfs]
[junit] at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:657)
[junit] at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:534)
[junit] at
org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:284)
[junit] at
org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:277)
[junit] at
org.apache.lucene.index.TestIndexWriter.assertNoUnreferencedFiles(TestIndexWriter.java:158)
[junit] at
org.apache.lucene.index.TestIndexWriterOnDiskFull.testAddDocumentOnDiskFull(TestIndexWriterOnDiskFull.java:114)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1526)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1428)
[junit]
[junit]
[junit] Test org.apache.lucene.index.TestIndexWriterOnDiskFull FAILED
{code}
--
This message is automatically generated by JIRA.
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] [Commented] (LUCENE-3189) TestIndexWriter.testThreadInterruptDeadlock failed (can't reproduce)
[
https://issues.apache.org/jira/browse/LUCENE-3189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073339#comment-13073339
]
selckin commented on LUCENE-3189:
-
had this fail a few days ago too but lost the log, hard to repro
trunk r1152530:
{code}
[junit] Testsuite: org.apache.lucene.index.TestIndexWriter
[junit] Testcase:
testThreadInterruptDeadlock(org.apache.lucene.index.TestIndexWriter): FAILED
[junit]
[junit] junit.framework.AssertionFailedError:
[junit] at
org.apache.lucene.index.TestIndexWriter.testThreadInterruptDeadlock(TestIndexWriter.java:1204)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1522)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1427)
[junit]
[junit]
[junit] Tests run: 40, Failures: 1, Errors: 0, Time elapsed: 19.376 sec
[junit]
[junit] - Standard Output ---
[junit] CheckIndex failed
[junit] ERROR: could not read any segments file in directory
[junit] java.io.FileNotFoundException: segments_27
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:411)
[junit] at
org.apache.lucene.index.codecs.DefaultSegmentInfosReader.openInput(DefaultSegmentInfosReader.java:112)
[junit] at
org.apache.lucene.index.codecs.DefaultSegmentInfosReader.read(DefaultSegmentInfosReader.java:45)
[junit] at
org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:258)
[junit] at
org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:288)
[junit] at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:699)
[junit] at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:534)
[junit] at
org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:284)
[junit] at
org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:334)
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:158)
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:148)
[junit] at
org.apache.lucene.index.TestIndexWriter$IndexerThreadInterrupt.run(TestIndexWriter.java:1155)
[junit]
[junit] CheckIndex FAILED: unexpected exception
[junit] java.lang.RuntimeException: CheckIndex failed
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:162)
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:148)
[junit] at
org.apache.lucene.index.TestIndexWriter$IndexerThreadInterrupt.run(TestIndexWriter.java:1155)
[junit] IndexReader.open FAILED: unexpected exception
[junit] java.io.FileNotFoundException: segments_27
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:411)
[junit] at
org.apache.lucene.index.codecs.DefaultSegmentInfosReader.openInput(DefaultSegmentInfosReader.java:112)
[junit] at
org.apache.lucene.index.codecs.DefaultSegmentInfosReader.read(DefaultSegmentInfosReader.java:45)
[junit] at
org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:258)
[junit] at
org.apache.lucene.index.DirectoryReader$1.doBody(DirectoryReader.java:90)
[junit] at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:699)
[junit] at
org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:86)
[junit] at
org.apache.lucene.index.IndexReader.open(IndexReader.java:497)
[junit] at
org.apache.lucene.index.IndexReader.open(IndexReader.java:290)
[junit] at
org.apache.lucene.index.TestIndexWriter$IndexerThreadInterrupt.run(TestIndexWriter.java:1162)
[junit] - ---
[junit] - Standard Error -
[junit] NOTE: test params are: codec=RandomCodecProvider: {=MockSep,
f6=MockSep, f7=Pulsing(freqCutoff=11), f8=SimpleText, f9=Memory, f1=Memory,
f0=SimpleText, f3=Standard, f2=MockRandom,
f5=MockVariableIntBlock(baseBlockSize=47), f4=MockFixedIntBlock(blockSize=390),
c=Memory, d9=Standard, d8=MockRandom, d5=Pulsing(freqCutoff=11), d4=MockSep,
d7=Memory, d6=SimpleText, d25=MockVariableIntBlock(baseBlockSize=47),
d0=MockRandom, c29=SimpleText, d24=MockFixedIntBlock(blockSize=390),
d1=Standard, c28=Pulsing(freqCutoff=11), d23=Standard,
d2=MockFixedIntBlock(blockSize=390), c27=MockSep, d22=MockRandom,
d3=MockVariableIntBlock(baseBlockSize=47), d21=Memory, d20=SimpleText,
c22=Memory, c21=SimpleText, c20=Pulsing(freqCutoff=11), d29=Memory,
c26=MockVariableIntBlock(baseBlockSize=47), d28=SimpleText,
c25=MockFixedIntBlock(blockSize=390), d27=Pulsing(freqCutoff=11), c24=Standard,
d26=MockSep, c23=MockRandom, e9=MockRandom, e8=Memory,
[jira] [Created] (LUCENE-3350) trunk: TestDocumentsWriterDeleteQueue.testStressDeleteQueue seed failure
trunk: TestDocumentsWriterDeleteQueue.testStressDeleteQueue seed failure
-
Key: LUCENE-3350
URL: https://issues.apache.org/jira/browse/LUCENE-3350
Project: Lucene - Java
Issue Type: Bug
Reporter: selckin
fails 100% of the time for me, trunk r1152089
{code}
[junit] Testsuite: org.apache.lucene.index.TestDocumentsWriterDeleteQueue
[junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.585 sec
[junit]
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test
-Dtestcase=TestDocumentsWriterDeleteQueue -Dtestmethod=testStressDeleteQueue
-Dtests.seed=724635056932528964:-56
53725200660632980
[junit] NOTE: test params are: codec=RandomCodecProvider: {}, locale=en_US,
timezone=Pacific/Port_Moresby
[junit] NOTE: all tests run in this JVM:
[junit] [TestDocumentsWriterDeleteQueue]
[junit] NOTE: Linux 2.6.39-gentoo amd64/Sun Microsystems Inc. 1.6.0_26
(64-bit)/cpus=8,threads=1,free=86067624,total=125632512
[junit] - ---
[junit] Testcase:
testStressDeleteQueue(org.apache.lucene.index.TestDocumentsWriterDeleteQueue):
FAILED
{code}
--
This message is automatically generated by JIRA.
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] [Created] (SOLR-2608) TestReplicationHandler is flakey
TestReplicationHandler is flakey
Key: SOLR-2608
URL: https://issues.apache.org/jira/browse/SOLR-2608
Project: Solr
Issue Type: Bug
Reporter: selckin
I've been running some while(1) tests on trunk, and TestReplicationHandler is
very flakey it fails about every 10th run.
Probably not a bug, but the test not waiting correctly
{code}
[junit] Testsuite: org.apache.solr.handler.TestReplicationHandler
[junit] Testcase: org.apache.solr.handler.TestReplicationHandler: FAILED
[junit] ERROR: SolrIndexSearcher opens=48 closes=47
[junit] junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher
opens=48 closes=47
[junit] at
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:131)
[junit] at
org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:74)
[junit]
[junit]
[junit] Tests run: 8, Failures: 1, Errors: 0, Time elapsed: 40.772 sec
[junit]
[junit] - Standard Error -
[junit] 19-Jun-2011 21:26:44 org.apache.solr.handler.SnapPuller
fetchLatestIndex
[junit] SEVERE: Master at: http://localhost:51817/solr/replication is not
available. Index fetch failed. Exception: Connection refused
[junit] 19-Jun-2011 21:26:49 org.apache.solr.common.SolrException log
[junit] SEVERE: java.util.concurrent.RejectedExecutionException
[junit] at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
[junit] at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
[junit] at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
[junit] at
java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:92)
[junit] at
java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:603)
[junit] at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1149)
[junit] at
org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:346)
[junit] at
org.apache.solr.handler.SnapPuller.doCommit(SnapPuller.java:483)
[junit] at
org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:332)
[junit] at
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:267)
[junit] at org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:166)
[junit] at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
[junit] at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
[junit] at
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[junit] at java.lang.Thread.run(Thread.java:662)
[junit]
[junit] 19-Jun-2011 21:26:51 org.apache.solr.update.SolrIndexWriter finalize
[junit] SEVERE: SolrIndexWriter was not closed prior to finalize(),
indicates a bug -- POSSIBLE RESOURCE LEAK!!!
[junit] 19-Jun-2011 21:26:51 org.apache.solr.common.util.ConcurrentLRUCache
finalize
[junit] SEVERE: ConcurrentLRUCache was not destroyed prior to finalize(),
indicates a bug -- POSSIBLE RESOURCE LEAK!!!
[junit] 19-Jun-2011 21:27:13 org.apache.solr.handler.SnapPuller
fetchLatestIndex
[junit] SEVERE: Master at: http://localhost:46559/solr/replication is not
available. Index fetch failed. Exception: Connection refused
[junit] 19-Jun-2011 21:27:14 org.apache.solr.handler.SnapPuller
fetchLatestIndex
[junit] SEVERE: Master at: http://localhost:46559/solr/replication is not
available. Index fetch failed. Exception: Connection refused
[junit] 19-Jun-2011 21:27:14 org.apache.solr.SolrTestCaseJ4
endTrackingSearchers
[junit] SEVERE: ERROR: SolrIndexSearcher opens=48 closes=47
[junit] - ---
[junit] TEST org.apache.solr.handler.TestReplicationHandler FAILED
{code}
--
This message is automatically generated by JIRA.
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] [Commented] (LUCENE-3190) TestStressIndexing2 testMultiConfig failure
[
https://issues.apache.org/jira/browse/LUCENE-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13049100#comment-13049100
]
selckin commented on LUCENE-3190:
-
{code}
[junit] Testsuite: org.apache.lucene.index.TestStressIndexing2
[junit] Tests run: 50, Failures: 2, Errors: 0, Time elapsed: 11.135 sec
[junit]
[junit] - Standard Error -
[junit] java.lang.AssertionError: ram was 460248 expected: 407592 flush
mem: 394568 active: 65680 pending: 0 flushing: 3 blocked: 0 peakDelta: 65959
[junit] at
org.apache.lucene.index.DocumentsWriterFlushControl.assertMemory(DocumentsWriterFlushControl.java:102)
[junit] at
org.apache.lucene.index.DocumentsWriterFlushControl.doAfterDocument(DocumentsWriterFlushControl.java:164)
[junit] at
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:380)
[junit] at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1474)
[junit] at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1446)
[junit] at
org.apache.lucene.index.TestStressIndexing2$IndexingThread.indexDoc(TestStressIndexing2.java:723)
[junit] at
org.apache.lucene.index.TestStressIndexing2$IndexingThread.run(TestStressIndexing2.java:757)
[junit] NOTE: reproduce with: ant test -Dtestcase=TestStressIndexing2
-Dtestmethod=testMultiConfig
-Dtests.seed=2571834029692482827:-8116419692655152763
[junit] NOTE: reproduce with: ant test -Dtestcase=TestStressIndexing2
-Dtestmethod=testMultiConfig
-Dtests.seed=2571834029692482827:-8116419692655152763
[junit] The following exceptions were thrown by threads:
[junit] *** Thread: Thread-793 ***
[junit] junit.framework.AssertionFailedError: java.lang.AssertionError: ram
was 460248 expected: 407592 flush mem: 394568 active: 65680 pending: 0
flushing: 3 blocked: 0 peakDelta: 65959
[junit] at junit.framework.Assert.fail(Assert.java:47)
[junit] at
org.apache.lucene.index.TestStressIndexing2$IndexingThread.run(TestStressIndexing2.java:762)
[junit] NOTE: test params are: codec=RandomCodecProvider: {f34=MockRandom,
f33=Standard, f32=Standard, f31=MockSep, f30=Pulsing(freqCutoff=7),
f39=Standard, f38=MockSep, f37=Pulsing(freqCutoff=7),
f36=MockFixedIntBlock(blockSize=649),
f35=MockVariableIntBlock(baseBlockSize=9),
f43=MockFixedIntBlock(blockSize=649),
f42=MockVariableIntBlock(baseBlockSize=9), f45=MockSep,
f44=Pulsing(freqCutoff=7), f41=MockRandom, f40=Standard, f47=Standard,
f46=Standard, f49=MockVariableIntBlock(baseBlockSize=9), f48=MockRandom,
f6=Pulsing(freqCutoff=7), f7=MockSep, f8=Standard,
f9=MockVariableIntBlock(baseBlockSize=9), f12=Standard, f11=Standard,
f10=MockSep, f16=Pulsing(freqCutoff=7), f15=MockFixedIntBlock(blockSize=649),
f14=MockVariableIntBlock(baseBlockSize=9), f13=MockRandom, f19=Standard,
f18=Standard, f17=MockSep, f1=MockFixedIntBlock(blockSize=649),
f0=MockVariableIntBlock(baseBlockSize=9), f3=MockSep, f2=Pulsing(freqCutoff=7),
f5=MockVariableIntBlock(baseBlockSize=9), f4=Standard,
f21=MockVariableIntBlock(baseBlockSize=9), f20=MockRandom,
f23=Pulsing(freqCutoff=7), f22=MockFixedIntBlock(blockSize=649), f25=Standard,
f24=MockSep, f27=MockRandom, f26=Standard,
f29=MockFixedIntBlock(blockSize=649),
f28=MockVariableIntBlock(baseBlockSize=9),
f98=MockVariableIntBlock(baseBlockSize=9), f97=MockRandom,
f99=MockFixedIntBlock(blockSize=649), f94=MockSep, f93=Pulsing(freqCutoff=7),
f96=Standard, f95=Standard, f79=Pulsing(freqCutoff=7),
f77=MockVariableIntBlock(baseBlockSize=9),
f78=MockFixedIntBlock(blockSize=649), f75=Standard, f76=MockRandom,
f73=MockSep, f74=Standard, f71=MockFixedIntBlock(blockSize=649),
f72=Pulsing(freqCutoff=7), f81=MockVariableIntBlock(baseBlockSize=9),
f80=MockRandom, f86=Pulsing(freqCutoff=7), f87=MockSep, f88=Standard,
f89=Standard, f82=Standard, f83=MockRandom,
f84=MockVariableIntBlock(baseBlockSize=9),
f85=MockFixedIntBlock(blockSize=649), f90=Pulsing(freqCutoff=7), f92=Standard,
f91=MockSep, f59=MockSep, f57=MockFixedIntBlock(blockSize=649),
f58=Pulsing(freqCutoff=7), f51=Pulsing(freqCutoff=7), f52=MockSep,
f50=MockFixedIntBlock(blockSize=649), f55=MockRandom,
f56=MockVariableIntBlock(baseBlockSize=9), f53=Standard, f54=Standard,
id=MockFixedIntBlock(blockSize=649), f68=Standard, f69=MockRandom,
f60=Standard, f61=Standard, f62=MockRandom,
f63=MockVariableIntBlock(baseBlockSize=9),
f64=MockFixedIntBlock(blockSize=649), f65=Pulsing(freqCutoff=7), f66=MockSep,
f67=Standard, f70=MockSep}, locale=en_SG, timezone=Europe/Dublin
[junit] NOTE: all tests run in this JVM:
[junit] [TestStressIndexing2]
[junit] NOTE: Linux 2.6.39-gentoo amd64/Sun Microsystems Inc. 1.6.0_26
(64-bit)/cpus=8,threads=1,free=61143744,total=147718144
[junit] - ---
[junit] Testcase:
[jira] [Created] (LUCENE-3189) TestIndexWriter.testThreadInterruptDeadlock failed (can't reproduce)
TestIndexWriter.testThreadInterruptDeadlock failed (can't reproduce)
Key: LUCENE-3189
URL: https://issues.apache.org/jira/browse/LUCENE-3189
Project: Lucene - Java
Issue Type: Bug
Reporter: selckin
trunk: r1134163
ran it a few times with tests.iter=200 and couldn't reproduce, but i believe
you like an issue anyway.
{code}
[junit] Testsuite: org.apache.lucene.index.TestIndexWriter
[junit] Testcase:
testThreadInterruptDeadlock(org.apache.lucene.index.TestIndexWriter): FAILED
[junit]
[junit] junit.framework.AssertionFailedError:
[junit] at
org.apache.lucene.index.TestIndexWriter.testThreadInterruptDeadlock(TestIndexWriter.java:1203)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1403)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1321)
[junit]
[junit]
[junit] Tests run: 40, Failures: 1, Errors: 0, Time elapsed: 23.79 sec
[junit]
[junit] - Standard Output ---
[junit] CheckIndex failed
[junit] ERROR: could not read any segments file in directory
[junit] java.io.FileNotFoundException: segments_2w
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:407)
[junit] at
org.apache.lucene.index.codecs.DefaultSegmentInfosReader.openInput(DefaultSegmentInfosReader.java:112)
[junit] at
org.apache.lucene.index.codecs.DefaultSegmentInfosReader.read(DefaultSegmentInfosReader.java:45)
[junit] at
org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:257)
[junit] at
org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:287)
[junit] at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:698)
[junit] at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:533)
[junit] at
org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:283)
[junit] at
org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:311)
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:154)
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:144)
[junit] at
org.apache.lucene.index.TestIndexWriter$IndexerThreadInterrupt.run(TestIndexWriter.java:1154)
[junit]
[junit] CheckIndex FAILED: unexpected exception
[junit] java.lang.RuntimeException: CheckIndex failed
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:158)
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:144)
[junit] at
org.apache.lucene.index.TestIndexWriter$IndexerThreadInterrupt.run(TestIndexWriter.java:1154)
[junit] IndexReader.open FAILED: unexpected exception
[junit] java.io.FileNotFoundException: segments_2w
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:407)
[junit] at
org.apache.lucene.index.codecs.DefaultSegmentInfosReader.openInput(DefaultSegmentInfosReader.java:112)
[junit] at
org.apache.lucene.index.codecs.DefaultSegmentInfosReader.read(DefaultSegmentInfosReader.java:45)
[junit] at
org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:257)
[junit] at
org.apache.lucene.index.DirectoryReader$1.doBody(DirectoryReader.java:88)
[junit] at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:698)
[junit] at
org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:84)
[junit] at
org.apache.lucene.index.IndexReader.open(IndexReader.java:500)
[junit] at
org.apache.lucene.index.IndexReader.open(IndexReader.java:293)
[junit] at
org.apache.lucene.index.TestIndexWriter$IndexerThreadInterrupt.run(TestIndexWriter.java:1161)
[junit] - ---
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestIndexWriter
-Dtestmethod=testThreadInterruptDeadlock
-Dtests.seed=6733070832417768606:3130345095020099096
[junit] NOTE: test params are: codec=RandomCodecProvider: {=MockRandom,
f6=SimpleText, f7=MockRandom, f8=MockSep, f9=Standard, f1=SimpleText,
f0=Standard, f3=Standard, f2=MockSep, f5=Pulsing(freqCutoff=12),
f4=MockFixedIntBlock(blockSize=552), c=MockVariableIntBlock(baseBlockSize=43),
d9=MockVariableIntBlock(baseBlockSize=43), d8=MockRandom, d5=MockSep,
d4=Pulsing(freqCutoff=12), d7=MockFixedIntBlock(blockSize=55
2), d6=MockVariableIntBlock(baseBlockSize=43), d25=MockSep,
d0=MockVariableIntBlock(baseBlockSize=43),
c29=MockFixedIntBlock(blockSize=552), d24=Pulsing(freqCutoff=12),
d1=MockFixedIntBlock(blockSize=552), c28=
Standard,
[jira] [Created] (LUCENE-3190) TestStressIndexing2 testMultiConfig failure
TestStressIndexing2 testMultiConfig failure
---
Key: LUCENE-3190
URL: https://issues.apache.org/jira/browse/LUCENE-3190
Project: Lucene - Java
Issue Type: Bug
Reporter: selckin
trunk: r1134311
reproducible
{code}
[junit] Testsuite: org.apache.lucene.index.TestStressIndexing2
[junit] Tests run: 1, Failures: 2, Errors: 0, Time elapsed: 0.882 sec
[junit]
[junit] - Standard Error -
[junit] java.lang.AssertionError: ram was 460908 expected: 408216 flush
mem: 395100 active: 65808
[junit] at
org.apache.lucene.index.DocumentsWriterFlushControl.assertMemory(DocumentsWriterFlushControl.java:102)
[junit] at
org.apache.lucene.index.DocumentsWriterFlushControl.doAfterDocument(DocumentsWriterFlushControl.java:164)
[junit] at
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:380)
[junit] at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1473)
[junit] at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1445)
[junit] at
org.apache.lucene.index.TestStressIndexing2$IndexingThread.indexDoc(TestStressIndexing2.java:723)
[junit] at
org.apache.lucene.index.TestStressIndexing2$IndexingThread.run(TestStressIndexing2.java:757)
[junit] NOTE: reproduce with: ant test -Dtestcase=TestStressIndexing2
-Dtestmethod=testMultiConfig
-Dtests.seed=2571834029692482827:-8116419692655152763
[junit] NOTE: reproduce with: ant test -Dtestcase=TestStressIndexing2
-Dtestmethod=testMultiConfig
-Dtests.seed=2571834029692482827:-8116419692655152763
[junit] The following exceptions were thrown by threads:
[junit] *** Thread: Thread-0 ***
[junit] junit.framework.AssertionFailedError: java.lang.AssertionError: ram
was 460908 expected: 408216 flush mem: 395100 active: 65808
[junit] at junit.framework.Assert.fail(Assert.java:47)
[junit] at
org.apache.lucene.index.TestStressIndexing2$IndexingThread.run(TestStressIndexing2.java:762)
[junit] NOTE: test params are: codec=RandomCodecProvider: {f33=Standard,
f57=MockFixedIntBlock(blockSize=649), f11=Standard, f41=MockRandom,
f40=Standard, f62=MockRandom, f75=Standard, f73=MockSep,
f29=MockFixedIntBlock(blockSize=649), f83=MockRandom, f66=MockSep,
f49=MockVariableIntBlock(baseBlockSize=9), f72=Pulsing(freqCutoff=7),
f54=Standard, id=MockFixedIntBlock(blockSize=649), f80=MockRandom, f94=MockSep,
f93=Pulsing(freqCutoff=7), f95=Standard}, locale=en_SG, timezone=Pacific/Palau
[junit] NOTE: all tests run in this JVM:
[junit] [TestStressIndexing2]
[junit] NOTE: Linux 2.6.39-gentoo amd64/Sun Microsystems Inc. 1.6.0_25
(64-bit)/cpus=8,threads=1,free=133324528,total=158400512
[junit] - ---
[junit] Testcase:
testMultiConfig(org.apache.lucene.index.TestStressIndexing2): FAILED
[junit] r1.numDocs()=17 vs r2.numDocs()=16
[junit] junit.framework.AssertionFailedError: r1.numDocs()=17 vs
r2.numDocs()=16
[junit] at
org.apache.lucene.index.TestStressIndexing2.verifyEquals(TestStressIndexing2.java:308)
[junit] at
org.apache.lucene.index.TestStressIndexing2.verifyEquals(TestStressIndexing2.java:278)
[junit] at
org.apache.lucene.index.TestStressIndexing2.testMultiConfig(TestStressIndexing2.java:124)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1403)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1321)
[junit]
[junit]
[junit] Testcase:
testMultiConfig(org.apache.lucene.index.TestStressIndexing2): FAILED
[junit] Some threads threw uncaught exceptions!
[junit] junit.framework.AssertionFailedError: Some threads threw uncaught
exceptions!
[junit] at
org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:603)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1403)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1321)
[junit]
[junit]
[junit] Test org.apache.lucene.index.TestStressIndexing2 FAILED
{code}
--
This message is automatically generated by JIRA.
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] [Created] (LUCENE-3182) TestAddIndexes reproducible test failure on turnk
TestAddIndexes reproducible test failure on turnk
-
Key: LUCENE-3182
URL: https://issues.apache.org/jira/browse/LUCENE-3182
Project: Lucene - Java
Issue Type: Bug
Reporter: selckin
trunk: r1133385
{code}
[junit] Testsuite: org.apache.lucene.index.TestAddIndexes
[junit] Tests run: 2843, Failures: 1, Errors: 0, Time elapsed: 137.121 sec
[junit]
[junit] - Standard Output ---
[junit] java.io.FileNotFoundException: _cy.fdx
[junit] at
org.apache.lucene.store.RAMDirectory.fileLength(RAMDirectory.java:121)
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.fileLength(MockDirectoryWrapper.java:606)
[junit] at
org.apache.lucene.index.SegmentInfo.sizeInBytes(SegmentInfo.java:294)
[junit] at
org.apache.lucene.index.TieredMergePolicy.size(TieredMergePolicy.java:633)
[junit] at
org.apache.lucene.index.TieredMergePolicy.useCompoundFile(TieredMergePolicy.java:611)
[junit] at
org.apache.lucene.index.IndexWriter.addIndexes(IndexWriter.java:2459)
[junit] at
org.apache.lucene.index.TestAddIndexes$CommitAndAddIndexes3.doBody(TestAddIndexes.java:847)
[junit] at
org.apache.lucene.index.TestAddIndexes$RunAddIndexesThreads$1.run(TestAddIndexes.java:675)
[junit] java.io.FileNotFoundException: _cx.fdx
[junit] at
org.apache.lucene.store.RAMDirectory.fileLength(RAMDirectory.java:121)
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.fileLength(MockDirectoryWrapper.java:606)
[junit] at
org.apache.lucene.index.SegmentInfo.sizeInBytes(SegmentInfo.java:294)
[junit] at
org.apache.lucene.index.TieredMergePolicy.size(TieredMergePolicy.java:633)
[junit] at
org.apache.lucene.index.TieredMergePolicy.useCompoundFile(TieredMergePolicy.java:611)
[junit] at
org.apache.lucene.index.IndexWriter.addIndexes(IndexWriter.java:2459)
[junit] at
org.apache.lucene.index.TestAddIndexes$CommitAndAddIndexes3.doBody(TestAddIndexes.java:847)
[junit] at
org.apache.lucene.index.TestAddIndexes$RunAddIndexesThreads$1.run(TestAddIndexes.java:675)
[junit] - ---
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestAddIndexes
-Dtestmethod=testAddIndexesWithRollback
-Dtests.seed=9026722750295014952:2645762923088581043 -Dtests.multiplier=3
[junit] NOTE: test params are: codec=RandomCodecProvider: {id=SimpleText,
content=SimpleText, d=MockRandom, c=SimpleText}, locale=fr,
timezone=Africa/Kigali
[junit] NOTE: all tests run in this JVM:
[junit] [TestAddIndexes]
[junit] NOTE: Linux 2.6.39-gentoo amd64/Sun Microsystems Inc. 1.6.0_25
(64-bit)/cpus=8,threads=1,free=68050392,total=446234624
[junit] - ---
[junit] Testcase:
testAddIndexesWithRollback(org.apache.lucene.index.TestAddIndexes): FAILED
[junit]
[junit] junit.framework.AssertionFailedError:
[junit] at
org.apache.lucene.index.TestAddIndexes.testAddIndexesWithRollback(TestAddIndexes.java:932)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1362)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1280)
[junit]
[junit]
[junit] Test org.apache.lucene.index.TestAddIndexes FAILED
{code}
Fails randomly in my while(1) test run, and Fails after a few min of running:
{code}
ant test -Dtestcase=TestAddIndexes
-Dtests.seed=9026722750295014952:2645762923088581043 -Dtests.multiplier=3
-Dtests.iter=200 -Dtests.iter.min=1
{code}
--
This message is automatically generated by JIRA.
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] [Created] (LUCENE-3183) TestIndexWriter failure: AIOOBE
TestIndexWriter failure: AIOOBE
---
Key: LUCENE-3183
URL: https://issues.apache.org/jira/browse/LUCENE-3183
Project: Lucene - Java
Issue Type: Bug
Reporter: selckin
trunk: r1133486
{code}
[junit] Testsuite: org.apache.lucene.index.TestIndexWriter
[junit] Testcase:
testEmptyFieldName(org.apache.lucene.index.TestIndexWriter): Caused an
ERROR
[junit] CheckIndex failed
[junit] java.lang.RuntimeException: CheckIndex failed
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:158)
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:144)
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:477)
[junit] at
org.apache.lucene.index.TestIndexWriter.testEmptyFieldName(TestIndexWriter.java:857)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1362)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1280)
[junit]
[junit]
[junit] Tests run: 39, Failures: 0, Errors: 1, Time elapsed: 17.634 sec
[junit]
[junit] - Standard Output ---
[junit] CheckIndex failed
[junit] Segments file=segments_1 numSegments=1 version=FORMAT_4_0 [Lucene
4.0]
[junit] 1 of 1: name=_0 docCount=1
[junit] codec=SegmentCodecs [codecs=[PreFlex],
provider=org.apache.lucene.index.codecs.CoreCodecProvider@3f78807]
[junit] compound=false
[junit] hasProx=true
[junit] numFiles=8
[junit] size (MB)=0
[junit] diagnostics = {os.version=2.6.39-gentoo, os=Linux,
lucene.version=4.0-SNAPSHOT, source=flush, os.arch=amd64,
java.version=1.6.0_25, java.vendor=Sun Microsystems Inc.}
[junit] no deletions
[junit] test: open reader.OK
[junit] test: fields..OK [1 fields]
[junit] test: field norms.OK [1 fields]
[junit] test: terms, freq, prox...ERROR:
java.lang.ArrayIndexOutOfBoundsException: -1
[junit] java.lang.ArrayIndexOutOfBoundsException: -1
[junit] at
org.apache.lucene.index.codecs.preflex.TermInfosReader.seekEnum(TermInfosReader.java:212)
[junit] at
org.apache.lucene.index.codecs.preflex.TermInfosReader.seekEnum(TermInfosReader.java:301)
[junit] at
org.apache.lucene.index.codecs.preflex.TermInfosReader.get(TermInfosReader.java:234)
[junit] at
org.apache.lucene.index.codecs.preflex.TermInfosReader.terms(TermInfosReader.java:371)
[junit] at
org.apache.lucene.index.codecs.preflex.PreFlexFields$PreTermsEnum.reset(PreFlexFields.java:719)
[junit] at
org.apache.lucene.index.codecs.preflex.PreFlexFields$PreTerms.iterator(PreFlexFields.java:249)
[junit] at
org.apache.lucene.index.PerFieldCodecWrapper$FieldsReader$FieldsIterator.terms(PerFieldCodecWrapper.java:147)
[junit] at
org.apache.lucene.index.CheckIndex.testTermIndex(CheckIndex.java:610)
[junit] at
org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:495)
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:154)
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:144)
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:477)
[junit] at
org.apache.lucene.index.TestIndexWriter.testEmptyFieldName(TestIndexWriter.java:857)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:597)
[junit] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
[junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
[junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
[junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
[junit] at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
[junit] at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1362)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1280)
[junit] at
[jira] [Created] (LUCENE-3170) TestDocValuesIndexing reproducible test failure
TestDocValuesIndexing reproducible test failure
Key: LUCENE-3170
URL: https://issues.apache.org/jira/browse/LUCENE-3170
Project: Lucene - Java
Issue Type: Bug
Reporter: selckin
docvalues branch: r1131275
{code}
[junit] Testsuite: org.apache.lucene.index.values.TestDocValuesIndexing
[junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.81 sec
[junit]
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestDocValuesIndexing
-Dtestmethod=testAddIndexes
-Dtests.seed=-3253978684351194958:-8331223747763543724
[junit] NOTE: test params are: codec=RandomCodecProvider: {id=Standard,
BYTES_VAR_STRAIGHT=Pulsing(freqCutoff=12), BYTES_FIXED_SORTED=MockRandom},
locale=es_MX, timezone=Pacific/Chatham
[junit] NOTE: all tests run in this JVM:
[junit] [TestDocValuesIndexing]
[junit] NOTE: Linux 2.6.39-gentoo amd64/Sun Microsystems Inc. 1.6.0_25
(64-bit)/cpus=8,threads=1,free=89168480,total=125632512
[junit] - ---
[junit] Testcase:
testAddIndexes(org.apache.lucene.index.values.TestDocValuesIndexing): FAILED
[junit] [first=BYTES_FIXED_SORTED, second=BYTES_VAR_STRAIGHT] expected:9
but was:10
[junit] junit.framework.AssertionFailedError: [first=BYTES_FIXED_SORTED,
second=BYTES_VAR_STRAIGHT] expected:9 but was:10
[junit] at
org.apache.lucene.index.values.TestDocValuesIndexing.testAddIndexes(TestDocValuesIndexing.java:208)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1348)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1266)
[junit]
[junit]
[junit] Test org.apache.lucene.index.values.TestDocValuesIndexing FAILED
{code}
--
This message is automatically generated by JIRA.
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] [Created] (LUCENE-3148) TestIndexWriterExceptions reproducible AOOBE in MockVariableIntBlockCodec
TestIndexWriterExceptions reproducible AOOBE in MockVariableIntBlockCodec
-
Key: LUCENE-3148
URL: https://issues.apache.org/jira/browse/LUCENE-3148
Project: Lucene - Java
Issue Type: Bug
Reporter: selckin
Priority: Minor
{code}
[junit] Testsuite: org.apache.lucene.index.TestIndexWriterExceptions
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.739 sec
[junit]
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestIndexWriterExceptions
-Dtestmethod=testDocumentsWriterAbort -Dtests.seed=4579947455
682149564:-7960989923752018504
[junit] NOTE: test params are: codec=RandomCodecProvider:
{content=MockVariableIntBlock(baseBlockSize=32)}, locale=bg_BG, timezone=Brazil
/Acre
[junit] NOTE: all tests run in this JVM:
[junit] [TestIndexWriterExceptions]
[junit] NOTE: Linux 2.6.37-gentoo amd64/Sun Microsystems Inc. 1.6.0_25
(64-bit)/cpus=8,threads=1,free=94363216,total=125632512
[junit] - ---
[junit] Testcase:
testDocumentsWriterAbort(org.apache.lucene.index.TestIndexWriterExceptions):
Caused an ERROR
[junit] 66
[junit] java.lang.ArrayIndexOutOfBoundsException: 66
[junit] at
org.apache.lucene.index.codecs.mockintblock.MockVariableIntBlockCodec$MockIntFactory$2.add(MockVariableIntBlockCodec.java:
114)
[junit] at
org.apache.lucene.index.codecs.intblock.VariableIntBlockIndexOutput.close(VariableIntBlockIndexOutput.java:118)
[junit] at
org.apache.lucene.index.codecs.sep.SepPostingsWriterImpl.close(SepPostingsWriterImpl.java:320)
[junit] at
org.apache.lucene.index.codecs.BlockTermsWriter.close(BlockTermsWriter.java:137)
[junit] at
org.apache.lucene.index.PerFieldCodecWrapper$FieldsWriter.close(PerFieldCodecWrapper.java:81)
[junit] at
org.apache.lucene.index.FreqProxTermsWriter.flush(FreqProxTermsWriter.java:103)
[junit] at org.apache.lucene.index.TermsHash.flush(TermsHash.java:118)
[junit] at
org.apache.lucene.index.DocInverter.flush(DocInverter.java:80)
[junit] at
org.apache.lucene.index.DocFieldProcessor.flush(DocFieldProcessor.java:75)
[junit] at
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:457)
[junit] at
org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:417)
[junit] at
org.apache.lucene.index.DocumentsWriter.postUpdate(DocumentsWriter.java:309)
[junit] at
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:381)
[junit] at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1469)
[junit] at
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1229)
[junit] at
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1210)
[junit] at
org.apache.lucene.index.TestIndexWriterExceptions.testDocumentsWriterAbort(TestIndexWriterExceptions.java:555)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1333)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1251)
[junit]
[junit]
[junit] Test org.apache.lucene.index.TestIndexWriterExceptions FAILED
{code}
trunk: r1127871
--
This message is automatically generated by JIRA.
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] [Created] (LUCENE-3125) TestDocValuesIndexing.testAddIndexes failures on docvalues branch
TestDocValuesIndexing.testAddIndexes failures on docvalues branch
-
Key: LUCENE-3125
URL: https://issues.apache.org/jira/browse/LUCENE-3125
Project: Lucene - Java
Issue Type: Bug
Reporter: selckin
doc values branch r1124825, reproducible
{code}
[junit] Testsuite: org.apache.lucene.index.values.TestDocValuesIndexing
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.716 sec
[junit]
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestDocValuesIndexing
-Dtestmethod=testAddIndexes
-Dtests.seed=5939035003978436534:-6429764582682717131
[junit] NOTE: test params are: codec=RandomCodecProvider: {id=MockRandom,
BYTES_VAR_DEREF=MockRandom, INTS=Pulsing(freqCutoff=13)}, locale=da_DK,
timezone=Asia/Macao
[junit] NOTE: all tests run in this JVM:
[junit] [TestDocValuesIndexing]
[junit] NOTE: Linux 2.6.37-gentoo amd64/Sun Microsystems Inc. 1.6.0_25
(64-bit)/cpus=8,threads=1,free=88582432,total=125632512
[junit] - ---
[junit] Testcase:
testAddIndexes(org.apache.lucene.index.values.TestDocValuesIndexing):
Caused an ERROR
[junit] null
[junit] java.nio.channels.ClosedChannelException
[junit] at
sun.nio.ch.FileChannelImpl.ensureOpen(FileChannelImpl.java:88)
[junit] at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:603)
[junit] at
org.apache.lucene.store.NIOFSDirectory$NIOFSIndexInput.readInternal(NIOFSDirectory.java:161)
[junit] at
org.apache.lucene.store.BufferedIndexInput.refill(BufferedIndexInput.java:222)
[junit] at
org.apache.lucene.store.BufferedIndexInput.readByte(BufferedIndexInput.java:39)
[junit] at org.apache.lucene.store.DataInput.readInt(DataInput.java:73)
[junit] at
org.apache.lucene.store.BufferedIndexInput.readInt(BufferedIndexInput.java:162)
[junit] at
org.apache.lucene.store.DataInput.readLong(DataInput.java:115)
[junit] at
org.apache.lucene.store.BufferedIndexInput.readLong(BufferedIndexInput.java:175)
[junit] at
org.apache.lucene.store.MockIndexInputWrapper.readLong(MockIndexInputWrapper.java:136)
[junit] at
org.apache.lucene.index.values.PackedIntsImpl$IntsEnumImpl.init(PackedIntsImpl.java:263)
[junit] at
org.apache.lucene.index.values.PackedIntsImpl$IntsEnumImpl.init(PackedIntsImpl.java:249)
[junit] at
org.apache.lucene.index.values.PackedIntsImpl$IntsReader.getEnum(PackedIntsImpl.java:239)
[junit] at
org.apache.lucene.index.values.DocValues.getEnum(DocValues.java:54)
[junit] at
org.apache.lucene.index.values.TestDocValuesIndexing.getValuesEnum(TestDocValuesIndexing.java:484)
[junit] at
org.apache.lucene.index.values.TestDocValuesIndexing.testAddIndexes(TestDocValuesIndexing.java:202)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1304)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1233)
[junit]
[junit]
[junit] Test org.apache.lucene.index.values.TestDocValuesIndexing FAILED
{code}
and
{code}
[junit] Testsuite: org.apache.lucene.index.values.TestDocValuesIndexing
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.94 sec
[junit]
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestDocValuesIndexing
-Dtestmethod=testAddIndexes
-Dtests.seed=-3677966427932339626:-4746638811786223564
[junit] NOTE: test params are: codec=RandomCodecProvider: {id=Standard,
BYTES_FIXED_DEREF=MockSep, FLOAT_64=SimpleText}, locale=ca,
timezone=Asia/Novosibirsk
[junit] NOTE: all tests run in this JVM:
[junit] [TestDocValuesIndexing]
[junit] NOTE: Linux 2.6.37-gentoo amd64/Sun Microsystems Inc. 1.6.0_25
(64-bit)/cpus=8,threads=1,free=88596152,total=125632512
[junit] - ---
[junit] Testcase:
testAddIndexes(org.apache.lucene.index.values.TestDocValuesIndexing):
Caused an ERROR
[junit] Bad file descriptor
[junit] java.io.IOException: Bad file descriptor
[junit] at java.io.RandomAccessFile.seek(Native Method)
[junit] at
org.apache.lucene.store.SimpleFSDirectory$SimpleFSIndexInput.readInternal(SimpleFSDirectory.java:101)
[junit] at
org.apache.lucene.store.BufferedIndexInput.refill(BufferedIndexInput.java:222)
[junit] at
org.apache.lucene.store.BufferedIndexInput.readByte(BufferedIndexInput.java:39)
[junit] at
org.apache.lucene.store.MockIndexInputWrapper.readByte(MockIndexInputWrapper.java:105)
[junit] at
org.apache.lucene.index.values.Floats$FloatsReader.load(Floats.java:281)
[junit] at
[jira] [Commented] (LUCENE-3125) TestDocValuesIndexing.testAddIndexes failures on docvalues branch
[
https://issues.apache.org/jira/browse/LUCENE-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13036378#comment-13036378
]
selckin commented on LUCENE-3125:
-
{code}
[junit] Testsuite: org.apache.lucene.index.values.TestDocValuesIndexing
[junit] Testcase:
testAddIndexes(org.apache.lucene.index.values.TestDocValuesIndexing):
Caused an ERROR
[junit] MMapIndexInput already closed
[junit] org.apache.lucene.store.AlreadyClosedException: MMapIndexInput
already closed
[junit] at
org.apache.lucene.store.MMapDirectory$MMapIndexInput.clone(MMapDirectory.java:291)
[junit] at
org.apache.lucene.store.MockIndexInputWrapper.clone(MockIndexInputWrapper.java:68)
[junit] at
org.apache.lucene.index.values.Bytes$BytesReaderBase.cloneData(Bytes.java:454)
[junit] at
org.apache.lucene.index.values.VarSortedBytesImpl$Reader.getEnum(VarSortedBytesImpl.java:234)
[junit] at
org.apache.lucene.index.values.DocValues.getEnum(DocValues.java:54)
[junit] at
org.apache.lucene.index.values.TestDocValuesIndexing.getValuesEnum(TestDocValuesIndexing.java:484)
[junit] at
org.apache.lucene.index.values.TestDocValuesIndexing.testAddIndexes(TestDocValuesIndexing.java:203)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1304)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1233)
[junit]
[junit]
[junit] Tests run: 10, Failures: 0, Errors: 1, Time elapsed: 16.858 sec
[junit]
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestDocValuesIndexing
-Dtestmethod=testAddIndexes -Dtests.seed=2717387190169859484:6990694723425578308
[junit] NOTE: test params are: codec=RandomCodecProvider:
{id=Pulsing(freqCutoff=14), FLOAT_32=Pulsing(freqCutoff=14),
BYTES_FIXED_DEREF=MockSep, BYTES_VAR_DEREF=MockFixedIntBlock(blockSize=1259),
BYTES_VAR_SORTED=MockSep,
BYTES_VAR_STRAIGHT=MockVariableIntBlock(baseBlockSize=15),
BYTES_FIXED_STRAIGHT=MockVariableIntBlock(baseBlockSize=15), docId=MockSep,
FLOAT_64=Standard, INTS=Standard, BYTES_FIXED_SORTED=MockSep}, locale=uk_UA,
timezone=EST
[junit] NOTE: all tests run in this JVM:
[junit] [TestAssertions, TestDemo, TestCachingTokenFilter, TestDocument,
TestDeletionPolicy, TestDirectoryReader, TestDocumentWriter, TestFlex,
TestIndexReaderCloneNorms, TestLongPostings, TestMultiReader, TestOmitTf,
TestRollingUpdates, TestSegmentTermEnum, TestDocValuesIndexing]
[junit] NOTE: Linux 2.6.37-gentoo amd64/Sun Microsystems Inc. 1.6.0_25
(64-bit)/cpus=8,threads=1,free=165611040,total=263258112
[junit] - ---
[junit] TEST org.apache.lucene.index.values.TestDocValuesIndexing FAILED
{code}
TestDocValuesIndexing.testAddIndexes failures on docvalues branch
-
Key: LUCENE-3125
URL: https://issues.apache.org/jira/browse/LUCENE-3125
Project: Lucene - Java
Issue Type: Bug
Reporter: selckin
doc values branch r1124825, reproducible
{code}
[junit] Testsuite: org.apache.lucene.index.values.TestDocValuesIndexing
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.716 sec
[junit]
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestDocValuesIndexing
-Dtestmethod=testAddIndexes
-Dtests.seed=5939035003978436534:-6429764582682717131
[junit] NOTE: test params are: codec=RandomCodecProvider: {id=MockRandom,
BYTES_VAR_DEREF=MockRandom, INTS=Pulsing(freqCutoff=13)}, locale=da_DK,
timezone=Asia/Macao
[junit] NOTE: all tests run in this JVM:
[junit] [TestDocValuesIndexing]
[junit] NOTE: Linux 2.6.37-gentoo amd64/Sun Microsystems Inc. 1.6.0_25
(64-bit)/cpus=8,threads=1,free=88582432,total=125632512
[junit] - ---
[junit] Testcase:
testAddIndexes(org.apache.lucene.index.values.TestDocValuesIndexing):
Caused an ERROR
[junit] null
[junit] java.nio.channels.ClosedChannelException
[junit] at
sun.nio.ch.FileChannelImpl.ensureOpen(FileChannelImpl.java:88)
[junit] at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:603)
[junit] at
org.apache.lucene.store.NIOFSDirectory$NIOFSIndexInput.readInternal(NIOFSDirectory.java:161)
[junit] at
org.apache.lucene.store.BufferedIndexInput.refill(BufferedIndexInput.java:222)
[junit] at
org.apache.lucene.store.BufferedIndexInput.readByte(BufferedIndexInput.java:39)
[junit] at
org.apache.lucene.store.DataInput.readInt(DataInput.java:73)
[junit] at
[jira] [Created] (LUCENE-3111) TestFSTs.testRandomWords failure
TestFSTs.testRandomWords failure
Key: LUCENE-3111
URL: https://issues.apache.org/jira/browse/LUCENE-3111
Project: Lucene - Java
Issue Type: Bug
Reporter: selckin
Priority: Minor
Was running some while(1) tests on the docvalues branch (r1103705) and the
following test failed:
{code}
[junit] Testsuite: org.apache.lucene.util.automaton.fst.TestFSTs
[junit] Testcase:
testRandomWords(org.apache.lucene.util.automaton.fst.TestFSTs): FAILED
[junit] expected:771 but was:TwoLongs:771,771
[junit] junit.framework.AssertionFailedError: expected:771 but
was:TwoLongs:771,771
[junit] at
org.apache.lucene.util.automaton.fst.TestFSTs$FSTTester.verifyUnPruned(TestFSTs.java:540)
[junit] at
org.apache.lucene.util.automaton.fst.TestFSTs$FSTTester.doTest(TestFSTs.java:496)
[junit] at
org.apache.lucene.util.automaton.fst.TestFSTs$FSTTester.doTest(TestFSTs.java:359)
[junit] at
org.apache.lucene.util.automaton.fst.TestFSTs.doTest(TestFSTs.java:319)
[junit] at
org.apache.lucene.util.automaton.fst.TestFSTs.testRandomWords(TestFSTs.java:940)
[junit] at
org.apache.lucene.util.automaton.fst.TestFSTs.testRandomWords(TestFSTs.java:915)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1282)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1211)
[junit]
[junit]
[junit] Tests run: 7, Failures: 1, Errors: 0, Time elapsed: 7.628 sec
[junit]
[junit] - Standard Error -
[junit] NOTE: Ignoring nightly-only test method 'testBigSet'
[junit] NOTE: reproduce with: ant test -Dtestcase=TestFSTs
-Dtestmethod=testRandomWords -Dtests.seed=-269475578956012681:0
[junit] NOTE: test params are: codec=PreFlex, locale=ar,
timezone=America/Blanc-Sablon
[junit] NOTE: all tests run in this JVM:
[junit] [TestToken, TestCodecs, TestIndexReaderReopen,
TestIndexWriterMerging, TestNoDeletionPolicy, TestParallelReaderEmptyIndex,
TestParallelTermEnum, TestPerSegmentDeletes, TestSegmentReader,
TestSegmentTermDocs, TestStressAdvance, TestTermVectorsReader, TestSurrogates,
TestMultiFieldQueryParser, TestAutomatonQuery, TestBooleanScorer,
TestFuzzyQuery, TestMultiTermConstantScore, TestNumericRangeQuery64,
TestPositiveScoresOnlyCollector, TestPrefixFilter, TestQueryTermVector,
TestScorerPerf, TestSloppyPhraseQuery, TestSpansAdvanced, TestWindowsMMap,
TestRamUsageEstimator, TestSmallFloat, TestUnicodeUtil, TestFSTs]
[junit] NOTE: Linux 2.6.37-gentoo amd64/Sun Microsystems Inc. 1.6.0_25
(64-bit)/cpus=8,threads=1,free=137329960,total=208207872
[junit] - ---
[junit] TEST org.apache.lucene.util.automaton.fst.TestFSTs FAILED
{code}
I am not able to reproduce
--
This message is automatically generated by JIRA.
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] [Created] (LUCENE-3101) TestMinimize.testAgainstBrzozowski reproducible seed OOM
TestMinimize.testAgainstBrzozowski reproducible seed OOM
Key: LUCENE-3101
URL: https://issues.apache.org/jira/browse/LUCENE-3101
Project: Lucene - Java
Issue Type: Bug
Reporter: selckin
{code}
[junit] Testsuite: org.apache.lucene.util.automaton.TestMinimize
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 3.792 sec
[junit]
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestMinimize
-Dtestmethod=testAgainstBrzozowski
-Dtests.seed=-7429820995201119781:1013305000165135537
[junit] NOTE: test params are: codec=PreFlex, locale=ru,
timezone=America/Pangnirtung
[junit] NOTE: all tests run in this JVM:
[junit] [TestMinimize]
[junit] NOTE: Linux 2.6.37-gentoo amd64/Sun Microsystems Inc. 1.6.0_25
(64-bit)/cpus=8,threads=1,free=294745976,total=310378496
[junit] - ---
[junit] Testcase:
testAgainstBrzozowski(org.apache.lucene.util.automaton.TestMinimize):
Caused an ERROR
[junit] Java heap space
[junit] java.lang.OutOfMemoryError: Java heap space
[junit] at java.util.BitSet.initWords(BitSet.java:144)
[junit] at java.util.BitSet.init(BitSet.java:139)
[junit] at
org.apache.lucene.util.automaton.MinimizationOperations.minimizeHopcroft(MinimizationOperations.java:85)
[junit] at
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:52)
[junit] at
org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:502)
[junit] at
org.apache.lucene.util.automaton.RegExp.toAutomatonAllowMutate(RegExp.java:478)
[junit] at
org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:428)
[junit] at
org.apache.lucene.util.automaton.AutomatonTestUtil.randomAutomaton(AutomatonTestUtil.java:256)
[junit] at
org.apache.lucene.util.automaton.TestMinimize.testAgainstBrzozowski(TestMinimize.java:43)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1282)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1211)
[junit]
[junit]
[junit] Test org.apache.lucene.util.automaton.TestMinimize FAILED
{code}
--
This message is automatically generated by JIRA.
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] [Commented] (LUCENE-3095) TestIndexWriter#testThreadInterruptDeadlock fails with OOM
[
https://issues.apache.org/jira/browse/LUCENE-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13033296#comment-13033296
]
selckin commented on LUCENE-3095:
-
I believe the test is wrong, and it can get back into the thread's while(true)
before setting the finish flag and after the last interrupt and therefor never
end, the inner while(true) should probably be a while(!finish) aswel.
TestIndexWriter#testThreadInterruptDeadlock fails with OOM
---
Key: LUCENE-3095
URL: https://issues.apache.org/jira/browse/LUCENE-3095
Project: Lucene - Java
Issue Type: Bug
Components: Index, Tests
Affects Versions: 4.0
Reporter: Simon Willnauer
Fix For: 4.0
Selckin reported a repeatedly failing test that throws OOM Exceptions.
According to the heapdump the MockDirectoryWrapper#createdFiles HashSet takes
about 400MB heapspace containing 4194304 entries. Seems kind of way too many
though :)
{noformat}
[junit] java.lang.OutOfMemoryError: Java heap space
[junit] Dumping heap to /tmp/java_pid25990.hprof ...
[junit] Heap dump file created [520807744 bytes in 4.250 secs]
[junit] Testsuite: org.apache.lucene.index.TestIndexWriter
[junit] Testcase:
testThreadInterruptDeadlock(org.apache.lucene.index.TestIndexWriter): FAILED
[junit]
[junit] junit.framework.AssertionFailedError:
[junit] at
org.apache.lucene.index.TestIndexWriter.testThreadInterruptDeadlock(TestIndexWriter.java:2249)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1282)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1211)
[junit]
[junit]
[junit] Testcase:
testThreadInterruptDeadlock(org.apache.lucene.index.TestIndexWriter): FAILED
[junit] Some threads threw uncaught exceptions!
[junit] junit.framework.AssertionFailedError: Some threads threw uncaught
exceptions!
[junit] at
org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:557)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1282)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1211)
[junit]
[junit]
[junit] Tests run: 67, Failures: 2, Errors: 0, Time elapsed: 3,254.884 sec
[junit]
[junit] - Standard Output ---
[junit] FAILED; unexpected exception
[junit] java.lang.OutOfMemoryError: Java heap space
[junit] at org.apache.lucene.store.RAMFile.newBuffer(RAMFile.java:85)
[junit] at org.apache.lucene.store.RAMFile.addBuffer(RAMFile.java:58)
[junit] at
org.apache.lucene.store.RAMOutputStream.switchCurrentBuffer(RAMOutputStream.java:132)
[junit] at
org.apache.lucene.store.RAMOutputStream.copyBytes(RAMOutputStream.java:171)
[junit] at
org.apache.lucene.store.MockIndexOutputWrapper.copyBytes(MockIndexOutputWrapper.java:155)
[junit] at
org.apache.lucene.index.CompoundFileWriter.copyFile(CompoundFileWriter.java:223)
[junit] at
org.apache.lucene.index.CompoundFileWriter.close(CompoundFileWriter.java:189)
[junit] at
org.apache.lucene.index.SegmentMerger.createCompoundFile(SegmentMerger.java:138)
[junit] at
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3344)
[junit] at
org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:2959)
[junit] at
org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:37)
[junit] at
org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1763)
[junit] at
org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1758)
[junit] at
org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1754)
[junit] at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1373)
[junit] at
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1230)
[junit] at
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1211)
[junit] at
org.apache.lucene.index.TestIndexWriter$IndexerThreadInterrupt.run(TestIndexWriter.java:2154)
[junit] - ---
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestIndexWriter
-Dtestmethod=testThreadInterruptDeadlock
-Dtests.seed=7183538093651149:3431510331342554160
[junit] NOTE: reproduce with: ant test -Dtestcase=TestIndexWriter
-Dtestmethod=testThreadInterruptDeadlock
-Dtests.seed=7183538093651149:3431510331342554160
[junit] The following exceptions were thrown by
[jira] [Commented] (LUCENE-2984) Move hasVectors() hasProx() responsibility out of SegmentInfo to FieldInfos
[ https://issues.apache.org/jira/browse/LUCENE-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031350#comment-13031350 ] selckin commented on LUCENE-2984: - http://www.selckin.be/trunk-2984-patched.txt Move hasVectors() hasProx() responsibility out of SegmentInfo to FieldInfos -- Key: LUCENE-2984 URL: https://issues.apache.org/jira/browse/LUCENE-2984 Project: Lucene - Java Issue Type: Improvement Components: Index Affects Versions: 4.0 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.0 Attachments: LUCENE-2984.patch Spin-off from LUCENE-2881 which had this change already but due to some random failures related to this change I remove this part of the patch to make it more isolated and easier to test. -- This message is automatically generated by JIRA. 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] [Commented] (LUCENE-3023) Land DWPT on trunk
[ https://issues.apache.org/jira/browse/LUCENE-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020579#comment-13020579 ] selckin commented on LUCENE-3023: - fyi, since last night's trunk merge (r1092636) not a single test has failed in my 'while true; ant clean test' (addIndexes LUCENE-3033 has not failed since either) Land DWPT on trunk -- Key: LUCENE-3023 URL: https://issues.apache.org/jira/browse/LUCENE-3023 Project: Lucene - Java Issue Type: Task Affects Versions: CSF branch, 4.0 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.0 Attachments: LUCENE-3023.patch, realtime-TestAddIndexes-3.txt, realtime-TestAddIndexes-5.txt, realtime-TestIndexWriterExceptions-assert-6.txt, realtime-TestIndexWriterExceptions-npe-1.txt, realtime-TestIndexWriterExceptions-npe-2.txt, realtime-TestIndexWriterExceptions-npe-4.txt, realtime-TestOmitTf-corrupt-0.txt With LUCENE-2956 we have resolved the last remaining issue for LUCENE-2324 so we can proceed landing the DWPT development on trunk soon. I think one of the bigger issues here is to make sure that all JavaDocs for IW etc. are still correct though. I will start going through that first. -- This message is automatically generated by JIRA. 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] [Commented] (LUCENE-3028) IW.getReader() returns inconsistent reader on RT Branch
[ https://issues.apache.org/jira/browse/LUCENE-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020222#comment-13020222 ] selckin commented on LUCENE-3028: - hasn't failed since above fix IW.getReader() returns inconsistent reader on RT Branch --- Key: LUCENE-3028 URL: https://issues.apache.org/jira/browse/LUCENE-3028 Project: Lucene - Java Issue Type: Bug Components: Index Affects Versions: Realtime Branch Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: Realtime Branch Attachments: LUCENE-3028.patch, LUCENE-3028.patch, realtime-1.txt I extended the testcase TestRollingUpdates#testUpdateSameDoc to pull a NRT reader after each update and asserted that is always sees only one document. Yet, this fails with current branch since there is a problem in how we flush in the getReader() case. What happens here is that we flush all threads and then release the lock (letting other flushes which came in after we entered the flushAllThread context, continue) so that we could concurrently get a new segment that transports global deletes without the corresponding add. They sneak in while we continue to open the NRT reader which in turn sees inconsistent results. I will upload a patch soon -- This message is automatically generated by JIRA. 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] [Updated] (LUCENE-3023) Land DWPT on trunk
[ https://issues.apache.org/jira/browse/LUCENE-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] selckin updated LUCENE-3023: Attachment: realtime-TestAddIndexes-3.txt Land DWPT on trunk -- Key: LUCENE-3023 URL: https://issues.apache.org/jira/browse/LUCENE-3023 Project: Lucene - Java Issue Type: Task Affects Versions: CSF branch, 4.0 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.0 Attachments: realtime-TestAddIndexes-3.txt, realtime-TestAddIndexes-5.txt, realtime-TestIndexWriterExceptions-assert-6.txt, realtime-TestIndexWriterExceptions-npe-1.txt, realtime-TestIndexWriterExceptions-npe-2.txt, realtime-TestIndexWriterExceptions-npe-4.txt, realtime-TestOmitTf-corrupt-0.txt With LUCENE-2956 we have resolved the last remaining issue for LUCENE-2324 so we can proceed landing the DWPT development on trunk soon. I think one of the bigger issues here is to make sure that all JavaDocs for IW etc. are still correct though. I will start going through that first. -- This message is automatically generated by JIRA. 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] [Updated] (LUCENE-3023) Land DWPT on trunk
[ https://issues.apache.org/jira/browse/LUCENE-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] selckin updated LUCENE-3023: Attachment: realtime-TestOmitTf-corrupt-0.txt Land DWPT on trunk -- Key: LUCENE-3023 URL: https://issues.apache.org/jira/browse/LUCENE-3023 Project: Lucene - Java Issue Type: Task Affects Versions: CSF branch, 4.0 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.0 Attachments: realtime-TestAddIndexes-3.txt, realtime-TestAddIndexes-5.txt, realtime-TestIndexWriterExceptions-assert-6.txt, realtime-TestIndexWriterExceptions-npe-1.txt, realtime-TestIndexWriterExceptions-npe-2.txt, realtime-TestIndexWriterExceptions-npe-4.txt, realtime-TestOmitTf-corrupt-0.txt With LUCENE-2956 we have resolved the last remaining issue for LUCENE-2324 so we can proceed landing the DWPT development on trunk soon. I think one of the bigger issues here is to make sure that all JavaDocs for IW etc. are still correct though. I will start going through that first. -- This message is automatically generated by JIRA. 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] [Updated] (LUCENE-3023) Land DWPT on trunk
[ https://issues.apache.org/jira/browse/LUCENE-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] selckin updated LUCENE-3023: Attachment: realtime-TestIndexWriterExceptions-npe-2.txt Land DWPT on trunk -- Key: LUCENE-3023 URL: https://issues.apache.org/jira/browse/LUCENE-3023 Project: Lucene - Java Issue Type: Task Affects Versions: CSF branch, 4.0 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.0 Attachments: realtime-TestAddIndexes-3.txt, realtime-TestAddIndexes-5.txt, realtime-TestIndexWriterExceptions-assert-6.txt, realtime-TestIndexWriterExceptions-npe-1.txt, realtime-TestIndexWriterExceptions-npe-2.txt, realtime-TestIndexWriterExceptions-npe-4.txt, realtime-TestOmitTf-corrupt-0.txt With LUCENE-2956 we have resolved the last remaining issue for LUCENE-2324 so we can proceed landing the DWPT development on trunk soon. I think one of the bigger issues here is to make sure that all JavaDocs for IW etc. are still correct though. I will start going through that first. -- This message is automatically generated by JIRA. 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] [Updated] (LUCENE-3023) Land DWPT on trunk
[ https://issues.apache.org/jira/browse/LUCENE-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] selckin updated LUCENE-3023: Attachment: realtime-TestIndexWriterExceptions-assert-6.txt Land DWPT on trunk -- Key: LUCENE-3023 URL: https://issues.apache.org/jira/browse/LUCENE-3023 Project: Lucene - Java Issue Type: Task Affects Versions: CSF branch, 4.0 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.0 Attachments: realtime-TestAddIndexes-3.txt, realtime-TestAddIndexes-5.txt, realtime-TestIndexWriterExceptions-assert-6.txt, realtime-TestIndexWriterExceptions-npe-1.txt, realtime-TestIndexWriterExceptions-npe-2.txt, realtime-TestIndexWriterExceptions-npe-4.txt, realtime-TestOmitTf-corrupt-0.txt With LUCENE-2956 we have resolved the last remaining issue for LUCENE-2324 so we can proceed landing the DWPT development on trunk soon. I think one of the bigger issues here is to make sure that all JavaDocs for IW etc. are still correct though. I will start going through that first. -- This message is automatically generated by JIRA. 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] [Updated] (LUCENE-3023) Land DWPT on trunk
[ https://issues.apache.org/jira/browse/LUCENE-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] selckin updated LUCENE-3023: Attachment: realtime-TestAddIndexes-5.txt Land DWPT on trunk -- Key: LUCENE-3023 URL: https://issues.apache.org/jira/browse/LUCENE-3023 Project: Lucene - Java Issue Type: Task Affects Versions: CSF branch, 4.0 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.0 Attachments: realtime-TestAddIndexes-3.txt, realtime-TestAddIndexes-5.txt, realtime-TestIndexWriterExceptions-assert-6.txt, realtime-TestIndexWriterExceptions-npe-1.txt, realtime-TestIndexWriterExceptions-npe-2.txt, realtime-TestIndexWriterExceptions-npe-4.txt, realtime-TestOmitTf-corrupt-0.txt With LUCENE-2956 we have resolved the last remaining issue for LUCENE-2324 so we can proceed landing the DWPT development on trunk soon. I think one of the bigger issues here is to make sure that all JavaDocs for IW etc. are still correct though. I will start going through that first. -- This message is automatically generated by JIRA. 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] [Updated] (LUCENE-3023) Land DWPT on trunk
[ https://issues.apache.org/jira/browse/LUCENE-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] selckin updated LUCENE-3023: Attachment: realtime-TestIndexWriterExceptions-npe-1.txt Land DWPT on trunk -- Key: LUCENE-3023 URL: https://issues.apache.org/jira/browse/LUCENE-3023 Project: Lucene - Java Issue Type: Task Affects Versions: CSF branch, 4.0 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.0 Attachments: realtime-TestAddIndexes-3.txt, realtime-TestAddIndexes-5.txt, realtime-TestIndexWriterExceptions-assert-6.txt, realtime-TestIndexWriterExceptions-npe-1.txt, realtime-TestIndexWriterExceptions-npe-2.txt, realtime-TestIndexWriterExceptions-npe-4.txt, realtime-TestOmitTf-corrupt-0.txt With LUCENE-2956 we have resolved the last remaining issue for LUCENE-2324 so we can proceed landing the DWPT development on trunk soon. I think one of the bigger issues here is to make sure that all JavaDocs for IW etc. are still correct though. I will start going through that first. -- This message is automatically generated by JIRA. 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] [Updated] (LUCENE-3023) Land DWPT on trunk
[ https://issues.apache.org/jira/browse/LUCENE-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] selckin updated LUCENE-3023: Attachment: realtime-TestIndexWriterExceptions-npe-4.txt Land DWPT on trunk -- Key: LUCENE-3023 URL: https://issues.apache.org/jira/browse/LUCENE-3023 Project: Lucene - Java Issue Type: Task Affects Versions: CSF branch, 4.0 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.0 Attachments: realtime-TestAddIndexes-3.txt, realtime-TestAddIndexes-5.txt, realtime-TestIndexWriterExceptions-assert-6.txt, realtime-TestIndexWriterExceptions-npe-1.txt, realtime-TestIndexWriterExceptions-npe-2.txt, realtime-TestIndexWriterExceptions-npe-4.txt, realtime-TestOmitTf-corrupt-0.txt With LUCENE-2956 we have resolved the last remaining issue for LUCENE-2324 so we can proceed landing the DWPT development on trunk soon. I think one of the bigger issues here is to make sure that all JavaDocs for IW etc. are still correct though. I will start going through that first. -- This message is automatically generated by JIRA. 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] [Created] (LUCENE-3027) TestOmitTf.testMixedMerge random seed failure
TestOmitTf.testMixedMerge random seed failure
-
Key: LUCENE-3027
URL: https://issues.apache.org/jira/browse/LUCENE-3027
Project: Lucene - Java
Issue Type: Bug
Reporter: selckin
Version: trunk r1091638
ant test -Dtests.seed=-6595054217575280191:5576532348905930588
[junit] - Standard Error -
[junit] WARNING: test method: 'testDeMorgan' left thread running:
Thread[NRT search threads-1691-thread-2,5,main]
[junit] RESOURCE LEAK: test method: 'testDeMorgan' left 1 thread(s) running
[junit] NOTE: reproduce with: ant test -Dtestcase=TestBooleanQuery
-Dtestmethod=testDeMorgan -Dtests.seed=-6595054217575280191:5576532348905930588
[junit] - ---
[junit] Testsuite: org.apache.lucene.index.TestNorms
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 5.064 sec
[junit]
[junit] Testsuite: org.apache.lucene.index.TestOmitTf
[junit] Testcase: testMixedMerge(org.apache.lucene.index.TestOmitTf):
Caused an ERROR
[junit] CheckIndex failed
[junit] java.lang.RuntimeException: CheckIndex failed
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:152)
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:138)
[junit] at
org.apache.lucene.index.TestOmitTf.testMixedMerge(TestOmitTf.java:155)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1232)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1160)
[junit]
[junit]
[junit] Tests run: 5, Failures: 0, Errors: 1, Time elapsed: 0.851 sec
[junit]
[junit] - Standard Output ---
[junit] CheckIndex failed
[junit] Segments file=segments_1 numSegments=1 version=FORMAT_4_0 [Lucene
4.0]
[junit] 1 of 1: name=_12 docCount=60
[junit] codec=SegmentCodecs [codecs=[MockRandom,
MockVariableIntBlock(baseBlockSize=112)], provider=RandomCodecProvider:
{f1=MockRandom, f2=MockVariableIntBlock(baseBlockSize=112)}]
[junit] compound=false
[junit] hasProx=false
[junit] numFiles=16
[junit] size (MB)=0,01
[junit] diagnostics = {optimize=true, mergeFactor=2,
os.version=2.6.37-gentoo, os=Linux, lucene.version=4.0-SNAPSHOT, source=merge,
os.arch=amd64, java.version=1.6.0_24, java.vendor=Sun Microsystems Inc.}
[junit] no deletions
[junit] test: open reader.OK
[junit] test: fields..OK [2 fields]
[junit] test: field norms.OK [2 fields]
[junit] test: terms, freq, prox...ERROR: java.io.IOException: Read past
EOF
[junit] java.io.IOException: Read past EOF
[junit] at
org.apache.lucene.store.RAMInputStream.switchCurrentBuffer(RAMInputStream.java:90)
[junit] at
org.apache.lucene.store.RAMInputStream.readByte(RAMInputStream.java:63)
[junit] at
org.apache.lucene.store.MockIndexInputWrapper.readByte(MockIndexInputWrapper.java:105)
[junit] at org.apache.lucene.store.DataInput.readVInt(DataInput.java:94)
[junit] at
org.apache.lucene.index.codecs.sep.SepSkipListReader.readSkipData(SepSkipListReader.java:188)
[junit] at
org.apache.lucene.index.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:142)
[junit] at
org.apache.lucene.index.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:112)
[junit] at
org.apache.lucene.index.codecs.sep.SepPostingsReaderImpl$SepDocsEnum.advance(SepPostingsReaderImpl.java:454)
[junit] at
org.apache.lucene.index.CheckIndex.testTermIndex(CheckIndex.java:782)
[junit] at
org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:495)
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:148)
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:138)
[junit] at
org.apache.lucene.index.TestOmitTf.testMixedMerge(TestOmitTf.java:155)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:597)
[junit] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
[junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
[junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
[junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
[junit] at
[jira] [Updated] (LUCENE-3027) TestOmitTf.testMixedMerge random seed failure
[
https://issues.apache.org/jira/browse/LUCENE-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
selckin updated LUCENE-3027:
Attachment: output.txt
ant output
TestOmitTf.testMixedMerge random seed failure
-
Key: LUCENE-3027
URL: https://issues.apache.org/jira/browse/LUCENE-3027
Project: Lucene - Java
Issue Type: Bug
Reporter: selckin
Attachments: output.txt
Version: trunk r1091638
ant test -Dtests.seed=-6595054217575280191:5576532348905930588
[junit] - Standard Error -
[junit] WARNING: test method: 'testDeMorgan' left thread running:
Thread[NRT search threads-1691-thread-2,5,main]
[junit] RESOURCE LEAK: test method: 'testDeMorgan' left 1 thread(s)
running
[junit] NOTE: reproduce with: ant test -Dtestcase=TestBooleanQuery
-Dtestmethod=testDeMorgan
-Dtests.seed=-6595054217575280191:5576532348905930588
[junit] - ---
[junit] Testsuite: org.apache.lucene.index.TestNorms
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 5.064 sec
[junit]
[junit] Testsuite: org.apache.lucene.index.TestOmitTf
[junit] Testcase: testMixedMerge(org.apache.lucene.index.TestOmitTf):
Caused an ERROR
[junit] CheckIndex failed
[junit] java.lang.RuntimeException: CheckIndex failed
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:152)
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:138)
[junit] at
org.apache.lucene.index.TestOmitTf.testMixedMerge(TestOmitTf.java:155)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1232)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1160)
[junit]
[junit]
[junit] Tests run: 5, Failures: 0, Errors: 1, Time elapsed: 0.851 sec
[junit]
[junit] - Standard Output ---
[junit] CheckIndex failed
[junit] Segments file=segments_1 numSegments=1 version=FORMAT_4_0 [Lucene
4.0]
[junit] 1 of 1: name=_12 docCount=60
[junit] codec=SegmentCodecs [codecs=[MockRandom,
MockVariableIntBlock(baseBlockSize=112)], provider=RandomCodecProvider:
{f1=MockRandom, f2=MockVariableIntBlock(baseBlockSize=112)}]
[junit] compound=false
[junit] hasProx=false
[junit] numFiles=16
[junit] size (MB)=0,01
[junit] diagnostics = {optimize=true, mergeFactor=2,
os.version=2.6.37-gentoo, os=Linux, lucene.version=4.0-SNAPSHOT,
source=merge, os.arch=amd64, java.version=1.6.0_24, java.vendor=Sun
Microsystems Inc.}
[junit] no deletions
[junit] test: open reader.OK
[junit] test: fields..OK [2 fields]
[junit] test: field norms.OK [2 fields]
[junit] test: terms, freq, prox...ERROR: java.io.IOException: Read
past EOF
[junit] java.io.IOException: Read past EOF
[junit] at
org.apache.lucene.store.RAMInputStream.switchCurrentBuffer(RAMInputStream.java:90)
[junit] at
org.apache.lucene.store.RAMInputStream.readByte(RAMInputStream.java:63)
[junit] at
org.apache.lucene.store.MockIndexInputWrapper.readByte(MockIndexInputWrapper.java:105)
[junit] at org.apache.lucene.store.DataInput.readVInt(DataInput.java:94)
[junit] at
org.apache.lucene.index.codecs.sep.SepSkipListReader.readSkipData(SepSkipListReader.java:188)
[junit] at
org.apache.lucene.index.codecs.MultiLevelSkipListReader.loadNextSkip(MultiLevelSkipListReader.java:142)
[junit] at
org.apache.lucene.index.codecs.MultiLevelSkipListReader.skipTo(MultiLevelSkipListReader.java:112)
[junit] at
org.apache.lucene.index.codecs.sep.SepPostingsReaderImpl$SepDocsEnum.advance(SepPostingsReaderImpl.java:454)
[junit] at
org.apache.lucene.index.CheckIndex.testTermIndex(CheckIndex.java:782)
[junit] at
org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:495)
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:148)
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:138)
[junit] at
org.apache.lucene.index.TestOmitTf.testMixedMerge(TestOmitTf.java:155)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:597)
[junit] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
[junit] at
[jira] [Commented] (LUCENE-3028) IW.getReader() returns inconsistent reader on RT Branch
[
https://issues.apache.org/jira/browse/LUCENE-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019996#comment-13019996
]
selckin commented on LUCENE-3028:
-
Seems to fail once every 6-8 runs quite consistently (at least i think this is
the issue)
brachnes/realtime_search r1092329
{{
[junit] Testsuite: org.apache.lucene.index.TestRollingUpdates
[junit] Testcase:
testUpdateSameDoc(org.apache.lucene.index.TestRollingUpdates):Caused an
ERROR
[junit] MockDirectoryWrapper: cannot close: there are still open files:
{_ho.fdt=1, _ho.prx=1, _ho.fdx=1, _ho.nrm=1, _j0.fdt=1, _ho.tis=1, _j0.fdx=1,
_j0.tis=1, _j0.prx=1, _ho.frq=1, _ho.tvx=1, _ho.tvd=1, _j0.nrm=1, _ho.tvf=1,
_j0.frq=1, _j0.tvf=1, _j0.tvd=1, _j0.tvx=1}
[junit] java.lang.RuntimeException: MockDirectoryWrapper: cannot close:
there are still open files: {_ho.fdt=1, _ho.prx=1, _ho.fdx=1, _ho.nrm=1,
_j0.fdt=1, _ho.tis=1, _j0.fdx=1, _j0.tis=1, _j0.prx=1, _ho.frq=1, _ho.tvx=1,
_ho.tvd=1, _j0.nrm=1, _ho.tvf=1, _j0.frq=1, _j0.tvf=1
, _j0.tvd=1, _j0.tvx=1}
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:414)
[junit] at
org.apache.lucene.index.TestRollingUpdates.testUpdateSameDoc(TestRollingUpdates.java:104)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1226)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1154)
[junit] Caused by: java.lang.RuntimeException: unclosed IndexInput
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:369)
[junit] at
org.apache.lucene.store.Directory.openInput(Directory.java:122)
[junit] at
org.apache.lucene.index.TermVectorsReader.init(TermVectorsReader.java:86)
[junit] at
org.apache.lucene.index.SegmentReader$CoreReaders.openDocStores(SegmentReader.java:236)
[junit] at
org.apache.lucene.index.SegmentReader.get(SegmentReader.java:495)
[junit] at
org.apache.lucene.index.IndexWriter$ReaderPool.get(IndexWriter.java:629)
[junit] at
org.apache.lucene.index.IndexWriter$ReaderPool.getReadOnlyClone(IndexWriter.java:587)
[junit] at
org.apache.lucene.index.DirectoryReader.init(DirectoryReader.java:172)
[junit] at
org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:377)
[junit] at
org.apache.lucene.index.DirectoryReader.doReopenFromWriter(DirectoryReader.java:419)
[junit] at
org.apache.lucene.index.DirectoryReader.doReopen(DirectoryReader.java:432)
[junit] at
org.apache.lucene.index.DirectoryReader.reopen(DirectoryReader.java:392)
[junit] at
org.apache.lucene.index.TestRollingUpdates$IndexingThread.run(TestRollingUpdates.java:129)
[junit]
[junit]
[junit] Testcase:
testUpdateSameDoc(org.apache.lucene.index.TestRollingUpdates):FAILED
[junit] Some threads threw uncaught exceptions!
[junit] junit.framework.AssertionFailedError: Some threads threw uncaught
exceptions!
[junit] at
org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:521)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1226)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1154)
[junit]
[junit]
[junit] Tests run: 2, Failures: 1, Errors: 1, Time elapsed: 6.649 sec
[junit]
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestRollingUpdates
-Dtestmethod=testUpdateSameDoc
-Dtests.seed=-4094951767438954769:-1203905293622856057
[junit] NOTE: reproduce with: ant test -Dtestcase=TestRollingUpdates
-Dtestmethod=testUpdateSameDoc
-Dtests.seed=-4094951767438954769:-1203905293622856057
[junit] The following exceptions were thrown by threads:
[junit] *** Thread: Thread-103 ***
[junit] java.lang.AssertionError: expected:
org.apache.lucene.index.DocumentsWriterDeleteQueue@18635827but was:
org.apache.lucene.index.DocumentsWriterDeleteQueue@223074f3 false
[junit] at
org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:359)
[junit] at
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:346)
[junit] at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1367)
[junit] at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1339)
[junit] at
org.apache.lucene.index.TestRollingUpdates$IndexingThread.run(TestRollingUpdates.java:125)
[junit] *** Thread: Thread-106 ***
[junit] java.lang.AssertionError: expected:
org.apache.lucene.index.DocumentsWriterDeleteQueue@18635827but was:
org.apache.lucene.index.DocumentsWriterDeleteQueue@223074f3 false
[junit]
[jira] [Updated] (LUCENE-3028) IW.getReader() returns inconsistent reader on RT Branch
[ https://issues.apache.org/jira/browse/LUCENE-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] selckin updated LUCENE-3028: Attachment: realtime-1.txt IW.getReader() returns inconsistent reader on RT Branch --- Key: LUCENE-3028 URL: https://issues.apache.org/jira/browse/LUCENE-3028 Project: Lucene - Java Issue Type: Bug Components: Index Affects Versions: Realtime Branch Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: Realtime Branch Attachments: LUCENE-3028.patch, LUCENE-3028.patch, realtime-1.txt I extended the testcase TestRollingUpdates#testUpdateSameDoc to pull a NRT reader after each update and asserted that is always sees only one document. Yet, this fails with current branch since there is a problem in how we flush in the getReader() case. What happens here is that we flush all threads and then release the lock (letting other flushes which came in after we entered the flushAllThread context, continue) so that we could concurrently get a new segment that transports global deletes without the corresponding add. They sneak in while we continue to open the NRT reader which in turn sees inconsistent results. I will upload a patch soon -- This message is automatically generated by JIRA. 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
