[jira] [Commented] (LUCENE-3855) TestStressNRT failures (reproducible)
[
https://issues.apache.org/jira/browse/LUCENE-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225085#comment-13225085
]
Dawid Weiss commented on LUCENE-3855:
-
Yep, there is something severely wrong in there, but I won't be able to figure
it out on my own. Don't get the logic in IndexWriter. But I tracked one of the
above exceptions to this scenario:
{noformat}
[junit] junit.framework.AssertionFailedError: info=_dm(4.0):cv6/4 isn't live
[junit] at
org.apache.lucene.index.IndexWriter$ReaderPool.infoIsLive(IndexWriter.java:663)
[junit] at
org.apache.lucene.index.IndexWriter$ReaderPool.dropAll(IndexWriter.java:717)
[junit] at
org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1136)
[junit] at
org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1069)
[junit] at
org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1033)
[junit] at
org.apache.lucene.index.RandomIndexWriter.close(RandomIndexWriter.java:408)
[junit] at
org.apache.lucene.index.TestStressNRT.test(TestStressNRT.java:380)
{noformat}
So, the case here is that infoIsLive attempts to check:
{noformat}
int idx = segmentInfos.indexOf(info);
assert idx != -1: info= + info + isn't live;
{noformat}
I added tracing to segmentInfos when segments do get removed from the
underlying array. Once executed, I get the listing:
{noformat}
...
Removing: _o1(4.0):Cv13/13
Removing: _o0(4.0):Cv6/6
Removing: _nu(4.0):C12/12
Removing: _nw(4.0):Cv12/12
Removing: _o9(4.0):c2/2
Removing: _q2(4.0):C12/12
Removing: _qc(4.0):Cv7/7
Removing: _q6(4.0):C12/12
Not found: _d9(4.0):Cv8/3
{noformat}
But that last segment is never on the list of removed segments. It was never
added there in the first place. The allocation stack for that segment is:
{noformat}
at java.lang.Thread.getStackTrace(Thread.java:1436)
at org.apache.lucene.index.SegmentInfo.init(SegmentInfo.java:130)
at org.apache.lucene.index.IndexWriter._mergeInit(IndexWriter.java:3418)
at org.apache.lucene.index.IndexWriter.mergeInit(IndexWriter.java:3382)
at
org.apache.lucene.index.ConcurrentMergeScheduler.merge(ConcurrentMergeScheduler.java:346)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1905)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1899)
at
org.apache.lucene.index.IndexWriter.prepareCommit(IndexWriter.java:2726)
at
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2809)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2791)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2775)
at
org.apache.lucene.index.RandomIndexWriter.commit(RandomIndexWriter.java:313)
at org.apache.lucene.index.TestStressNRT$1.run(TestStressNRT.java:156)
{noformat}
So this looks like a race condition between closing the writer and a concurrent
merge scheduler?
Let me know if you need any further stacks/ tracing listings -- this is fairly
easy to reproduce on my machine and I can add anything.
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
Attachments: output1.log, output2.log, output3.log, output4.log
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)
[jira] [Issue Comment Edited] (LUCENE-3855) TestStressNRT failures (reproducible)
[
https://issues.apache.org/jira/browse/LUCENE-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225088#comment-13225088
]
Dawid Weiss edited comment on LUCENE-3855 at 3/8/12 8:50 AM:
-
This is definitely a race between ConcurrentMergeScheduler and the thread
calling close. Everything else seems to stem from this problem. For example
this one:
{noformat}
java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are still
open files: {_dc.tvx=1, _dc.tvf=1, _dc.tvd=1, _dc.fdx=1, _dc.fdt=1, _dc.frq=1,
_dc.tis=1}
at
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:555)
at org.apache.lucene.index.TestStressNRT.test(TestStressNRT.java:385)
{noformat}
has an underlying open file handle stack:
{noformat}
Caused by: java.lang.RuntimeException: unclosed IndexInput: _dc.tvf
at
org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:479)
at
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:504)
at
org.apache.lucene.codecs.lucene3x.Lucene3xTermVectorsReader.init(Lucene3xTermVectorsReader.java:137)
at
org.apache.lucene.codecs.lucene3x.PreFlexRWTermVectorsFormat$1.init(PreFlexRWTermVectorsFormat.java:39)
at
org.apache.lucene.codecs.lucene3x.PreFlexRWTermVectorsFormat.vectorsReader(PreFlexRWTermVectorsFormat.java:39)
at
org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:119)
at org.apache.lucene.index.SegmentReader.init(SegmentReader.java:51)
at
org.apache.lucene.index.IndexWriter$ReadersAndLiveDocs.getMergeReader(IndexWriter.java:521)
at
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3591)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3261)
at
org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:382)
at
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:451)
{noformat}
Uwe, this just calls for your German analytic mind to solve :)
was (Author: dweiss):
This is definitely a race between ConcurrentMergeScheduler and the thread
calling close. Everything else seems to be stem from this. For example this one:
{noformat}
java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are still
open files: {_dc.tvx=1, _dc.tvf=1, _dc.tvd=1, _dc.fdx=1, _dc.fdt=1, _dc.frq=1,
_dc.tis=1}
at
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:555)
at org.apache.lucene.index.TestStressNRT.test(TestStressNRT.java:385)
{noformat}
has an underlying open file handle stack:
{noformat}
Caused by: java.lang.RuntimeException: unclosed IndexInput: _dc.tvf
at
org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:479)
at
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:504)
at
org.apache.lucene.codecs.lucene3x.Lucene3xTermVectorsReader.init(Lucene3xTermVectorsReader.java:137)
at
org.apache.lucene.codecs.lucene3x.PreFlexRWTermVectorsFormat$1.init(PreFlexRWTermVectorsFormat.java:39)
at
org.apache.lucene.codecs.lucene3x.PreFlexRWTermVectorsFormat.vectorsReader(PreFlexRWTermVectorsFormat.java:39)
at
org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:119)
at org.apache.lucene.index.SegmentReader.init(SegmentReader.java:51)
at
org.apache.lucene.index.IndexWriter$ReadersAndLiveDocs.getMergeReader(IndexWriter.java:521)
at
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3591)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3261)
at
org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:382)
at
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:451)
{noformat}
Uwe, this just calls for your German analytic mind to solve :)
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
Attachments: output1.log, output2.log, output3.log, output4.log
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,
[jira] [Commented] (LUCENE-3855) TestStressNRT failures (reproducible)
[
https://issues.apache.org/jira/browse/LUCENE-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225088#comment-13225088
]
Dawid Weiss commented on LUCENE-3855:
-
This is definitely a race between ConcurrentMergeScheduler and the thread
calling close. Everything else seems to be stem from this. For example this one:
{noformat}
java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are still
open files: {_dc.tvx=1, _dc.tvf=1, _dc.tvd=1, _dc.fdx=1, _dc.fdt=1, _dc.frq=1,
_dc.tis=1}
at
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:555)
at org.apache.lucene.index.TestStressNRT.test(TestStressNRT.java:385)
{noformat}
has an underlying open file handle stack:
{noformat}
Caused by: java.lang.RuntimeException: unclosed IndexInput: _dc.tvf
at
org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:479)
at
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:504)
at
org.apache.lucene.codecs.lucene3x.Lucene3xTermVectorsReader.init(Lucene3xTermVectorsReader.java:137)
at
org.apache.lucene.codecs.lucene3x.PreFlexRWTermVectorsFormat$1.init(PreFlexRWTermVectorsFormat.java:39)
at
org.apache.lucene.codecs.lucene3x.PreFlexRWTermVectorsFormat.vectorsReader(PreFlexRWTermVectorsFormat.java:39)
at
org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:119)
at org.apache.lucene.index.SegmentReader.init(SegmentReader.java:51)
at
org.apache.lucene.index.IndexWriter$ReadersAndLiveDocs.getMergeReader(IndexWriter.java:521)
at
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3591)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3261)
at
org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:382)
at
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:451)
{noformat}
Uwe, this just calls for your German analytic mind to solve :)
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
Attachments: output1.log, output2.log, output3.log, output4.log
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
[JENKINS] Solr-trunk - Build # 1786 - Failure
Build: https://builds.apache.org/job/Solr-trunk/1786/ 1 tests failed. REGRESSION: org.apache.solr.TestDistributedSearch.testDistribSearch Error Message: java.lang.AssertionError: Some threads threw uncaught exceptions! Stack Trace: java.lang.RuntimeException: java.lang.AssertionError: Some threads threw uncaught exceptions! at org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:816) at org.apache.lucene.util.LuceneTestCase.access$1100(LuceneTestCase.java:137) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:640) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase.checkUncaughtExceptionsAfter(LuceneTestCase.java:844) at org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:788) Build Log (for compile errors): [...truncated 9335 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3208) Implement Logging UI with /admin/logging handler
[ https://issues.apache.org/jira/browse/SOLR-3208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225098#comment-13225098 ] Stefan Matheis (steffkes) commented on SOLR-3208: - Is no working, after Erick committed SOLR-3162 (r1298010) Implement Logging UI with /admin/logging handler Key: SOLR-3208 URL: https://issues.apache.org/jira/browse/SOLR-3208 Project: Solr Issue Type: Improvement Components: web gui Reporter: Ryan McKinley Priority: Blocker Fix For: 4.0 The admin UI currently uses a stub /logging.json to display a tree. It should use the LogLevelHandler -- 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] [Issue Comment Edited] (SOLR-3208) Implement Logging UI with /admin/logging handler
[ https://issues.apache.org/jira/browse/SOLR-3208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225098#comment-13225098 ] Stefan Matheis (steffkes) edited comment on SOLR-3208 at 3/8/12 9:26 AM: - Is now working, after Erick committed SOLR-3162 (r1298010) was (Author: steffkes): Is no working, after Erick committed SOLR-3162 (r1298010) Implement Logging UI with /admin/logging handler Key: SOLR-3208 URL: https://issues.apache.org/jira/browse/SOLR-3208 Project: Solr Issue Type: Improvement Components: web gui Reporter: Ryan McKinley Priority: Blocker Fix For: 4.0 The admin UI currently uses a stub /logging.json to display a tree. It should use the LogLevelHandler -- 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
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 1913 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/1913/ All tests passed Build Log (for compile errors): [...truncated 5985 lines...] [javac] missing type arguments for generic class AbstractSecondPassGroupingCollectorGROUP_VALUE_TYPE [javac] where GROUP_VALUE_TYPE is a type-variable: [javac] GROUP_VALUE_TYPE extends Object declared in class AbstractSecondPassGroupingCollector [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk-java7/checkout/modules/grouping/src/test/org/apache/lucene/search/grouping/TestGrouping.java:346: warning: [rawtypes] found raw type: GroupDocs [javac] return new TopGroupsBytesRef(mvalTopGroups.groupSort, mvalTopGroups.withinGroupSort, mvalTopGroups.totalHitCount, mvalTopGroups.totalGroupedHitCount, groups.toArray(new GroupDocs[groups.size()])); [javac] ^ [javac] missing type arguments for generic class GroupDocsGROUP_VALUE_TYPE [javac] where GROUP_VALUE_TYPE is a type-variable: [javac] GROUP_VALUE_TYPE extends Object declared in class GroupDocs [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk-java7/checkout/modules/grouping/src/test/org/apache/lucene/search/grouping/TestGrouping.java:430: warning: [rawtypes] found raw type: Comparable [javac] final Comparable?[] fields = new Comparable[sortFields.length]; [javac]^ [javac] missing type arguments for generic class ComparableT [javac] where T is a type-variable: [javac] T extends Object declared in interface Comparable [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk-java7/checkout/modules/grouping/src/test/org/apache/lucene/search/grouping/TestGrouping.java:518: warning: [rawtypes] found raw type: GroupDocs [javac] final GroupDocsBytesRef[] result = new GroupDocs[limit-groupOffset]; [javac] ^ [javac] missing type arguments for generic class GroupDocsGROUP_VALUE_TYPE [javac] where GROUP_VALUE_TYPE is a type-variable: [javac] GROUP_VALUE_TYPE extends Object declared in class GroupDocs [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk-java7/checkout/modules/grouping/src/test/org/apache/lucene/search/grouping/TestGrouping.java:877: warning: [rawtypes] found raw type: AbstractFirstPassGroupingCollector [javac] final AbstractFirstPassGroupingCollector c1 = createRandomFirstPassCollector(group, groupSort, groupOffset+topNGroups, canUseIDV); [javac] ^ [javac] missing type arguments for generic class AbstractFirstPassGroupingCollectorGROUP_VALUE_TYPE [javac] where GROUP_VALUE_TYPE is a type-variable: [javac] GROUP_VALUE_TYPE extends Object declared in class AbstractFirstPassGroupingCollector [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk-java7/checkout/modules/grouping/src/test/org/apache/lucene/search/grouping/TestGrouping.java:881: warning: [rawtypes] found raw type: AbstractAllGroupsCollector [javac] final AbstractAllGroupsCollector allGroupsCollector; [javac] ^ [javac] missing type arguments for generic class AbstractAllGroupsCollectorGROUP_VALUE_TYPE [javac] where GROUP_VALUE_TYPE is a type-variable: [javac] GROUP_VALUE_TYPE extends Object declared in class AbstractAllGroupsCollector [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk-java7/checkout/modules/grouping/src/test/org/apache/lucene/search/grouping/TestGrouping.java:956: warning: [rawtypes] found raw type: AbstractSecondPassGroupingCollector [javac] final AbstractSecondPassGroupingCollector c2; [javac] ^ [javac] missing type arguments for generic class AbstractSecondPassGroupingCollectorGROUP_VALUE_TYPE [javac] where GROUP_VALUE_TYPE is a type-variable: [javac] GROUP_VALUE_TYPE extends Object declared in class AbstractSecondPassGroupingCollector [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk-java7/checkout/modules/grouping/src/test/org/apache/lucene/search/grouping/TestGrouping.java:1066: error: incompatible types [javac] final TopGroupsBytesRef tempTopGroupsBlocks = c3.getTopGroups(docSort, groupOffset, docOffset, docOffset+docsPerGroup, fillFields); [javac] ^ [javac] required: TopGroupsBytesRef [javac] found:TopGroupsCAP#1 [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends Object from capture of ? [javac]
[jira] [Created] (SOLR-3216) Solr logo missing from /browse GUI
Solr logo missing from /browse GUI -- Key: SOLR-3216 URL: https://issues.apache.org/jira/browse/SOLR-3216 Project: Solr Issue Type: Bug Components: Response Writers Reporter: Jan Høydahl Priority: Trivial A refactoring obviously removed webapp/web/admin/solr_small.png, used by Velocity templates. We should switch to webapp/web/img/solr.png -- 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] (SOLR-3216) Solr logo missing from /browse GUI
[ https://issues.apache.org/jira/browse/SOLR-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-3216: -- Fix Version/s: 4.0 Solr logo missing from /browse GUI -- Key: SOLR-3216 URL: https://issues.apache.org/jira/browse/SOLR-3216 Project: Solr Issue Type: Bug Components: Response Writers Reporter: Jan Høydahl Priority: Trivial Fix For: 4.0 A refactoring obviously removed webapp/web/admin/solr_small.png, used by Velocity templates. We should switch to webapp/web/img/solr.png -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3216) Solr logo missing from /browse GUI
[ https://issues.apache.org/jira/browse/SOLR-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-3216. --- Resolution: Fixed Solr logo missing from /browse GUI -- Key: SOLR-3216 URL: https://issues.apache.org/jira/browse/SOLR-3216 Project: Solr Issue Type: Bug Components: Response Writers Reporter: Jan Høydahl Priority: Trivial Fix For: 4.0 A refactoring obviously removed webapp/web/admin/solr_small.png, used by Velocity templates. We should switch to webapp/web/img/solr.png -- 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
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12658 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12658/ All tests passed Build Log (for compile errors): [...truncated 4672 lines...] [junit] [junit] - Standard Error - [junit] NOTE: Ignoring @nightly test method 'testbig' [junit] - --- [junit] Testsuite: org.apache.lucene.facet.taxonomy.writercache.cl2o.TestCompactLabelToOrdinal [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.134 sec [junit] [junit] Testsuite: org.apache.lucene.util.UnsafeByteArrayInputStreamTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.012 sec [junit] [junit] Testsuite: org.apache.lucene.util.collections.IntHashSetTest [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.041 sec [junit] [junit] Testsuite: org.apache.lucene.util.collections.ObjectToIntMapTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.024 sec [junit] [junit] Testsuite: org.apache.lucene.util.collections.TestLRUHashMap [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.006 sec [junit] common.test: [echo] Building grouping... common.init: compile-lucene-core: jflex-uptodate-check: jflex-notice: javacc-uptodate-check: javacc-notice: init: clover.setup: clover.info: [echo] [echo] Clover not found. Code coverage reports disabled. [echo] clover: common.compile-core: [javac] Compiling 1 source file to /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/build/core/classes/java compile-core: init: test: [echo] Building grouping... common.init: compile-lucene-core: init: compile-test: [echo] Building grouping... common.init: compile-lucene-core: init: clover.setup: clover.info: [echo] [echo] Clover not found. Code coverage reports disabled. [echo] clover: compile-core: [mkdir] Created dir: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/modules/grouping/build/classes/java [javac] Compiling 23 source files to /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/modules/grouping/build/classes/java compile-test-framework: init: compile-lucene-core: compile-core: common.compile-test: [mkdir] Created dir: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/modules/grouping/build/classes/test [javac] Compiling 5 source files to /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/modules/grouping/build/classes/test [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/modules/grouping/src/test/org/apache/lucene/search/grouping/TestGrouping.java:1066: incompatible types [javac] found : org.apache.lucene.search.grouping.TopGroupscapture#62 of ? [javac] required: org.apache.lucene.search.grouping.TopGroupsorg.apache.lucene.util.BytesRef [javac] final TopGroupsBytesRef tempTopGroupsBlocks = c3.getTopGroups(docSort, groupOffset, docOffset, docOffset+docsPerGroup, fillFields); [javac] ^ [javac] 1 error [...truncated 17 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 12658 - Failure
I committed a fix for this. Martijn On 8 March 2012 11:11, Apache Jenkins Server jenk...@builds.apache.orgwrote: Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12658/ All tests passed Build Log (for compile errors): [...truncated 4672 lines...] [junit] [junit] - Standard Error - [junit] NOTE: Ignoring @nightly test method 'testbig' [junit] - --- [junit] Testsuite: org.apache.lucene.facet.taxonomy.writercache.cl2o.TestCompactLabelToOrdinal [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.134 sec [junit] [junit] Testsuite: org.apache.lucene.util.UnsafeByteArrayInputStreamTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.012 sec [junit] [junit] Testsuite: org.apache.lucene.util.collections.IntHashSetTest [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.041 sec [junit] [junit] Testsuite: org.apache.lucene.util.collections.ObjectToIntMapTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.024 sec [junit] [junit] Testsuite: org.apache.lucene.util.collections.TestLRUHashMap [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.006 sec [junit] common.test: [echo] Building grouping... common.init: compile-lucene-core: jflex-uptodate-check: jflex-notice: javacc-uptodate-check: javacc-notice: init: clover.setup: clover.info: [echo] [echo] Clover not found. Code coverage reports disabled. [echo] clover: common.compile-core: [javac] Compiling 1 source file to /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/build/core/classes/java compile-core: init: test: [echo] Building grouping... common.init: compile-lucene-core: init: compile-test: [echo] Building grouping... common.init: compile-lucene-core: init: clover.setup: clover.info: [echo] [echo] Clover not found. Code coverage reports disabled. [echo] clover: compile-core: [mkdir] Created dir: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/modules/grouping/build/classes/java [javac] Compiling 23 source files to /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/modules/grouping/build/classes/java compile-test-framework: init: compile-lucene-core: compile-core: common.compile-test: [mkdir] Created dir: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/modules/grouping/build/classes/test [javac] Compiling 5 source files to /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/modules/grouping/build/classes/test [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/modules/grouping/src/test/org/apache/lucene/search/grouping/TestGrouping.java:1066: incompatible types [javac] found : org.apache.lucene.search.grouping.TopGroupscapture#62 of ? [javac] required: org.apache.lucene.search.grouping.TopGroupsorg.apache.lucene.util.BytesRef [javac] final TopGroupsBytesRef tempTopGroupsBlocks = c3.getTopGroups(docSort, groupOffset, docOffset, docOffset+docsPerGroup, fillFields); [javac] ^ [javac] 1 error [...truncated 17 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3850) Fix rawtypes warnings for Java 7 compiler
[
https://issues.apache.org/jira/browse/LUCENE-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225133#comment-13225133
]
Martijn van Groningen commented on LUCENE-3850:
---
I've fixed most of the grouping compile warnings.
I now only see this warning during compilation:
warning: [options] bootstrap class path not set in conjunction with -source 1.6
Fix rawtypes warnings for Java 7 compiler
-
Key: LUCENE-3850
URL: https://issues.apache.org/jira/browse/LUCENE-3850
Project: Lucene - Java
Issue Type: Improvement
Affects Versions: 3.5, 4.0
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 3.6, 4.0
Attachments: LUCENE-3850-part1-branch3x.patch,
LUCENE-3850-part1.patch, LUCENE-3850-part2.patch,
LUCENE-3850-parts2-branch3x.patch
Java 7 changed the warnings a little bit:
- Java 6 only knew unchecked warning type, applying for all types of
generics violations, like missing generics (raw types)
- Java 7 still knows unchecked but only emits warning if the call is really
unchecked. Declaration of variables/fields or constructing instances without
type param now emits rawtypes warning.
The changes above causes the Java 7 compile now emit lots of rawtypes
warnings, where Java 6 is silent. The easy fix is to suppres both warning
types: @SuppressWarnings({unchecked,rawtypes}) for all those places.
Changes are easy to do, will provide patch later!
--
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-3855) TestStressNRT failures (reproducible)
[
https://issues.apache.org/jira/browse/LUCENE-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225134#comment-13225134
]
Michael McCandless commented on LUCENE-3855:
I can [eventually] reproduce the failure too, if I beast the test...
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
Attachments: output1.log, output2.log, output3.log, output4.log
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.init(TermInfosReader.java:112)
[junit] at
org.apache.lucene.codecs.lucene3x.Lucene3xFields.init(Lucene3xFields.java:84)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat$1.init(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat.fieldsProducer(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:108)
[junit] at
org.apache.lucene.index.SegmentReader.init(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
[jira] [Commented] (LUCENE-3855) TestStressNRT failures (reproducible)
[
https://issues.apache.org/jira/browse/LUCENE-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225136#comment-13225136
]
Dawid Weiss commented on LUCENE-3855:
-
I think you can try to run a few threads in the background doing just while
(true);. I have a slower computer 2-core computer and this happens there most
often.
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
Attachments: output1.log, output2.log, output3.log, output4.log
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.init(TermInfosReader.java:112)
[junit] at
org.apache.lucene.codecs.lucene3x.Lucene3xFields.init(Lucene3xFields.java:84)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat$1.init(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat.fieldsProducer(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:108)
[junit] at
org.apache.lucene.index.SegmentReader.init(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:
[jira] [Updated] (LUCENE-3846) Fuzzy suggester
[ https://issues.apache.org/jira/browse/LUCENE-3846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-3846: Attachment: LUCENE-3846.patch I applied this and fixed some compile errors while reading through the code. I also simplified the build() method and removed some minor things. basically updated to trunk Fuzzy suggester --- Key: LUCENE-3846 URL: https://issues.apache.org/jira/browse/LUCENE-3846 Project: Lucene - Java Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 3.6, 4.0 Attachments: LUCENE-3846.patch, LUCENE-3846.patch Would be nice to have a suggester that can handle some fuzziness (like spell correction) so that it's able to suggest completions that are near what you typed. As a first go at this, I implemented 1T (ie up to 1 edit, including a transposition), except the first letter must be correct. But there is a penalty, ie, the corrected suggestion needs to have a much higher freq than the exact match suggestion before it can compete. Still tons of nocommits, and somehow we should merge this / make it work with analyzing suggester too (LUCENE-3842). -- 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-3850) Fix rawtypes warnings for Java 7 compiler
[
https://issues.apache.org/jira/browse/LUCENE-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225142#comment-13225142
]
Martijn van Groningen commented on LUCENE-3850:
---
Also fixed the warnings for the join module.
Fix rawtypes warnings for Java 7 compiler
-
Key: LUCENE-3850
URL: https://issues.apache.org/jira/browse/LUCENE-3850
Project: Lucene - Java
Issue Type: Improvement
Affects Versions: 3.5, 4.0
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 3.6, 4.0
Attachments: LUCENE-3850-part1-branch3x.patch,
LUCENE-3850-part1.patch, LUCENE-3850-part2.patch,
LUCENE-3850-parts2-branch3x.patch
Java 7 changed the warnings a little bit:
- Java 6 only knew unchecked warning type, applying for all types of
generics violations, like missing generics (raw types)
- Java 7 still knows unchecked but only emits warning if the call is really
unchecked. Declaration of variables/fields or constructing instances without
type param now emits rawtypes warning.
The changes above causes the Java 7 compile now emit lots of rawtypes
warnings, where Java 6 is silent. The easy fix is to suppres both warning
types: @SuppressWarnings({unchecked,rawtypes}) for all those places.
Changes are easy to do, will provide patch later!
--
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-3846) Fuzzy suggester
[ https://issues.apache.org/jira/browse/LUCENE-3846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225144#comment-13225144 ] Michael McCandless commented on LUCENE-3846: Thanks Simon! Fuzzy suggester --- Key: LUCENE-3846 URL: https://issues.apache.org/jira/browse/LUCENE-3846 Project: Lucene - Java Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 3.6, 4.0 Attachments: LUCENE-3846.patch, LUCENE-3846.patch Would be nice to have a suggester that can handle some fuzziness (like spell correction) so that it's able to suggest completions that are near what you typed. As a first go at this, I implemented 1T (ie up to 1 edit, including a transposition), except the first letter must be correct. But there is a penalty, ie, the corrected suggestion needs to have a much higher freq than the exact match suggestion before it can compete. Still tons of nocommits, and somehow we should merge this / make it work with analyzing suggester too (LUCENE-3842). -- 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-3778) Create a grouping convenience class
[ https://issues.apache.org/jira/browse/LUCENE-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225146#comment-13225146 ] Michael McCandless commented on LUCENE-3778: bq. In the join module we have the JoinUtil. Maybe rename it to GroupUtil? Just to be consistent? Or rename JoinUtil to JoinSearch? Hmm, except in JoinUtil's case, it just has one static method... vs GroupingSearch which you instantiate, tweak, and use. So I think it's good that they are named differently? Create a grouping convenience class --- Key: LUCENE-3778 URL: https://issues.apache.org/jira/browse/LUCENE-3778 Project: Lucene - Java Issue Type: Improvement Components: modules/grouping Reporter: Martijn van Groningen Attachments: LUCENE-3778.patch, LUCENE-3778.patch Currently the grouping module has many collector classes with a lot of different options per class. I think it would be a good idea to have a GroupUtil (Or another name?) convenience class. I think this could be a builder, because of the many options (sort,sortWithinGroup,groupOffset,groupCount and more) and implementations (term/dv/function) grouping has. -- 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-3778) Create a grouping convenience class
[ https://issues.apache.org/jira/browse/LUCENE-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225149#comment-13225149 ] Martijn van Groningen commented on LUCENE-3778: --- bq. Hmm, except in JoinUtil's case, it just has one static method... vs GroupingSearch which you instantiate, tweak, and use. So I think it's good that they are named differently? True. Lets keep the current name then. I think that the package.html should also be updated? It should use the GroupSearch instead of all the different collectors. Create a grouping convenience class --- Key: LUCENE-3778 URL: https://issues.apache.org/jira/browse/LUCENE-3778 Project: Lucene - Java Issue Type: Improvement Components: modules/grouping Reporter: Martijn van Groningen Attachments: LUCENE-3778.patch, LUCENE-3778.patch Currently the grouping module has many collector classes with a lot of different options per class. I think it would be a good idea to have a GroupUtil (Or another name?) convenience class. I think this could be a builder, because of the many options (sort,sortWithinGroup,groupOffset,groupCount and more) and implementations (term/dv/function) grouping has. -- 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] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
[ https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225150#comment-13225150 ] Michael McCandless commented on SOLR-3204: -- bq. If you don't change the packages, don't change the gav. If you do change the packages, do change the gav. +1 And... I hate to heap even more invasiveness/virality onto Maven, but... it seems like if Maven also checked across artifacts (groupID+artifactID?) for package name conflicts... that would prevent future cases of accidentally releasing a private dependency? (Hmmm, assuming commons-csv releases snapshots...). solr-commons-csv must not use the org.apache.commons.csv package Key: SOLR-3204 URL: https://issues.apache.org/jira/browse/SOLR-3204 Project: Solr Issue Type: Bug Components: Build Affects Versions: 3.5 Reporter: Emmanuel Bourg Assignee: Uwe Schindler Priority: Blocker Fix For: 3.6, 4.0 Attachments: SOLR-3204.patch, SOLR-3204.patch, SOLR-3204.patch, SOLR-3204.patch, apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar, apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar, rule.txt, rule.txt, solr-csv.patch The solr-commons-csv artifact reused the code from the Apache Commons CSV project but the package wasn't changed to something else than org.apache.commons.csv in the process. This creates a compatibility issue as the Apache Commons team works toward an official release of Commons CSV. It prevents Commons CSV from using its own org.apache.commons.csv package, or forces the renaming of all the classes to avoid a classpath conflict. -- 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
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 1914 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/1914/ 1 tests failed. FAILED: org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest.testMultiThreaded Error Message: expected:500 but was:300 Stack Trace: junit.framework.AssertionFailedError: expected:500 but was:300 at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.solr.client.solrj.LargeVolumeTestBase.query(LargeVolumeTestBase.java:70) at org.apache.solr.client.solrj.LargeVolumeTestBase.testMultiThreaded(LargeVolumeTestBase.java:61) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600) Build Log (for compile errors): [...truncated 11737 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: TestStressNRT failures.
Not a linux box, but -Dtests.iter=1000 and no failures on my Macbook Pro. FWIW Erick On Wed, Mar 7, 2012 at 5:52 PM, Dawid Weiss dawid.we...@gmail.com wrote: https://issues.apache.org/jira/browse/LUCENE-3855 Ehm, either I'm going crazy or my machines are somehow different from anybody else's ;) If you have a spare cycle could you: cd lucene ant test-core -Dtestcase=TestStressNRT -Dtestmethod=test -Dtests.seed=69468941c1bbf693:19e66d58475da929:69e9d2f81769b6d0 -Dargs=-Dfile.encoding=UTF-8 A few times? In my case (a few different machines, different hardware, JVMs, but all Linuxes) the above yields errors in about 25-30% of executions. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: svn commit: r1298287 - in /lucene/dev/trunk: lucene/common-build.xml modules/grouping/src/test/org/apache/lucene/search/grouping/AbstractGroupingTestCase.java
+1, thanks Dawid.
-Original Message-
From: dwe...@apache.org [mailto:dwe...@apache.org]
Sent: Thursday, March 08, 2012 2:58 AM
To: comm...@lucene.apache.org
Subject: svn commit: r1298287 - in /lucene/dev/trunk: lucene/common-build.xml
modules/grouping/src/test/org/apache/lucene/search/grouping/AbstractGroupingTestCase.java
Author: dweiss
Date: Thu Mar 8 07:57:51 2012
New Revision: 1298287
URL: http://svn.apache.org/viewvc?rev=1298287view=rev
Log:
Steve: this should be a better solution than @Ignore? Maven won't run abstract
classes and this seems more consistent with the declared class purpose...
Modified:
lucene/dev/trunk/lucene/common-build.xml
lucene/dev/trunk/modules/grouping/src/test/org/apache/lucene/search/grouping/AbstractGroupingTestCase.java
Modified: lucene/dev/trunk/lucene/common-build.xml
URL:
http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/common-build.xml?rev=1298287r1=1298286r2=1298287view=diff
==
--- lucene/dev/trunk/lucene/common-build.xml (original)
+++ lucene/dev/trunk/lucene/common-build.xml Thu Mar 8 07:57:51 2012
@@ -170,7 +170,7 @@
property name=junit.output.dir.backwards
location=${build.dir.backwards}/test/
property name=junit.reports location=${build.dir}/test/reports/
property name=junit.reports.backwards
location=${build.dir.backwards}/test/reports/
- property name=junit.excludes value=/
+ property name=junit.excludes value=**/Abstract*/
condition property=junit.details.formatter
value=org.apache.tools.ant.taskdefs.optional.junit.BriefJUnitResultFormatter
else=org.apache.lucene.util.LuceneJUnitResultFormatter
Modified:
lucene/dev/trunk/modules/grouping/src/test/org/apache/lucene/search/grouping/AbstractGroupingTestCase.java
URL:
http://svn.apache.org/viewvc/lucene/dev/trunk/modules/grouping/src/test/org/apache/lucene/search/grouping/AbstractGroupingTestCase.java?rev=1298287r1=1298286r2=1298287view=diff
==
---
lucene/dev/trunk/modules/grouping/src/test/org/apache/lucene/search/grouping/AbstractGroupingTestCase.java
(original)
+++ lucene/dev/trunk/modules/grouping/src/test/org/apache/lucene/search/
+++ grouping/AbstractGroupingTestCase.java Thu Mar 8 07:57:51 2012
@@ -17,30 +17,14 @@ package org.apache.lucene.search.groupin
* limitations under the License.
*/
-import org.apache.lucene.document.Field; -import
org.apache.lucene.document.FieldType;
-import org.apache.lucene.search.Sort;
-import org.apache.lucene.search.SortField;
-import org.apache.lucene.util.BytesRef; import
org.apache.lucene.util.LuceneTestCase;
import org.apache.lucene.util._TestUtil; -import org.junit.Ignore;
-
-import java.util.ArrayList;
-import java.util.Comparator;
-import java.util.List;
-import java.util.Random;
-
-import static org.junit.Assert.assertEquals; -import static
org.junit.Assert.fail;
/**
* Base class for grouping related tests.
*/
// TODO (MvG) : The grouping tests contain a lot of code duplication. Try to
move the common code to this class..
-@Ignore(Maven Surefire will attempt to run this test suite without an @Ignore
annotation.) -public class AbstractGroupingTestCase extends LuceneTestCase {
-
+public abstract class AbstractGroupingTestCase extends LuceneTestCase {
protected String generateRandomNonEmptyString() {
String randomValue;
do {
@@ -50,5 +34,4 @@ public class AbstractGroupingTestCase ex
} while (.equals(randomValue));
return randomValue;
}
-
}
Re: TestStressNRT failures.
I also don't get any failures. I ran the test on a linux box (latest checkout) and with -Dtests.iter=1000 Martijn On 8 March 2012 13:45, Erick Erickson erickerick...@gmail.com wrote: Not a linux box, but -Dtests.iter=1000 and no failures on my Macbook Pro. FWIW Erick On Wed, Mar 7, 2012 at 5:52 PM, Dawid Weiss dawid.we...@gmail.com wrote: https://issues.apache.org/jira/browse/LUCENE-3855 Ehm, either I'm going crazy or my machines are somehow different from anybody else's ;) If you have a spare cycle could you: cd lucene ant test-core -Dtestcase=TestStressNRT -Dtestmethod=test -Dtests.seed=69468941c1bbf693:19e66d58475da929:69e9d2f81769b6d0 -Dargs=-Dfile.encoding=UTF-8 A few times? In my case (a few different machines, different hardware, JVMs, but all Linuxes) the above yields errors in about 25-30% of executions. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Met vriendelijke groet, Martijn van Groningen
RE: TestStressNRT failures.
I let it run for 100 or so iterations in a shell while loop, and I got zero failures. This is on a Windows 7 box, 4 cores + HT (= OS thinks 8 cores). -Original Message- From: Erick Erickson [mailto:erickerick...@gmail.com] Sent: Thursday, March 08, 2012 7:45 AM To: dev@lucene.apache.org Subject: Re: TestStressNRT failures. Not a linux box, but -Dtests.iter=1000 and no failures on my Macbook Pro. FWIW Erick On Wed, Mar 7, 2012 at 5:52 PM, Dawid Weiss dawid.we...@gmail.com wrote: https://issues.apache.org/jira/browse/LUCENE-3855 Ehm, either I'm going crazy or my machines are somehow different from anybody else's ;) If you have a spare cycle could you: cd lucene ant test-core -Dtestcase=TestStressNRT -Dtestmethod=test -Dtests.seed=69468941c1bbf693:19e66d58475da929:69e9d2f81769b6d0 -Dargs=-Dfile.encoding=UTF-8 A few times? In my case (a few different machines, different hardware, JVMs, but all Linuxes) the above yields errors in about 25-30% of executions. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: TestStressNRT failures.
I also don't get any failures. I ran the test on a linux box (latest checkout) and with -Dtests.iter=1000 Did you run with any of the known failing seeds though? For example this one? -Dtests.seed=69468941c1bbf693:19e66d58475da929:69e9d2f81769b6d0 -Dargs=-Dfile.encoding=UTF-8 Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: TestStressNRT failures.
I let it run for 100 or so iterations in a shell while loop, and I got zero failures. I couldn't repeat it on a similar Windows box as well. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #417: POMs out of sync
Stdout/Stderr for this failure - n must be positive??? (Does not reproduce on my Windows 7 box, neither using the exact repro string below, nor adding -Dtests.iter=100): = Standard Output Thread-1065: hit exc java.lang.IllegalArgumentException: n must be positive at java.util.Random.nextInt(Random.java:265) at org.apache.lucene.index.ThreadedIndexingAndSearchingTestCase$2.run(ThreadedIndexingAndSearchingTestCase.java:360) Standard Error NOTE: Using no memory expensive codecs (Memory, SimpleText) for TestNRTManager. NOTE: reproduce with: ant test -Dtestcase=TestNRTManager -Dtestmethod=testNRTManager -Dtests.seed=3136e2201aee314e:-5c2cfc618a3a106b:-40af97ad3a3e225c -Dargs=-Dfile.encoding=ISO8859-1 = -Original Message- From: Apache Jenkins Server [mailto:jenk...@builds.apache.org] Sent: Wednesday, March 07, 2012 10:44 AM To: dev@lucene.apache.org Subject: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #417: POMs out of sync Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/417/ 1 tests failed. REGRESSION: org.apache.lucene.search.TestNRTManager.testNRTManager Error Message: null Stack Trace: java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.junit.Assert.assertFalse(Assert.java:79) at org.apache.lucene.index.ThreadedIndexingAndSearchingTestCase.runTest(ThreadedIndexingAndSearchingTestCase.java:519) at org.apache.lucene.search.TestNRTManager.testNRTManager(TestNRTManager.java:53) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at
Re: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #417: POMs out of sync
I'll fix... thanks Steven! Mike McCandless http://blog.mikemccandless.com On Thu, Mar 8, 2012 at 8:42 AM, Steven A Rowe sar...@syr.edu wrote: Stdout/Stderr for this failure - n must be positive??? (Does not reproduce on my Windows 7 box, neither using the exact repro string below, nor adding -Dtests.iter=100): = Standard Output Thread-1065: hit exc java.lang.IllegalArgumentException: n must be positive at java.util.Random.nextInt(Random.java:265) at org.apache.lucene.index.ThreadedIndexingAndSearchingTestCase$2.run(ThreadedIndexingAndSearchingTestCase.java:360) Standard Error NOTE: Using no memory expensive codecs (Memory, SimpleText) for TestNRTManager. NOTE: reproduce with: ant test -Dtestcase=TestNRTManager -Dtestmethod=testNRTManager -Dtests.seed=3136e2201aee314e:-5c2cfc618a3a106b:-40af97ad3a3e225c -Dargs=-Dfile.encoding=ISO8859-1 = -Original Message- From: Apache Jenkins Server [mailto:jenk...@builds.apache.org] Sent: Wednesday, March 07, 2012 10:44 AM To: dev@lucene.apache.org Subject: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #417: POMs out of sync Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/417/ 1 tests failed. REGRESSION: org.apache.lucene.search.TestNRTManager.testNRTManager Error Message: null Stack Trace: java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.junit.Assert.assertFalse(Assert.java:79) at org.apache.lucene.index.ThreadedIndexingAndSearchingTestCase.runTest(ThreadedIndexingAndSearchingTestCase.java:519) at org.apache.lucene.search.TestNRTManager.testNRTManager(TestNRTManager.java:53) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
Re: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #417: POMs out of sync
Stdout/Stderr for this failure - n must be positive??? (Does not reproduce on my Windows 7 box, neither using the exact repro string below, nor adding -Dtests.iter=100): Has to be 0 for nextInt; apparently it's 0. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3140) Make omitNorms default for all numeric field types
[ https://issues.apache.org/jira/browse/SOLR-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-3140: -- Attachment: SOLR-3140.patch New patch with tests. Gonna commit and backport Make omitNorms default for all numeric field types -- Key: SOLR-3140 URL: https://issues.apache.org/jira/browse/SOLR-3140 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Assignee: Jan Høydahl Labels: omitNorms Fix For: 3.6, 4.0 Attachments: SOLR-3140.patch, SOLR-3140.patch, SOLR-3140.patch Today norms are enabled for all Solr field types by default, while in Lucene norms are omitted for the numeric types. Propose to make the Solr defaults the same as in Lucene, so that if someone occasionally wants index-side boost for a numeric field type they must say omitNorms=false. This lets us simplify the example schema too. -- 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-3631) Remove write access from SegmentReader and possibly move to separate class or IndexWriter/BufferedDeletes/...
[ https://issues.apache.org/jira/browse/LUCENE-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225210#comment-13225210 ] Aliaksandr Zhuhrou commented on LUCENE-3631: Guys, is it possible in a current implementation to update the doc values fields without re-indexing a whole document? Remove write access from SegmentReader and possibly move to separate class or IndexWriter/BufferedDeletes/... - Key: LUCENE-3631 URL: https://issues.apache.org/jira/browse/LUCENE-3631 Project: Lucene - Java Issue Type: Task Components: core/index Affects Versions: 4.0 Reporter: Uwe Schindler Assignee: Michael McCandless Attachments: LUCENE-3631-threadlocals.patch, LUCENE-3631.patch, LUCENE-3631.patch After LUCENE-3606 is finished, there are some TODOs: SegmentReader still contains (package-private) all delete logic including crazy copyOnWrite for validDocs Bits. It would be good, if SegmentReader itsself could be read-only like all other IndexReaders. There are two possibilities to do this: # the simple one: Subclass SegmentReader and make a RWSegmentReader that is only used by IndexWriter/BufferedDeletes/... DirectoryReader will only use the read-only SegmentReader. This would move all TODOs to a separate class. It's reopen/clone method would always create a RO-SegmentReader (for NRT). # Remove all write and commit stuff from SegmentReader completely and move it to IndexWriter's readerPool (it must be in readerPool as deletions need a not-changing view on an index snapshot). Unfortunately the code is so complicated and I have no real experience in those internals of IndexWriter so I did not want to do it with LUCENE-3606, I just separated the code in SegmentReader and marked with TODO. Maybe Mike McCandless can help :-) -- 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] [Assigned] (LUCENE-3855) TestStressNRT failures (reproducible)
[
https://issues.apache.org/jira/browse/LUCENE-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-3855:
--
Assignee: Michael McCandless
TestStressNRT failures (reproducible)
-
Key: LUCENE-3855
URL: https://issues.apache.org/jira/browse/LUCENE-3855
Project: Lucene - Java
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Michael McCandless
Priority: Minor
Fix For: 4.0
Attachments: output1.log, output2.log, output3.log, output4.log
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.init(TermInfosReader.java:112)
[junit] at
org.apache.lucene.codecs.lucene3x.Lucene3xFields.init(Lucene3xFields.java:84)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat$1.init(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat.fieldsProducer(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:108)
[junit] at
org.apache.lucene.index.SegmentReader.init(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:
[jira] [Commented] (LUCENE-3855) TestStressNRT failures (reproducible)
[
https://issues.apache.org/jira/browse/LUCENE-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225229#comment-13225229
]
Michael McCandless commented on LUCENE-3855:
Hmm... compounding problems here is that, somehow, an exception is occurring in
a CMS merge thread, yet is never reported by the test runner. I hit a fail,
and only got this:
{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=Australia/LHI
[junit] NOTE: all tests run in this JVM:
[junit] [TestStressNRT]
[junit] NOTE: Linux 2.6.33.6-147.fc13.x86_64 amd64/Sun Microsystems Inc.
1.6.0_21 (64-bit)/cpus=24,threads=1,free=257856112,total=285933568
[junit] - ---
[junit] Testcase: test(org.apache.lucene.index.TestStressNRT): FAILED
[junit] info=_fu(4.0):C11/1 isn't live
[junit] junit.framework.AssertionFailedError: info=_fu(4.0):C11/1 isn't live
[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] at
org.apache.lucene.index.IndexWriter$ReaderPool.infoIsLive(IndexWriter.java:663)
[junit] at
org.apache.lucene.index.IndexWriter$ReaderPool.dropAll(IndexWriter.java:717)
[junit] at
org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1137)
[junit] at
org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1069)
[junit] at
org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1033)
[junit] at
org.apache.lucene.index.RandomIndexWriter.close(RandomIndexWriter.java:408)
[junit] at
org.apache.lucene.index.TestStressNRT.test(TestStressNRT.java:386)
[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]
[junit]
{noformat}
I also separately added a SOP to ConcurrentMergeScheduler.handleMergeException
and we are calling that... yet something is not then reporting this exception.
However: I made a silly small test case that spawns a thread that throws an
exception from its run method, and when I run that indeed I see the unhandled
exception from thread. So I'm not sure why exceptions in CMS threads in
particular are not being reported...
TestStressNRT failures (reproducible)
-
Key: LUCENE-3855
URL: https://issues.apache.org/jira/browse/LUCENE-3855
Project: Lucene - Java
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Michael McCandless
Priority: Minor
Fix For: 4.0
Attachments: output1.log, output2.log, output3.log, output4.log
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
[jira] [Created] (LUCENE-3857) exceptions from other threads in beforeclass/etc do not fail the test
exceptions from other threads in beforeclass/etc do not fail the test
-
Key: LUCENE-3857
URL: https://issues.apache.org/jira/browse/LUCENE-3857
Project: Lucene - Java
Issue Type: Task
Reporter: Robert Muir
Lots of tests create indexes in beforeClass methods, but if an exception is
thrown from another thread
it won't fail the test... e.g. this test passes:
{code}
public class TestExc extends LuceneTestCase {
@BeforeClass
public static void beforeClass() {
new Thread() {
public void run() {
throw new RuntimeException(boo!);
}
}.start();
}
public void test() { }
}
{code}
this is because the uncaught exception handler is in setup/teardown
--
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-3857) exceptions from other threads in beforeclass/etc do not fail the test
[
https://issues.apache.org/jira/browse/LUCENE-3857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225237#comment-13225237
]
Dawid Weiss commented on LUCENE-3857:
-
This is solved by 3808 but I can also fix it on the trunk if you need a
temporary fix.
exceptions from other threads in beforeclass/etc do not fail the test
-
Key: LUCENE-3857
URL: https://issues.apache.org/jira/browse/LUCENE-3857
Project: Lucene - Java
Issue Type: Task
Reporter: Robert Muir
Lots of tests create indexes in beforeClass methods, but if an exception is
thrown from another thread
it won't fail the test... e.g. this test passes:
{code}
public class TestExc extends LuceneTestCase {
@BeforeClass
public static void beforeClass() {
new Thread() {
public void run() {
throw new RuntimeException(boo!);
}
}.start();
}
public void test() { }
}
{code}
this is because the uncaught exception handler is in setup/teardown
--
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] [Assigned] (LUCENE-3857) exceptions from other threads in beforeclass/etc do not fail the test
[
https://issues.apache.org/jira/browse/LUCENE-3857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss reassigned LUCENE-3857:
---
Assignee: Dawid Weiss
exceptions from other threads in beforeclass/etc do not fail the test
-
Key: LUCENE-3857
URL: https://issues.apache.org/jira/browse/LUCENE-3857
Project: Lucene - Java
Issue Type: Task
Reporter: Robert Muir
Assignee: Dawid Weiss
Lots of tests create indexes in beforeClass methods, but if an exception is
thrown from another thread
it won't fail the test... e.g. this test passes:
{code}
public class TestExc extends LuceneTestCase {
@BeforeClass
public static void beforeClass() {
new Thread() {
public void run() {
throw new RuntimeException(boo!);
}
}.start();
}
public void test() { }
}
{code}
this is because the uncaught exception handler is in setup/teardown
--
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-3855) TestStressNRT failures (reproducible)
[
https://issues.apache.org/jira/browse/LUCENE-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225241#comment-13225241
]
Dawid Weiss commented on LUCENE-3855:
-
I'll fix this, Mike.
TestStressNRT failures (reproducible)
-
Key: LUCENE-3855
URL: https://issues.apache.org/jira/browse/LUCENE-3855
Project: Lucene - Java
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Michael McCandless
Priority: Minor
Fix For: 4.0
Attachments: output1.log, output2.log, output3.log, output4.log
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.init(TermInfosReader.java:112)
[junit] at
org.apache.lucene.codecs.lucene3x.Lucene3xFields.init(Lucene3xFields.java:84)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat$1.init(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat.fieldsProducer(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:108)
[junit] at
org.apache.lucene.index.SegmentReader.init(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
[jira] [Commented] (LUCENE-3855) TestStressNRT failures (reproducible)
[
https://issues.apache.org/jira/browse/LUCENE-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225242#comment-13225242
]
Dawid Weiss commented on LUCENE-3855:
-
And by this I mean LUCENE-3857.
TestStressNRT failures (reproducible)
-
Key: LUCENE-3855
URL: https://issues.apache.org/jira/browse/LUCENE-3855
Project: Lucene - Java
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Michael McCandless
Priority: Minor
Fix For: 4.0
Attachments: output1.log, output2.log, output3.log, output4.log
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.init(TermInfosReader.java:112)
[junit] at
org.apache.lucene.codecs.lucene3x.Lucene3xFields.init(Lucene3xFields.java:84)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat$1.init(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat.fieldsProducer(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:108)
[junit] at
org.apache.lucene.index.SegmentReader.init(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
[jira] [Commented] (LUCENE-3855) TestStressNRT failures (reproducible)
[
https://issues.apache.org/jira/browse/LUCENE-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225250#comment-13225250
]
Michael McCandless commented on LUCENE-3855:
Thanks Dawid! I'm not sure LUCENE-3857 is what I'm hitting (this test doesn't
have a @beforeClass).
One more piece of data: sometimes the CMS exception *is* printed in the
unhandled exceptions output... so it's somehow intermittant. Hmm, it could
be... the main thread threw its exc before CMS thread did? Odd, though,
because IW closes CMS first (which should join to all outstanding threads),
before hitting the exc in main thread. Still baffled...
Anyway it's not a blocker for me... I'm printing the exc in CMS.handleExc.
TestStressNRT failures (reproducible)
-
Key: LUCENE-3855
URL: https://issues.apache.org/jira/browse/LUCENE-3855
Project: Lucene - Java
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Michael McCandless
Priority: Minor
Fix For: 4.0
Attachments: output1.log, output2.log, output3.log, output4.log
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.init(TermInfosReader.java:112)
[junit] at
org.apache.lucene.codecs.lucene3x.Lucene3xFields.init(Lucene3xFields.java:84)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat$1.init(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat.fieldsProducer(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:108)
[junit] at
org.apache.lucene.index.SegmentReader.init(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
[jira] [Updated] (SOLR-3140) Make omitNorms default for all numeric field types
[ https://issues.apache.org/jira/browse/SOLR-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-3140: -- Attachment: SOLR-3140-3x.patch Patch for branch_3x Make omitNorms default for all numeric field types -- Key: SOLR-3140 URL: https://issues.apache.org/jira/browse/SOLR-3140 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Assignee: Jan Høydahl Labels: omitNorms Fix For: 3.6, 4.0 Attachments: SOLR-3140-3x.patch, SOLR-3140.patch, SOLR-3140.patch, SOLR-3140.patch Today norms are enabled for all Solr field types by default, while in Lucene norms are omitted for the numeric types. Propose to make the Solr defaults the same as in Lucene, so that if someone occasionally wants index-side boost for a numeric field type they must say omitNorms=false. This lets us simplify the example schema too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3140) Make omitNorms default for all numeric field types
[ https://issues.apache.org/jira/browse/SOLR-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-3140. --- Resolution: Fixed Committed in trunk, merged to 3x Make omitNorms default for all numeric field types -- Key: SOLR-3140 URL: https://issues.apache.org/jira/browse/SOLR-3140 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Assignee: Jan Høydahl Labels: omitNorms Fix For: 3.6, 4.0 Attachments: SOLR-3140-3x.patch, SOLR-3140.patch, SOLR-3140.patch, SOLR-3140.patch Today norms are enabled for all Solr field types by default, while in Lucene norms are omitted for the numeric types. Propose to make the Solr defaults the same as in Lucene, so that if someone occasionally wants index-side boost for a numeric field type they must say omitNorms=false. This lets us simplify the example schema too. -- 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-3855) TestStressNRT failures (reproducible)
[
https://issues.apache.org/jira/browse/LUCENE-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225265#comment-13225265
]
Dawid Weiss commented on LUCENE-3855:
-
bq. I'm not sure LUCENE-3857 is what I'm hitting (this test doesn't have a
@beforeClass).
No, I don't think it is. But I'll fix that issue anyway.
bq. One more piece of data: sometimes the CMS exception is printed in the
unhandled exceptions output... so it's somehow intermittant.
This is really messy in the current LTC. I'll try to do something about it.
TestStressNRT failures (reproducible)
-
Key: LUCENE-3855
URL: https://issues.apache.org/jira/browse/LUCENE-3855
Project: Lucene - Java
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Michael McCandless
Priority: Minor
Fix For: 4.0
Attachments: output1.log, output2.log, output3.log, output4.log
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.init(TermInfosReader.java:112)
[junit] at
org.apache.lucene.codecs.lucene3x.Lucene3xFields.init(Lucene3xFields.java:84)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat$1.init(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat.fieldsProducer(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:108)
[junit] at
org.apache.lucene.index.SegmentReader.init(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}
--
[jira] [Commented] (SOLR-1856) In Solr Cell, literals should override Tika-parsed values
[ https://issues.apache.org/jira/browse/SOLR-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225292#comment-13225292 ] Ravish Bhagdev commented on SOLR-1856: -- This will be very useful. In Solr Cell, literals should override Tika-parsed values - Key: SOLR-1856 URL: https://issues.apache.org/jira/browse/SOLR-1856 Project: Solr Issue Type: Improvement Components: contrib - Solr Cell (Tika extraction) Affects Versions: 1.4 Reporter: Chris Harris Attachments: SOLR-1856.patch I propose that ExtractingRequestHandler / SolrCell literals should take precedence over Tika-parsed metadata in all situations, including where multiValued=true. (Compare SOLR-1633?) My personal motivation is that I have several fields (e.g. title, date) where my own metadata is much superior to what Tika offers, and I want to throw those Tika values away. (I actually wouldn't mind throwing away _all_ Tika-parsed values, but let's set that aside.) SOLR-1634 is one potential approach to this, but the fix here might be simpler. I'll attach a patch shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3850) Fix rawtypes warnings for Java 7 compiler
[
https://issues.apache.org/jira/browse/LUCENE-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225313#comment-13225313
]
Uwe Schindler commented on LUCENE-3850:
---
bq. warning: [options] bootstrap class path not set in conjunction with -source
1.6
Its because you are compiling the code with Java 7 but using 1.6 compatibility.
Previous versions did not complain about that (e.g. compiling 1.5 code with
1.6). This warning simply says, that you should have a different bootstrap
classpath with only the 1.6 JDK rt.jar in it, so the compiler can check that
the methods/classes you are using are really existing. If you compoile against
Java 7's rt.jar this is not guaranteed.
The warning is obsolete for us, as we also check java 6 and java 5 (for 3.x).
Fix rawtypes warnings for Java 7 compiler
-
Key: LUCENE-3850
URL: https://issues.apache.org/jira/browse/LUCENE-3850
Project: Lucene - Java
Issue Type: Improvement
Affects Versions: 3.5, 4.0
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 3.6, 4.0
Attachments: LUCENE-3850-part1-branch3x.patch,
LUCENE-3850-part1.patch, LUCENE-3850-part2.patch,
LUCENE-3850-parts2-branch3x.patch
Java 7 changed the warnings a little bit:
- Java 6 only knew unchecked warning type, applying for all types of
generics violations, like missing generics (raw types)
- Java 7 still knows unchecked but only emits warning if the call is really
unchecked. Declaration of variables/fields or constructing instances without
type param now emits rawtypes warning.
The changes above causes the Java 7 compile now emit lots of rawtypes
warnings, where Java 6 is silent. The easy fix is to suppres both warning
types: @SuppressWarnings({unchecked,rawtypes}) for all those places.
Changes are easy to do, will provide patch later!
--
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
Re: TestStressNRT failures.
I got a failure on second run:
[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=JST
[junit] NOTE: all tests run in this JVM:
[junit] [TestStressNRT]
[junit] NOTE: Linux 2.6.42.3-2.fc15.x86_64 amd64/Sun Microsystems
Inc. 1.6.0_25 (64-bit)/cpus=4,threads=1,free=92473168,total=165806080
[junit] - ---
[junit] Testcase:
test(org.apache.lucene.index.TestStressNRT):Caused an ERROR
[junit] MockDirectoryWrapper: cannot close: there are still open
files: {_a6.frq=1, _a6.fdx=1, _a6.fdt=1, _a6.tis=1}
[junit] java.lang.RuntimeException: MockDirectoryWrapper: cannot
close: there are still open files: {_a6.frq=1, _a6.fdx=1, _a6.fdt=1,
_a6.tis=1}
[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: _a6.tis
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:479)
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:504)
[junit] at
org.apache.lucene.codecs.lucene3x.TermInfosReader.init(TermInfosReader.java:112)
[junit] at
org.apache.lucene.codecs.lucene3x.Lucene3xFields.init(Lucene3xFields.java:84)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat$1.init(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat.fieldsProducer(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:108)
[junit] at
org.apache.lucene.index.SegmentReader.init(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
--
Sami Siren
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: TestStressNRT failures.
The test seems to fail in different ways, here's couple more examples:
[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=JST
[junit] NOTE: all tests run in this JVM:
[junit] [TestStressNRT]
[junit] NOTE: Linux 2.6.42.3-2.fc15.x86_64 amd64/Sun Microsystems
Inc. 1.6.0_25 (64-bit)/cpus=4,threads=1,free=104981544,total=194838528
[junit] - ---
[junit] Testcase:
test(org.apache.lucene.index.TestStressNRT):Caused an ERROR
[junit] MockDirectoryWrapper: cannot close: there are still open
files: {_27.frq=1, _27.tis=1, _27.fdt=1, _27.fdx=1, _27.tvx=1,
_eq.cfs=8, _27.tvd=1, _27.tvf=1}
[junit] java.lang.RuntimeException: MockDirectoryWrapper: cannot
close: there are still open files: {_27.frq=1, _27.tis=1, _27.fdt=1,
_27.fdx=1, _27.tvx=1, _eq.cfs=8, _27.tvd=1, _27.tvf=1}
[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: _27.frq
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:479)
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:504)
[junit] at
org.apache.lucene.codecs.lucene3x.Lucene3xFields.init(Lucene3xFields.java:96)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat$1.init(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat.fieldsProducer(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:108)
[junit] at
org.apache.lucene.index.SegmentReader.init(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
[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=JST
[junit] NOTE: all tests run in this JVM:
[junit] [TestStressNRT]
[junit] NOTE: Linux 2.6.42.3-2.fc15.x86_64 amd64/Sun Microsystems
Inc. 1.6.0_25 (64-bit)/cpus=4,threads=1,free=151905320,total=195821568
[junit] - ---
[junit] Testcase: test(org.apache.lucene.index.TestStressNRT): FAILED
[junit] info=_ir(4.0):Cv23/3 isn't live
[junit] junit.framework.AssertionFailedError: info=_ir(4.0):Cv23/3
isn't live
[junit] at
org.apache.lucene.index.IndexWriter$ReaderPool.infoIsLive(IndexWriter.java:663)
[junit] at
org.apache.lucene.index.IndexWriter$ReaderPool.dropAll(IndexWriter.java:717)
[junit] at
org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1136)
[junit] at
[jira] [Updated] (LUCENE-3855) TestStressNRT failures (reproducible)
[
https://issues.apache.org/jira/browse/LUCENE-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated LUCENE-3855:
-
Attachment:
hoss-r1298470-fixed-seed__TEST-org.apache.lucene.index.TestStressNRT.xml
attached file was generated using trunk r1298470 with the command...
{noformat}
X=0; while ant test-core -Dtestcase=TestStressNRT -Dtestmethod=test
-Dtests.seed=69468941c1bbf693:19e66d58475da929:69e9d2f81769b6d0
-Dargs=-Dfile.encoding=UTF-8; do X=$(($X+1)); echo Finished Loop $X; done;
echo TOTAL LOOPS: $X
{noformat}
the failure occured on loop #52
{noformat}
junit-sequential:
[junit] Testsuite: org.apache.lucene.index.TestStressNRT
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 5.082 sec
[junit]
[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=Asia/Thimphu
[junit] NOTE: all tests run in this JVM:
[junit] [TestStressNRT]
[junit] NOTE: Linux 2.6.31-23-generic amd64/Sun Microsystems Inc. 1.6.0_24
(64-bit)/cpus=2,threads=1,free=192293192,total=256966656
[junit] - ---
[junit] Testcase: test(org.apache.lucene.index.TestStressNRT): Caused
an ERROR
[junit] MockDirectoryWrapper: cannot close: there are still open files:
{_47.frq=1, _47.tis=1, _47.fdx=1, _47.fdt=1}
[junit] java.lang.RuntimeException: MockDirectoryWrapper: cannot close:
there are still open files: {_47.frq=1, _47.tis=1, _47.fdx=1, _47.fdt=1}
[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: _47.tis
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:479)
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:504)
[junit] at
org.apache.lucene.codecs.lucene3x.TermInfosReader.init(TermInfosReader.java:112)
[junit] at
org.apache.lucene.codecs.lucene3x.Lucene3xFields.init(Lucene3xFields.java:84)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat$1.init(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat.fieldsProducer(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:108)
[junit] at
org.apache.lucene.index.SegmentReader.init(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
BUILD FAILED
/home/hossman/lucene/dev/lucene/build.xml:43: The following error occurred
while executing this line:
/home/hossman/lucene/dev/lucene/common-build.xml:688: The following error
occurred while executing this line:
/home/hossman/lucene/dev/lucene/common-build.xml:677: Tests failed!
Total time: 8 seconds
TOTAL LOOPS: 52
{noformat}
TestStressNRT failures (reproducible)
Invalid xml
Hi all, I like your Solr tutorial located at http://lucene.apache.org/solr/tutorial.html However I think I found a bug: in order to delete a document specified by an id, the following command must be used: java -Ddata=args -Dcommit=no -jar post.jar deleteidSP2514N/id/delete instead of java -Ddata=args -Dcommit=no -jar post.jar deleteidSP2514N/id/delete (the after /id makes the xml invalid) Best regards Jan - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Invalid xml
: http://lucene.apache.org/solr/tutorial.html : : However I think I found a bug: in order to delete a document specified by an : id, the following command must be used: fixed, thanks for reporting (FYI: i already verified that the javadoc versions on 3x and trunk don't have this problem so this looks like a glitch when it was copied to the CMS) -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3209) solrj FieldStatsInfo can not assume Double
[ https://issues.apache.org/jira/browse/SOLR-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-3209. - Resolution: Fixed Assignee: Ryan McKinley solrj FieldStatsInfo can not assume Double -- Key: SOLR-3209 URL: https://issues.apache.org/jira/browse/SOLR-3209 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley Priority: Minor Fix For: 4.0 Attachments: SOLR-3209-FieldStatsInfo-object.patch Since SOLR-1023, the response from a stats request can be Number, Date, or even string. But FieldStatsInfo always assumes Double and will get a class cast exception. -- 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
Re: TestStressNRT failures.
The test seems to fail in different ways, here's couple more examples: Yes, it does. They all seem to be related to CMS though -- I attached a few stacks to the issue. Thanks for helping Sami (and everyone). Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 1917 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/1917/ 1 tests failed. REGRESSION: org.apache.solr.handler.component.StatsComponentTest.testFieldStatisticsResultsDateField Error Message: test date statistics values query failed XPath: //date[@name='sum'][.='1970-01-13T20:38:30Z'] xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime1/int /lst result name=response numFound=3 start=0 doc float name=id1.0/float date name=active_dt1970-01-02T10:17:36Z/date/doc doc float name=id2.0/float date name=active_dt1970-01-12T10:20:54Z/date/doc doc float name=id3.0/float/doc /result lst name=stats lst name=stats_fields lst name=active_dt date name=min1970-01-02T10:17:36Z/date date name=max1970-01-12T10:20:54Z/date long name=count2/long long name=missing1/long date name=sum1970-01-13T20:38:29.999Z/date date name=mean1970-01-07T10:19:14.999Z/date double name=sumOfSquares9.90701807652E17/double double name=stddev6.110802669969879E8/double /lst /lst /lst /response request was: indent=truestats.field=active_dtstats=trueq=*:* Stack Trace: junit.framework.AssertionFailedError: test date statistics values query failed XPath: //date[@name='sum'][.='1970-01-13T20:38:30Z'] xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime1/int /lst result name=response numFound=3 start=0 doc float name=id1.0/float date name=active_dt1970-01-02T10:17:36Z/date/doc doc float name=id2.0/float date name=active_dt1970-01-12T10:20:54Z/date/doc doc float name=id3.0/float/doc /result lst name=stats lst name=stats_fields lst name=active_dt date name=min1970-01-02T10:17:36Z/date date name=max1970-01-12T10:20:54Z/date long name=count2/long long name=missing1/long date name=sum1970-01-13T20:38:29.999Z/date date name=mean1970-01-07T10:19:14.999Z/date double name=sumOfSquares9.90701807652E17/double double name=stddev6.110802669969879E8/double /lst /lst /lst /response request was: indent=truestats.field=active_dtstats=trueq=*:* at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime1/int /lst result name=response numFound=3 start=0 doc float name=id1.0/float date name=active_dt1970-01-02T10:17:36Z/date/doc doc float name=id2.0/float date name=active_dt1970-01-12T10:20:54Z/date/doc doc float name=id3.0/float/doc /result lst name=stats lst name=stats_fields lst name=active_dt date name=min1970-01-02T10:17:36Z/date date name=max1970-01-12T10:20:54Z/date long name=count2/long long name=missing1/long date name=sum1970-01-13T20:38:29.999Z/date date name=mean1970-01-07T10:19:14.999Z/date double name=sumOfSquares9.90701807652E17/double double name=stddev6.110802669969879E8/double /lst /lst /lst /response request was: indent=truestats.field=active_dtstats=trueq=*:* at org.apache.solr.util.AbstractSolrTestCase.assertQ(AbstractSolrTestCase.java:276) at org.apache.solr.handler.component.StatsComponentTest.testFieldStatisticsResultsDateField(StatsComponentTest.java:195) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600) Build Log (for compile errors): [...truncated 8275 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 1917 - Failure
I'll fix in ~1 hour On Mar 8, 2012 11:57 AM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/1917/ 1 tests failed. REGRESSION: org.apache.solr.handler.component.StatsComponentTest.testFieldStatisticsResultsDateField Error Message: test date statistics values query failed XPath: //date[@name='sum'][.='1970-01-13T20:38:30Z'] xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime1/int /lst result name=response numFound=3 start=0 doc float name=id1.0/float date name=active_dt1970-01-02T10:17:36Z/date/doc doc float name=id2.0/float date name=active_dt1970-01-12T10:20:54Z/date/doc doc float name=id3.0/float/doc /result lst name=stats lst name=stats_fields lst name=active_dt date name=min1970-01-02T10:17:36Z/date date name=max1970-01-12T10:20:54Z/date long name=count2/long long name=missing1/long date name=sum1970-01-13T20:38:29.999Z/date date name=mean1970-01-07T10:19:14.999Z/date double name=sumOfSquares9.90701807652E17/double double name=stddev6.110802669969879E8/double /lst /lst /lst /response request was: indent=truestats.field=active_dtstats=trueq=*:* Stack Trace: junit.framework.AssertionFailedError: test date statistics values query failed XPath: //date[@name='sum'][.='1970-01-13T20:38:30Z'] xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime1/int /lst result name=response numFound=3 start=0 doc float name=id1.0/float date name=active_dt1970-01-02T10:17:36Z/date/doc doc float name=id2.0/float date name=active_dt1970-01-12T10:20:54Z/date/doc doc float name=id3.0/float/doc /result lst name=stats lst name=stats_fields lst name=active_dt date name=min1970-01-02T10:17:36Z/date date name=max1970-01-12T10:20:54Z/date long name=count2/long long name=missing1/long date name=sum1970-01-13T20:38:29.999Z/date date name=mean1970-01-07T10:19:14.999Z/date double name=sumOfSquares9.90701807652E17/double double name=stddev6.110802669969879E8/double /lst /lst /lst /response request was: indent=truestats.field=active_dtstats=trueq=*:* at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime1/int /lst result name=response numFound=3 start=0 doc float name=id1.0/float date name=active_dt1970-01-02T10:17:36Z/date/doc doc float name=id2.0/float date name=active_dt1970-01-12T10:20:54Z/date/doc doc float name=id3.0/float/doc /result lst name=stats lst name=stats_fields lst name=active_dt date name=min1970-01-02T10:17:36Z/date date name=max1970-01-12T10:20:54Z/date long name=count2/long long name=missing1/long date name=sum1970-01-13T20:38:29.999Z/date date name=mean1970-01-07T10:19:14.999Z/date double name=sumOfSquares9.90701807652E17/double double name=stddev6.110802669969879E8/double /lst /lst /lst /response request was: indent=truestats.field=active_dtstats=trueq=*:* at org.apache.solr.util.AbstractSolrTestCase.assertQ(AbstractSolrTestCase.java:276) at org.apache.solr.handler.component.StatsComponentTest.testFieldStatisticsResultsDateField(StatsComponentTest.java:195) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600) Build Log (for compile errors): [...truncated 8275 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12664 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12664/ 1 tests failed. REGRESSION: org.apache.solr.handler.component.StatsComponentTest.testFieldStatisticsResultsDateField Error Message: test date statistics values query failed XPath: //date[@name='sum'][.='1970-01-13T20:38:30Z'] xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime1/int /lst result name=response numFound=3 start=0 doc float name=id1.0/float date name=active_dt1970-01-02T10:17:36Z/date/doc doc float name=id2.0/float date name=active_dt1970-01-12T10:20:54Z/date/doc doc float name=id3.0/float/doc /result lst name=stats lst name=stats_fields lst name=active_dt date name=min1970-01-02T10:17:36Z/date date name=max1970-01-12T10:20:54Z/date long name=count2/long long name=missing1/long date name=sum1970-01-13T20:38:29.999Z/date date name=mean1970-01-07T10:19:14.999Z/date double name=sumOfSquares9.90701807652E17/double double name=stddev6.110802669969879E8/double /lst /lst /lst /response request was: indent=truestats.field=active_dtstats=trueq=*:* Stack Trace: junit.framework.AssertionFailedError: test date statistics values query failed XPath: //date[@name='sum'][.='1970-01-13T20:38:30Z'] xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime1/int /lst result name=response numFound=3 start=0 doc float name=id1.0/float date name=active_dt1970-01-02T10:17:36Z/date/doc doc float name=id2.0/float date name=active_dt1970-01-12T10:20:54Z/date/doc doc float name=id3.0/float/doc /result lst name=stats lst name=stats_fields lst name=active_dt date name=min1970-01-02T10:17:36Z/date date name=max1970-01-12T10:20:54Z/date long name=count2/long long name=missing1/long date name=sum1970-01-13T20:38:29.999Z/date date name=mean1970-01-07T10:19:14.999Z/date double name=sumOfSquares9.90701807652E17/double double name=stddev6.110802669969879E8/double /lst /lst /lst /response request was: indent=truestats.field=active_dtstats=trueq=*:* at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime1/int /lst result name=response numFound=3 start=0 doc float name=id1.0/float date name=active_dt1970-01-02T10:17:36Z/date/doc doc float name=id2.0/float date name=active_dt1970-01-12T10:20:54Z/date/doc doc float name=id3.0/float/doc /result lst name=stats lst name=stats_fields lst name=active_dt date name=min1970-01-02T10:17:36Z/date date name=max1970-01-12T10:20:54Z/date long name=count2/long long name=missing1/long date name=sum1970-01-13T20:38:29.999Z/date date name=mean1970-01-07T10:19:14.999Z/date double name=sumOfSquares9.90701807652E17/double double name=stddev6.110802669969879E8/double /lst /lst /lst /response request was: indent=truestats.field=active_dtstats=trueq=*:* at org.apache.solr.util.AbstractSolrTestCase.assertQ(AbstractSolrTestCase.java:276) at org.apache.solr.handler.component.StatsComponentTest.testFieldStatisticsResultsDateField(StatsComponentTest.java:195) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600) Build Log (for compile errors): [...truncated 7630 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Stefan Matheis
: Subject: Re: Welcome Stefan Matheis Stefan: I just noticed you aren't currently listed on the website... http://lucene.apache.org/whoweare.html I think Ryan forgot to mention that traditionally new committers add themselves to that list (it's typically your first commit to verify that SVN auth is working) now that the website uses the CMS, it's fairly trivial using the bookmarklet... http://lucene.apache.org/site-instructions.html -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225485#comment-13225485 ] Chris A. Mattmann commented on LUCENE-3795: --- bq. It looks like SIS is not even off the ground yet. I guess if you call making an Apache release, with a working Java Quad Tree implementation, point-radius and bounding box against that QuadTree, the ability to load GeoRSS, and a demo webapp that plugs into Google Maps, not even off the ground yet, then yeah, I guess it's not. Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- 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] (SOLR-2202) Money FieldType
[
https://issues.apache.org/jira/browse/SOLR-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225493#comment-13225493
]
Hoss Man commented on SOLR-2202:
a) CurrencyField (and by extension CurrencyValue) gets my vote
b) i really only reviewed the facet stuff in SOLR-2202-solr-10.patch (i know
Jan has already been reviewing the more core stuff about the type) ... it makes
me realize that we really need to refactor the range faceting code to be easier
to do in custom FieldTypes, but that's certainly no fault of this issue and can
be done later.
The facet code itself looks correct but my one concern is that (if i'm
understanding all of this MoneyValue conversion stuff correctly) it _should_ be
possible to facet with start/end/gap values specified in any currency, as long
as they are all consistent -- but there is not test of this situation. the
negative test only looks at using an inconsistent gap, and the positive tests
only use USD, or the default which is also USD. We should have at least one
test that uses something like EUR for start/end/gap and verifies that the
counts are correct given the conversion rates used in the test.
incidentally: I don't see anything actually enforcing that start/end are in the
same currency -- just that gap is in the same currency as the values it's being
added to, so essentially that start and gap use hte same currenty. But I'm
actually not at all clear on why there is any attempt to enforce that the
currencies used are the same, since the whole point of the type (as i
understand it) is that you can do conversions on the fly -- it may seem silly
for someone to say {{facet.range.start=0,USD facet.range.gap=200,EUR
facet.range.end=1000,YEN}} but is there any technical reason why we can't let
them do that?
Money FieldType
---
Key: SOLR-2202
URL: https://issues.apache.org/jira/browse/SOLR-2202
Project: Solr
Issue Type: New Feature
Components: Schema and Analysis
Affects Versions: 1.5
Reporter: Greg Fodor
Assignee: Jan Høydahl
Fix For: 3.6, 4.0
Attachments: SOLR-2022-solr-3.patch, SOLR-2202-lucene-1.patch,
SOLR-2202-solr-1.patch, SOLR-2202-solr-10.patch, SOLR-2202-solr-2.patch,
SOLR-2202-solr-4.patch, SOLR-2202-solr-5.patch, SOLR-2202-solr-6.patch,
SOLR-2202-solr-7.patch, SOLR-2202-solr-8.patch, SOLR-2202-solr-9.patch,
SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch
Provides support for monetary values to Solr/Lucene with query-time currency
conversion. The following features are supported:
- Point queries
- Range quries
- Sorting
- Currency parsing by either currency code or symbol.
- Symmetric Asymmetric exchange rates. (Asymmetric exchange rates are
useful if there are fees associated with exchanging the currency.)
At indexing time, money fields can be indexed in a native currency. For
example, if a product on an e-commerce site is listed in Euros, indexing the
price field as 1000,EUR will index it appropriately. By altering the
currency.xml file, the sorting and querying against Solr can take into
account fluctuations in currency exchange rates without having to re-index
the documents.
The new money field type is a polyfield which indexes two fields, one which
contains the amount of the value and another which contains the currency code
or symbol. The currency metadata (names, symbols, codes, and exchange rates)
are expected to be in an xml file which is pointed to by the field type
declaration in the schema.xml.
The current patch is factored such that Money utility functions and
configuration metadata lie in Lucene (see MoneyUtil and CurrencyConfig),
while the MoneyType and MoneyValueSource lie in Solr. This was meant to
mirror the work being done on the spacial field types.
This patch will be getting used to power the international search
capabilities of the search engine at Etsy.
Also see WIKI page: http://wiki.apache.org/solr/MoneyFieldType
--
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-3857) exceptions from other threads in beforeclass/etc do not fail the test
[
https://issues.apache.org/jira/browse/LUCENE-3857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-3857:
Attachment: LUCENE-3857.patch
A patch against the trunk extracting uncaught exceptions management to a class
and test rule.
There are tiny differences to previous implementations -- the exception is
logged to stderr at the time it is thrown and parent handler is NOT invoked
(because it'd cause double detection and the default handler's job is only to
dump the stack).
I will commit immediately?
exceptions from other threads in beforeclass/etc do not fail the test
-
Key: LUCENE-3857
URL: https://issues.apache.org/jira/browse/LUCENE-3857
Project: Lucene - Java
Issue Type: Task
Reporter: Robert Muir
Assignee: Dawid Weiss
Attachments: LUCENE-3857.patch
Lots of tests create indexes in beforeClass methods, but if an exception is
thrown from another thread
it won't fail the test... e.g. this test passes:
{code}
public class TestExc extends LuceneTestCase {
@BeforeClass
public static void beforeClass() {
new Thread() {
public void run() {
throw new RuntimeException(boo!);
}
}.start();
}
public void test() { }
}
{code}
this is because the uncaught exception handler is in setup/teardown
--
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-3217) refactor range faceting code so that the list of FieldTypes supported isn't hardcoded
refactor range faceting code so that the list of FieldTypes supported isn't
hardcoded
-
Key: SOLR-3217
URL: https://issues.apache.org/jira/browse/SOLR-3217
Project: Solr
Issue Type: Improvement
Reporter: Hoss Man
idea that occured to me reviewing SOLR-2202, haven't thought it through all the
way to be certain it would work...
1) create a new marker interface RangeFacetable which contains a single
method {{getRangeEndpointCalculator(SchemaField)}}
2) refactor SimpleFacets so that instead of the big {{if (ft instanceof ...) {
... } else if }} block there right now, we just check if the FieldType is
an instance of RangeFacetable
3) use ft.getRangeEndpointCalculator to do the voodoo we curently doodoo
4) make all of the existing {{private static}} subclasses of
RangeEndpointCalculator (like IntegerRangeEndpointCalculator) public top level
classes so custom FieldTypes can use them
--
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] [Reopened] (SOLR-3216) Solr logo missing from /browse GUI
[ https://issues.apache.org/jira/browse/SOLR-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl reopened SOLR-3216: --- More bugs related to removing old /admin Solr logo missing from /browse GUI -- Key: SOLR-3216 URL: https://issues.apache.org/jira/browse/SOLR-3216 Project: Solr Issue Type: Bug Components: Response Writers Reporter: Jan Høydahl Priority: Trivial Fix For: 4.0 A refactoring obviously removed webapp/web/admin/solr_small.png, used by Velocity templates. We should switch to webapp/web/img/solr.png -- 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-3855) TestStressNRT failures (reproducible)
[
https://issues.apache.org/jira/browse/LUCENE-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225517#comment-13225517
]
Dawid Weiss commented on LUCENE-3855:
-
Mike, would it help if we dumped a linear sequence of each thread's ops on
indexwriter/ segmentinfos, whatever else? If you can tell me which classes and
methods would be of interest then I can provide such dumps with relative ease
(using an aspect or even hardcoded printlns).
Alternatively, can you express certain assertions that should always hold wrt
multi-threaded access? I mean something that I could try to weave into the code
so that we can catch an abnormal interaction pattern while it's happening (as
opposed just seing the result)?
TestStressNRT failures (reproducible)
-
Key: LUCENE-3855
URL: https://issues.apache.org/jira/browse/LUCENE-3855
Project: Lucene - Java
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Michael McCandless
Priority: Minor
Fix For: 4.0
Attachments:
hoss-r1298470-fixed-seed__TEST-org.apache.lucene.index.TestStressNRT.xml,
output1.log, output2.log, output3.log, output4.log
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.init(TermInfosReader.java:112)
[junit] at
org.apache.lucene.codecs.lucene3x.Lucene3xFields.init(Lucene3xFields.java:84)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat$1.init(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat.fieldsProducer(PreFlexRWPostingsFormat.java:51)
[junit] at
org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:108)
[junit] at
org.apache.lucene.index.SegmentReader.init(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
[jira] [Updated] (SOLR-3216) Velcity /browse GUI broken by removal of old admin
[ https://issues.apache.org/jira/browse/SOLR-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-3216: -- Description: The removal of old admin obviously removed webapp/web/admin including solr_small.png and jquery-1.4.3.min.js, used by Velocity templates. (was: A refactoring obviously removed webapp/web/admin/solr_small.png, used by Velocity templates. We should switch to webapp/web/img/solr.png) Summary: Velcity /browse GUI broken by removal of old admin (was: Solr logo missing from /browse GUI) Velcity /browse GUI broken by removal of old admin -- Key: SOLR-3216 URL: https://issues.apache.org/jira/browse/SOLR-3216 Project: Solr Issue Type: Bug Components: Response Writers Reporter: Jan Høydahl Priority: Trivial Fix For: 4.0 The removal of old admin obviously removed webapp/web/admin including solr_small.png and jquery-1.4.3.min.js, used by Velocity templates. -- 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] (SOLR-3216) Velcity /browse GUI broken by removal of old admin
[ https://issues.apache.org/jira/browse/SOLR-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225523#comment-13225523 ] Jan Høydahl commented on SOLR-3216: --- The logo is fixed, replaced with webapp/web/img/solr.png What can we use to replace jquery-1.4.3.min.js Velcity /browse GUI broken by removal of old admin -- Key: SOLR-3216 URL: https://issues.apache.org/jira/browse/SOLR-3216 Project: Solr Issue Type: Bug Components: Response Writers Reporter: Jan Høydahl Priority: Trivial Fix For: 4.0 The removal of old admin obviously removed webapp/web/admin including solr_small.png and jquery-1.4.3.min.js, used by Velocity templates. -- 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] (SOLR-3216) Velcity /browse GUI broken by removal of old admin
[ https://issues.apache.org/jira/browse/SOLR-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-3216: -- Priority: Critical (was: Trivial) Uppering to Critical since the velocity contrib actually is broken Velcity /browse GUI broken by removal of old admin -- Key: SOLR-3216 URL: https://issues.apache.org/jira/browse/SOLR-3216 Project: Solr Issue Type: Bug Components: Response Writers Reporter: Jan Høydahl Priority: Critical Fix For: 4.0 The removal of old admin obviously removed webapp/web/admin including solr_small.png and jquery-1.4.3.min.js, used by Velocity templates. -- 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
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12665 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12665/ 1 tests failed. FAILED: org.apache.solr.handler.component.StatsComponentTest.testFieldStatisticsResultsDateField Error Message: test date statistics values query failed XPath: //date[@name='sum'][.='1970-01-13T20:38:30Z'] xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime0/int /lst result name=response numFound=3 start=0 doc float name=id1.0/float date name=active_dt1970-01-02T10:17:36Z/date/doc doc float name=id2.0/float date name=active_dt1970-01-12T10:20:54Z/date/doc doc float name=id3.0/float/doc /result lst name=stats lst name=stats_fields lst name=active_dt date name=min1970-01-02T10:17:36Z/date date name=max1970-01-12T10:20:54Z/date long name=count2/long long name=missing1/long date name=sum1970-01-13T20:38:29.999Z/date date name=mean1970-01-07T10:19:14.999Z/date double name=sumOfSquares9.90701807652E17/double double name=stddev6.110802669969879E8/double /lst /lst /lst /response request was: indent=truestats.field=active_dtstats=trueq=*:* Stack Trace: junit.framework.AssertionFailedError: test date statistics values query failed XPath: //date[@name='sum'][.='1970-01-13T20:38:30Z'] xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime0/int /lst result name=response numFound=3 start=0 doc float name=id1.0/float date name=active_dt1970-01-02T10:17:36Z/date/doc doc float name=id2.0/float date name=active_dt1970-01-12T10:20:54Z/date/doc doc float name=id3.0/float/doc /result lst name=stats lst name=stats_fields lst name=active_dt date name=min1970-01-02T10:17:36Z/date date name=max1970-01-12T10:20:54Z/date long name=count2/long long name=missing1/long date name=sum1970-01-13T20:38:29.999Z/date date name=mean1970-01-07T10:19:14.999Z/date double name=sumOfSquares9.90701807652E17/double double name=stddev6.110802669969879E8/double /lst /lst /lst /response request was: indent=truestats.field=active_dtstats=trueq=*:* at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime0/int /lst result name=response numFound=3 start=0 doc float name=id1.0/float date name=active_dt1970-01-02T10:17:36Z/date/doc doc float name=id2.0/float date name=active_dt1970-01-12T10:20:54Z/date/doc doc float name=id3.0/float/doc /result lst name=stats lst name=stats_fields lst name=active_dt date name=min1970-01-02T10:17:36Z/date date name=max1970-01-12T10:20:54Z/date long name=count2/long long name=missing1/long date name=sum1970-01-13T20:38:29.999Z/date date name=mean1970-01-07T10:19:14.999Z/date double name=sumOfSquares9.90701807652E17/double double name=stddev6.110802669969879E8/double /lst /lst /lst /response request was: indent=truestats.field=active_dtstats=trueq=*:* at org.apache.solr.util.AbstractSolrTestCase.assertQ(AbstractSolrTestCase.java:276) at org.apache.solr.handler.component.StatsComponentTest.testFieldStatisticsResultsDateField(StatsComponentTest.java:195) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600) Build Log (for compile errors): [...truncated 8352 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3216) Velcity /browse GUI broken by removal of old admin
[ https://issues.apache.org/jira/browse/SOLR-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-3216. --- Resolution: Fixed Fixed. Now autocomplete and the toggle explain and toggle all fields work again Velcity /browse GUI broken by removal of old admin -- Key: SOLR-3216 URL: https://issues.apache.org/jira/browse/SOLR-3216 Project: Solr Issue Type: Bug Components: Response Writers Reporter: Jan Høydahl Priority: Critical Fix For: 4.0 The removal of old admin obviously removed webapp/web/admin including solr_small.png and jquery-1.4.3.min.js, used by Velocity templates. -- 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
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 1918 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/1918/ 1 tests failed. FAILED: org.apache.solr.handler.component.StatsComponentTest.testFieldStatisticsResultsDateField Error Message: test date statistics values query failed XPath: //date[@name='sum'][.='1970-01-13T20:38:30Z'] xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime0/int /lst result name=response numFound=3 start=0 doc float name=id1.0/float date name=active_dt1970-01-02T10:17:36Z/date/doc doc float name=id2.0/float date name=active_dt1970-01-12T10:20:54Z/date/doc doc float name=id3.0/float/doc /result lst name=stats lst name=stats_fields lst name=active_dt date name=min1970-01-02T10:17:36Z/date date name=max1970-01-12T10:20:54Z/date long name=count2/long long name=missing1/long date name=sum1970-01-13T20:38:29.999Z/date date name=mean1970-01-07T10:19:14.999Z/date double name=sumOfSquares9.90701807652E17/double double name=stddev6.110802669969879E8/double /lst /lst /lst /response request was: indent=truestats.field=active_dtstats=trueq=*:* Stack Trace: junit.framework.AssertionFailedError: test date statistics values query failed XPath: //date[@name='sum'][.='1970-01-13T20:38:30Z'] xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime0/int /lst result name=response numFound=3 start=0 doc float name=id1.0/float date name=active_dt1970-01-02T10:17:36Z/date/doc doc float name=id2.0/float date name=active_dt1970-01-12T10:20:54Z/date/doc doc float name=id3.0/float/doc /result lst name=stats lst name=stats_fields lst name=active_dt date name=min1970-01-02T10:17:36Z/date date name=max1970-01-12T10:20:54Z/date long name=count2/long long name=missing1/long date name=sum1970-01-13T20:38:29.999Z/date date name=mean1970-01-07T10:19:14.999Z/date double name=sumOfSquares9.90701807652E17/double double name=stddev6.110802669969879E8/double /lst /lst /lst /response request was: indent=truestats.field=active_dtstats=trueq=*:* at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime0/int /lst result name=response numFound=3 start=0 doc float name=id1.0/float date name=active_dt1970-01-02T10:17:36Z/date/doc doc float name=id2.0/float date name=active_dt1970-01-12T10:20:54Z/date/doc doc float name=id3.0/float/doc /result lst name=stats lst name=stats_fields lst name=active_dt date name=min1970-01-02T10:17:36Z/date date name=max1970-01-12T10:20:54Z/date long name=count2/long long name=missing1/long date name=sum1970-01-13T20:38:29.999Z/date date name=mean1970-01-07T10:19:14.999Z/date double name=sumOfSquares9.90701807652E17/double double name=stddev6.110802669969879E8/double /lst /lst /lst /response request was: indent=truestats.field=active_dtstats=trueq=*:* at org.apache.solr.util.AbstractSolrTestCase.assertQ(AbstractSolrTestCase.java:276) at org.apache.solr.handler.component.StatsComponentTest.testFieldStatisticsResultsDateField(StatsComponentTest.java:195) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600) Build Log (for compile errors): [...truncated 9640 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2202) Money FieldType
[ https://issues.apache.org/jira/browse/SOLR-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-2202: -- Attachment: SOLR-2202.patch New patch (without faceting). * Renamed to CurrencyField * Fixed bug when default type missing in document * Added a copyField from price to price_c in schema * Various cleanup I think this is more or less ready Money FieldType --- Key: SOLR-2202 URL: https://issues.apache.org/jira/browse/SOLR-2202 Project: Solr Issue Type: New Feature Components: Schema and Analysis Affects Versions: 1.5 Reporter: Greg Fodor Assignee: Jan Høydahl Fix For: 3.6, 4.0 Attachments: SOLR-2022-solr-3.patch, SOLR-2202-lucene-1.patch, SOLR-2202-solr-1.patch, SOLR-2202-solr-10.patch, SOLR-2202-solr-2.patch, SOLR-2202-solr-4.patch, SOLR-2202-solr-5.patch, SOLR-2202-solr-6.patch, SOLR-2202-solr-7.patch, SOLR-2202-solr-8.patch, SOLR-2202-solr-9.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch Provides support for monetary values to Solr/Lucene with query-time currency conversion. The following features are supported: - Point queries - Range quries - Sorting - Currency parsing by either currency code or symbol. - Symmetric Asymmetric exchange rates. (Asymmetric exchange rates are useful if there are fees associated with exchanging the currency.) At indexing time, money fields can be indexed in a native currency. For example, if a product on an e-commerce site is listed in Euros, indexing the price field as 1000,EUR will index it appropriately. By altering the currency.xml file, the sorting and querying against Solr can take into account fluctuations in currency exchange rates without having to re-index the documents. The new money field type is a polyfield which indexes two fields, one which contains the amount of the value and another which contains the currency code or symbol. The currency metadata (names, symbols, codes, and exchange rates) are expected to be in an xml file which is pointed to by the field type declaration in the schema.xml. The current patch is factored such that Money utility functions and configuration metadata lie in Lucene (see MoneyUtil and CurrencyConfig), while the MoneyType and MoneyValueSource lie in Solr. This was meant to mirror the work being done on the spacial field types. This patch will be getting used to power the international search capabilities of the search engine at Etsy. Also see WIKI page: http://wiki.apache.org/solr/MoneyFieldType -- 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-3218) Range faceting support for CurrencyField
Range faceting support for CurrencyField Key: SOLR-3218 URL: https://issues.apache.org/jira/browse/SOLR-3218 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Fix For: 4.0 Spinoff from SOLR-2202. Need to add range faceting capabilities for CurrencyField -- 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] (SOLR-2202) Money/Currency FieldType
[ https://issues.apache.org/jira/browse/SOLR-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-2202: -- Summary: Money/Currency FieldType (was: Money FieldType) Money/Currency FieldType Key: SOLR-2202 URL: https://issues.apache.org/jira/browse/SOLR-2202 Project: Solr Issue Type: New Feature Components: Schema and Analysis Affects Versions: 1.5 Reporter: Greg Fodor Assignee: Jan Høydahl Fix For: 3.6, 4.0 Attachments: SOLR-2022-solr-3.patch, SOLR-2202-lucene-1.patch, SOLR-2202-solr-1.patch, SOLR-2202-solr-10.patch, SOLR-2202-solr-2.patch, SOLR-2202-solr-4.patch, SOLR-2202-solr-5.patch, SOLR-2202-solr-6.patch, SOLR-2202-solr-7.patch, SOLR-2202-solr-8.patch, SOLR-2202-solr-9.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch Provides support for monetary values to Solr/Lucene with query-time currency conversion. The following features are supported: - Point queries - Range quries - Sorting - Currency parsing by either currency code or symbol. - Symmetric Asymmetric exchange rates. (Asymmetric exchange rates are useful if there are fees associated with exchanging the currency.) At indexing time, money fields can be indexed in a native currency. For example, if a product on an e-commerce site is listed in Euros, indexing the price field as 1000,EUR will index it appropriately. By altering the currency.xml file, the sorting and querying against Solr can take into account fluctuations in currency exchange rates without having to re-index the documents. The new money field type is a polyfield which indexes two fields, one which contains the amount of the value and another which contains the currency code or symbol. The currency metadata (names, symbols, codes, and exchange rates) are expected to be in an xml file which is pointed to by the field type declaration in the schema.xml. The current patch is factored such that Money utility functions and configuration metadata lie in Lucene (see MoneyUtil and CurrencyConfig), while the MoneyType and MoneyValueSource lie in Solr. This was meant to mirror the work being done on the spacial field types. This patch will be getting used to power the international search capabilities of the search engine at Etsy. Also see WIKI page: http://wiki.apache.org/solr/MoneyFieldType -- 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] (SOLR-2202) Money FieldType
[ https://issues.apache.org/jira/browse/SOLR-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225595#comment-13225595 ] Jan Høydahl commented on SOLR-2202: --- Andrew, please see SOLR-3218 for faceting support. I suggest we first commit this basic field type for Solr3.6, and then add faceting support Money FieldType --- Key: SOLR-2202 URL: https://issues.apache.org/jira/browse/SOLR-2202 Project: Solr Issue Type: New Feature Components: Schema and Analysis Affects Versions: 1.5 Reporter: Greg Fodor Assignee: Jan Høydahl Fix For: 3.6, 4.0 Attachments: SOLR-2022-solr-3.patch, SOLR-2202-lucene-1.patch, SOLR-2202-solr-1.patch, SOLR-2202-solr-10.patch, SOLR-2202-solr-2.patch, SOLR-2202-solr-4.patch, SOLR-2202-solr-5.patch, SOLR-2202-solr-6.patch, SOLR-2202-solr-7.patch, SOLR-2202-solr-8.patch, SOLR-2202-solr-9.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch Provides support for monetary values to Solr/Lucene with query-time currency conversion. The following features are supported: - Point queries - Range quries - Sorting - Currency parsing by either currency code or symbol. - Symmetric Asymmetric exchange rates. (Asymmetric exchange rates are useful if there are fees associated with exchanging the currency.) At indexing time, money fields can be indexed in a native currency. For example, if a product on an e-commerce site is listed in Euros, indexing the price field as 1000,EUR will index it appropriately. By altering the currency.xml file, the sorting and querying against Solr can take into account fluctuations in currency exchange rates without having to re-index the documents. The new money field type is a polyfield which indexes two fields, one which contains the amount of the value and another which contains the currency code or symbol. The currency metadata (names, symbols, codes, and exchange rates) are expected to be in an xml file which is pointed to by the field type declaration in the schema.xml. The current patch is factored such that Money utility functions and configuration metadata lie in Lucene (see MoneyUtil and CurrencyConfig), while the MoneyType and MoneyValueSource lie in Solr. This was meant to mirror the work being done on the spacial field types. This patch will be getting used to power the international search capabilities of the search engine at Etsy. Also see WIKI page: http://wiki.apache.org/solr/MoneyFieldType -- 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
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12666 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12666/ 1 tests failed. FAILED: org.apache.solr.handler.component.StatsComponentTest.testFieldStatisticsResultsDateField Error Message: test date statistics values query failed XPath: //date[@name='sum'][.='1970-01-13T20:38:30Z'] xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime1/int /lst result name=response numFound=3 start=0 doc float name=id1.0/float date name=active_dt1970-01-02T10:17:36Z/date/doc doc float name=id2.0/float date name=active_dt1970-01-12T10:20:54Z/date/doc doc float name=id3.0/float/doc /result lst name=stats lst name=stats_fields lst name=active_dt date name=min1970-01-02T10:17:36Z/date date name=max1970-01-12T10:20:54Z/date long name=count2/long long name=missing1/long date name=sum1970-01-13T20:38:29.999Z/date date name=mean1970-01-07T10:19:14.999Z/date double name=sumOfSquares9.90701807652E17/double double name=stddev6.110802669969879E8/double /lst /lst /lst /response request was: indent=truestats.field=active_dtstats=trueq=*:* Stack Trace: junit.framework.AssertionFailedError: test date statistics values query failed XPath: //date[@name='sum'][.='1970-01-13T20:38:30Z'] xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime1/int /lst result name=response numFound=3 start=0 doc float name=id1.0/float date name=active_dt1970-01-02T10:17:36Z/date/doc doc float name=id2.0/float date name=active_dt1970-01-12T10:20:54Z/date/doc doc float name=id3.0/float/doc /result lst name=stats lst name=stats_fields lst name=active_dt date name=min1970-01-02T10:17:36Z/date date name=max1970-01-12T10:20:54Z/date long name=count2/long long name=missing1/long date name=sum1970-01-13T20:38:29.999Z/date date name=mean1970-01-07T10:19:14.999Z/date double name=sumOfSquares9.90701807652E17/double double name=stddev6.110802669969879E8/double /lst /lst /lst /response request was: indent=truestats.field=active_dtstats=trueq=*:* at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime1/int /lst result name=response numFound=3 start=0 doc float name=id1.0/float date name=active_dt1970-01-02T10:17:36Z/date/doc doc float name=id2.0/float date name=active_dt1970-01-12T10:20:54Z/date/doc doc float name=id3.0/float/doc /result lst name=stats lst name=stats_fields lst name=active_dt date name=min1970-01-02T10:17:36Z/date date name=max1970-01-12T10:20:54Z/date long name=count2/long long name=missing1/long date name=sum1970-01-13T20:38:29.999Z/date date name=mean1970-01-07T10:19:14.999Z/date double name=sumOfSquares9.90701807652E17/double double name=stddev6.110802669969879E8/double /lst /lst /lst /response request was: indent=truestats.field=active_dtstats=trueq=*:* at org.apache.solr.util.AbstractSolrTestCase.assertQ(AbstractSolrTestCase.java:276) at org.apache.solr.handler.component.StatsComponentTest.testFieldStatisticsResultsDateField(StatsComponentTest.java:195) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600) Build Log (for compile errors): [...truncated 9137 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3218) Range faceting support for CurrencyField
[ https://issues.apache.org/jira/browse/SOLR-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225616#comment-13225616 ] Andrew Morrison commented on SOLR-3218: --- Hoss Mann had posted the following on SOLR-2202 --- a) CurrencyField (and by extension CurrencyValue) gets my vote b) i really only reviewed the facet stuff in SOLR-2202-solr-10.patch (i know Jan has already been reviewing the more core stuff about the type) ... it makes me realize that we really need to refactor the range faceting code to be easier to do in custom FieldTypes, but that's certainly no fault of this issue and can be done later. The facet code itself looks correct but my one concern is that (if i'm understanding all of this MoneyValue conversion stuff correctly) it should be possible to facet with start/end/gap values specified in any currency, as long as they are all consistent – but there is not test of this situation. the negative test only looks at using an inconsistent gap, and the positive tests only use USD, or the default which is also USD. We should have at least one test that uses something like EUR for start/end/gap and verifies that the counts are correct given the conversion rates used in the test. incidentally: I don't see anything actually enforcing that start/end are in the same currency – just that gap is in the same currency as the values it's being added to, so essentially that start and gap use hte same currenty. But I'm actually not at all clear on why there is any attempt to enforce that the currencies used are the same, since the whole point of the type (as i understand it) is that you can do conversions on the fly – it may seem silly for someone to say facet.range.start=0,USD facet.range.gap=200,EUR facet.range.end=1000,YEN but is there any technical reason why we can't let them do that? Range faceting support for CurrencyField Key: SOLR-3218 URL: https://issues.apache.org/jira/browse/SOLR-3218 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Fix For: 4.0 Attachments: SOLR-3218-1.patch Spinoff from SOLR-2202. Need to add range faceting capabilities for CurrencyField -- 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] (SOLR-3218) Range faceting support for CurrencyField
[ https://issues.apache.org/jira/browse/SOLR-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Morrison updated SOLR-3218: -- Attachment: SOLR-3218-1.patch Range faceting support for CurrencyField Key: SOLR-3218 URL: https://issues.apache.org/jira/browse/SOLR-3218 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Fix For: 4.0 Attachments: SOLR-3218-1.patch Spinoff from SOLR-2202. Need to add range faceting capabilities for CurrencyField -- 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] (SOLR-3218) Range faceting support for CurrencyField
[ https://issues.apache.org/jira/browse/SOLR-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225627#comment-13225627 ] Andrew Morrison commented on SOLR-3218: --- Hoss, The attached patch (SOLR-3218-1.patch) adds additional tests for EUR and GBP. I believe start/end currency equality is enforced by MoneyType.compareTo which will throw an exception when end is compared to the first (start+gap). As far as enforcing currency equality being a good idea or not, it would make sense and I would prefer if start/end/gap currencies didn't need to be equal. This patch doesn't allow for that given the tradeoff of the utility of being able to use different currencies versus the annoyance of keeping a handle open to an ExchangeRateProvider in the places we'd need it. I'd be happy to take a look at making different currencies possible if there is enough interest. It'll be good to add a test for start/end currency mismatches. I'll upload SOLR-3218-2.patch in a moment. Range faceting support for CurrencyField Key: SOLR-3218 URL: https://issues.apache.org/jira/browse/SOLR-3218 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Fix For: 4.0 Attachments: SOLR-3218-1.patch, SOLR-3218-2.patch Spinoff from SOLR-2202. Need to add range faceting capabilities for CurrencyField -- 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] (SOLR-3218) Range faceting support for CurrencyField
[ https://issues.apache.org/jira/browse/SOLR-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Morrison updated SOLR-3218: -- Attachment: SOLR-3218-2.patch Range faceting support for CurrencyField Key: SOLR-3218 URL: https://issues.apache.org/jira/browse/SOLR-3218 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Fix For: 4.0 Attachments: SOLR-3218-1.patch, SOLR-3218-2.patch Spinoff from SOLR-2202. Need to add range faceting capabilities for CurrencyField -- 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] (SOLR-3218) Range faceting support for CurrencyField
[ https://issues.apache.org/jira/browse/SOLR-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225632#comment-13225632 ] Andrew Morrison commented on SOLR-3218: --- Jan, Once SOLR-2202 is trunked I'll update this patch to work with CurrencyField. Range faceting support for CurrencyField Key: SOLR-3218 URL: https://issues.apache.org/jira/browse/SOLR-3218 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Fix For: 4.0 Attachments: SOLR-3218-1.patch, SOLR-3218-2.patch Spinoff from SOLR-2202. Need to add range faceting capabilities for CurrencyField -- 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] (SOLR-3218) Range faceting support for CurrencyField
[ https://issues.apache.org/jira/browse/SOLR-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225639#comment-13225639 ] Hoss Man commented on SOLR-3218: bq. I believe start/end currency equality is enforced by MoneyType.compareTo which will throw an exception when end is compared to the first (start+gap). Ah ..ok. and then ultimately start+gap is compared to end (even if hardend is false) so you'll get a exception then. ok fair enough. bq. As far as enforcing currency equality being a good idea or not, it would make sense and I would prefer if start/end/gap currencies didn't need to be equal. This patch doesn't allow for that given the tradeoff of the utility of being able to use different currencies versus the annoyance of keeping a handle open to an ExchangeRateProvider in the places we'd need it. I'm not completley understanding, but i don't need to: If it's easier/simpler (for now) to require that start/end/gap are all in the same currency that's fine -- we should just test/document that clearly .. we can alwasy relax that restriction later if you think of a clean/easy way to do it. like i said before: it's probably silly to do it anyway, i just didn't understand if/what the complication was Range faceting support for CurrencyField Key: SOLR-3218 URL: https://issues.apache.org/jira/browse/SOLR-3218 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Fix For: 4.0 Attachments: SOLR-3218-1.patch, SOLR-3218-2.patch Spinoff from SOLR-2202. Need to add range faceting capabilities for CurrencyField -- 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] (SOLR-3124) explain output is confusing when using trie fields (or any field type where the indexed terms are not human readable)
[
https://issues.apache.org/jira/browse/SOLR-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-3124:
---
Description:
using the trunk example schema containing...
{noformat}
fieldType name=tint class=solr.TrieIntField precisionStep=8
positionIncrementGap=0/
dynamicField name=*_ti type=tintindexed=true stored=true/
{noformat}
...and indexing the doc...
{noformat}
$ java -Ddata=args -jar post.jar 'adddocfield name=idHOSS/fieldfield
name=foo_ti42/field/doc/add'
{noformat}
...results in a query for
[foo_ti:42|http://localhost:8983/solr/select?q=foo_ti:42start=0rows=10wt=jsondebug.explain.structured=truedebugQuery=trueindent=true]
producing the following debug output...
{noformat}
debug:{
rawquerystring:foo_ti:42,
querystring:foo_ti:42,
parsedquery:foo_ti:42,
parsedquery_toString:foo_ti:`\b\u\u\u*,
explain:{
HOSS:{
match:true,
value:3.6741486,
description:weight(foo_ti:`\b\u\u\u* in 0)
[DefaultSimilarity], result of:,
details:[{
match:true,
value:3.6741486,
description:fieldWeight in 0, product of:,
details:[{
match:true,
value:1.0,
description:tf(freq=1.0), with freq of:,
details:[{
match:true,
value:1.0,
description:termFreq=1.0}]},
{
match:true,
value:3.6741486,
description:idf(docFreq=1, maxDocs=29)},
{
match:true,
value:1.0,
description:fieldNorm(doc=0)}]}]}},
...
{noformat}
was:
defType=edismaxboost=query($param)param=specialties_ids:32debugQuery=true
str name=2H7DF
6.351252 = (MATCH) boost(*:*,query(specialties_ids: #1;#0;#0;#0;#0;#0;#0;#0;#0;
,def=0.0)), product of:
1.0 = (MATCH) MatchAllDocsQuery, product of:
1.0 = queryNorm
6.351252 = query(specialties_ids: #1;#0;#0;#0;#0;#0;#0;#0;#0;
,def=0.0)=6.351252
/strstr name=X5PJW
6.351252 = (MATCH) boost(*:*,query(specialties_ids: #1;#0;#0;#0;#0;#0;#0;#0;#0;
,def=0.0)), product of:
1.0 = (MATCH) MatchAllDocsQuery, product of:
1.0 = queryNorm
6.351252 = query(specialties_ids: #1;#0;#0;#0;#0;#0;#0;#0;#0;
,def=0.0)=6.351252
/str
Summary: explain output is confusing when using trie fields (or any
field type where the indexed terms are not human readable) (was: explain
output looks unreadable when using boost and edismax - #0; ?)
generalizing summary description since the issue actually has nothing to do
with boosting and clarifying exactly how to reproduce (the field types used
matter)
Bill: the fundamental problem is that the code for generating explain
information works with the indexed terms in the queries, which for some field
types is non-readable. The Solr FieldType classes know how to format those
indexed terms as readable strings, but the code for generating Explanation
objects is at a lower level in lucene and doens't know about the schema at all.
explain output is confusing when using trie fields (or any field type where
the indexed terms are not human readable)
-
Key: SOLR-3124
URL: https://issues.apache.org/jira/browse/SOLR-3124
Project: Solr
Issue Type: Bug
Affects Versions: 3.5
Reporter: Bill Bell
using the trunk example schema containing...
{noformat}
fieldType name=tint class=solr.TrieIntField precisionStep=8
positionIncrementGap=0/
dynamicField name=*_ti type=tintindexed=true stored=true/
{noformat}
...and indexing the doc...
{noformat}
$ java -Ddata=args -jar post.jar 'adddocfield
name=idHOSS/fieldfield name=foo_ti42/field/doc/add'
{noformat}
...results in a query for
[foo_ti:42|http://localhost:8983/solr/select?q=foo_ti:42start=0rows=10wt=jsondebug.explain.structured=truedebugQuery=trueindent=true]
producing the following debug output...
{noformat}
debug:{
rawquerystring:foo_ti:42,
querystring:foo_ti:42,
parsedquery:foo_ti:42,
parsedquery_toString:foo_ti:`\b\u\u\u*,
explain:{
HOSS:{
match:true,
value:3.6741486,
description:weight(foo_ti:`\b\u\u\u* in 0)
[DefaultSimilarity], result of:,
details:[{
match:true,
value:3.6741486,
description:fieldWeight in 0, product of:,
details:[{
match:true,
value:1.0,
description:tf(freq=1.0), with freq of:,
details:[{
match:true,
value:1.0,
description:termFreq=1.0}]},
[jira] [Commented] (SOLR-3218) Range faceting support for CurrencyField
[ https://issues.apache.org/jira/browse/SOLR-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225664#comment-13225664 ] Jan Høydahl commented on SOLR-3218: --- Thanks for your work Andrew. Just a small comment about pathces. We prefer that you name the patch simply SOLR-3218.patch every time. JIRA takes care of greying out the older versions. Also, is it possible to convert your GIT patch to svn compatible patch? Good plan to jump over to CurrencyField once it is in trunk. Range faceting support for CurrencyField Key: SOLR-3218 URL: https://issues.apache.org/jira/browse/SOLR-3218 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Fix For: 4.0 Attachments: SOLR-3218-1.patch, SOLR-3218-2.patch Spinoff from SOLR-2202. Need to add range faceting capabilities for CurrencyField -- 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
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12667 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12667/ 5 tests failed. FAILED: org.apache.solr.client.solrj.SolrExampleBinaryTest.testStatistics Error Message: expected:20.0 but was:5.0 Stack Trace: junit.framework.AssertionFailedError: expected:20.0 but was:5.0 at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.solr.client.solrj.SolrExampleTests.testStatistics(SolrExampleTests.java:741) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600) FAILED: org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest.testStatistics Error Message: expected:20.0 but was:5.0 Stack Trace: junit.framework.AssertionFailedError: expected:20.0 but was:5.0 at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.solr.client.solrj.SolrExampleTests.testStatistics(SolrExampleTests.java:741) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600) FAILED: org.apache.solr.client.solrj.embedded.SolrExampleJettyTest.testStatistics Error Message: expected:20.0 but was:5.0 Stack Trace: junit.framework.AssertionFailedError: expected:20.0 but was:5.0 at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.solr.client.solrj.SolrExampleTests.testStatistics(SolrExampleTests.java:741) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600) FAILED: org.apache.solr.client.solrj.embedded.SolrExampleStreamingBinaryTest.testStatistics Error Message: expected:20.0 but was:5.0 Stack Trace: junit.framework.AssertionFailedError: expected:20.0 but was:5.0 at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at
[jira] [Commented] (SOLR-3159) Upgrade to Jetty 8
[
https://issues.apache.org/jira/browse/SOLR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225674#comment-13225674
]
Hoss Man commented on SOLR-3159:
FWIW: on trunk, using an svn checkout, and runing java -jar start.jar i'm
getting the following error in the jetty logging after solr starts up...
{noformat}
2012-03-08 15:16:09.382:WARN:oejw.WebAppContext:Failed startup of context
o.e.j.w.WebAppContext{/.svn,file:/home/hossman/lucene/dev/solr/example/webapps/.svn/},/home/hossman/lucene/dev/solr/example/webapps/.svn
java.lang.StringIndexOutOfBoundsException: String index out of range: 0
at java.lang.String.charAt(String.java:686)
at
org.eclipse.jetty.util.log.StdErrLog.condensePackageString(StdErrLog.java:210)
at org.eclipse.jetty.util.log.StdErrLog.init(StdErrLog.java:105)
at org.eclipse.jetty.util.log.StdErrLog.init(StdErrLog.java:97)
at org.eclipse.jetty.util.log.StdErrLog.newLogger(StdErrLog.java:569)
at
org.eclipse.jetty.util.log.AbstractLogger.getLogger(AbstractLogger.java:21)
at org.eclipse.jetty.util.log.Log.getLogger(Log.java:438)
at
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:677)
at
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:454)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
at
org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:36)
at
org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:183)
at
org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:491)
at
org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:138)
at
org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:142)
at
org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:53)
at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:604)
at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:535)
at org.eclipse.jetty.util.Scanner.scan(Scanner.java:398)
at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:332)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
at
org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:118)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
at
org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:552)
at
org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:227)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
at
org.eclipse.jetty.util.component.AggregateLifeCycle.doStart(AggregateLifeCycle.java:58)
at
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:53)
at
org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:91)
at org.eclipse.jetty.server.Server.doStart(Server.java:263)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
at
org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1215)
at java.security.AccessController.doPrivileged(Native Method)
at
org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1138)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:457)
at org.eclipse.jetty.start.Main.start(Main.java:602)
at org.eclipse.jetty.start.Main.main(Main.java:82)
{noformat}
...solr is functioning just fine, but it seems like something has changed
subtley in either how jetty handles the webapps dir, or how we have it
configured to handle the webapps dir, such that it is trying to load .svn as a
webapp.
Upgrade to Jetty 8
--
Key: SOLR-3159
URL: https://issues.apache.org/jira/browse/SOLR-3159
Project: Solr
Issue Type: Task
Reporter: Ryan McKinley
Priority: Minor
Fix For: 4.0
Attachments: SOLR-3159-maven.patch
Solr is currently tested (and bundled) with a patched jetty-6 version.
Ideally we can release and test with a standard version.
Jetty-6 (at codehaus) is just maintenance now. New development and
improvements are now hosted at eclipse. Assuming performance is
[jira] [Commented] (SOLR-3159) Upgrade to Jetty 8
[ https://issues.apache.org/jira/browse/SOLR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225675#comment-13225675 ] Hoss Man commented on SOLR-3159: https://jira.codehaus.org/browse/JETTY-1489 - apparently fixed in 8.1.2 ? Upgrade to Jetty 8 -- Key: SOLR-3159 URL: https://issues.apache.org/jira/browse/SOLR-3159 Project: Solr Issue Type: Task Reporter: Ryan McKinley Priority: Minor Fix For: 4.0 Attachments: SOLR-3159-maven.patch Solr is currently tested (and bundled) with a patched jetty-6 version. Ideally we can release and test with a standard version. Jetty-6 (at codehaus) is just maintenance now. New development and improvements are now hosted at eclipse. Assuming performance is equivalent, I think we should switch to Jetty 8. -- 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
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 1919 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/1919/ 5 tests failed. FAILED: org.apache.solr.client.solrj.SolrExampleBinaryTest.testStatistics Error Message: expected:20.0 but was:5.0 Stack Trace: junit.framework.AssertionFailedError: expected:20.0 but was:5.0 at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.solr.client.solrj.SolrExampleTests.testStatistics(SolrExampleTests.java:741) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600) FAILED: org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest.testStatistics Error Message: expected:20.0 but was:5.0 Stack Trace: junit.framework.AssertionFailedError: expected:20.0 but was:5.0 at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.solr.client.solrj.SolrExampleTests.testStatistics(SolrExampleTests.java:741) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600) FAILED: org.apache.solr.client.solrj.embedded.SolrExampleJettyTest.testStatistics Error Message: expected:20.0 but was:5.0 Stack Trace: junit.framework.AssertionFailedError: expected:20.0 but was:5.0 at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.solr.client.solrj.SolrExampleTests.testStatistics(SolrExampleTests.java:741) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600) FAILED: org.apache.solr.client.solrj.embedded.SolrExampleStreamingBinaryTest.testStatistics Error Message: expected:20.0 but was:5.0 Stack Trace: junit.framework.AssertionFailedError: expected:20.0 but was:5.0 at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at
[jira] [Commented] (SOLR-3159) Upgrade to Jetty 8
[ https://issues.apache.org/jira/browse/SOLR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225685#comment-13225685 ] Shawn Heisey commented on SOLR-3159: bq. The pile of config files in etc are for the various features you can enable – this just includes the ones I think we need I checked out trunk from SVN and took a look at the example etc directory. It only includes jetty.xml and webdefault.xml, so once things on this issue have settled down, I'll compare my config with yours and go ahead with an upgrade on my test server. Upgrade to Jetty 8 -- Key: SOLR-3159 URL: https://issues.apache.org/jira/browse/SOLR-3159 Project: Solr Issue Type: Task Reporter: Ryan McKinley Priority: Minor Fix For: 4.0 Attachments: SOLR-3159-maven.patch Solr is currently tested (and bundled) with a patched jetty-6 version. Ideally we can release and test with a standard version. Jetty-6 (at codehaus) is just maintenance now. New development and improvements are now hosted at eclipse. Assuming performance is equivalent, I think we should switch to Jetty 8. -- 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] (SOLR-3159) Upgrade to Jetty 8
[ https://issues.apache.org/jira/browse/SOLR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225688#comment-13225688 ] Steven Rowe commented on SOLR-3159: --- bq. apparently fixed in 8.1.2 ? Wierdly, I don't see an annoucement for v8.1.2 on [the jetty-announce list archives|http://dev.eclipse.org/mhonarc/lists/jetty-announce/] (unlike v8.1.1, which was announced), and the Maven artifacts haven't shown up in Maven central (again, unlike the v8.1.1 artifacts). The full 8.1.2 version name is 8.1.2.v20120302, where AFAICT the suffix is the release date, six days ago. Unlike 8.1.2, the Maven Central artifacts for 8.1.0 and 8.1.1 are dated one day after the (assumed) release date from the version number. Upgrade to Jetty 8 -- Key: SOLR-3159 URL: https://issues.apache.org/jira/browse/SOLR-3159 Project: Solr Issue Type: Task Reporter: Ryan McKinley Priority: Minor Fix For: 4.0 Attachments: SOLR-3159-maven.patch Solr is currently tested (and bundled) with a patched jetty-6 version. Ideally we can release and test with a standard version. Jetty-6 (at codehaus) is just maintenance now. New development and improvements are now hosted at eclipse. Assuming performance is equivalent, I think we should switch to Jetty 8. -- 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-3219) StreamingUpdateSolrServer is not quiet at INFO, but CommonsHttpSolrServer is
StreamingUpdateSolrServer is not quiet at INFO, but CommonsHttpSolrServer is Key: SOLR-3219 URL: https://issues.apache.org/jira/browse/SOLR-3219 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 3.5, 4.0 Reporter: Shawn Heisey Priority: Minor When using CommonsHttpSolrServer, nothing gets logged by SolrJ at the INFO level. When using StreamingUpdateSolrServer, I have seen two messages logged each time it is used: Mar 08, 2012 4:41:01 PM org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer$Runner run INFO: starting runner: org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer$Runner@6bf28508 Mar 08, 2012 4:41:01 PM org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer$Runner run INFO: finished: org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer$Runner@6bf28508 I think one of these behaviors should be considered a bug. My preference is to move the logging in SUSS out of INFO so it is silent like CHSS. If the decision is to leave it at INFO, I'll just live with it. A knob to make it configurable would be cool, but that's probably a fair amount of work. -- 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-3220) RecoveryZkTest test failure
RecoveryZkTest test failure --- Key: SOLR-3220 URL: https://issues.apache.org/jira/browse/SOLR-3220 Project: Solr Issue Type: Bug Reporter: Hoss Man observed a failure in RecoveryZkTest.testDistribSearch using r1298661 that had some odd looking (to me) log info. could not reproduce with identical seed -- 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] (SOLR-3220) RecoveryZkTest test failure
[ https://issues.apache.org/jira/browse/SOLR-3220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-3220: --- Attachment: TEST-org.apache.solr.cloud.RecoveryZkTest.xml RecoveryZkTest test failure --- Key: SOLR-3220 URL: https://issues.apache.org/jira/browse/SOLR-3220 Project: Solr Issue Type: Bug Reporter: Hoss Man Attachments: TEST-org.apache.solr.cloud.RecoveryZkTest.xml observed a failure in RecoveryZkTest.testDistribSearch using r1298661 that had some odd looking (to me) log info. could not reproduce with identical seed -- 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] (SOLR-3219) StreamingUpdateSolrServer is not quiet at INFO, but CommonsHttpSolrServer is
[ https://issues.apache.org/jira/browse/SOLR-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225720#comment-13225720 ] Ryan McKinley commented on SOLR-3219: - bq. A knob to make it configurable would be cool, but that's probably a fair amount of work. Any logging framework will let you decide if that component should show INFO or not. I think the rationale behind showing it for SUSS is that it is starting up a pool of connections that are expected to run for a long while. But I don't really care if it stays or changes. 'Bug' seems extreme to me StreamingUpdateSolrServer is not quiet at INFO, but CommonsHttpSolrServer is Key: SOLR-3219 URL: https://issues.apache.org/jira/browse/SOLR-3219 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 3.5, 4.0 Reporter: Shawn Heisey Priority: Minor When using CommonsHttpSolrServer, nothing gets logged by SolrJ at the INFO level. When using StreamingUpdateSolrServer, I have seen two messages logged each time it is used: Mar 08, 2012 4:41:01 PM org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer$Runner run INFO: starting runner: org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer$Runner@6bf28508 Mar 08, 2012 4:41:01 PM org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer$Runner run INFO: finished: org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer$Runner@6bf28508 I think one of these behaviors should be considered a bug. My preference is to move the logging in SUSS out of INFO so it is silent like CHSS. If the decision is to leave it at INFO, I'll just live with it. A knob to make it configurable would be cool, but that's probably a fair amount of work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3077) error: blank undefined field IndexSchema.getDynamicFieldType
[
https://issues.apache.org/jira/browse/SOLR-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-3077.
Resolution: Fixed
Fix Version/s: 4.0
3.6
Assignee: Hoss Man
Committed revision 1298667.
Committed revision 1298668.
thanks for the suggestion Antony
error: blank undefined field IndexSchema.getDynamicFieldType
Key: SOLR-3077
URL: https://issues.apache.org/jira/browse/SOLR-3077
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 4.0
Reporter: Antony Stubbs
Assignee: Hoss Man
Priority: Minor
Fix For: 3.6, 4.0
Seems to be an issue parsing the query string, as the parser is trying to
lookup a blank field?
{code}
2012-01-29 09:15:50,320 ERROR org.apache.solr.core.SolrCore -
org.apache.solr.common.SolrException: undefined field 
at
org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1028)
at org.apache.solr.schema.IndexSchema.getFieldType(IndexSchema.java:980)
at
org.apache.solr.search.SolrQueryParser.getRegexpQuery(SolrQueryParser.java:216)
at
org.apache.lucene.queryparser.classic.QueryParserBase.handleBareTokenQuery(QueryParserBase.java:1045)
at
org.apache.lucene.queryparser.classic.QueryParser.Term(QueryParser.java:358)
at
org.apache.lucene.queryparser.classic.QueryParser.Clause(QueryParser.java:257)
at
org.apache.lucene.queryparser.classic.QueryParser.Query(QueryParser.java:212)
at
org.apache.lucene.queryparser.classic.QueryParser.TopLevelQuery(QueryParser.java:170)
at
org.apache.lucene.queryparser.classic.QueryParserBase.parse(QueryParserBase.java:118)
at
org.apache.solr.search.ExtendedDismaxQParser.parse(ExtendedDismaxQParserPlugin.java:284)
at org.apache.solr.search.QParser.getQuery(QParser.java:143)
at
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:121)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:173)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1471)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:353)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:248)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
{code}
In the code:
{code}
throw new SolrException( SolrException.ErrorCode.BAD_REQUEST,undefined
field + fieldName );
{code}
So it does print out the field name, but in my case it's blank. I got this
error maybe 20 times, over 260,000 requests over the weekend.
Initially, I would submit this patch, to clarify:
{code}
diff --git a/solr/core/src/java/org/apache/solr/schema/IndexSchema.java
b/solr/core/src/java/org/apache/solr/schema/IndexSchema.java
index 1325397..3dd51c3 100644
--- a/solr/core/src/java/org/apache/solr/schema/IndexSchema.java
+++ b/solr/core/src/java/org/apache/solr/schema/IndexSchema.java
@@ -1025,7 +1025,7 @@ public final class IndexSchema {
for (DynamicField df : dynamicFields) {
if (df.matches(fieldName)) return df.prototype.getType();
}
-throw new SolrException( SolrException.ErrorCode.BAD_REQUEST,undefined
field
[jira] [Created] (SOLR-3221) Make Shard handler threadpool configurable
Make Shard handler threadpool configurable -- Key: SOLR-3221 URL: https://issues.apache.org/jira/browse/SOLR-3221 Project: Solr Issue Type: Improvement Affects Versions: 3.6 Reporter: Greg Bowyer From profiling of monitor contention, as well as observations of the 95th and 99th response times for nodes that perform distributed search (or ‟aggregator‟ nodes) it would appear that the HttpShardHandler code currently does a suboptimal job of managing outgoing shard level requests. Presently the code contained within lucene 3.5's SearchHandler and Lucene trunk / 3x's ShardHandlerFactory create arbitrary threads in order to service distributed search requests. This is done presently to limit the size of the threadpool such that it does not consume resources in deployment configurations that do not use distributed search. This unfortunately has two impacts on the response time if the node coordinating the distribution is under high load. The usage of the MaxConnectionsPerHost configuration option results in aggressive activity on semaphores within HttpCommons, it has been observed that the aggregator can have a response time far greater than that of the searchers. The above monitor contention would appear to suggest that in some cases its possible for liveness issues to occur and for simple queries to be starved of resources simply due to a lack of attention from the viewpoint of context switching. With, as mentioned above the http commons connection being hotly contended The fair, queue based configuration eliminates this, at the cost of throughput. This patch aims to make the threadpool largely configurable allowing for those using solr to choose the throughput vs latency balance they desire. -- 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] (SOLR-3221) Make Shard handler threadpool configurable
[ https://issues.apache.org/jira/browse/SOLR-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Bowyer updated SOLR-3221: -- Attachment: SOLR-3221-3x_branch.patch Make Shard handler threadpool configurable -- Key: SOLR-3221 URL: https://issues.apache.org/jira/browse/SOLR-3221 Project: Solr Issue Type: Improvement Affects Versions: 3.6 Reporter: Greg Bowyer Labels: distributed, http, shard Attachments: SOLR-3221-3x_branch.patch From profiling of monitor contention, as well as observations of the 95th and 99th response times for nodes that perform distributed search (or ‟aggregator‟ nodes) it would appear that the HttpShardHandler code currently does a suboptimal job of managing outgoing shard level requests. Presently the code contained within lucene 3.5's SearchHandler and Lucene trunk / 3x's ShardHandlerFactory create arbitrary threads in order to service distributed search requests. This is done presently to limit the size of the threadpool such that it does not consume resources in deployment configurations that do not use distributed search. This unfortunately has two impacts on the response time if the node coordinating the distribution is under high load. The usage of the MaxConnectionsPerHost configuration option results in aggressive activity on semaphores within HttpCommons, it has been observed that the aggregator can have a response time far greater than that of the searchers. The above monitor contention would appear to suggest that in some cases its possible for liveness issues to occur and for simple queries to be starved of resources simply due to a lack of attention from the viewpoint of context switching. With, as mentioned above the http commons connection being hotly contended The fair, queue based configuration eliminates this, at the cost of throughput. This patch aims to make the threadpool largely configurable allowing for those using solr to choose the throughput vs latency balance they desire. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-1048) Ids parameter and fl=score throws an exception for wt=json
[ https://issues.apache.org/jira/browse/SOLR-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-1048. - Resolution: Fixed Fix Version/s: 4.0 This goes away with SOLR-1566. Ids parameter and fl=score throws an exception for wt=json -- Key: SOLR-1048 URL: https://issues.apache.org/jira/browse/SOLR-1048 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.3 Reporter: Laurent Chavet Fix For: 4.0 http://yourHost:8080/solr/select/?ids=YourDocIdversion=2.2start=0rows=10indent=onfl=score,idq=%2B*:* shows that when using ids= the score for docs is null; when using wt=json: http://yourHost:8080/solr/select/?ids=YourDocIdversion=2.2start=0rows=10indent=onfl=score,idq=%2B*:*wt=json that throws a NullPointerException: HTTP Status 500 - null java.lang.NullPointerException at org.apache.solr.search.DocSlice$1.score(DocSlice.java:120) at org.apache.solr.request.JSONWriter.writeDocList(JSONResponseWriter.java:490) at org.apache.solr.request.TextResponseWriter.writeVal(TextResponseWriter.java:140) at org.apache.solr.request.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:175) at org.apache.solr.request.JSONWriter.writeNamedList(JSONResponseWriter.java:288) at org.apache.solr.request.JSONWriter.writeResponse(JSONResponseWriter.java:88) at org.apache.solr.request.JSONResponseWriter.write(JSONResponseWriter.java:49) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:847) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2441) Requesting invalid field names should return an error
[
https://issues.apache.org/jira/browse/SOLR-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-2441.
-
Resolution: Won't Fix
Fix Version/s: (was: 4.0)
While it would be nice... I don't think we should do this
Requesting invalid field names should return an error
-
Key: SOLR-2441
URL: https://issues.apache.org/jira/browse/SOLR-2441
Project: Solr
Issue Type: Improvement
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Attachments: SOLR-2441-invalid-fl-error.patch,
SOLR-2441-invalid-fl-error.patch
If you send a request for *fl=foofoofoo* and that field does not exist, solr
just returns empty documents:
{code}
result name=response numFound=17 start=0
doc/doc
doc/doc
doc/doc
/result
{code}
This seems like an error, not something we should support. (I think
requesting an invalid field name should also be an error, but that is another
issue)
The distributed tests check if this is supported -- I don't think they should
--
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-3222) Pull optimal cache warming queries from a warm solr instance
Pull optimal cache warming queries from a warm solr instance
Key: SOLR-3222
URL: https://issues.apache.org/jira/browse/SOLR-3222
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 3.5, 4.0
Reporter: Russell Black
Ever wondered what queries to use to prime your cache? This patch allows you
to query a warm running instance for a list of warming queries. The list is
generated from the server's caches, meaning you get back an optimal set of
queries. The set is optimal to the extent that the caches are optimized. The
queries are returned in a format that can be consumed by the
{code:xml}listener event=firstSearcher
class=solr.QuerySenderListener{code} section of {{solrconfig.xml}}.
One can use this feature to generate a static set of good warming queries to
place in {{solrconfig.xml}} under {code:xml}listener event=firstSearcher
class=solr.QuerySenderListener{code}
It can even be used in a dynamic faction like this:
{code:xml}
listener event=firstSearcher class=solr.QuerySenderListener
xi:include href=http://host/solr/core/autowarm; xpointer=element(/1/2)
xmlns:xi=http://www.w3.org/2001/XInclude/
/listener
{code}
which can work well in certain distributed load-balanced architectures,
although in production it would be wise to add an {{xi:fallback}} element to
the include in the event that the host is down.
I implemented this by introducing a new request handler:
{code:xml}
requestHandler name=/autowarm class=solr.AutoWarmRequestHandler /
{code}
The request handler pulls a configurable number of top keys from the
{{filterCache}},{{fieldValueCache}}, and {{queryResultCache}}. For each key,
it constructs a query that will cause that key to be placed in the associated
cache. The list of constructed queries are then returned in the response.
Patch to follow.
--
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] [Assigned] (SOLR-3221) Make Shard handler threadpool configurable
[ https://issues.apache.org/jira/browse/SOLR-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson reassigned SOLR-3221: Assignee: Erick Erickson Make Shard handler threadpool configurable -- Key: SOLR-3221 URL: https://issues.apache.org/jira/browse/SOLR-3221 Project: Solr Issue Type: Improvement Affects Versions: 3.6 Reporter: Greg Bowyer Assignee: Erick Erickson Labels: distributed, http, shard Attachments: SOLR-3221-3x_branch.patch From profiling of monitor contention, as well as observations of the 95th and 99th response times for nodes that perform distributed search (or ‟aggregator‟ nodes) it would appear that the HttpShardHandler code currently does a suboptimal job of managing outgoing shard level requests. Presently the code contained within lucene 3.5's SearchHandler and Lucene trunk / 3x's ShardHandlerFactory create arbitrary threads in order to service distributed search requests. This is done presently to limit the size of the threadpool such that it does not consume resources in deployment configurations that do not use distributed search. This unfortunately has two impacts on the response time if the node coordinating the distribution is under high load. The usage of the MaxConnectionsPerHost configuration option results in aggressive activity on semaphores within HttpCommons, it has been observed that the aggregator can have a response time far greater than that of the searchers. The above monitor contention would appear to suggest that in some cases its possible for liveness issues to occur and for simple queries to be starved of resources simply due to a lack of attention from the viewpoint of context switching. With, as mentioned above the http commons connection being hotly contended The fair, queue based configuration eliminates this, at the cost of throughput. This patch aims to make the threadpool largely configurable allowing for those using solr to choose the throughput vs latency balance they desire. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2712) Deprecate fl=score behavior.
[
https://issues.apache.org/jira/browse/SOLR-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-2712.
-
Resolution: Fixed
Assignee: Ryan McKinley
Added warning in 3.x #1298683
removed from trunk in #1298690
Deprecate fl=score behavior.
--
Key: SOLR-2712
URL: https://issues.apache.org/jira/browse/SOLR-2712
Project: Solr
Issue Type: Task
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Fix For: 3.6, 4.0
SOLR-2657 points out that all fields show up when you request score and
something becides a 'normal' field. To support the strange behavior and
avoid it when uncenessary we have this:
{code:java}
if( fields.size() == 1 _wantsScore augmenters.size() == 1
globs.isEmpty() ) {
_wantsAllFields = true;
}
{code}
I suggest we advertise in 3.x that expecting *fl=score* to return all fields
is deprecated, and remove this bit of crazy code from 4.x
--
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
