[jira] [Created] (LUCENE-4002) Running tests with internal JVM diagnostic options (such as -verbose:*) will fail.
Running tests with internal JVM diagnostic options (such as -verbose:*) will fail. -- Key: LUCENE-4002 URL: https://issues.apache.org/jira/browse/LUCENE-4002 Project: Lucene - Java Issue Type: Bug Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Fix For: 4.0 Passing JVM options that dump something to output streams before they are intercepted (-verbose:gc, -verbose:class) will break the communication between the runner and the master. Currently junit4 communicates with forked processes via stdout or stderr (depending on the JVM and which stream the JVM uses to dump crash infos). This is done for efficiency since it's a natural blocking pipe between the two processes. I forgot that the jvm can: 1) use process streams to dump verbose logs (gc, classes, jit), 2) use process streams directly, bypassing System.* overrides, to dump warnings. This can be solved my moving the communication layer to another pipe or to a socket. I'll play with the options. -- 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-4000) Non-redirected JVM output causes build errors
Non-redirected JVM output causes build errors - Key: LUCENE-4000 URL: https://issues.apache.org/jira/browse/LUCENE-4000 Project: Lucene - Java Issue Type: Sub-task Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss https://builds.apache.org/job/Lucene-Trunk/1899/consoleText Code cache JVM warning. Harmless but causes build errors. -- 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-3993) Polishing annoyances from JUnit4
Polishing annoyances from JUnit4 Key: LUCENE-3993 URL: https://issues.apache.org/jira/browse/LUCENE-3993 Project: Lucene - Java Issue Type: Sub-task Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 4.0 - @Ignore and @TestGroup-ignored tests should report the reason much like assumption-ignored tests. https://github.com/carrotsearch/randomizedtesting/issues/82 -- 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-3991) Random shared by threads in RandomIndexWriter and MockAnalyzer
Random shared by threads in RandomIndexWriter and MockAnalyzer
--
Key: LUCENE-3991
URL: https://issues.apache.org/jira/browse/LUCENE-3991
Project: Lucene - Java
Issue Type: Task
Reporter: Dawid Weiss
Priority: Minor
This is currently patched by creating a non-asserting Random like this:
{code}
public MockIndexWriter(Random r, Directory dir, IndexWriterConfig conf)
throws IOException {
super(dir, conf);
// TODO: this should be solved in a different way; Random should not be
shared (!).
this.r = new Random(r.nextLong());
}
{code}
and
{code}
public MockAnalyzer(Random random, CharacterRunAutomaton runAutomaton,
boolean lowerCase, CharacterRunAutomaton filter, boolean
enablePositionIncrements) {
super(new PerFieldReuseStrategy());
// TODO: this should be solved in a different way; Random should not be
shared (!).
this.random = new Random(random.nextLong());
{code}
If you replace new Random(...) with a simple assignment you'll get errors
indicating the Random instance is shared (or passed between threads). I don't
know how to fix it so I left it as it was before.
--
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-3987) Ivy/maven config to pull from sonatype releases
Ivy/maven config to pull from sonatype releases --- Key: LUCENE-3987 URL: https://issues.apache.org/jira/browse/LUCENE-3987 Project: Lucene - Java Issue Type: Improvement Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial -- 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-3986) Support running tests with a simple, non-asserting (and possibly shared) Random
Support running tests with a simple, non-asserting (and possibly shared) Random --- Key: LUCENE-3986 URL: https://issues.apache.org/jira/browse/LUCENE-3986 Project: Lucene - Java Issue Type: Sub-task Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 4.0 Robert asked for it. Calling random() (and its methods) can obscure memory visibility issues (because random() is thread local, context-sensitive, etc.). An option (or randomly selected mode) of running with a simple Random (static/ test method level only) would simulate the framework as it was before (reading -- possibly non-reproducible thread races but at the same time testing memory visibility issues in the core 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-3985) Refactor support for thread leaks
Refactor support for thread leaks - Key: LUCENE-3985 URL: https://issues.apache.org/jira/browse/LUCENE-3985 Project: Lucene - Java Issue Type: Sub-task Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 4.0 This will be duplicated in the runner and in LuceneTestCase; try to consolidate. -- 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-3984) Add a target to recalculate SHA1 checksums for JAR
Add a target to recalculate SHA1 checksums for JAR
--
Key: LUCENE-3984
URL: https://issues.apache.org/jira/browse/LUCENE-3984
Project: Lucene - Java
Issue Type: Task
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Something like this. Either top-level or common-build.xml?
{noformat}
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3354) LeaderElectionIntegrationTest
LeaderElectionIntegrationTest
-
Key: SOLR-3354
URL: https://issues.apache.org/jira/browse/SOLR-3354
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Sami Siren
Priority: Minor
Fix For: 4.0
>From my build server.
{noformat}
12-Apr-2012 02:29:21[junit] Testcase:
testSimpleSliceLeaderElection(org.apache.solr.cloud.LeaderElectionIntegrationTest):
FAILED
12-Apr-2012 02:29:21[junit] We didn't find a new leader! 7004 was
shutdown, but it's still showing as the leader
12-Apr-2012 02:29:21[junit] junit.framework.AssertionFailedError: We
didn't find a new leader! 7004 was shutdown, but it's still showing as the
leader
12-Apr-2012 02:29:21[junit] at
org.junit.Assert.fail(Assert.java:93)
12-Apr-2012 02:29:21[junit] at
org.apache.solr.cloud.LeaderElectionIntegrationTest.testSimpleSliceLeaderElection(LeaderElectionIntegrationTest.java:174)
12-Apr-2012 02:29:21[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
12-Apr-2012 02:29:21[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
12-Apr-2012 02:29:21[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
12-Apr-2012 02:29:21[junit] at
java.lang.reflect.Method.invoke(Method.java:597)
12-Apr-2012 02:29:21[junit] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
12-Apr-2012 02:29:21[junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
12-Apr-2012 02:29:21[junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
12-Apr-2012 02:29:21[junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
12-Apr-2012 02:29:21[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
12-Apr-2012 02:29:21[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
12-Apr-2012 02:29:21[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
12-Apr-2012 02:29:21[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754)
12-Apr-2012 02:29:21[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670)
12-Apr-2012 02:29:21[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
12-Apr-2012 02:29:21[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
12-Apr-2012 02:29:21[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
12-Apr-2012 02:29:21[junit] at
org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
12-Apr-2012 02:29:21[junit] at
org.junit.rules.RunRules.evaluate(RunRules.java:18)
12-Apr-2012 02:29:21[junit] at
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
12-Apr-2012 02:29:21[junit] at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
12-Apr-2012 02:29:21[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
12-Apr-2012 02:29:21[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
12-Apr-2012 02:29:21[junit] at
org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
12-Apr-2012 02:29:21[junit] at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
12-Apr-2012 02:29:21[junit] at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
12-Apr-2012 02:29:21[junit] at
org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
12-Apr-2012 02:29:21[junit] at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
12-Apr-2012 02:29:21[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
12-Apr-2012 02:29:21[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
12-Apr-2012 02:29:21[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
12-Apr-2012 02:29:21[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtE
[jira] [Created] (SOLR-3335) testDistribSearch failure
testDistribSearch failure
-
Key: SOLR-3335
URL: https://issues.apache.org/jira/browse/SOLR-3335
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 4.0
Happened on my test machine. Is there a way to disable these tests if we cannot
fix them? There are two three tests that fail most of the time and that
apparently nobody knows how to fix (including me).
There is also a typo in the error message (I'm away from home for Easter, can't
do it now).
{noformat}
build 06-Apr-2012 16:11:54[junit] Testsuite:
org.apache.solr.cloud.RecoveryZkTest
build 06-Apr-2012 16:11:54[junit] Testcase:
testDistribSearch(org.apache.solr.cloud.RecoveryZkTest): FAILED
build 06-Apr-2012 16:11:54[junit] There are still nodes recoverying
build 06-Apr-2012 16:11:54[junit]
junit.framework.AssertionFailedError: There are still nodes recoverying
build 06-Apr-2012 16:11:54[junit] at
org.junit.Assert.fail(Assert.java:93)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.cloud.AbstractDistributedZkTestCase.waitForRecoveriesToFinish(AbstractDistributedZkTestCase.java:132)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.cloud.RecoveryZkTest.doTest(RecoveryZkTest.java:84)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:670)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
build 06-Apr-2012 16:11:54[junit] at
java.lang.reflect.Method.invoke(Method.java:597)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
build 06-Apr-2012 16:11:54[junit] at
org.junit.rules.RunRules.evaluate(RunRules.java:18)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.ParentRunner.access$000(ParentRunne
[jira] [Created] (SOLR-3295) Binaries contain 1.6 classes
Binaries contain 1.6 classes
Key: SOLR-3295
URL: https://issues.apache.org/jira/browse/SOLR-3295
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Priority: Minor
Fix For: 3.6
Attachments: output.log
I've ran this tool (does the job): http://code.google.com/p/versioncheck/ on
the checkout of branch_3x. To my surprise there is a JAR which contains Java
1.6 code:
{noformat}
Major.Minor Version : 50.0 JAVA compatibility : Java 1.6 platform:
45.3-50.0
Number of classes : 60
Classes are :
c:\Work\lucene-solr\.\solr\contrib\extraction\lib\netcdf-4.2-min.jar [:]
ucar/unidata/geoloc/Bearing.class
...
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3294) Remove binary carrot2.jar and replace it with a maven dependency.
Remove binary carrot2.jar and replace it with a maven dependency. - Key: SOLR-3294 URL: https://issues.apache.org/jira/browse/SOLR-3294 Project: Solr Issue Type: Task Components: contrib - Clustering Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Blocker Fix For: 3.6 The repo contains a manually retrowoven Carrot2 JAR which does not have a corresponding artefact in Maven Central (so won't work for ivy). We will make a release with 1.5 backport (I hate this!). http://issues.carrot2.org/browse/CARROT-902 -- 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] (SOLR-3267) TestSort failures (reproducible)
TestSort failures (reproducible)
Key: SOLR-3267
URL: https://issues.apache.org/jira/browse/SOLR-3267
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Fix For: 4.0
{noformat}
Over 0.2% oddities in test: 14/6386 have func/query parsing semenatics gotten
broader?
{noformat}
Huh? Steps to reproduce:
{noformat}
ant test -Dtestcase=TestSort -Dtestmethod=testRandomFieldNameSorts
-Dtests.seed=-3e789c8564f08cbd:515c61b079794ea7:-6347ac0df7ad45c0
-Dargs="-Dfile.encoding=UTF-8"
[junit] Testcase:
testRandomFieldNameSorts(org.apache.solr.search.TestSort):FAILED
[junit] Over 0.2% oddities in test: 14/6386 have func/query parsing
semenatics gotten broader?
[junit] junit.framework.AssertionFailedError: Over 0.2% oddities in test:
14/6386 have func/query parsing semenatics gotten broader?
[junit] at org.junit.Assert.fail(Assert.java:93)
[junit] at org.junit.Assert.assertTrue(Assert.java:43)
[junit] at
org.apache.solr.search.TestSort.testRandomFieldNameSorts(TestSort.java:145)
[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:45)
[junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
[junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
[junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:739)
[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:655)
[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:566)
[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
[junit] at
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:628)
[junit] at org.junit.rules.RunRules.evaluate(RunRules.java:18)
[junit] at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
[junit] at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
[junit] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
[junit] at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
[junit] at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
[junit] at
org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
[junit] at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
[junit] at
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38)
[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
[junit] at org.junit.rules.RunRules.evaluate(RunRules.java:18)
[junit] at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
[junit] at
junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:518)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1052)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.mai
[jira] [Created] (LUCENE-3876) TestIndexWriterExceptions fails (reproducible)
TestIndexWriterExceptions fails (reproducible)
--
Key: LUCENE-3876
URL: https://issues.apache.org/jira/browse/LUCENE-3876
Project: Lucene - Java
Issue Type: Bug
Reporter: Dawid Weiss
Priority: Minor
Fix For: 4.0
{noformat}
ant test -Dtestcase=TestIndexWriterExceptions -Dtestmethod=testIllegalPositions
-Dtests.seed=-228094d3d2f35cf2:-496e33eec9bbd57c:36a1c54f4e1bb32
-Dargs="-Dfile.encoding=UTF-8"
[junit] junit.framework.AssertionFailedError: position=-2 lastPosition=0
[junit] at
org.apache.lucene.codecs.lucene40.Lucene40PostingsWriter.addPosition(Lucene40PostingsWriter.java:215)
[junit] at
org.apache.lucene.index.FreqProxTermsWriterPerField.flush(FreqProxTermsWriterPerField.java:519)
[junit] at
org.apache.lucene.index.FreqProxTermsWriter.flush(FreqProxTermsWriter.java:92)
[junit] at org.apache.lucene.index.TermsHash.flush(TermsHash.java:117)
[junit] at
org.apache.lucene.index.DocInverter.flush(DocInverter.java:53)
[junit] at
org.apache.lucene.index.DocFieldProcessor.flush(DocFieldProcessor.java:81)
[junit] at
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:475)
[junit] at
org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:422)
[junit] at
org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:553)
[junit] at
org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:2640)
[junit] at
org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:2616)
[junit] at
org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:851)
[junit] at
org.apache.lucene.index.IndexWriter.close(IndexWriter.java:810)
[junit] at
org.apache.lucene.index.IndexWriter.close(IndexWriter.java:774)
[junit] at
org.apache.lucene.index.TestIndexWriterExceptions.testIllegalPositions(TestIndexWriterExceptions.java:1517)
[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:45)
[junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
[junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
[junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729)
[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645)
[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556)
[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
[junit] at
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618)
[junit] at org.junit.rules.RunRules.evaluate(RunRules.java:18)
[junit] at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
[junit] at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
[junit] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
[junit] at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
[junit] at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
[junit] at
org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
[junit] at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
[junit] at
org.apache.lucene.util.StoreClassNameRule$1.evaluate(
[jira] [Created] (LUCENE-3871) Check what's up with stack traces being insane.
Check what's up with stack traces being insane. --- Key: LUCENE-3871 URL: https://issues.apache.org/jira/browse/LUCENE-3871 Project: Lucene - Java Issue Type: Task Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 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] [Created] (LUCENE-3868) Thread interruptions shouldn't cause unhandled thread errors (or should they?).
Thread interruptions shouldn't cause unhandled thread errors (or should they?). --- Key: LUCENE-3868 URL: https://issues.apache.org/jira/browse/LUCENE-3868 Project: Lucene - Java Issue Type: Bug Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.6, 4.0 This is a result of pulling uncaught exception catching to a rule above interrupt in internalTearDown(); check how it was before and restore previous behavior? -- 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] (SOLR-3237) OverseerTest failure (non-reproducible)
OverseerTest failure (non-reproducible)
---
Key: SOLR-3237
URL: https://issues.apache.org/jira/browse/SOLR-3237
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Priority: Minor
Fix For: 4.0
Nighly log harvest. Couldn't reproduce, unfortunately.
{noformat}
build 13-Mar-2012 06:08:43[junit] Testsuite:
org.apache.solr.cloud.OverseerTest
build 13-Mar-2012 06:08:43[junit] Testcase:
testShardLeaderChange(org.apache.solr.cloud.OverseerTest):FAILED
build 13-Mar-2012 06:08:43[junit] Unexpected shard leader
coll:collection1 shard:shard1 expected: but was:
build 13-Mar-2012 06:08:43[junit]
junit.framework.AssertionFailedError: Unexpected shard leader coll:collection1
shard:shard1 expected: but was:
build 13-Mar-2012 06:08:43[junit] at
org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:549)
build 13-Mar-2012 06:08:43[junit] at
org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:711)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit] Tests run: 7, Failures: 1, Errors:
0, Time elapsed: 74.666 sec
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit] - Standard Error
-
build 13-Mar-2012 06:08:43[junit] NOTE: reproduce with: ant test
-Dtestcase=OverseerTest -Dtestmethod=testShardLeaderChange
-Dtests.seed=48c9960216b3d5d:6c1600de0df53cdd:69c37083161d807d
-Dargs="-Dfile.encoding=UTF-8"
build 13-Mar-2012 06:08:43[junit] WARNING: test class left thread
running: Session Sets (4):
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:45 MST
2012:
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:48 MST
2012:
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:51 MST
2012:
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:54 MST
2012:
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit] RESOURCE LEAK: test class left 1
thread(s) running
build 13-Mar-2012 06:08:43[junit] NOTE: test params are:
codec=Lucene40: {}, sim=DefaultSimilarity, locale=zh_TW, timezone=Mexico/BajaSur
build 13-Mar-2012 06:08:43[junit] NOTE: all tests run in this JVM:
build 13-Mar-2012 06:08:43[junit] [BasicFunctionalityTest,
SolrInfoMBeanTest, SnowballPorterFilterFactoryTest, TestCJKTokenizerFactory,
TestCJKWidthFilterFactory, TestChineseTokenizerFactory,
TestElisionFilterFactory, TestFinnishLightStemFilterFactory,
TestGalicianStemFilterFactory, TestGermanNormalizationFilterFactory,
TestGermanStemFilterFactory, TestGreekLowerCaseFilterFactory,
TestIndonesianStemFilterFactory, TestLatvianStemFilterFactory,
TestPatternReplaceCharFilterFactory, TestPatternReplaceFilterFactory,
TestPortugueseMinimalStemFilterFac
[jira] [Created] (SOLR-3233) SolrExampleStreamingBinaryTest num results != expected exceptions (reproducible).
SolrExampleStreamingBinaryTest num results != expected exceptions
(reproducible).
-
Key: SOLR-3233
URL: https://issues.apache.org/jira/browse/SOLR-3233
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Priority: Minor
Fix For: 4.0
{noformat}
git clone -b SOLR-3220 --depth 0 g...@github.com:dweiss/lucene_solr.git
git co 9b1efde7a4882caa9dd04556aa4b849db68081a5
cd solr
ant test-core -Dtests.filter=*.SolrExampleStreamingBinaryTest
-Dtests.filter.method=testStatistics -Drt.seed=F57E2420CEBDC955
-Dargs="-Dfile.encoding=UTF-8"
{noformat}
The number of returned committed docs is invalid, this is reproducible and
occurs in many methods, not only in testStatistics?
{code}
int i=0; // 0 1 2 3 4 5 6 7 8 9
int[] nums = new int[] { 23, 26, 38, 46, 55, 63, 77, 84, 92, 94 };
for( int num : nums ) {
SolrInputDocument doc = new SolrInputDocument();
doc.setField( "id", "doc"+i++ );
doc.setField( "name", "doc: "+num );
doc.setField( f, num );
server.add( doc );
}
server.commit();
assertNumFound( "*:*", nums.length ); // <<< FAILURE here. Indeed, a query
via web browser shows not all docs are in?
{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-3855) TestStressNRT failures (reproducible)
TestStressNRT failures (reproducible)
-
Key: LUCENE-3855
URL: https://issues.apache.org/jira/browse/LUCENE-3855
Project: Lucene - Java
Issue Type: Bug
Reporter: Dawid Weiss
Priority: Minor
Fix For: 4.0
Build server logs. Reproduces on at least two machines.
{noformat}
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestStressNRT
-Dtestmethod=test
-Dtests.seed=69468941c1bbf693:19e66d58475da929:69e9d2f81769b6d0
-Dargs="-Dfile.encoding=UTF-8"
[junit] NOTE: test params are: codec=Lucene3x,
sim=RandomSimilarityProvider(queryNorm=true,coord=false): {}, locale=ro,
timezone=Etc/GMT+1
[junit] NOTE: all tests run in this JVM:
[junit] [TestStressNRT]
[junit] NOTE: Linux 3.0.0-16-generic amd64/Sun Microsystems Inc. 1.6.0_27
(64-bit)/cpus=2,threads=1,free=74960064,total=135987200
[junit] - ---
[junit] Testcase: test(org.apache.lucene.index.TestStressNRT): Caused
an ERROR
[junit] MockDirectoryWrapper: cannot close: there are still open files:
{_ng.cfs=8}
[junit] java.lang.RuntimeException: MockDirectoryWrapper: cannot close:
there are still open files: {_ng.cfs=8}
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:555)
[junit] at
org.apache.lucene.index.TestStressNRT.test(TestStressNRT.java:385)
[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743)
[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639)
[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538)
[junit] at
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
[junit] at
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
[junit] Caused by: java.lang.RuntimeException: unclosed IndexInput: _ng.cfs
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:479)
[junit] at
org.apache.lucene.store.MockDirectoryWrapper$1.openSlice(MockDirectoryWrapper.java:777)
[junit] at
org.apache.lucene.store.CompoundFileDirectory.openInput(CompoundFileDirectory.java:221)
[junit] at
org.apache.lucene.codecs.lucene3x.TermInfosReader.(TermInfosReader.java:112)
[junit] at
org.apache.lucene.codecs.lucene3x.Lucene3xFields.(Lucene3xFields.java:84)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat$1.(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat.fieldsProducer(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:108)
[junit] at
org.apache.lucene.index.SegmentReader.(SegmentReader.java:51)
[junit] at
org.apache.lucene.index.IndexWriter$ReadersAndLiveDocs.getMergeReader(IndexWriter.java:521)
[junit] at
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3587)
[junit] at
org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3257)
[junit] at
org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:382)
[junit] at
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:451)
[junit]
[junit]
[junit] Test org.apache.lucene.index.TestStressNRT FAILED
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3206) testRecoveryMultipleLogs(org.apache.solr.search.TestRecovery)
testRecoveryMultipleLogs(org.apache.solr.search.TestRecovery)
-
Key: SOLR-3206
URL: https://issues.apache.org/jira/browse/SOLR-3206
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Priority: Minor
Fix For: 4.0
Failure on the build server. Looks like a number parsing problem but I cannot
reproduce with the same seed.
{noformat}
build 06-Mar-2012 08:11:20[junit] Testcase:
testRecoveryMultipleLogs(org.apache.solr.search.TestRecovery):Caused an
ERROR
build 06-Mar-2012 08:11:20[junit] org.apache.solr.common.SolrException
build 06-Mar-2012 08:11:20[junit] java.lang.RuntimeException:
org.apache.solr.common.SolrException
build 06-Mar-2012 08:11:20[junit] at
org.apache.solr.util.TestHarness.(TestHarness.java:152)
build 06-Mar-2012 08:11:20[junit] at
org.apache.solr.util.TestHarness.(TestHarness.java:135)
build 06-Mar-2012 08:11:20[junit] at
org.apache.solr.util.TestHarness.(TestHarness.java:125)
build 06-Mar-2012 08:11:20[junit] at
org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:351)
build 06-Mar-2012 08:11:20[junit] at
org.apache.solr.search.TestRecovery.testRecoveryMultipleLogs(TestRecovery.java:797)
build 06-Mar-2012 08:11:20[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
build 06-Mar-2012 08:11:20[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:736)
build 06-Mar-2012 08:11:20[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:632)
build 06-Mar-2012 08:11:20[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
build 06-Mar-2012 08:11:20[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:531)
build 06-Mar-2012 08:11:20[junit] at
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:593)
build 06-Mar-2012 08:11:20[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165)
build 06-Mar-2012 08:11:20[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
build 06-Mar-2012 08:11:20[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
build 06-Mar-2012 08:11:20[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
build 06-Mar-2012 08:11:20[junit] Caused by:
org.apache.solr.common.SolrException
build 06-Mar-2012 08:11:20[junit] at
org.apache.solr.core.SolrCore.(SolrCore.java:614)
build 06-Mar-2012 08:11:20[junit] at
org.apache.solr.core.SolrCore.(SolrCore.java:498)
build 06-Mar-2012 08:11:20[junit] at
org.apache.solr.util.TestHarness$Initializer.initialize(TestHarness.java:216)
build 06-Mar-2012 08:11:20[junit] at
org.apache.solr.util.TestHarness.(TestHarness.java:140)
build 06-Mar-2012 08:11:20[junit] Caused by:
org.apache.solr.common.SolrException: Error Instantiating Update Handler,
solr.DirectUpdateHandler2 failed to instantiate
org.apache.solr.update.UpdateHandler
build 06-Mar-2012 08:11:20[junit] at
org.apache.solr.core.SolrCore.createInstance(SolrCore.java:425)
build 06-Mar-2012 08:11:20[junit] at
org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:475)
build 06-Mar-2012 08:11:20[junit] at
org.apache.solr.core.SolrCore.(SolrCore.java:598)
build 06-Mar-2012 08:11:20[junit] Caused by:
java.lang.reflect.InvocationTargetException
build 06-Mar-2012 08:11:20[junit] at
java.lang.reflect.Constructor.newInstance(Constructor.java:513)
build 06-Mar-2012 08:11:20[junit] at
org.apache.solr.core.SolrCore.createInstance(SolrCore.java:418)
build 06-Mar-2012 08:11:20[junit] Caused by:
java.lang.NumberFormatException: For input string: "01:"
build 06-Mar-2012 08:11:20[junit] at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
build 06-Mar-2012 08:11:20[junit] at
java.lang.Long.parseLong(Long.java:419)
build 06-Mar-2012 08:11:20[junit] at
java.lang.Long.parseLong(Long.java:468)
build 06-Mar-2012 08:11:20[junit] at
org.apache.solr.update.UpdateLog.getLastLogId(UpdateLog.java:264)
build 06-Mar-2012 08:11:20[junit] at
org.apache.solr.update.UpdateLog.init(UpdateLog.java:164)
build 06-Mar-2012 08
[jira] [Created] (LUCENE-3851) TestTermInfosReaderIndex failing (always reproducible)
TestTermInfosReaderIndex failing (always reproducible)
--
Key: LUCENE-3851
URL: https://issues.apache.org/jira/browse/LUCENE-3851
Project: Lucene - Java
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Robert Muir
Priority: Minor
Fix For: 4.0
Always fails on branch (use reproduce string below):
git clone --depth 1 -b rr g...@github.com:dweiss/lucene_solr.git
{noformat}
[junit4] Running org.apache.lucene.codecs.lucene3x.TestTermInfosReaderIndex
[junit4] FAILURE 0.04s J0 | TestTermInfosReaderIndex.testSeekEnum
[junit4]> Throwable #1: java.lang.AssertionError:
expected: but was:<:>
[junit4]> at
__randomizedtesting.SeedInfo.seed([C7597DFBBE0B3D7D:C6D9CEDD0700AAFF]:0)
[junit4]> at org.junit.Assert.fail(Assert.java:93)
[junit4]> at org.junit.Assert.failNotEquals(Assert.java:647)
[junit4]> at org.junit.Assert.assertEquals(Assert.java:128)
[junit4]> at org.junit.Assert.assertEquals(Assert.java:147)
[junit4]> at
org.apache.lucene.codecs.lucene3x.TestTermInfosReaderIndex.testSeekEnum(TestTermInfosReaderIndex.java:137)
[junit4]> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit4]> at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit4]> at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit4]> at java.lang.reflect.Method.invoke(Method.java:597)
[junit4]> at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1766)
[junit4]> at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1000(RandomizedRunner.java:141)
[junit4]> at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:728)
[junit4]> at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:789)
[junit4]> at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:803)
[junit4]> at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:744)
[junit4]> at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:636)
[junit4]> at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
[junit4]> at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:550)
[junit4]> at
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600)
[junit4]> at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:735)
[junit4]> at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:141)
[junit4]> at
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:586)
[junit4]> at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:605)
[junit4]> at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:641)
[junit4]> at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:652)
[junit4]> at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
[junit4]> at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:533)
[junit4]> at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:141)
[junit4]> at
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:479)
[junit4]>
[junit4] 2> NOTE: reproduce with: ant test
-Dtests.filter=*.TestTermInfosReaderIndex -Dtests.filter.method=testSeekEnum
-Drt.seed=C7597DFBBE0B3D7D -Dargs="-Dfile.encoding=UTF-8"
[junit4] 2>
[junit4]> (@AfterClass output)
[junit4] 2> NOTE: test params are: codec=Appending, sim=DefaultSimilarity,
locale=en, timezone=Atlantic/Stanley
[junit4] 2> NOTE: all tests run in this JVM:
[junit4] 2> [TestLock, TestFileSwitchDirectory, TestWildcardRandom,
TestVersionComparator, TestTermdocPerf, TestBitVector, TestParallelTermEnum,
TestSimpleSearchEquivalence, TestNumericRangeQuery64, TestSort, TestIsCurrent,
TestToken, TestIntBlockCodec, TestDocumentsWriterDeleteQueue, TestPagedBytes,
TestThreadedForceMerge, TestOmitTf, TestSegmentTermEnum, TestIndexWriterConfig,
TestCheckIndex, TestTermVectorsWriter, TestNumericTokenStream, TestSearchAfter,
TestRegexpQuery, InBeforeClass, InAfterClass, InTestMethod,
NonStringProperties, TestIndexWriterMergePolicy, TestVirtualMethod,
TestFieldCache, TestSurrogates, TestSegmentTermDocs,
TestMultiValuedNumericRangeQuery, TestBasicOperations, TestCodecs,
TestDateSort, TestPositiveScoresOnlyColl
[jira] [Created] (LUCENE-3847) LuceneTestCase should check for modifications on System properties
LuceneTestCase should check for modifications on System properties -- Key: LUCENE-3847 URL: https://issues.apache.org/jira/browse/LUCENE-3847 Project: Lucene - Java Issue Type: Improvement Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.6, 4.0 - fail the test if changes have been detected. - revert the state of system properties before the suite. - cleanup after the suite. -- 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] (SOLR-3199) Non-repeatable failures in BasicDistributedZkTest
Non-repeatable failures in BasicDistributedZkTest - Key: SOLR-3199 URL: https://issues.apache.org/jira/browse/SOLR-3199 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 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] [Created] (LUCENE-3840) Threads leak out from Executors created in LuceneTestCase#newSearcher
Threads leak out from Executors created in LuceneTestCase#newSearcher - Key: LUCENE-3840 URL: https://issues.apache.org/jira/browse/LUCENE-3840 Project: Lucene - Java Issue Type: Bug Components: general/test Reporter: Dawid Weiss Fix For: 4.0 Not every IndexReader/close listener is called and this results in executors not being properly shut down/ disposed of. -- 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-3835) MergeThread throws unchecked exceptions from toString()
MergeThread throws unchecked exceptions from toString() --- Key: LUCENE-3835 URL: https://issues.apache.org/jira/browse/LUCENE-3835 Project: Lucene - Java Issue Type: Bug Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 4.0 This causes nearly all thread-dumping routines to fail and in the effect obscure the original problem. I think this should return a string (always), possibly indicating the underlying writer has been closed or something. -- 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-3832) Port BasicAutomata.stringUnion from Brics to Lucene
Port BasicAutomata.stringUnion from Brics to Lucene --- Key: LUCENE-3832 URL: https://issues.apache.org/jira/browse/LUCENE-3832 Project: Lucene - Java Issue Type: Improvement Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 3.6, 4.0 Brics has my code to build Automaton from a set of sorted strings in one step (Daciuk/Mihov's algorithm again). This should be easily portable to Lucene and is quite useful. -- 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-3830) MappingCharFilter could be improved by switching to an FST.
MappingCharFilter could be improved by switching to an FST. --- Key: LUCENE-3830 URL: https://issues.apache.org/jira/browse/LUCENE-3830 Project: Lucene - Java Issue Type: Improvement Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 4.0 MappingCharFilter stores an overly complex tree-like structure for matching input patterns. The input is a union of fixed strings mapped to a set of fixed strings; an fst matcher would be ideal here and provide both memory and speed improvement I bet. -- 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-3820) Wrong trailing index calculation in PatternReplaceCharFilter
Wrong trailing index calculation in PatternReplaceCharFilter Key: LUCENE-3820 URL: https://issues.apache.org/jira/browse/LUCENE-3820 Project: Lucene - Java Issue Type: Bug Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 4.0 I need to use PatternReplaceCharFilter's index corrections directly and it fails for me -- the trailing index is not mapped correctly for a pattern "\\.[\\s]*" and replacement ".", input "A. .B.". I tried to understand the logic in getReplaceBlock but I eventually failed and simply rewrote it from scratch. After my changes a few tests don't pass but I don't know if it's the tests that are screwed up or my logic. In essence, the difference between the previous implementation and my implementation is how indexes are mapped for shorter replacements. I shift indexes of shorter regions to the "right" of the original index pool and the previous patch seems to squeeze them to the left (don't know why though). If anybody remembers how it's supposed to work, feel free to correct me? -- 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-3808) Switch LuceneTestCaseRunner to RandomizedRunner. Enforce Random sharing contracts. Enforce thread leaks.
Switch LuceneTestCaseRunner to RandomizedRunner. Enforce Random sharing contracts. Enforce thread leaks. Key: LUCENE-3808 URL: https://issues.apache.org/jira/browse/LUCENE-3808 Project: Lucene - Java Issue Type: Sub-task Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 4.0 Switch the runner to RandomizedRunner. Enforce the following: - Random sharing will result in a failure/ exception. - Thread leaks will result in a failure (add lingering if needed, but no ignores). - Add a validator for @Test method overrides (no-no). - Add a validator for static hook shadowing (no-no). - Add a validator for testXXX without @Test annotation. - Modify custom execution groups in LTC to be real @Groups. -- 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-3791) ant eclipse should setup default project formatting.
ant eclipse should setup default project formatting. Key: LUCENE-3791 URL: https://issues.apache.org/jira/browse/LUCENE-3791 Project: Lucene - Java Issue Type: Improvement Components: general/build Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial I admit it's selfish. I have a git workflow and I often do "git clean -xfd" which restores a pristine state of the current branch (faster than ant clean :). Unfortunately this also results in removal of Eclipse files. "ant eclipse" doesn't reset formatting properly so I need to restore it manually. This patch does two things: - it sets project formatting automatically on "ant eclipse", - it removes explicit Lucene-formatting.xml to avoid duplication (and potential inconsistencies) between project-specific formatter rules contained in org.eclipse.jdt.core.prefs and the formatter's XML. The XML can be exported manually if needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3785) Replace ant macros for running concurrent tests with ant-junit4.
Replace ant macros for running concurrent tests with ant-junit4. Key: LUCENE-3785 URL: https://issues.apache.org/jira/browse/LUCENE-3785 Project: Lucene - Java Issue Type: Sub-task Components: general/build, general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 4.0 ant-junit4 is an ANT task for running tests in parallel (on slave JVMs). Its advantages over the current macros: - dynamic load balancing based on historical test runs and current execution (job-stealing), - jvm-crash resilience (I wrote tests that actually crash a slave jvms to make sure such an event is reported appropriately), - nicer console reporting (no need for syserrs on LuceneTestCase level). More documentation and info will follow as I roll out a patch. -- 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-3784) Switching tests infrastructure to randomizedtesting.*
Switching tests infrastructure to randomizedtesting.* - Key: LUCENE-3784 URL: https://issues.apache.org/jira/browse/LUCENE-3784 Project: Lucene - Java Issue Type: Improvement Components: general/build, general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 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] [Created] (LUCENE-3775) A shell script to generate .gitignore from svn:ignore properties
A shell script to generate .gitignore from svn:ignore properties Key: LUCENE-3775 URL: https://issues.apache.org/jira/browse/LUCENE-3775 Project: Lucene - Java Issue Type: Improvement Components: general/build Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Attachments: gitignore-gen.sh Attached is a small shell script that generates .gitignore-new from all svn:ignore properties (on an svn checkout). I was able to successfully regenerate existing .gitignore. There are spurious entries (no recursive rules), but at least it's consistent with svn:ignore? -- 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-3762) Upgrade JUnit to 4.10, refactor state-machine of detecting setUp/tearDown call chaining.
Upgrade JUnit to 4.10, refactor state-machine of detecting setUp/tearDown call chaining. Key: LUCENE-3762 URL: https://issues.apache.org/jira/browse/LUCENE-3762 Project: Lucene - Java Issue Type: Improvement Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 3.6, 4.0 Both Lucene and Solr use JUnit 4.7. I suggest we move forward and upgrade to JUnit 4.10 which provides several infrastructural changes (serializable Description objects, class-level rules, various tweaks). JUnit 4.10 also changes (or fixes, depends how you look at it) the order in which @Before/@After hooks and @Rules are applied. This makes the old state-machine in LuceneTestCase fail (because the order is changed). I rewrote the state machine and used a different, I think simpler, although Uwe may disagree :), mechanism in which the hook methods setUp/ tearDown are still there, but they are empty at the top level and serve only to detect whether subclasses chain super.setUp/tearDown properly (if they override anything). In the long term, I would love to just get rid of public setup/teardown methods and make them private (so that they cannot be overriden or even seen by subclasses) but this will require changes to the runner itself. -- 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-3582) NumericUtils.floatToSortableInt does not sort certain NaN ranges correctly.
NumericUtils.floatToSortableInt does not sort certain NaN ranges correctly.
---
Key: LUCENE-3582
URL: https://issues.apache.org/jira/browse/LUCENE-3582
Project: Lucene - Java
Issue Type: Bug
Reporter: Dawid Weiss
Priority: Trivial
Fix For: 4.0
The current implementation of floatToSortableInt does not account for different
NaN ranges which may result in NaNs sorted before -Infinity and after
+Infinity. The default Java ordering is: all NaNs after Infinity.
A possible fix is to make all NaNs canonic "quiet NaN" as in:
{code}
// Canonicalize NaN ranges. I assume this check will be faster here than
// (v == v) == false on the FPU? We don't distinguish between different
// flavors of NaNs here (see http://en.wikipedia.org/wiki/NaN). I guess
// in Java this doesn't matter much anyway.
if ((v & 0x7fff) > 0x7f80) {
// Apply the logic below to a canonical "quiet NaN"
return 0x7fc0 ^ 0x8000;
}
{code}
I don't commit because I don't know how much of the existing stuff relies on
this (nobody should be keeping different NaNs in their indexes, but who
knows...).
--
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] (SOLR-2888) FSTSuggester should use utf8/utf32 order
FSTSuggester should use utf8/utf32 order - Key: SOLR-2888 URL: https://issues.apache.org/jira/browse/SOLR-2888 Project: Solr Issue Type: Improvement Components: spellchecker Reporter: Dawid Weiss Assignee: Dawid Weiss Fix For: 4.0 For some reason it uses utf16 internally. Shouldn't make much of a difference, really. -- 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] (SOLR-2887) FSTSuggester shouldn't OOM on large inputs
FSTSuggester shouldn't OOM on large inputs -- Key: SOLR-2887 URL: https://issues.apache.org/jira/browse/SOLR-2887 Project: Solr Issue Type: Improvement Components: spellchecker Reporter: Dawid Weiss Assignee: Dawid Weiss Fix For: 3.5, 4.0 Currently the input to FSTSuggester needs to be re-sorted and this is done in-memory. Kind of defeats the purpose of the component since everything else is super-efficient but we don't even get to that part because of OOMs during construction. Robert suggested using a spill-to-disk and merge sort on-disk. I suggested creating a lucene index and then enumerating terms for automaton construction or taking the automaton directly from the index structure (if it isn't pruned). -- 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] (SOLR-2862) CarrotClusteringEngine's resource locator should log the absolute location of lexical resources
CarrotClusteringEngine's resource locator should log the absolute location of lexical resources --- Key: SOLR-2862 URL: https://issues.apache.org/jira/browse/SOLR-2862 Project: Solr Issue Type: Improvement Components: contrib - Clustering Affects Versions: 3.4, 3.3, 3.2, 3.1 Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 3.5 Currently it returns default toString() jibberish. -- 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-3492) Extract a generic framework for running randomized tests.
Extract a generic framework for running randomized tests. - Key: LUCENE-3492 URL: https://issues.apache.org/jira/browse/LUCENE-3492 Project: Lucene - Java Issue Type: Improvement Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 4.0 I love the idea of randomized testing. Everyone (we at CarrotSearch, Lucene and Solr folks) have their glue to make it possible. The question is if there's something to pull out that others could share without having the need to import Lucene-specific classes. -- 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
