[jira] [Commented] (LUCENE-3335) jrebug causes porter stemmer to sigsegv
[ https://issues.apache.org/jira/browse/LUCENE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071562#comment-13071562 ] Dawid Weiss commented on LUCENE-3335: - @Hoss Yeah, it's scary, isn't it? But then: there is no piece of software that is 100% bug free and anybody running a production server will be running migration tests first before running on a new infrastructure. Hey, that's also part of the reason we still have folks running 1.5 :) I think I'm for releasing 1.7 and getting the road paved for bugfix releases rather than delaying it indefinitely... I mean: it'll be motivational for Oracle if people start screaming! > jrebug causes porter stemmer to sigsegv > --- > > Key: LUCENE-3335 > URL: https://issues.apache.org/jira/browse/LUCENE-3335 > Project: Lucene - Java > Issue Type: Bug >Reporter: Robert Muir > Labels: Java7 > Attachments: LUCENE-3335.patch, LUCENE-3335_slow.patch, > patch-0uwe.patch > > > happens easily on java7: ant test -Dtestcase=TestPorterStemFilter > -Dtests.iter=100 > might happen on 1.6.0_u26 too, a user reported something that looks like the > same bug already: > http://www.lucidimagination.com/search/document/3beaa082c4d2fdd4/porterstemfilter_kills_jvm -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3335) jrebug causes porter stemmer to sigsegv
[
https://issues.apache.org/jira/browse/LUCENE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071555#comment-13071555
]
Robert Muir commented on LUCENE-3335:
-
{quote}
Even if we found a work around for all the affected issues in Lucene that
didn't hurt performance in older JVMs, and spun up a 3.3.1 RC in the next 5
minutes, we still don't have enough time to vote for that release and get it
out to the mirrors by the time Java 7 comes out – let alone have any confidence
that all our users will upgrade Lucene/Solr before they upgrade their JVM.
{quote}
I agree, I'm not implying we should rush anything. But I guess I'm saying its
worth it to understand the scope of what's affected, because if its just:
* PorterStemmer jrecrash <- workarounds already posted here
* Pulsing negative readVint <-- no workaround yet.
well, thats manageable, only one of these affects any released code.
> jrebug causes porter stemmer to sigsegv
> ---
>
> Key: LUCENE-3335
> URL: https://issues.apache.org/jira/browse/LUCENE-3335
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Robert Muir
> Labels: Java7
> Attachments: LUCENE-3335.patch, LUCENE-3335_slow.patch,
> patch-0uwe.patch
>
>
> happens easily on java7: ant test -Dtestcase=TestPorterStemFilter
> -Dtests.iter=100
> might happen on 1.6.0_u26 too, a user reported something that looks like the
> same bug already:
> http://www.lucidimagination.com/search/document/3beaa082c4d2fdd4/porterstemfilter_kills_jvm
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3345) docvalues FNFE
[
https://issues.apache.org/jira/browse/LUCENE-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071528#comment-13071528
]
Robert Muir commented on LUCENE-3345:
-
{noformat}
[junit] Testsuite: org.apache.lucene.index.codecs.pulsing.Test10KPulsings
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.81 sec
[junit]
[junit] - Standard Output ---
[junit] CheckIndex failed
[junit] Segments file=segments_e numSegments=1 version=4.0
format=FORMAT_4_0 [Lucene 4.0]
[junit] 1 of 1: name=_p docCount=10050
[junit] codec=SegmentCodecs [codecs=[Pulsing(freqCutoff=3)],
provider=RandomCodecProvider: {}]
[junit] compound=true
[junit] hasProx=true
[junit] numFiles=2
[junit] size (MB)=3,141
[junit] diagnostics = {optimize=false, mergeFactor=3,
os.version=2.6.38-8-generic, os=Linux, lucene.version=4.0-SNAPSHOT,
source=merge, os.arch=amd64, java.version=1.6.0_25, java.vendor=Sun
Microsystems Inc.}
[junit] no deletions
[junit] test: open reader.FAILED
[junit] WARNING: fixIndex() would remove reference to this segment;
full exception:
[junit] java.io.IOException: No sub-file with id _0-1.dat found (files:
[_0.cfs, _0.tib, _0.tiv, .fnm, _0.cfe, _0.frq, .fdt, .nrm, _0.prx, .fdx])
[junit] at
org.apache.lucene.store.CompoundFileDirectory.openInput(CompoundFileDirectory.java:198)
[junit] at
org.apache.lucene.store.MockCompoundFileDirectoryWrapper.openInput(MockCompoundFileDirectoryWrapper.java:55)
[junit] at
org.apache.lucene.index.values.Bytes$BytesReaderBase.(Bytes.java:448)
[junit] at
org.apache.lucene.index.values.VarDerefBytesImpl$Reader.(VarDerefBytesImpl.java:225)
[junit] at
org.apache.lucene.index.values.Bytes.getValues(Bytes.java:177)
[junit] at
org.apache.lucene.index.codecs.DefaultDocValuesProducer.loadDocValues(DefaultDocValuesProducer.java:170)
[junit] at
org.apache.lucene.index.codecs.DefaultDocValuesProducer.load(DefaultDocValuesProducer.java:113)
[junit] at
org.apache.lucene.index.codecs.DefaultDocValuesProducer.(DefaultDocValuesProducer.java:86)
[junit] at
org.apache.lucene.index.codecs.pulsing.PulsingCodec.docsProducer(PulsingCodec.java:184)
[junit] at
org.apache.lucene.index.PerFieldCodecWrapper$PerDocProducers.(PerFieldCodecWrapper.java:224)
[junit] at
org.apache.lucene.index.PerFieldCodecWrapper.docsProducer(PerFieldCodecWrapper.java:207)
[junit] at
org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:92)
[junit] at
org.apache.lucene.index.SegmentReader.get(SegmentReader.java:113)
[junit] at
org.apache.lucene.index.SegmentReader.get(SegmentReader.java:92)
[junit] at
org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:517)
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:158)
[junit] at
org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:148)
[junit] at
org.apache.lucene.index.codecs.pulsing.Test10KPulsings.test10kPulsed(Test10KPulsings.java:92)
...
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=Test10KPulsings
-Dtestmethod=test10kPulsed -Dtests.seed=2835406743900800199:-6668246351730332054
{noformat}
> docvalues FNFE
> --
>
> Key: LUCENE-3345
> URL: https://issues.apache.org/jira/browse/LUCENE-3345
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Robert Muir
>
> I created a test for LUCENE-3335, and it found an unrelated bug in docvalues.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3345) docvalues FNFE
docvalues FNFE -- Key: LUCENE-3345 URL: https://issues.apache.org/jira/browse/LUCENE-3345 Project: Lucene - Java Issue Type: Bug Reporter: Robert Muir I created a test for LUCENE-3335, and it found an unrelated bug in docvalues. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3335) jrebug causes porter stemmer to sigsegv
[ https://issues.apache.org/jira/browse/LUCENE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071520#comment-13071520 ] Robert Muir commented on LUCENE-3335: - I just wrote a test (Test10KPulsings) designed to seek out the corrupt index bug. it didnt work, but it separately sometimes creates a corrupt index with java6 :) Adding lucene/src/test/org/apache/lucene/index/codecs/pulsing Adding lucene/src/test/org/apache/lucene/index/codecs/pulsing/Test10KPulsings.java Transmitting file data . Committed revision 1151335. > jrebug causes porter stemmer to sigsegv > --- > > Key: LUCENE-3335 > URL: https://issues.apache.org/jira/browse/LUCENE-3335 > Project: Lucene - Java > Issue Type: Bug >Reporter: Robert Muir > Labels: Java7 > Attachments: LUCENE-3335.patch, LUCENE-3335_slow.patch, > patch-0uwe.patch > > > happens easily on java7: ant test -Dtestcase=TestPorterStemFilter > -Dtests.iter=100 > might happen on 1.6.0_u26 too, a user reported something that looks like the > same bug already: > http://www.lucidimagination.com/search/document/3beaa082c4d2fdd4/porterstemfilter_kills_jvm -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 9775 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/9775/ 1 tests failed. FAILED: org.apache.solr.search.TestRealTimeGet.testStressGetRealtime Error Message: Some threads threw uncaught exceptions! Stack Trace: junit.framework.AssertionFailedError: Some threads threw uncaught exceptions! at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1522) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1427) at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:639) at org.apache.solr.SolrTestCaseJ4.tearDown(SolrTestCaseJ4.java:99) Build Log (for compile errors): [...truncated 8099 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3338) Flexible query parser does not support open ranges and range queries with mixed inclusive and exclusive ranges
[ https://issues.apache.org/jira/browse/LUCENE-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinicius Barros updated LUCENE-3338: Attachment: week9-merged-nosurround_with_failing_junit.patch hi Uwe, I changed the patch to make the junit fail and you see the problem with [x TO x} matching nothing. > Flexible query parser does not support open ranges and range queries with > mixed inclusive and exclusive ranges > -- > > Key: LUCENE-3338 > URL: https://issues.apache.org/jira/browse/LUCENE-3338 > Project: Lucene - Java > Issue Type: Bug > Components: modules/queryparser >Affects Versions: 3.3 >Reporter: Vinicius Barros > Fix For: 4.0 > > Attachments: week9-merged-nosurround.patch, > week9-merged-nosurround_with_failing_junit.patch, week9-merged.patch, > week9.patch > > > Flexible query parser does not support open ranges and range queries with > mixed inclusive and exclusive ranges. > These two problems were found while developing LUCENE-1768. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3338) Flexible query parser does not support open ranges and range queries with mixed inclusive and exclusive ranges
[ https://issues.apache.org/jira/browse/LUCENE-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071501#comment-13071501 ] Vinicius Barros commented on LUCENE-3338: - Hi Uwe, I used javacc-4.1. When I ran ant javacc by the first time and it didn't find it, it told me I should use javacc-4.1, so I installed it. > Flexible query parser does not support open ranges and range queries with > mixed inclusive and exclusive ranges > -- > > Key: LUCENE-3338 > URL: https://issues.apache.org/jira/browse/LUCENE-3338 > Project: Lucene - Java > Issue Type: Bug > Components: modules/queryparser >Affects Versions: 3.3 >Reporter: Vinicius Barros > Fix For: 4.0 > > Attachments: week9-merged-nosurround.patch, week9-merged.patch, > week9.patch > > > Flexible query parser does not support open ranges and range queries with > mixed inclusive and exclusive ranges. > These two problems were found while developing LUCENE-1768. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 9774 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/9774/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestIndexWriterDelete.testApplyDeletesOnFlush Error Message: only 9 in segment Stack Trace: junit.framework.AssertionFailedError: only 9 in segment at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1522) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1427) at org.apache.lucene.index.TestIndexWriterDelete$4.doAfterFlush(TestIndexWriterDelete.java:1048) at org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:445) at org.apache.lucene.index.DocumentsWriter.postUpdate(DocumentsWriter.java:312) at org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:384) at org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1540) at org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1512) at org.apache.lucene.index.TestIndexWriterDelete.testApplyDeletesOnFlush(TestIndexWriterDelete.java:1066) Build Log (for compile errors): [...truncated 1217 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-trunk - Build # 1636 - Failure
Build: https://builds.apache.org/job/Lucene-trunk/1636/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestNRTThreads.testNRTThreads Error Message: this writer hit an OutOfMemoryError; cannot commit Stack Trace: java.lang.IllegalStateException: this writer hit an OutOfMemoryError; cannot commit at org.apache.lucene.index.IndexWriter.prepareCommit(IndexWriter.java:2711) at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2793) at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2775) at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2759) at org.apache.lucene.index.TestNRTThreads.testNRTThreads(TestNRTThreads.java:355) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1522) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1427) Build Log (for compile errors): [...truncated 12943 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3335) jrebug causes porter stemmer to sigsegv
[
https://issues.apache.org/jira/browse/LUCENE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071494#comment-13071494
]
Robert Muir commented on LUCENE-3335:
-
{quote}
Should we place a warning on the "Download" and "News" page on Solr and Lucene
website? The risk is high that you corrupt your index, if you index using these
JDK versions.
{quote}
Not totally sure, the issue is not so different from LUCENE-2975: if we can we
make a easy workaround I think (there are 2 possible ones on this issue for the
Porter bug), we give it our best try, and we get it out in a release. this way
if someone has to support jdk 7, we can at least say, upgrade to this version
of lucene rather than "won't fix". No matter how much we scream, users will be
confused because it seems these bugs only affect loops of a very specific form.
On the other hand if it makes our code messy or confusing or slows things down,
we should not do this.
I will look into this new negative vint bug, it might only affect pulsing, and
see if i can make a test case+workaround for it.
> jrebug causes porter stemmer to sigsegv
> ---
>
> Key: LUCENE-3335
> URL: https://issues.apache.org/jira/browse/LUCENE-3335
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Robert Muir
> Labels: Java7
> Attachments: LUCENE-3335.patch, LUCENE-3335_slow.patch,
> patch-0uwe.patch
>
>
> happens easily on java7: ant test -Dtestcase=TestPorterStemFilter
> -Dtests.iter=100
> might happen on 1.6.0_u26 too, a user reported something that looks like the
> same bug already:
> http://www.lucidimagination.com/search/document/3beaa082c4d2fdd4/porterstemfilter_kills_jvm
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-3.x - Build # 9782 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/9782/ 1 tests failed. REGRESSION: org.apache.solr.client.solrj.TestLBHttpSolrServer.testReliability Error Message: No live SolrServers available to handle this request Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request at org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:222) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:89) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:118) at org.apache.solr.client.solrj.TestLBHttpSolrServer.waitForServer(TestLBHttpSolrServer.java:189) at org.apache.solr.client.solrj.TestLBHttpSolrServer.testReliability(TestLBHttpSolrServer.java:182) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1335) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1240) Caused by: org.apache.solr.client.solrj.SolrServerException: java.net.SocketTimeoutException: Read timed out at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:478) at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:206) Caused by: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:146) at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at java.io.BufferedInputStream.read(BufferedInputStream.java:254) at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78) at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106) at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1413) at org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973) at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098) at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323) at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:422) Build Log (for compile errors): [...truncated 13660 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 # 48 - Failure
Hmmm, well this is odd. After the last fix, I changed the 1 operations to 10M and ran the test a few times. I'll crank it up even further and let the test run for a few hours. -Yonik http://www.lucidimagination.com On Tue, Jul 26, 2011 at 5:57 PM, Apache Jenkins Server wrote: > Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/48/ > > 1 tests failed. > REGRESSION: org.apache.solr.search.TestRealTimeGet.testStressGetRealtime > > Error Message: > Some threads threw uncaught exceptions! > > Stack Trace: > junit.framework.AssertionFailedError: Some threads threw uncaught exceptions! > at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1522) > at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1427) > at > org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:639) > at org.apache.solr.SolrTestCaseJ4.tearDown(SolrTestCaseJ4.java:99) > > > > > Build Log (for compile errors): > [...truncated 11245 lines...] > > > > - > 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
[JENKINS] Lucene-3.x - Build # 451 - Failure
Build: https://builds.apache.org/job/Lucene-3.x/451/ No tests ran. Build Log (for compile errors): [...truncated 8045 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2665) Solr Post Group Faceting
[ https://issues.apache.org/jira/browse/SOLR-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn van Groningen updated SOLR-2665: Attachment: SOLR-2665.patch Added initial patch with basic test. You can enable post grouping facets and post grouping statistics by using the following parameter: group.after=true|false The default is false. Better names are welcome. I initially wanted to name it group.groupBasedDocSet. Because the DocSet used by faceting and statistics is based on groups. The docset is computed based on the first field / func command. > Solr Post Group Faceting > > > Key: SOLR-2665 > URL: https://issues.apache.org/jira/browse/SOLR-2665 > Project: Solr > Issue Type: New Feature >Affects Versions: 3.3 >Reporter: Bill Bell >Assignee: Martijn van Groningen > Fix For: 3.4, 4.0 > > Attachments: SOLR-2665.patch > > > Once Lucene is wired, add this feature to Solr. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 48 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/48/ 1 tests failed. REGRESSION: org.apache.solr.search.TestRealTimeGet.testStressGetRealtime Error Message: Some threads threw uncaught exceptions! Stack Trace: junit.framework.AssertionFailedError: Some threads threw uncaught exceptions! at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1522) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1427) at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:639) at org.apache.solr.SolrTestCaseJ4.tearDown(SolrTestCaseJ4.java:99) Build Log (for compile errors): [...truncated 11245 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-java7 - Build # 46 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/46/ 1 tests failed. FAILED: org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest.testMultiThreaded Error Message: expected:<500> but was:<300> Stack Trace: junit.framework.AssertionFailedError: expected:<500> but was:<300> at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1522) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1427) at org.apache.solr.client.solrj.LargeVolumeTestBase.query(LargeVolumeTestBase.java:70) at org.apache.solr.client.solrj.LargeVolumeTestBase.testMultiThreaded(LargeVolumeTestBase.java:61) Build Log (for compile errors): [...truncated 12334 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3335) jrebug causes porter stemmer to sigsegv
[ https://issues.apache.org/jira/browse/LUCENE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071348#comment-13071348 ] Uwe Schindler commented on LUCENE-3335: --- Here the final patch for OpenJDK including Porter.java as testcase: - [http://cr.openjdk.java.net/~kvn/7070134/webrev/7070134.patch] (see also [http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-July/005972.html], [http://cr.openjdk.java.net/~kvn/7070134/webrev/]) For the full bugfix, also the following fixes are needed: - [http://cr.openjdk.java.net/~kvn/7044738/webrev/7044738.patch] - [http://cr.openjdk.java.net/~kvn/7068051/webrev/7068051.patch] All three were applied to Jenkins' OpenJDK7 (excluding the testcases). > jrebug causes porter stemmer to sigsegv > --- > > Key: LUCENE-3335 > URL: https://issues.apache.org/jira/browse/LUCENE-3335 > Project: Lucene - Java > Issue Type: Bug >Reporter: Robert Muir > Labels: Java7 > Attachments: LUCENE-3335.patch, LUCENE-3335_slow.patch, > patch-0uwe.patch > > > happens easily on java7: ant test -Dtestcase=TestPorterStemFilter > -Dtests.iter=100 > might happen on 1.6.0_u26 too, a user reported something that looks like the > same bug already: > http://www.lucidimagination.com/search/document/3beaa082c4d2fdd4/porterstemfilter_kills_jvm -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 45 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/45/ 1 tests failed. REGRESSION: org.apache.solr.search.TestRealTimeGet.testStressGetRealtime Error Message: Some threads threw uncaught exceptions! Stack Trace: junit.framework.AssertionFailedError: Some threads threw uncaught exceptions! at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1522) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1427) at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:639) at org.apache.solr.SolrTestCaseJ4.tearDown(SolrTestCaseJ4.java:99) Build Log (for compile errors): [...truncated 11246 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-3.x-java7 - Build # 38 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/38/ 1 tests failed. REGRESSION: org.apache.solr.handler.component.DistributedTermsComponentTest.testDistribSearch Error Message: Some threads threw uncaught exceptions! Stack Trace: junit.framework.AssertionFailedError: Some threads threw uncaught exceptions! at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1335) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1240) at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:495) at org.apache.solr.SolrTestCaseJ4.tearDown(SolrTestCaseJ4.java:96) at org.apache.solr.BaseDistributedSearchTestCase.tearDown(BaseDistributedSearchTestCase.java:160) Build Log (for compile errors): [...truncated 13401 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3335) jrebug causes porter stemmer to sigsegv
[ https://issues.apache.org/jira/browse/LUCENE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071326#comment-13071326 ] Uwe Schindler commented on LUCENE-3335: --- Link to the message: [http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-July/005971.html] > jrebug causes porter stemmer to sigsegv > --- > > Key: LUCENE-3335 > URL: https://issues.apache.org/jira/browse/LUCENE-3335 > Project: Lucene - Java > Issue Type: Bug >Reporter: Robert Muir > Labels: Java7 > Attachments: LUCENE-3335.patch, LUCENE-3335_slow.patch, > patch-0uwe.patch > > > happens easily on java7: ant test -Dtestcase=TestPorterStemFilter > -Dtests.iter=100 > might happen on 1.6.0_u26 too, a user reported something that looks like the > same bug already: > http://www.lucidimagination.com/search/document/3beaa082c4d2fdd4/porterstemfilter_kills_jvm -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3335) jrebug causes porter stemmer to sigsegv
[
https://issues.apache.org/jira/browse/LUCENE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071324#comment-13071324
]
Uwe Schindler commented on LUCENE-3335:
---
Response from the Hotspot mailing list about their release plans:
{quote}
Thank you, Uwe
I will send the patch for reviews shortly.
About java 7 release. We are late to do any bugs fixes in GA which should
happen soon. All loop optimization fixes will go definitely into jdk7 update 2.
We will try to push them into update 1 (which is targeted only for security
fixes) but we can't promise.
There is going discussion about using current Hotspot VM in future jdk6 updates
but there is no decision yet. Note: current Hotspot VM sources are targeted for
JDK8 and jdk7 updates only.
Regards,
Vladimir
{quote}
This means, Java 7 will come out with heavy broken loops (so almost for any for
or while loop you cannot make sure that it is still working correct when
executed 10thousand times.
What do others mean. Should we place a warning on the "Download" and "News"
page on Solr and Lucene website? The risk is high that you corrupt your index,
if you index using these JDK versions. Also the default configuration of Solr
will SIGSEGV.
We should also inform the user mailing lists.
I can prepare something and we can discuss? Oracle JDK 1.7.0 GA will be
released on July 28th, according to Oracle's press releases. At least on that
day we should have something available to present to the users.
> jrebug causes porter stemmer to sigsegv
> ---
>
> Key: LUCENE-3335
> URL: https://issues.apache.org/jira/browse/LUCENE-3335
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Robert Muir
> Labels: Java7
> Attachments: LUCENE-3335.patch, LUCENE-3335_slow.patch,
> patch-0uwe.patch
>
>
> happens easily on java7: ant test -Dtestcase=TestPorterStemFilter
> -Dtests.iter=100
> might happen on 1.6.0_u26 too, a user reported something that looks like the
> same bug already:
> http://www.lucidimagination.com/search/document/3beaa082c4d2fdd4/porterstemfilter_kills_jvm
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 39 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/39/ 1 tests failed. REGRESSION: org.apache.solr.cloud.CloudStateUpdateTest.testCoreRegistration Error Message: expected:<2> but was:<3> Stack Trace: junit.framework.AssertionFailedError: expected:<2> but was:<3> at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1522) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1427) at org.apache.solr.cloud.CloudStateUpdateTest.testCoreRegistration(CloudStateUpdateTest.java:198) Build Log (for compile errors): [...truncated 11269 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3344) Add workaround for ICU bug in combination with Java7 to LuceneTestCase
[ https://issues.apache.org/jira/browse/LUCENE-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-3344. --- Resolution: Fixed Committed trunk revision: 1151146 Committed 3.x revision: 1151148 > Add workaround for ICU bug in combination with Java7 to LuceneTestCase > -- > > Key: LUCENE-3344 > URL: https://issues.apache.org/jira/browse/LUCENE-3344 > Project: Lucene - Java > Issue Type: Bug > Components: modules/analysis > Environment: JDK7 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Labels: Java7 > Fix For: 3.4, 4.0 > > Attachments: LUCENE-3344.patch > > > There is a bug in ICU that makes it fail to load it ULocale class in Java7: > http://bugs.icu-project.org/trac/ticket/8734 > The problem is caused by some new locales in Java 7, that lead to a > chicken-and-egg problem in the static initializer of ULocale. It initializes > its default locale from the JDK locale in a static ctor. Until the default > ULocale instance is created, the default is not set in ULocale. But ULocales > ctor itsself needs the default locale to fetch some ressource bundles and > throws NPE. > The code in LuceneTestCase that randomizes the default locale should > classload ULocale before it tries to set another random locale, using a > defined, safe locale (Locale.US). Patch is easy. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3344) Add workaround for ICU bug in combination with Java7 to LuceneTestCase
[ https://issues.apache.org/jira/browse/LUCENE-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071176#comment-13071176 ] Robert Muir commented on LUCENE-3344: - nice workaround! +1 to commit > Add workaround for ICU bug in combination with Java7 to LuceneTestCase > -- > > Key: LUCENE-3344 > URL: https://issues.apache.org/jira/browse/LUCENE-3344 > Project: Lucene - Java > Issue Type: Bug > Components: modules/analysis > Environment: JDK7 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Labels: Java7 > Fix For: 3.4, 4.0 > > Attachments: LUCENE-3344.patch > > > There is a bug in ICU that makes it fail to load it ULocale class in Java7: > http://bugs.icu-project.org/trac/ticket/8734 > The problem is caused by some new locales in Java 7, that lead to a > chicken-and-egg problem in the static initializer of ULocale. It initializes > its default locale from the JDK locale in a static ctor. Until the default > ULocale instance is created, the default is not set in ULocale. But ULocales > ctor itsself needs the default locale to fetch some ressource bundles and > throws NPE. > The code in LuceneTestCase that randomizes the default locale should > classload ULocale before it tries to set another random locale, using a > defined, safe locale (Locale.US). Patch is easy. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3344) Add workaround for ICU bug in combination with Java7 to LuceneTestCase
[ https://issues.apache.org/jira/browse/LUCENE-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-3344: -- Attachment: LUCENE-3344.patch Patch that tries to init ICU's ULocale before randomization by a simple Class.forName(). If ICU is not in classpath, its a no-op. Will commit soon. > Add workaround for ICU bug in combination with Java7 to LuceneTestCase > -- > > Key: LUCENE-3344 > URL: https://issues.apache.org/jira/browse/LUCENE-3344 > Project: Lucene - Java > Issue Type: Bug > Components: modules/analysis > Environment: JDK7 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Labels: Java7 > Fix For: 3.4, 4.0 > > Attachments: LUCENE-3344.patch > > > There is a bug in ICU that makes it fail to load it ULocale class in Java7: > http://bugs.icu-project.org/trac/ticket/8734 > The problem is caused by some new locales in Java 7, that lead to a > chicken-and-egg problem in the static initializer of ULocale. It initializes > its default locale from the JDK locale in a static ctor. Until the default > ULocale instance is created, the default is not set in ULocale. But ULocales > ctor itsself needs the default locale to fetch some ressource bundles and > throws NPE. > The code in LuceneTestCase that randomizes the default locale should > classload ULocale before it tries to set another random locale, using a > defined, safe locale (Locale.US). Patch is easy. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3344) Add workaround for ICU bug in combination with Java7 to LuceneTestCase
Add workaround for ICU bug in combination with Java7 to LuceneTestCase -- Key: LUCENE-3344 URL: https://issues.apache.org/jira/browse/LUCENE-3344 Project: Lucene - Java Issue Type: Bug Components: modules/analysis Environment: JDK7 Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 3.4, 4.0 There is a bug in ICU that makes it fail to load it ULocale class in Java7: http://bugs.icu-project.org/trac/ticket/8734 The problem is caused by some new locales in Java 7, that lead to a chicken-and-egg problem in the static initializer of ULocale. It initializes its default locale from the JDK locale in a static ctor. Until the default ULocale instance is created, the default is not set in ULocale. But ULocales ctor itsself needs the default locale to fetch some ressource bundles and throws NPE. The code in LuceneTestCase that randomizes the default locale should classload ULocale before it tries to set another random locale, using a defined, safe locale (Locale.US). Patch is easy. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3337) avoid building jar files unless necessary in build
[
https://issues.apache.org/jira/browse/LUCENE-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071169#comment-13071169
]
Steven Rowe commented on LUCENE-3337:
-
When I look at the output from {{ant -v example}} after applying my version of
the patch, I can see that the {{compile-test}} target is called 16 times from
{{lucene/build.xml}}. Seems like it could be sped up through more/better
property passing. And why should building a module's jar trigger compilation
of Lucene's tests?
> avoid building jar files unless necessary in build
> --
>
> Key: LUCENE-3337
> URL: https://issues.apache.org/jira/browse/LUCENE-3337
> Project: Lucene - Java
> Issue Type: Bug
> Components: general/build
>Affects Versions: 3.4, 4.0
>Reporter: Robert Muir
> Attachments: LUCENE-3337.patch, LUCENE-3337.patch, LUCENE-3337.patch,
> LUCENE-3337.patch
>
>
> This causes the build to be slow, we can avoid it in lots of cases (e.g. ant
> test)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2675) Support core properties when creating cores via REST API (CoreAdminHandler)
[ https://issues.apache.org/jira/browse/SOLR-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Kats updated SOLR-2675: Component/s: (was: Build) multicore > Support core properties when creating cores via REST API (CoreAdminHandler) > --- > > Key: SOLR-2675 > URL: https://issues.apache.org/jira/browse/SOLR-2675 > Project: Solr > Issue Type: Improvement > Components: multicore >Affects Versions: 4.0 >Reporter: Yury Kats > Attachments: coreadmin.patch > > > When crating cores through solr.xml, I am able to specify custom > properties, to be referenced in solrconfig.xml. For example: > > > > > > > > > > > There does not seem a way to specify such properties when creating cores > through the CoreAdminHandler request. > CoreAdminHandler#handleCreateAction always calls > dcore.setCoreProperties(null); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2675) Support core properties when creating cores via REST API (CoreAdminHandler)
[ https://issues.apache.org/jira/browse/SOLR-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Kats updated SOLR-2675: Attachment: coreadmin.patch Patch against the trunk. CoreAdminHandler#handleCreateAction looks at request parameters in format property.name=value and uses them as name=value properties when creating a core. > Support core properties when creating cores via REST API (CoreAdminHandler) > --- > > Key: SOLR-2675 > URL: https://issues.apache.org/jira/browse/SOLR-2675 > Project: Solr > Issue Type: Improvement > Components: multicore >Affects Versions: 4.0 >Reporter: Yury Kats > Attachments: coreadmin.patch > > > When crating cores through solr.xml, I am able to specify custom > properties, to be referenced in solrconfig.xml. For example: > > > > > > > > > > > There does not seem a way to specify such properties when creating cores > through the CoreAdminHandler request. > CoreAdminHandler#handleCreateAction always calls > dcore.setCoreProperties(null); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2675) Support core properties when creating cores via REST API (CoreAdminHandler)
Support core properties when creating cores via REST API (CoreAdminHandler) --- Key: SOLR-2675 URL: https://issues.apache.org/jira/browse/SOLR-2675 Project: Solr Issue Type: Improvement Components: Build Affects Versions: 4.0 Reporter: Yury Kats When crating cores through solr.xml, I am able to specify custom properties, to be referenced in solrconfig.xml. For example: There does not seem a way to specify such properties when creating cores through the CoreAdminHandler request. CoreAdminHandler#handleCreateAction always calls dcore.setCoreProperties(null); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2242) Get distinct count of names for a facet field
[
https://issues.apache.org/jira/browse/SOLR-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071162#comment-13071162
]
Ryan McKinley commented on SOLR-2242:
-
bq. Perhaps we should return the maximum and sum of all shard counts? That way,
assuming the client knew how many shards exist, they could handle most
scenarios.
Once we change the output format, we should be able to add a few thigns to the
output. Perhaps something like
{code:xml}
385
385
845
...
{code}
> Get distinct count of names for a facet field
> -
>
> Key: SOLR-2242
> URL: https://issues.apache.org/jira/browse/SOLR-2242
> Project: Solr
> Issue Type: New Feature
> Components: Response Writers
>Affects Versions: 4.0
>Reporter: Bill Bell
>Assignee: Simon Willnauer
>Priority: Minor
> Fix For: 4.0
>
> Attachments: NumFacetTermsFacetsTest.java,
> SOLR-2242-notworkingtest.patch, SOLR-2242.patch, SOLR-2242.patch,
> SOLR-2242.shard.patch, SOLR-2242.shard.patch,
> SOLR-2242.shard.withtests.patch, SOLR-2242.solr3.1.patch,
> SOLR.2242.solr3.1.patch, SOLR.2242.v2.patch
>
>
> When returning facet.field= you will get a list of matches for
> distinct values. This is normal behavior. This patch tells you how many
> distinct values you have (# of rows). Use with limit=-1 and mincount=1.
> The feature is called "namedistinct". Here is an example:
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=2&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=0&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=1&facet.limit=-1&facet.field=price
> This currently only works on facet.field.
> {code}
>
>
> 14
> 31 name="19.95">111 name="179.99">111 name="329.95">111 name="479.95">111
>
>
> {code}
> Several people use this to get the group.field count (the # of groups).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3337) avoid building jar files unless necessary in build
[
https://issues.apache.org/jira/browse/LUCENE-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3337:
Attachment: LUCENE-3337.patch
{quote}
I plan on looking next at the utility of the *.compiled & *.uptodate property
passing scheme - you mentioned on #lucene IRC that it didn't seem to be having
any effect on the build.
{quote}
The properties were being passed in as intended, but the {{}} tasks
were still running, since their execution was not dependent on the
already-defined values of {{\*.uptodate}} output properties.
The attached version of the patch, which includes Robert's latest patch, wraps
the {{}} tasks in {{check-\*\-uptodate}} targets, and makes the
{{compile-\*}} targets depend on them, so that the {{}} tasks only
run when the corresponding {{\*.update}} property value has not previously been
set.
The only problem with this approach is that the {{\*.jar}} properties aren't
constructed properly, since the property passing scheme only works one-way
(properties are passed into {{}} invocations, but not back out of them).
I worked around this problem by defining the {{\*.jar}} properties statically.
My build times now:
||task||trunk||patch||patch w/property passing optimizations||
|ant example (clean checkout)|180s|119s|93s|
|ant example (already compiled)|132s|61s|55s|
This shaves a few more seconds off my build time.
> avoid building jar files unless necessary in build
> --
>
> Key: LUCENE-3337
> URL: https://issues.apache.org/jira/browse/LUCENE-3337
> Project: Lucene - Java
> Issue Type: Bug
> Components: general/build
>Affects Versions: 3.4, 4.0
>Reporter: Robert Muir
> Attachments: LUCENE-3337.patch, LUCENE-3337.patch, LUCENE-3337.patch,
> LUCENE-3337.patch
>
>
> This causes the build to be slow, we can avoid it in lots of cases (e.g. ant
> test)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-3.x-java7 - Build # 29 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/29/ 1 tests failed. FAILED: org.apache.lucene.index.TestIndexWriterDelete.testFlushPushedDeletesByCount Error Message: delete's were not applied at count=6100 Stack Trace: junit.framework.AssertionFailedError: delete's were not applied at count=6100 at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1316) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1221) at org.apache.lucene.index.TestIndexWriterDelete.testFlushPushedDeletesByCount(TestIndexWriterDelete.java:1030) Build Log (for compile errors): [...truncated 7071 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-3.x-java7 - Build # 28 - Still Failing
I committed a fix for this -- this was a new bug, only in 3.x, uncovered by the test cases added for LUCENE-3340. Mike McCandless http://blog.mikemccandless.com On Tue, Jul 26, 2011 at 11:05 AM, Apache Jenkins Server wrote: > Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/28/ > > 1 tests failed. > FAILED: > org.apache.lucene.index.TestIndexWriterDelete.testFlushPushedDeletesByCount > > Error Message: > delete's were not applied at count=5868 > > Stack Trace: > junit.framework.AssertionFailedError: delete's were not applied at count=5868 > at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1316) > at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1221) > at > org.apache.lucene.index.TestIndexWriterDelete.testFlushPushedDeletesByCount(TestIndexWriterDelete.java:1030) > > > > > Build Log (for compile errors): > [...truncated 7064 lines...] > > > > - > 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
[jira] [Issue Comment Edited] (SOLR-2242) Get distinct count of names for a facet field
[
https://issues.apache.org/jira/browse/SOLR-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071156#comment-13071156
]
Chris Male edited comment on SOLR-2242 at 7/26/11 3:28 PM:
---
{quote}
That seems reasonable – though I think we would also want to be able to have
the sum when you know that all shards have unique values.
{quote}
Perhaps we should return the maximum and sum of all shard counts? That way,
assuming the client knew how many shards exist, they could handle most
scenarios.
{quote}
I don't think bill is referring to the accuracy/meaning of distinct count in
distributed search. His problem is that if we change the output format, we also
need to update the code that collects the various values and passes them along.
This patch just add a magic value (numFacetTerms) to the count list so that the
value is handled with existing distributed response parsing. This is a fine
one-off solution, but I am -1 for adding any more magic field names to solr. To
add this feature, i think we need to bite the bullet and update the facet
response format.
{quote}
Absolutely. I hadn't even considered the prospect of not changing the
distributed response parsing.
was (Author: cmale):
{code}
That seems reasonable – though I think we would also want to be able to have
the sum when you know that all shards have unique values.
{code}
Perhaps we should return the maximum and sum of all shard counts? That way,
assuming the client knew how many shards exist, they could handle most
scenarios.
{code}
I don't think bill is referring to the accuracy/meaning of distinct count in
distributed search. His problem is that if we change the output format, we also
need to update the code that collects the various values and passes them along.
This patch just add a magic value (numFacetTerms) to the count list so that the
value is handled with existing distributed response parsing. This is a fine
one-off solution, but I am -1 for adding any more magic field names to solr. To
add this feature, i think we need to bite the bullet and update the facet
response format.
{code}
Absolutely. I hadn't even considered the prospect of not changing the
distributed response parsing.
> Get distinct count of names for a facet field
> -
>
> Key: SOLR-2242
> URL: https://issues.apache.org/jira/browse/SOLR-2242
> Project: Solr
> Issue Type: New Feature
> Components: Response Writers
>Affects Versions: 4.0
>Reporter: Bill Bell
>Assignee: Simon Willnauer
>Priority: Minor
> Fix For: 4.0
>
> Attachments: NumFacetTermsFacetsTest.java,
> SOLR-2242-notworkingtest.patch, SOLR-2242.patch, SOLR-2242.patch,
> SOLR-2242.shard.patch, SOLR-2242.shard.patch,
> SOLR-2242.shard.withtests.patch, SOLR-2242.solr3.1.patch,
> SOLR.2242.solr3.1.patch, SOLR.2242.v2.patch
>
>
> When returning facet.field= you will get a list of matches for
> distinct values. This is normal behavior. This patch tells you how many
> distinct values you have (# of rows). Use with limit=-1 and mincount=1.
> The feature is called "namedistinct". Here is an example:
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=2&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=0&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=1&facet.limit=-1&facet.field=price
> This currently only works on facet.field.
> {code}
>
>
> 14
> 31 name="19.95">111 name="179.99">111 name="329.95">111 name="479.95">111
>
>
> {code}
> Several people use this to get the group.field count (the # of groups).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2242) Get distinct count of names for a facet field
[
https://issues.apache.org/jira/browse/SOLR-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071156#comment-13071156
]
Chris Male commented on SOLR-2242:
--
{code}
That seems reasonable – though I think we would also want to be able to have
the sum when you know that all shards have unique values.
{code}
Perhaps we should return the maximum and sum of all shard counts? That way,
assuming the client knew how many shards exist, they could handle most
scenarios.
{code}
I don't think bill is referring to the accuracy/meaning of distinct count in
distributed search. His problem is that if we change the output format, we also
need to update the code that collects the various values and passes them along.
This patch just add a magic value (numFacetTerms) to the count list so that the
value is handled with existing distributed response parsing. This is a fine
one-off solution, but I am -1 for adding any more magic field names to solr. To
add this feature, i think we need to bite the bullet and update the facet
response format.
{code}
Absolutely. I hadn't even considered the prospect of not changing the
distributed response parsing.
> Get distinct count of names for a facet field
> -
>
> Key: SOLR-2242
> URL: https://issues.apache.org/jira/browse/SOLR-2242
> Project: Solr
> Issue Type: New Feature
> Components: Response Writers
>Affects Versions: 4.0
>Reporter: Bill Bell
>Assignee: Simon Willnauer
>Priority: Minor
> Fix For: 4.0
>
> Attachments: NumFacetTermsFacetsTest.java,
> SOLR-2242-notworkingtest.patch, SOLR-2242.patch, SOLR-2242.patch,
> SOLR-2242.shard.patch, SOLR-2242.shard.patch,
> SOLR-2242.shard.withtests.patch, SOLR-2242.solr3.1.patch,
> SOLR.2242.solr3.1.patch, SOLR.2242.v2.patch
>
>
> When returning facet.field= you will get a list of matches for
> distinct values. This is normal behavior. This patch tells you how many
> distinct values you have (# of rows). Use with limit=-1 and mincount=1.
> The feature is called "namedistinct". Here is an example:
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=2&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=0&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=1&facet.limit=-1&facet.field=price
> This currently only works on facet.field.
> {code}
>
>
> 14
> 31 name="19.95">111 name="179.99">111 name="329.95">111 name="479.95">111
>
>
> {code}
> Several people use this to get the group.field count (the # of groups).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2242) Get distinct count of names for a facet field
[
https://issues.apache.org/jira/browse/SOLR-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071147#comment-13071147
]
Ryan McKinley commented on SOLR-2242:
-
bq. The simplest option seems to be to return the max constraint count taken
from all the shards
That seems reasonable -- though I think we would also want to be able to have
the sum when you know that all shards have unique values.
I don't think bill is referring to the accuracy/meaning of distinct count in
distributed search. His problem is that if we change the output format, we
also need to update the code that collects the various values and passes them
along. This patch just add a magic value (numFacetTerms) to the count list so
that the value is handled with existing distributed response parsing. This is
a fine one-off solution, but I am -1 for adding any more magic field names to
solr. To add this feature, i think we need to bite the bullet and update the
facet response format.
> Get distinct count of names for a facet field
> -
>
> Key: SOLR-2242
> URL: https://issues.apache.org/jira/browse/SOLR-2242
> Project: Solr
> Issue Type: New Feature
> Components: Response Writers
>Affects Versions: 4.0
>Reporter: Bill Bell
>Assignee: Simon Willnauer
>Priority: Minor
> Fix For: 4.0
>
> Attachments: NumFacetTermsFacetsTest.java,
> SOLR-2242-notworkingtest.patch, SOLR-2242.patch, SOLR-2242.patch,
> SOLR-2242.shard.patch, SOLR-2242.shard.patch,
> SOLR-2242.shard.withtests.patch, SOLR-2242.solr3.1.patch,
> SOLR.2242.solr3.1.patch, SOLR.2242.v2.patch
>
>
> When returning facet.field= you will get a list of matches for
> distinct values. This is normal behavior. This patch tells you how many
> distinct values you have (# of rows). Use with limit=-1 and mincount=1.
> The feature is called "namedistinct". Here is an example:
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=2&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=0&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=1&facet.limit=-1&facet.field=price
> This currently only works on facet.field.
> {code}
>
>
> 14
> 31 name="19.95">111 name="179.99">111 name="329.95">111 name="479.95">111
>
>
> {code}
> Several people use this to get the group.field count (the # of groups).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 34 - Failure
Yonik, same problem still there:
[junit] NOTE: reproduce with: ant test -Dtestcase=TestRealTimeGet
-Dtestmethod=testStressGetRealtime
-Dtests.seed=-5497110170060928176:-4129666932955567608 -Dtests.multiplier=3
[junit] The following exceptions were thrown by threads:
[junit] *** Thread: READER0 ***
[junit] java.lang.AssertionError: java.lang.AssertionError: expected:<1>
but was:<2>
[junit] at org.junit.Assert.fail(Assert.java:91)
[junit] at
org.apache.solr.search.TestRealTimeGet$2.run(TestRealTimeGet.java:239)
[junit] *** Thread: READER6 ***
[junit] java.lang.AssertionError: java.lang.AssertionError: expected:<1>
but was:<2>
[junit] at org.junit.Assert.fail(Assert.java:91)
[junit] at
org.apache.solr.search.TestRealTimeGet$2.run(TestRealTimeGet.java:239)
[junit] NOTE: test params are: codec=RandomCodecProvider:
{id=MockVariableIntBlock(baseBlockSize=15), val_l=MockSep}, locale=ar_DZ,
timezone=GMT0
[junit] NOTE: all tests run in this JVM:
[junit] [ConvertedLegacyTest, TestTrie, CommonGramsQueryFilterFactoryTest,
TestCJKTokenizerFactory, TestIndonesianStemFilterFactory,
TestKStemFilterFactory, TestKeepFilterFactory, TestLatvianStemFilterFactory,
TestMappingCharFilterFactory, TestPatternReplaceFilterFactory,
TestPortugueseLightStemFilterFactory, RAMDirectoryFactoryTest, TestConfig,
TestPropInjectDefaults, JsonLoaderTest, DistributedTermsComponentTest,
TermVectorComponentTest, FastVectorHighlighterTest, TestCSVResponseWriter,
DateFieldTest, TestDocSet, TestRealTimeGet]
[junit] NOTE: FreeBSD 8.2-RELEASE amd64/Oracle Corporation 1.7.0
(64-bit)/cpus=16,threads=8,free=205637192,total=240648192
[junit] - ---
[junit] TEST org.apache.solr.search.TestRealTimeGet FAILED
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
> Sent: Tuesday, July 26, 2011 4:54 PM
> To: dev@lucene.apache.org
> Subject: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 34 - Failure
>
> Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/34/
>
> 1 tests failed.
> REGRESSION:
> org.apache.solr.search.TestRealTimeGet.testStressGetRealtime
>
> Error Message:
> Some threads threw uncaught exceptions!
>
> Stack Trace:
> junit.framework.AssertionFailedError: Some threads threw uncaught
> exceptions!
> at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc
> eneTestCase.java:1503)
> at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc
> eneTestCase.java:1408)
> at
> org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:620)
> at org.apache.solr.SolrTestCaseJ4.tearDown(SolrTestCaseJ4.java:99)
>
>
>
>
> Build Log (for compile errors):
> [...truncated 11269 lines...]
>
>
>
> -
> 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
[JENKINS] Lucene-Solr-tests-only-3.x-java7 - Build # 28 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/28/ 1 tests failed. FAILED: org.apache.lucene.index.TestIndexWriterDelete.testFlushPushedDeletesByCount Error Message: delete's were not applied at count=5868 Stack Trace: junit.framework.AssertionFailedError: delete's were not applied at count=5868 at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1316) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1221) at org.apache.lucene.index.TestIndexWriterDelete.testFlushPushedDeletesByCount(TestIndexWriterDelete.java:1030) Build Log (for compile errors): [...truncated 7064 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-java7 - Build # 34 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/34/ 1 tests failed. REGRESSION: org.apache.solr.search.TestRealTimeGet.testStressGetRealtime Error Message: Some threads threw uncaught exceptions! Stack Trace: junit.framework.AssertionFailedError: Some threads threw uncaught exceptions! at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1503) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1408) at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:620) at org.apache.solr.SolrTestCaseJ4.tearDown(SolrTestCaseJ4.java:99) Build Log (for compile errors): [...truncated 11269 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-3.x-java7 - Build # 27 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/27/ 1 tests failed. FAILED: org.apache.lucene.index.TestIndexWriterDelete.testFlushPushedDeletesByCount Error Message: delete's were not applied at count=6762 Stack Trace: junit.framework.AssertionFailedError: delete's were not applied at count=6762 at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1316) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1221) at org.apache.lucene.index.TestIndexWriterDelete.testFlushPushedDeletesByCount(TestIndexWriterDelete.java:1030) Build Log (for compile errors): [...truncated 7067 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-3.x-java7 - Build # 26 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/26/ 1 tests failed. FAILED: org.apache.lucene.index.TestIndexWriterDelete.testFlushPushedDeletesByCount Error Message: delete's were not applied at count=7330 Stack Trace: junit.framework.AssertionFailedError: delete's were not applied at count=7330 at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1316) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1221) at org.apache.lucene.index.TestIndexWriterDelete.testFlushPushedDeletesByCount(TestIndexWriterDelete.java:1030) Build Log (for compile errors): [...truncated 7064 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-java7 - Build # 31 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/31/ 1 tests failed. REGRESSION: org.apache.solr.search.TestRealTimeGet.testStressGetRealtime Error Message: Some threads threw uncaught exceptions! Stack Trace: junit.framework.AssertionFailedError: Some threads threw uncaught exceptions! at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1503) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1408) at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:620) at org.apache.solr.SolrTestCaseJ4.tearDown(SolrTestCaseJ4.java:99) Build Log (for compile errors): [...truncated 11263 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 # 30 - Failure
I'm looking at this: its an icu issue. On Tue, Jul 26, 2011 at 9:54 AM, Apache Jenkins Server wrote: > Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/30/ > > 4 tests failed. > REGRESSION: > org.apache.solr.analysis.TestICUCollationKeyFilterFactory.testCustomRules > > Error Message: > null > > Stack Trace: > java.lang.ExceptionInInitializerError > at > org.apache.solr.analysis.TestICUCollationKeyFilterFactory.testCustomRules(TestICUCollationKeyFilterFactory.java:110) > at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1503) > at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1408) > Caused by: java.lang.NullPointerException > at > com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundle.java:840) > at > com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundle.java:815) > at > com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489) > at > com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.java:536) > at > com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.java:144) > at > com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.java:124) > at com.ibm.icu.util.ULocale.bcp47ToLDMLKey(ULocale.java:3410) > at com.ibm.icu.util.ULocale.access$400(ULocale.java:107) > at > com.ibm.icu.util.ULocale$JDKLocaleMapper.toULocale7(ULocale.java:3691) > at > com.ibm.icu.util.ULocale$JDKLocaleMapper.toULocale(ULocale.java:3566) > at com.ibm.icu.util.ULocale.forLocale(ULocale.java:399) > at com.ibm.icu.util.ULocale.(ULocale.java:380) > at com.ibm.icu.util.ULocale.(ULocale.java:516) > > > REGRESSION: > org.apache.solr.analysis.TestICUCollationKeyFilterFactory.testBasicUsage > > Error Message: > Could not initialize class com.ibm.icu.util.ULocale > > Stack Trace: > java.lang.NoClassDefFoundError: Could not initialize class > com.ibm.icu.util.ULocale > at > org.apache.solr.analysis.ICUCollationKeyFilterFactory.createFromLocale(ICUCollationKeyFilterFactory.java:124) > at > org.apache.solr.analysis.ICUCollationKeyFilterFactory.inform(ICUCollationKeyFilterFactory.java:82) > at > org.apache.solr.analysis.TestICUCollationKeyFilterFactory.testBasicUsage(TestICUCollationKeyFilterFactory.java:54) > at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1503) > at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1408) > > > REGRESSION: > org.apache.solr.analysis.TestICUCollationKeyFilterFactory.testNormalization > > Error Message: > Could not initialize class com.ibm.icu.util.ULocale > > Stack Trace: > java.lang.NoClassDefFoundError: Could not initialize class > com.ibm.icu.util.ULocale > at > org.apache.solr.analysis.ICUCollationKeyFilterFactory.createFromLocale(ICUCollationKeyFilterFactory.java:124) > at > org.apache.solr.analysis.ICUCollationKeyFilterFactory.inform(ICUCollationKeyFilterFactory.java:82) > at > org.apache.solr.analysis.TestICUCollationKeyFilterFactory.testNormalization(TestICUCollationKeyFilterFactory.java:74) > at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1503) > at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1408) > > > REGRESSION: > org.apache.solr.analysis.TestICUCollationKeyFilterFactory.testSecondaryStrength > > Error Message: > Could not initialize class com.ibm.icu.util.ULocale > > Stack Trace: > java.lang.NoClassDefFoundError: Could not initialize class > com.ibm.icu.util.ULocale > at > org.apache.solr.analysis.ICUCollationKeyFilterFactory.createFromLocale(ICUCollationKeyFilterFactory.java:124) > at > org.apache.solr.analysis.ICUCollationKeyFilterFactory.inform(ICUCollationKeyFilterFactory.java:82) > at > org.apache.solr.analysis.TestICUCollationKeyFilterFactory.testSecondaryStrength(TestICUCollationKeyFilterFactory.java:94) > at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1503) > at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1408) > > > > > Build Log (for compile errors): > [...truncated 15358 lines...] > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- lucidimagination.com - 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 # 30 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/30/ 4 tests failed. REGRESSION: org.apache.solr.analysis.TestICUCollationKeyFilterFactory.testCustomRules Error Message: null Stack Trace: java.lang.ExceptionInInitializerError at org.apache.solr.analysis.TestICUCollationKeyFilterFactory.testCustomRules(TestICUCollationKeyFilterFactory.java:110) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1503) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1408) Caused by: java.lang.NullPointerException at com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundle.java:840) at com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundle.java:815) at com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489) at com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.java:536) at com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.java:144) at com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.java:124) at com.ibm.icu.util.ULocale.bcp47ToLDMLKey(ULocale.java:3410) at com.ibm.icu.util.ULocale.access$400(ULocale.java:107) at com.ibm.icu.util.ULocale$JDKLocaleMapper.toULocale7(ULocale.java:3691) at com.ibm.icu.util.ULocale$JDKLocaleMapper.toULocale(ULocale.java:3566) at com.ibm.icu.util.ULocale.forLocale(ULocale.java:399) at com.ibm.icu.util.ULocale.(ULocale.java:380) at com.ibm.icu.util.ULocale.(ULocale.java:516) REGRESSION: org.apache.solr.analysis.TestICUCollationKeyFilterFactory.testBasicUsage Error Message: Could not initialize class com.ibm.icu.util.ULocale Stack Trace: java.lang.NoClassDefFoundError: Could not initialize class com.ibm.icu.util.ULocale at org.apache.solr.analysis.ICUCollationKeyFilterFactory.createFromLocale(ICUCollationKeyFilterFactory.java:124) at org.apache.solr.analysis.ICUCollationKeyFilterFactory.inform(ICUCollationKeyFilterFactory.java:82) at org.apache.solr.analysis.TestICUCollationKeyFilterFactory.testBasicUsage(TestICUCollationKeyFilterFactory.java:54) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1503) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1408) REGRESSION: org.apache.solr.analysis.TestICUCollationKeyFilterFactory.testNormalization Error Message: Could not initialize class com.ibm.icu.util.ULocale Stack Trace: java.lang.NoClassDefFoundError: Could not initialize class com.ibm.icu.util.ULocale at org.apache.solr.analysis.ICUCollationKeyFilterFactory.createFromLocale(ICUCollationKeyFilterFactory.java:124) at org.apache.solr.analysis.ICUCollationKeyFilterFactory.inform(ICUCollationKeyFilterFactory.java:82) at org.apache.solr.analysis.TestICUCollationKeyFilterFactory.testNormalization(TestICUCollationKeyFilterFactory.java:74) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1503) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1408) REGRESSION: org.apache.solr.analysis.TestICUCollationKeyFilterFactory.testSecondaryStrength Error Message: Could not initialize class com.ibm.icu.util.ULocale Stack Trace: java.lang.NoClassDefFoundError: Could not initialize class com.ibm.icu.util.ULocale at org.apache.solr.analysis.ICUCollationKeyFilterFactory.createFromLocale(ICUCollationKeyFilterFactory.java:124) at org.apache.solr.analysis.ICUCollationKeyFilterFactory.inform(ICUCollationKeyFilterFactory.java:82) at org.apache.solr.analysis.TestICUCollationKeyFilterFactory.testSecondaryStrength(TestICUCollationKeyFilterFactory.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1503) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1408) Build Log (for compile errors): [...truncated 15358 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-3.x-java7 - Build # 25 - Still Failing
This one is real. Also happens locally with Java 5 reproducible: $ ant test-core -Dtestcase=TestIndexWriterDelete -Dtestmethod=testFlushPushedDeletesByCount -Dtests.seed=3728512532261700821:674509683516976857 -Dtests.multiplier=5 ... junit-sequential: [junit] Testsuite: org.apache.lucene.index.TestIndexWriterDelete [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 2,259 sec [junit] [junit] - Standard Error - [junit] NOTE: reproduce with: ant test -Dtestcase=TestIndexWriterDelete -Dtestmethod=testFlushPushedDeletesByCount -Dtests.seed=3728512532261700821:674509683516976857 -Dtests.multiplier=5 [junit] NOTE: test params are: locale=pl_PL, timezone=Asia/Manila [junit] NOTE: all tests run in this JVM: [junit] [TestIndexWriterDelete] [junit] NOTE: Windows 7 6.1 amd64/Sun Microsystems Inc. 1.5.0_22 (64-bit)/cpus=2,threads=1,free=13481536,total=15335424 [junit] - --- [junit] Testcase: testFlushPushedDeletesByCount(org.apache.lucene.index.TestIndexWriterDelete): FAILED [junit] delete's were not applied at count=6998 [junit] junit.framework.AssertionFailedError: delete's were not applied at count=6998 [junit] at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1316) [junit] at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1221) [junit] at org.apache.lucene.index.TestIndexWriterDelete.testFlushPushedDeletesByCount(TestIndexWriterDelete.java:1030) [junit] [junit] [junit] Test org.apache.lucene.index.TestIndexWriterDelete FAILED - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Apache Jenkins Server [mailto:jenk...@builds.apache.org] > Sent: Tuesday, July 26, 2011 3:38 PM > To: dev@lucene.apache.org > Subject: [JENKINS] Lucene-Solr-tests-only-3.x-java7 - Build # 25 - Still > Failing > > Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/25/ > > 1 tests failed. > FAILED: > org.apache.lucene.index.TestIndexWriterDelete.testFlushPushedDeletesBy > Count > > Error Message: > delete's were not applied at count=6212 > > Stack Trace: > junit.framework.AssertionFailedError: delete's were not applied at > count=6212 > at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc > eneTestCase.java:1316) > at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc > eneTestCase.java:1221) > at > org.apache.lucene.index.TestIndexWriterDelete.testFlushPushedDeletesBy > Count(TestIndexWriterDelete.java:1030) > > > > > Build Log (for compile errors): > [...truncated 7062 lines...] > > > > - > 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
[JENKINS] Lucene-Solr-tests-only-3.x-java7 - Build # 25 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/25/ 1 tests failed. FAILED: org.apache.lucene.index.TestIndexWriterDelete.testFlushPushedDeletesByCount Error Message: delete's were not applied at count=6212 Stack Trace: junit.framework.AssertionFailedError: delete's were not applied at count=6212 at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1316) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1221) at org.apache.lucene.index.TestIndexWriterDelete.testFlushPushedDeletesByCount(TestIndexWriterDelete.java:1030) Build Log (for compile errors): [...truncated 7062 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (LUCENE-1823) QueryParser with new features for Lucene 3
[
https://issues.apache.org/jira/browse/LUCENE-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071091#comment-13071091
]
Olivier Favre edited comment on LUCENE-1823 at 7/26/11 1:28 PM:
Relates to LUCENE-3343: Open range comparison operator >,>=,<,<= and =.
was (Author: ofavre):
Open range comparison operator >,>=,<,<= and =.
> QueryParser with new features for Lucene 3
> --
>
> Key: LUCENE-1823
> URL: https://issues.apache.org/jira/browse/LUCENE-1823
> Project: Lucene - Java
> Issue Type: New Feature
> Components: core/queryparser
>Reporter: Michael Busch
>Assignee: Luis Alves
>Priority: Minor
> Fix For: 4.0
>
> Attachments: lucene_1823_any_opaque_precedence_fuzzybug_v2.patch,
> lucene_1823_foo_bug_08_26_2009.patch
>
>
> I'd like to have a new QueryParser implementation in Lucene 3.1, ideally
> based on the new QP framework in contrib. It should share as much code as
> possible with the current StandardQueryParser implementation for easy
> maintainability.
> Wish list (feel free to extend):
> 1. *Operator precedence*: Support operator precedence for boolean operators
> 2. *Opaque terms*: Ability to plugin an external parser for certain syntax
> extensions, e.g. XML query terms
> 3. *Improved RangeQuery syntax*: Use more intuitive <=, =, >= instead of []
> and {}
> 4. *Support for trierange queries*: See LUCENE-1768
> 5. *Complex phrases*: See LUCENE-1486
> 6. *ANY operator*: E.g. (a b c d) ANY 3 should match if 3 of the 4 terms
> occur in the same document
> 7. *New syntax for Span queries*: I think the surround parser supports this?
> 8. *Escaped wildcards*: See LUCENE-588
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3343) Comparison operators >,>=,<,<= and = support as RangeQuery syntax in QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Favre updated LUCENE-3343: -- Attachment: NumCompQueryParser.patch The patch, including regenerated files by javacc. Tests ran successfully for queryparser. New tests created for the new feature. > Comparison operators >,>=,<,<= and = support as RangeQuery syntax in > QueryParser > > > Key: LUCENE-3343 > URL: https://issues.apache.org/jira/browse/LUCENE-3343 > Project: Lucene - Java > Issue Type: New Feature > Components: modules/queryparser >Reporter: Olivier Favre >Priority: Minor > Labels: parser, query > Fix For: 4.0 > > Attachments: NumCompQueryParser.patch > > Original Estimate: 96h > Remaining Estimate: 96h > > To offer better interoperability with other search engines and to provide an > easier and more straight forward syntax, > the operators >, >=, <, <= and = should be available to express an open range > query. > They should at least work for numeric queries. > '=' can be made a synonym for ':'. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3343) Comparison operators >,>=,<,<= and = support as RangeQuery syntax in QueryParser
Comparison operators >,>=,<,<= and = support as RangeQuery syntax in QueryParser Key: LUCENE-3343 URL: https://issues.apache.org/jira/browse/LUCENE-3343 Project: Lucene - Java Issue Type: New Feature Components: modules/queryparser Reporter: Olivier Favre Priority: Minor Fix For: 4.0 To offer better interoperability with other search engines and to provide an easier and more straight forward syntax, the operators >, >=, <, <= and = should be available to express an open range query. They should at least work for numeric queries. '=' can be made a synonym for ':'. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: FST construction on jrockit, 1.6 and 1.7
> Y axis is time to build the FST (ie, smaller is better), and X axis is > iteration? Yes, vert. is time in seconds, X is round (iteration). I re-checked on another machine (linux box this time) with swap turned off to make sure it's now that. Nope: the behavior of jrockit is pretty much random and the timings deviate 2-3x from each other. Very weird. 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-3.x-java7 - Build # 24 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/24/ 1 tests failed. FAILED: org.apache.lucene.index.TestIndexWriterDelete.testFlushPushedDeletesByCount Error Message: delete's were not applied at count=6998 Stack Trace: junit.framework.AssertionFailedError: delete's were not applied at count=6998 at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1316) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1221) at org.apache.lucene.index.TestIndexWriterDelete.testFlushPushedDeletesByCount(TestIndexWriterDelete.java:1030) Build Log (for compile errors): [...truncated 7073 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3337) avoid building jar files unless necessary in build
[ https://issues.apache.org/jira/browse/LUCENE-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071084#comment-13071084 ] Steven Rowe commented on LUCENE-3337: - Robert, your patch is a collection of optimizations to the SOLR-2452 work. Looks good! My build times: ||task||trunk||patch|| |ant example (clean checkout)|180s|119s| |ant example (already compiled)|132s|61s| So I'm seeing the same kind of speedups as you. +1 to commit - we could use this issue to host a series of further patches. I plan on looking next at the utility of the *.compiled & *.uptodate property passing scheme - you mentioned on #lucene IRC that it didn't seem to be having any effect on the build. > avoid building jar files unless necessary in build > -- > > Key: LUCENE-3337 > URL: https://issues.apache.org/jira/browse/LUCENE-3337 > Project: Lucene - Java > Issue Type: Bug > Components: general/build >Affects Versions: 3.4, 4.0 >Reporter: Robert Muir > Attachments: LUCENE-3337.patch, LUCENE-3337.patch, LUCENE-3337.patch > > > This causes the build to be slow, we can avoid it in lots of cases (e.g. ant > test) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3335) jrebug causes porter stemmer to sigsegv
[ https://issues.apache.org/jira/browse/LUCENE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-3335: -- Attachment: patch-0uwe.patch Patch again, without Apache License > jrebug causes porter stemmer to sigsegv > --- > > Key: LUCENE-3335 > URL: https://issues.apache.org/jira/browse/LUCENE-3335 > Project: Lucene - Java > Issue Type: Bug >Reporter: Robert Muir > Labels: Java7 > Attachments: LUCENE-3335.patch, LUCENE-3335_slow.patch, > patch-0uwe.patch > > > happens easily on java7: ant test -Dtestcase=TestPorterStemFilter > -Dtests.iter=100 > might happen on 1.6.0_u26 too, a user reported something that looks like the > same bug already: > http://www.lucidimagination.com/search/document/3beaa082c4d2fdd4/porterstemfilter_kills_jvm -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3335) jrebug causes porter stemmer to sigsegv
[ https://issues.apache.org/jira/browse/LUCENE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-3335: -- Attachment: (was: patch-0uwe.patch) > jrebug causes porter stemmer to sigsegv > --- > > Key: LUCENE-3335 > URL: https://issues.apache.org/jira/browse/LUCENE-3335 > Project: Lucene - Java > Issue Type: Bug >Reporter: Robert Muir > Labels: Java7 > Attachments: LUCENE-3335.patch, LUCENE-3335_slow.patch, > patch-0uwe.patch > > > happens easily on java7: ant test -Dtestcase=TestPorterStemFilter > -Dtests.iter=100 > might happen on 1.6.0_u26 too, a user reported something that looks like the > same bug already: > http://www.lucidimagination.com/search/document/3beaa082c4d2fdd4/porterstemfilter_kills_jvm -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3340) Buffered deletes are not flushed by RAM or count
[ https://issues.apache.org/jira/browse/LUCENE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-3340. Resolution: Fixed Thanks Simon! > Buffered deletes are not flushed by RAM or count > > > Key: LUCENE-3340 > URL: https://issues.apache.org/jira/browse/LUCENE-3340 > Project: Lucene - Java > Issue Type: Bug > Components: core/index >Affects Versions: 4.0 >Reporter: Michael McCandless > Fix For: 4.0 > > Attachments: LUCENE-3340.patch, LUCENE-3340.patch, LUCENE-3340.patch > > > When a segment is flushed, we will generally NOT flush the deletes, ie we > simply buffer up the pending delete terms/queries, and the only apply them if > 1) a segment is going to be merged (so we can remove the del docs in that > segment), or 2) the buffered deletes' RAM exceeds 1/2 of IW's RAM limit when > we are flushing a segment, or 3) the buffered deletes count exceeds IWC's > maxBufferedDeleteTerms. > But the latter 2 triggers are currently broken on trunk; I suspect (but I'm > not sure) when we landed DWPT we introduced this bug. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3335) jrebug causes porter stemmer to sigsegv
[ https://issues.apache.org/jira/browse/LUCENE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-3335: -- Attachment: patch-0uwe.patch Hi, we had some success with direct communication to the hotspot developers. The whole story: - Java 7 contains a fix to the readVInt issue since 1.6.0_21 (approx, LUCENE-2975), this fix was fortunately not included in 1.6.0_26 - This fix causes the SIGSEGV on Porter code, but also breaks other loops (e.g. a strange CheckIndex failure in org.apache.lucene.facet.search.SamplingWrapperTest) - We had contact to the hotspot-compiler-dev list and Vladimir sent me the patches, that should fix the bug. The attached patch is a combination of all patches received, in a format suitable for the FreeBSD ports build framework. Place the file in your port's "files/" folder and rebuild the package. In Debian/Ubuntu you should be able to do the same thing by placing the file in the debian/patches folder somehow. - I have now disabled all jenkins builds and queued the Java 7 builds for 3.x and trunk quarter-hourly. The machine now stress tests. - We will report the resuls back to Oracle, but it seems that the attached patch fixes the issues. If they would have added their original broken fix to the 1.6.0_26 release it would have been catastrophic... > jrebug causes porter stemmer to sigsegv > --- > > Key: LUCENE-3335 > URL: https://issues.apache.org/jira/browse/LUCENE-3335 > Project: Lucene - Java > Issue Type: Bug >Reporter: Robert Muir > Labels: Java7 > Attachments: LUCENE-3335.patch, LUCENE-3335_slow.patch, > patch-0uwe.patch > > > happens easily on java7: ant test -Dtestcase=TestPorterStemFilter > -Dtests.iter=100 > might happen on 1.6.0_u26 too, a user reported something that looks like the > same bug already: > http://www.lucidimagination.com/search/document/3beaa082c4d2fdd4/porterstemfilter_kills_jvm -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3339) TestNRTThreads hangs in nightly 3.x builds
[ https://issues.apache.org/jira/browse/LUCENE-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071075#comment-13071075 ] Michael McCandless commented on LUCENE-3339: OK last fix wasn't quite right: we have to re-check whether or not to pause after the loop ends, and it must be inside sync block. I'll leave this open until we see that this no longer hangs in nightly build... > TestNRTThreads hangs in nightly 3.x builds > -- > > Key: LUCENE-3339 > URL: https://issues.apache.org/jira/browse/LUCENE-3339 > Project: Lucene - Java > Issue Type: Bug >Reporter: Robert Muir >Assignee: Michael McCandless > Fix For: 3.4 > > Attachments: LUCENE-3339.patch > > > Maybe we have a problem, maybe its a bug in the test. > But its strange that lately the 3.x nightlies have been hanging here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3342) make frozenbuffereddeletes more efficient for terms
[ https://issues.apache.org/jira/browse/LUCENE-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071073#comment-13071073 ] Michael McCandless commented on LUCENE-3342: Wow, this looks awesome! This should be a sizable reduction in the amount of RAM required to hold the buffered delete terms. > make frozenbuffereddeletes more efficient for terms > --- > > Key: LUCENE-3342 > URL: https://issues.apache.org/jira/browse/LUCENE-3342 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Robert Muir > Fix For: 3.4, 4.0 > > Attachments: LUCENE-3342.patch > > > when looking at LUCENE-3340, I thought its also ridiculous how much ram we > use for delete by term. > so we can save a lot of memory, especially object overhead by being a little > more efficient. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: FST construction on jrockit, 1.6 and 1.7
Y axis is time to build the FST (ie, smaller is better), and X axis is iteration? 1.6 and 1.7 are very close, but JRockit is much slower except for iteration #2 where it's nearly the same. Scary how hotspot can be so wrong so "randomly". Mike McCandless http://blog.mikemccandless.com On Mon, Jul 25, 2011 at 5:18 PM, Dawid Weiss wrote: > I am preparing an unrelated presentation to which I needed something > that crunches lots of data and uses some cpu cycles. I decided to run > FST construction on that half-gig wikipedia file. Three jits: 1.6_u26, > 1.7 pre-release and jrockit (newest available). The results are > interesting (although not by any means indicative of the advantages of > each vm, as I only did it on a single machine and with only 5 reps per > vm): 1.6_u26 is ahead of 1.7, but watch what happens with the timing > of jrockit (no, the bumps are not caused by background activity). I'm > guessing the optimizer picking wrong paths and unable to revert, but > who the hell knows these days... > > 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
[jira] [Updated] (LUCENE-3342) make frozenbuffereddeletes more efficient for terms
[ https://issues.apache.org/jira/browse/LUCENE-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3342: Attachment: LUCENE-3342.patch > make frozenbuffereddeletes more efficient for terms > --- > > Key: LUCENE-3342 > URL: https://issues.apache.org/jira/browse/LUCENE-3342 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Robert Muir > Fix For: 3.4, 4.0 > > Attachments: LUCENE-3342.patch > > > when looking at LUCENE-3340, I thought its also ridiculous how much ram we > use for delete by term. > so we can save a lot of memory, especially object overhead by being a little > more efficient. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3342) make frozenbuffereddeletes more efficient for terms
make frozenbuffereddeletes more efficient for terms --- Key: LUCENE-3342 URL: https://issues.apache.org/jira/browse/LUCENE-3342 Project: Lucene - Java Issue Type: Improvement Reporter: Robert Muir Fix For: 3.4, 4.0 Attachments: LUCENE-3342.patch when looking at LUCENE-3340, I thought its also ridiculous how much ram we use for delete by term. so we can save a lot of memory, especially object overhead by being a little more efficient. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1150683 - in /lucene/dev/branches/branch_3x/lucene: CHANGES.txt src/java/org/apache/lucene/index/DocumentsWriter.java
No problem -- I think I see what's causing the deadlock (still).
I think it's (confusingly!) kill -QUIT to get the thread stacks.
Mike McCandless
http://blog.mikemccandless.com
On Tue, Jul 26, 2011 at 8:12 AM, Uwe Schindler wrote:
> Sorry, I missed to create a stack dump :(
> What was the signal for that? -HUP -TERM -KILL?
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>> -Original Message-
>> From: Michael McCandless [mailto:luc...@mikemccandless.com]
>> Sent: Tuesday, July 26, 2011 1:06 PM
>> To: dev@lucene.apache.org
>> Subject: Re: svn commit: r1150683 - in
>> /lucene/dev/branches/branch_3x/lucene: CHANGES.txt
>> src/java/org/apache/lucene/index/DocumentsWriter.java
>>
>> Ugh, I'll dig.
>>
>> Uwe was it hung on TestNRTThreads again? And the stack dump looked the
>> same as LUCENE-3339?
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> On Tue, Jul 26, 2011 at 3:07 AM, Uwe Schindler wrote:
>> > We still have a deadlock! I killed the 3.x build few minutes ago.
>> >
>> > -
>> > Uwe Schindler
>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>> > http://www.thetaphi.de
>> > eMail: u...@thetaphi.de
>> >
>> >
>> >> -Original Message-
>> >> From: mikemcc...@apache.org [mailto:mikemcc...@apache.org]
>> >> Sent: Monday, July 25, 2011 3:09 PM
>> >> To: comm...@lucene.apache.org
>> >> Subject: svn commit: r1150683 - in
>> /lucene/dev/branches/branch_3x/lucene:
>> >> CHANGES.txt src/java/org/apache/lucene/index/DocumentsWriter.java
>> >>
>> >> Author: mikemccand
>> >> Date: Mon Jul 25 13:09:28 2011
>> >> New Revision: 1150683
>> >>
>> >> URL: http://svn.apache.org/viewvc?rev=1150683&view=rev
>> >> Log:
>> >> LUCENE-3339: fix deadlock case when multiple threads add/update doc
>> >> blocks
>> >>
>> >> Modified:
>> >> lucene/dev/branches/branch_3x/lucene/CHANGES.txt
>> >>
>> >>
>> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
>> >> /DocumentsWriter.java
>> >>
>> >> Modified: lucene/dev/branches/branch_3x/lucene/CHANGES.txt
>> >> URL:
>> >>
>> http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/lucene/CHA
>> >> NGES.txt?rev=1150683&r1=1150682&r2=1150683&view=diff
>> >>
>> ==
>> >>
>> >> --- lucene/dev/branches/branch_3x/lucene/CHANGES.txt (original)
>> >> +++ lucene/dev/branches/branch_3x/lucene/CHANGES.txt Mon Jul 25
>> >> 13:09:28 2011
>> >> @@ -26,6 +26,10 @@ Bug fixes
>> >> suppressed exceptions in the original exception, so stack trace
>> >> will contain them. (Uwe Schindler)
>> >>
>> >> +* LUCENE-3339: Fixed deadlock case when multiple threads use the new
>> >> + block-add (IndexWriter.add/updateDocuments) methods. (Robert
>> >> +Muir,
>> >> + Mike McCandless)
>> >> +
>> >> New Features
>> >>
>> >> * LUCENE-3290: Added FieldInvertState.numUniqueTerms
>> >>
>> >> Modified:
>> >>
>> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
>> >> /DocumentsWriter.java
>> >> URL:
>> >>
>> http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/lucene/src
>> >> /
>> >>
>> java/org/apache/lucene/index/DocumentsWriter.java?rev=1150683&r1=115
>> >> 0682&r2=1150683&view=diff
>> >>
>> ==
>> >>
>> >> ---
>> >>
>> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
>> >> /DocumentsWriter.java (original)
>> >> +++
>> >>
>> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
>> >> /DocumentsWriter.java Mon Jul 25 13:09:28 2011 @@ -843,6 +843,12 @@
>> >> final class DocumentsWriter {
>> >> final int startDocID = docState.docID;
>> >> int docID = startDocID;
>> >>
>> >> + // We must delay pausing until the full doc block is
>> >> + // added, else we can hit deadlock if more than one
>> >> + // thread is adding a block and we need to pause when
>> >> + // both are only part way done:
>> >> + boolean doPauseWaitQueue = false;
>> >> +
>> >> //System.out.println(Thread.currentThread().getName() + ": A " +
>> >> docCount);
>> >> for(Document doc : docs) {
>> >> docState.doc = doc;
>> >> @@ -873,13 +879,10 @@ final class DocumentsWriter {
>> >> assert perDoc == null || perDoc.docID == docState.docID;
>> >> final boolean doPause;
>> >> if (perDoc != null) {
>> >> - doPause = waitQueue.add(perDoc);
>> >> + doPauseWaitQueue |= waitQueue.add(perDoc);
>> >> } else {
>> >> skipDocWriter.docID = docState.docID;
>> >> - doPause = waitQueue.add(skipDocWriter);
>> >> - }
>> >> - if (doPause) {
>> >> - waitForWaitQueue();
>> >> + doPauseWaitQueue |= waitQueue.add(skipDocWriter);
>> >> }
>> >> }
>> >>
>> >> @@ -937,6 +940,10 @@ final class DocumentsWriter {
>> >> }
>> >> }
>> >>
RE: svn commit: r1150683 - in /lucene/dev/branches/branch_3x/lucene: CHANGES.txt src/java/org/apache/lucene/index/DocumentsWriter.java
Sorry, I missed to create a stack dump :(
What was the signal for that? -HUP -TERM -KILL?
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Michael McCandless [mailto:luc...@mikemccandless.com]
> Sent: Tuesday, July 26, 2011 1:06 PM
> To: dev@lucene.apache.org
> Subject: Re: svn commit: r1150683 - in
> /lucene/dev/branches/branch_3x/lucene: CHANGES.txt
> src/java/org/apache/lucene/index/DocumentsWriter.java
>
> Ugh, I'll dig.
>
> Uwe was it hung on TestNRTThreads again? And the stack dump looked the
> same as LUCENE-3339?
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Tue, Jul 26, 2011 at 3:07 AM, Uwe Schindler wrote:
> > We still have a deadlock! I killed the 3.x build few minutes ago.
> >
> > -
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> >
> >> -Original Message-
> >> From: mikemcc...@apache.org [mailto:mikemcc...@apache.org]
> >> Sent: Monday, July 25, 2011 3:09 PM
> >> To: comm...@lucene.apache.org
> >> Subject: svn commit: r1150683 - in
> /lucene/dev/branches/branch_3x/lucene:
> >> CHANGES.txt src/java/org/apache/lucene/index/DocumentsWriter.java
> >>
> >> Author: mikemccand
> >> Date: Mon Jul 25 13:09:28 2011
> >> New Revision: 1150683
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1150683&view=rev
> >> Log:
> >> LUCENE-3339: fix deadlock case when multiple threads add/update doc
> >> blocks
> >>
> >> Modified:
> >> lucene/dev/branches/branch_3x/lucene/CHANGES.txt
> >>
> >>
> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
> >> /DocumentsWriter.java
> >>
> >> Modified: lucene/dev/branches/branch_3x/lucene/CHANGES.txt
> >> URL:
> >>
> http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/lucene/CHA
> >> NGES.txt?rev=1150683&r1=1150682&r2=1150683&view=diff
> >>
> ==
> >>
> >> --- lucene/dev/branches/branch_3x/lucene/CHANGES.txt (original)
> >> +++ lucene/dev/branches/branch_3x/lucene/CHANGES.txt Mon Jul 25
> >> 13:09:28 2011
> >> @@ -26,6 +26,10 @@ Bug fixes
> >> suppressed exceptions in the original exception, so stack trace
> >> will contain them. (Uwe Schindler)
> >>
> >> +* LUCENE-3339: Fixed deadlock case when multiple threads use the new
> >> + block-add (IndexWriter.add/updateDocuments) methods. (Robert
> >> +Muir,
> >> + Mike McCandless)
> >> +
> >> New Features
> >>
> >> * LUCENE-3290: Added FieldInvertState.numUniqueTerms
> >>
> >> Modified:
> >>
> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
> >> /DocumentsWriter.java
> >> URL:
> >>
> http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/lucene/src
> >> /
> >>
> java/org/apache/lucene/index/DocumentsWriter.java?rev=1150683&r1=115
> >> 0682&r2=1150683&view=diff
> >>
> ==
> >>
> >> ---
> >>
> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
> >> /DocumentsWriter.java (original)
> >> +++
> >>
> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
> >> /DocumentsWriter.java Mon Jul 25 13:09:28 2011 @@ -843,6 +843,12 @@
> >> final class DocumentsWriter {
> >> final int startDocID = docState.docID;
> >> int docID = startDocID;
> >>
> >> + // We must delay pausing until the full doc block is
> >> + // added, else we can hit deadlock if more than one
> >> + // thread is adding a block and we need to pause when
> >> + // both are only part way done:
> >> + boolean doPauseWaitQueue = false;
> >> +
> >> //System.out.println(Thread.currentThread().getName() + ": A " +
> >> docCount);
> >> for(Document doc : docs) {
> >> docState.doc = doc;
> >> @@ -873,13 +879,10 @@ final class DocumentsWriter {
> >> assert perDoc == null || perDoc.docID == docState.docID;
> >> final boolean doPause;
> >> if (perDoc != null) {
> >> - doPause = waitQueue.add(perDoc);
> >> + doPauseWaitQueue |= waitQueue.add(perDoc);
> >> } else {
> >> skipDocWriter.docID = docState.docID;
> >> - doPause = waitQueue.add(skipDocWriter);
> >> - }
> >> - if (doPause) {
> >> - waitForWaitQueue();
> >> + doPauseWaitQueue |= waitQueue.add(skipDocWriter);
> >> }
> >> }
> >>
> >> @@ -937,6 +940,10 @@ final class DocumentsWriter {
> >> }
> >> }
> >> }
> >> +
> >> + if (doPauseWaitQueue) {
> >> + waitForWaitQueue();
> >> + }
> >> }
> >> //System.out.println(Thread.currentThread().getName() + ": A "
> >> + docCount);
> >>
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
> > additional comm
[jira] [Created] (LUCENE-3341) Spellcheker is not checking word with less than 3 characters
Spellcheker is not checking word with less than 3 characters
Key: LUCENE-3341
URL: https://issues.apache.org/jira/browse/LUCENE-3341
Project: Lucene - Java
Issue Type: Bug
Components: modules/spellchecker
Affects Versions: 3.2
Environment: Window XP, Java 6, JBoss 4.2.3GA
Reporter: Devang Panchal
Fix For: 3.2
*Problem:* SpellChecker is not checking spelling of a word less than 3
characters. i.e "en", "am", "an", etc. So these words are getting misspelled in
result.
*Cause:*
org.apache.lucene.search.spell.SpellChecker class is not adding in index
dictionary a word which has less than 3 characters.
The method indexDictionary() in SpellChecker class is ignoring all the
characters less than 3 characters length and not adding them in index
dictionary.
*Example code:*
SpellChecker luceneSpellChecker = null;
luceneSpellChecker = new SpellChecker(new RAMDirectory(), new NGramDistance());
luceneSpellChecker.indexDictionary(
new PlainTextDictionary( new
InputStreamReader(dictionaryFile, "UTF-8")),
10, 500, false);
System.out.println("Word 'an' exist? "+luceneSpellChecker.exist("an");
System.out.println("Word 'am' exist? "+luceneSpellChecker.exist("am");
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (LUCENE-3339) TestNRTThreads hangs in nightly 3.x builds
[ https://issues.apache.org/jira/browse/LUCENE-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless reopened LUCENE-3339: Nightly build hung again... > TestNRTThreads hangs in nightly 3.x builds > -- > > Key: LUCENE-3339 > URL: https://issues.apache.org/jira/browse/LUCENE-3339 > Project: Lucene - Java > Issue Type: Bug >Reporter: Robert Muir >Assignee: Michael McCandless > Fix For: 3.4 > > Attachments: LUCENE-3339.patch > > > Maybe we have a problem, maybe its a bug in the test. > But its strange that lately the 3.x nightlies have been hanging here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1150683 - in /lucene/dev/branches/branch_3x/lucene: CHANGES.txt src/java/org/apache/lucene/index/DocumentsWriter.java
Ugh, I'll dig.
Uwe was it hung on TestNRTThreads again? And the stack dump looked
the same as LUCENE-3339?
Mike McCandless
http://blog.mikemccandless.com
On Tue, Jul 26, 2011 at 3:07 AM, Uwe Schindler wrote:
> We still have a deadlock! I killed the 3.x build few minutes ago.
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>> -Original Message-
>> From: mikemcc...@apache.org [mailto:mikemcc...@apache.org]
>> Sent: Monday, July 25, 2011 3:09 PM
>> To: comm...@lucene.apache.org
>> Subject: svn commit: r1150683 - in /lucene/dev/branches/branch_3x/lucene:
>> CHANGES.txt src/java/org/apache/lucene/index/DocumentsWriter.java
>>
>> Author: mikemccand
>> Date: Mon Jul 25 13:09:28 2011
>> New Revision: 1150683
>>
>> URL: http://svn.apache.org/viewvc?rev=1150683&view=rev
>> Log:
>> LUCENE-3339: fix deadlock case when multiple threads add/update doc
>> blocks
>>
>> Modified:
>> lucene/dev/branches/branch_3x/lucene/CHANGES.txt
>>
>> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
>> /DocumentsWriter.java
>>
>> Modified: lucene/dev/branches/branch_3x/lucene/CHANGES.txt
>> URL:
>> http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/lucene/CHA
>> NGES.txt?rev=1150683&r1=1150682&r2=1150683&view=diff
>> ==
>>
>> --- lucene/dev/branches/branch_3x/lucene/CHANGES.txt (original)
>> +++ lucene/dev/branches/branch_3x/lucene/CHANGES.txt Mon Jul 25
>> 13:09:28 2011
>> @@ -26,6 +26,10 @@ Bug fixes
>> suppressed exceptions in the original exception, so stack trace
>> will contain them. (Uwe Schindler)
>>
>> +* LUCENE-3339: Fixed deadlock case when multiple threads use the new
>> + block-add (IndexWriter.add/updateDocuments) methods. (Robert Muir,
>> + Mike McCandless)
>> +
>> New Features
>>
>> * LUCENE-3290: Added FieldInvertState.numUniqueTerms
>>
>> Modified:
>> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
>> /DocumentsWriter.java
>> URL:
>> http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/lucene/src/
>> java/org/apache/lucene/index/DocumentsWriter.java?rev=1150683&r1=115
>> 0682&r2=1150683&view=diff
>> ==
>>
>> ---
>> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
>> /DocumentsWriter.java (original)
>> +++
>> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
>> /DocumentsWriter.java Mon Jul 25 13:09:28 2011
>> @@ -843,6 +843,12 @@ final class DocumentsWriter {
>> final int startDocID = docState.docID;
>> int docID = startDocID;
>>
>> + // We must delay pausing until the full doc block is
>> + // added, else we can hit deadlock if more than one
>> + // thread is adding a block and we need to pause when
>> + // both are only part way done:
>> + boolean doPauseWaitQueue = false;
>> +
>> //System.out.println(Thread.currentThread().getName() + ": A " +
>> docCount);
>> for(Document doc : docs) {
>> docState.doc = doc;
>> @@ -873,13 +879,10 @@ final class DocumentsWriter {
>> assert perDoc == null || perDoc.docID == docState.docID;
>> final boolean doPause;
>> if (perDoc != null) {
>> - doPause = waitQueue.add(perDoc);
>> + doPauseWaitQueue |= waitQueue.add(perDoc);
>> } else {
>> skipDocWriter.docID = docState.docID;
>> - doPause = waitQueue.add(skipDocWriter);
>> - }
>> - if (doPause) {
>> - waitForWaitQueue();
>> + doPauseWaitQueue |= waitQueue.add(skipDocWriter);
>> }
>> }
>>
>> @@ -937,6 +940,10 @@ final class DocumentsWriter {
>> }
>> }
>> }
>> +
>> + if (doPauseWaitQueue) {
>> + waitForWaitQueue();
>> + }
>> }
>> //System.out.println(Thread.currentThread().getName() + ": A " +
>> docCount);
>>
>
>
>
> -
> 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
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 9766 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/9766/ 1 tests failed. REGRESSION: org.apache.solr.cloud.ZkControllerTest.testUploadToCloud Error Message: null Stack Trace: java.lang.NullPointerException at org.apache.solr.cloud.ZkTestServer$ZKServerMain.shutdown(ZkTestServer.java:111) at org.apache.solr.cloud.ZkTestServer.shutdown(ZkTestServer.java:227) at org.apache.solr.cloud.ZkControllerTest.testUploadToCloud(ZkControllerTest.java:202) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1503) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1408) Build Log (for compile errors): [...truncated 8117 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1150683 - in /lucene/dev/branches/branch_3x/lucene: CHANGES.txt src/java/org/apache/lucene/index/DocumentsWriter.java
without looking at the actual code I would say the
if(doPauseWaitQueue) should be while(doPauseWaitQueue)?
On Tue, Jul 26, 2011 at 9:07 AM, Uwe Schindler wrote:
> We still have a deadlock! I killed the 3.x build few minutes ago.
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>> -Original Message-
>> From: mikemcc...@apache.org [mailto:mikemcc...@apache.org]
>> Sent: Monday, July 25, 2011 3:09 PM
>> To: comm...@lucene.apache.org
>> Subject: svn commit: r1150683 - in /lucene/dev/branches/branch_3x/lucene:
>> CHANGES.txt src/java/org/apache/lucene/index/DocumentsWriter.java
>>
>> Author: mikemccand
>> Date: Mon Jul 25 13:09:28 2011
>> New Revision: 1150683
>>
>> URL: http://svn.apache.org/viewvc?rev=1150683&view=rev
>> Log:
>> LUCENE-3339: fix deadlock case when multiple threads add/update doc
>> blocks
>>
>> Modified:
>> lucene/dev/branches/branch_3x/lucene/CHANGES.txt
>>
>> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
>> /DocumentsWriter.java
>>
>> Modified: lucene/dev/branches/branch_3x/lucene/CHANGES.txt
>> URL:
>> http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/lucene/CHA
>> NGES.txt?rev=1150683&r1=1150682&r2=1150683&view=diff
>> ==
>>
>> --- lucene/dev/branches/branch_3x/lucene/CHANGES.txt (original)
>> +++ lucene/dev/branches/branch_3x/lucene/CHANGES.txt Mon Jul 25
>> 13:09:28 2011
>> @@ -26,6 +26,10 @@ Bug fixes
>> suppressed exceptions in the original exception, so stack trace
>> will contain them. (Uwe Schindler)
>>
>> +* LUCENE-3339: Fixed deadlock case when multiple threads use the new
>> + block-add (IndexWriter.add/updateDocuments) methods. (Robert Muir,
>> + Mike McCandless)
>> +
>> New Features
>>
>> * LUCENE-3290: Added FieldInvertState.numUniqueTerms
>>
>> Modified:
>> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
>> /DocumentsWriter.java
>> URL:
>> http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/lucene/src/
>> java/org/apache/lucene/index/DocumentsWriter.java?rev=1150683&r1=115
>> 0682&r2=1150683&view=diff
>> ==
>>
>> ---
>> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
>> /DocumentsWriter.java (original)
>> +++
>> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
>> /DocumentsWriter.java Mon Jul 25 13:09:28 2011
>> @@ -843,6 +843,12 @@ final class DocumentsWriter {
>> final int startDocID = docState.docID;
>> int docID = startDocID;
>>
>> + // We must delay pausing until the full doc block is
>> + // added, else we can hit deadlock if more than one
>> + // thread is adding a block and we need to pause when
>> + // both are only part way done:
>> + boolean doPauseWaitQueue = false;
>> +
>> //System.out.println(Thread.currentThread().getName() + ": A " +
>> docCount);
>> for(Document doc : docs) {
>> docState.doc = doc;
>> @@ -873,13 +879,10 @@ final class DocumentsWriter {
>> assert perDoc == null || perDoc.docID == docState.docID;
>> final boolean doPause;
>> if (perDoc != null) {
>> - doPause = waitQueue.add(perDoc);
>> + doPauseWaitQueue |= waitQueue.add(perDoc);
>> } else {
>> skipDocWriter.docID = docState.docID;
>> - doPause = waitQueue.add(skipDocWriter);
>> - }
>> - if (doPause) {
>> - waitForWaitQueue();
>> + doPauseWaitQueue |= waitQueue.add(skipDocWriter);
>> }
>> }
>>
>> @@ -937,6 +940,10 @@ final class DocumentsWriter {
>> }
>> }
>> }
>> +
>> + if (doPauseWaitQueue) {
>> + waitForWaitQueue();
>> + }
>> }
>> //System.out.println(Thread.currentThread().getName() + ": A " +
>> docCount);
>>
>
>
>
> -
> 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
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 26 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/26/ 1 tests failed. REGRESSION: org.apache.lucene.facet.search.SamplingWrapperTest.testCountUsingSamping Error Message: CheckIndex failed Stack Trace: java.lang.RuntimeException: CheckIndex failed at org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:162) at org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:148) at org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:493) at org.apache.lucene.facet.FacetTestBase.closeAll(FacetTestBase.java:219) at org.apache.lucene.facet.search.sampling.BaseSampleTestTopK.testCountUsingSamping(BaseSampleTestTopK.java:79) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1503) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1408) Build Log (for compile errors): [...truncated 6681 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: svn commit: r1150683 - in /lucene/dev/branches/branch_3x/lucene: CHANGES.txt src/java/org/apache/lucene/index/DocumentsWriter.java
We still have a deadlock! I killed the 3.x build few minutes ago.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: mikemcc...@apache.org [mailto:mikemcc...@apache.org]
> Sent: Monday, July 25, 2011 3:09 PM
> To: comm...@lucene.apache.org
> Subject: svn commit: r1150683 - in /lucene/dev/branches/branch_3x/lucene:
> CHANGES.txt src/java/org/apache/lucene/index/DocumentsWriter.java
>
> Author: mikemccand
> Date: Mon Jul 25 13:09:28 2011
> New Revision: 1150683
>
> URL: http://svn.apache.org/viewvc?rev=1150683&view=rev
> Log:
> LUCENE-3339: fix deadlock case when multiple threads add/update doc
> blocks
>
> Modified:
> lucene/dev/branches/branch_3x/lucene/CHANGES.txt
>
> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
> /DocumentsWriter.java
>
> Modified: lucene/dev/branches/branch_3x/lucene/CHANGES.txt
> URL:
> http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/lucene/CHA
> NGES.txt?rev=1150683&r1=1150682&r2=1150683&view=diff
> ==
>
> --- lucene/dev/branches/branch_3x/lucene/CHANGES.txt (original)
> +++ lucene/dev/branches/branch_3x/lucene/CHANGES.txt Mon Jul 25
> 13:09:28 2011
> @@ -26,6 +26,10 @@ Bug fixes
>suppressed exceptions in the original exception, so stack trace
>will contain them. (Uwe Schindler)
>
> +* LUCENE-3339: Fixed deadlock case when multiple threads use the new
> + block-add (IndexWriter.add/updateDocuments) methods. (Robert Muir,
> + Mike McCandless)
> +
> New Features
>
> * LUCENE-3290: Added FieldInvertState.numUniqueTerms
>
> Modified:
> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
> /DocumentsWriter.java
> URL:
> http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/lucene/src/
> java/org/apache/lucene/index/DocumentsWriter.java?rev=1150683&r1=115
> 0682&r2=1150683&view=diff
> ==
>
> ---
> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
> /DocumentsWriter.java (original)
> +++
> lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/index
> /DocumentsWriter.java Mon Jul 25 13:09:28 2011
> @@ -843,6 +843,12 @@ final class DocumentsWriter {
> final int startDocID = docState.docID;
> int docID = startDocID;
>
> +// We must delay pausing until the full doc block is
> +// added, else we can hit deadlock if more than one
> +// thread is adding a block and we need to pause when
> +// both are only part way done:
> +boolean doPauseWaitQueue = false;
> +
> //System.out.println(Thread.currentThread().getName() + ": A " +
> docCount);
> for(Document doc : docs) {
>docState.doc = doc;
> @@ -873,13 +879,10 @@ final class DocumentsWriter {
>assert perDoc == null || perDoc.docID == docState.docID;
>final boolean doPause;
>if (perDoc != null) {
> -doPause = waitQueue.add(perDoc);
> +doPauseWaitQueue |= waitQueue.add(perDoc);
>} else {
> skipDocWriter.docID = docState.docID;
> -doPause = waitQueue.add(skipDocWriter);
> - }
> - if (doPause) {
> -waitForWaitQueue();
> +doPauseWaitQueue |= waitQueue.add(skipDocWriter);
>}
> }
>
> @@ -937,6 +940,10 @@ final class DocumentsWriter {
>}
> }
>}
> +
> + if (doPauseWaitQueue) {
> +waitForWaitQueue();
> + }
> }
> //System.out.println(Thread.currentThread().getName() + ": A " +
> docCount);
>
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
