[JENKINS] Lucene-Solr-SmokeRelease-trunk - Build # 29 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-trunk/29/
No tests ran.
Build Log:
[...truncated 30392 lines...]
prepare-release-no-sign:
[mkdir] Created dir:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease
[copy] Copying 396 files to
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/lucene
[copy] Copying 4 files to
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/lucene/changes
[get] Getting: http://people.apache.org/keys/group/lucene.asc
[get] To:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/lucene/KEYS
[copy] Copying 189 files to
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/solr
[copy] Copying 1 file to
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/solr
[copy] Copying 4 files to
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/solr/changes
[exec] NOTE: output encoding is US-ASCII
[exec]
[exec] Load release URL
"file:/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/"...
[exec]
[exec] Test Lucene...
[exec] test basics...
[exec] get KEYS
[exec] 0.1 MB
[exec] check changes HTML...
[exec] download lucene-5.0.0-src.tgz...
[exec] 26.2 MB
[exec] verify md5/sha1 digests
[exec] download lucene-5.0.0.tgz...
[exec] 47.2 MB
[exec] verify md5/sha1 digests
[exec] download lucene-5.0.0.zip...
[exec] 56.6 MB
[exec] verify md5/sha1 digests
[exec] unpack lucene-5.0.0.tgz...
[exec] verify JAR/WAR metadata...
[exec] test demo with 1.6...
[exec] got 5285 hits for query "lucene"
[exec] test demo with 1.7...
[exec] got 5285 hits for query "lucene"
[exec] check Lucene's javadoc JAR
[exec] unpack lucene-5.0.0.zip...
[exec] verify JAR/WAR metadata...
[exec] test demo with 1.6...
[exec] got 5285 hits for query "lucene"
[exec] test demo with 1.7...
[exec] got 5285 hits for query "lucene"
[exec] check Lucene's javadoc JAR
[exec] unpack lucene-5.0.0-src.tgz...
[exec] make sure no JARs/WARs in src dist...
[exec] run "ant validate"
[exec] run tests w/ Java 6...
[exec] test demo with 1.6...
[exec] got 202 hits for query "lucene"
[exec] generate javadocs w/ Java 6...
[exec] run tests w/ Java 7...
[exec] test demo with 1.7...
[exec] got 202 hits for query "lucene"
[exec] generate javadocs w/ Java 7...
[exec]
[exec] Crawl/parse...
[exec] Traceback (most recent call last):
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
line 1342, in
[exec] main()
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
line 1288, in main
[exec] smokeTest(baseURL, version, tmpDir, isSigned)
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
line 1324, in smokeTest
[exec] unpackAndVerify('lucene', tmpDir, 'lucene-%s-src.tgz' %
version, version)
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
line 563, in unpackAndVerify
[exec] verifyUnpacked(project, artifact, unpackPath, version, tmpDir)
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
line 673, in verifyUnpacked
[exec] checkJavadocpathFull('%s/build/docs' % unpackPath)
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
line 854, in checkJavadocpathFull
[exec] if checkJavadocLinks.checkAll(path):
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/checkJavadocLinks.py",
line 160, in checkAll
[exec] allFiles[fullPath] = parse(fullPath, open('%s/%s' % (root, f),
encoding='UTF-8').read())
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/checkJavadocLinks.py",
line 110, in parse
[exec] parser.feed(html)
[exec] File "/usr/local/lib/python3.2/html/parser.py", line 142, in feed
[exec] self.goahead(0)
[exec] File "/usr/local/lib/python3.2/html/parser.py", line 188, in
goahead
[exec] k = self
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 2207 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/2207/ Java: 32bit/jdk1.7.0_09 -client -XX:+UseParallelGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.TestSolrCoreProperties Error Message: 2 threads leaked from SUITE scope at org.apache.solr.TestSolrCoreProperties: 1) Thread[id=24, name=metrics-meter-tick-thread-2, state=WAITING, group=TGRP-TestSolrCoreProperties] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1085) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722)2) Thread[id=23, name=metrics-meter-tick-thread-1, state=TIMED_WAITING, group=TGRP-TestSolrCoreProperties] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE scope at org.apache.solr.TestSolrCoreProperties: 1) Thread[id=24, name=metrics-meter-tick-thread-2, state=WAITING, group=TGRP-TestSolrCoreProperties] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1085) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) 2) Thread[id=23, name=metrics-meter-tick-thread-1, state=TIMED_WAITING, group=TGRP-TestSolrCoreProperties] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) at __randomizedtesting.SeedInfo.seed([D641E7CB765DCFC1]:0) FAILED: junit.framework.TestSuite.org.apache.solr.TestSolrCoreProperties Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=24, name=metrics-meter-tick-thread-2, state=WAITING, group=TGRP-TestSolrCoreProperties] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1085) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExe
[jira] [Updated] (LUCENE-4527) CompressingStoredFieldsFormat: encode numStoredFields more efficiently
[
https://issues.apache.org/jira/browse/LUCENE-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-4527:
-
Attachment: LUCENE-4527.patch
New patch without the minValue+delta trick. Instead it uses the exact same
trick as ForUtil: bitsRequired == 0 => all elements have the same value, which
is the next VInt.
> CompressingStoredFieldsFormat: encode numStoredFields more efficiently
> --
>
> Key: LUCENE-4527
> URL: https://issues.apache.org/jira/browse/LUCENE-4527
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.1
>
> Attachments: LUCENE-4527.patch, LUCENE-4527.patch
>
>
> Another interesting idea from Robert: many applications have a schema and all
> documents are likely to have the same number of stored fields. We could save
> space by using packed ints and the same kind of optimization as {{ForUtil}}
> (requiring only one VInt if all values are equal).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4030) Use Lucene segment merge throttling
[ https://issues.apache.org/jira/browse/SOLR-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated SOLR-4030: -- Labels: patch (was: ) > Use Lucene segment merge throttling > --- > > Key: SOLR-4030 > URL: https://issues.apache.org/jira/browse/SOLR-4030 > Project: Solr > Issue Type: Improvement >Affects Versions: 5.0 >Reporter: Radim Kolar > Labels: patch > Attachments: solr-mergeratelimit.txt > > > add argument "maxMergeWriteMBPerSec" to Solr directory factories. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4030) Use Lucene segment merge throttling
[ https://issues.apache.org/jira/browse/SOLR-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated SOLR-4030: -- Attachment: solr-mergeratelimit.txt > Use Lucene segment merge throttling > --- > > Key: SOLR-4030 > URL: https://issues.apache.org/jira/browse/SOLR-4030 > Project: Solr > Issue Type: Improvement >Affects Versions: 5.0 >Reporter: Radim Kolar > Attachments: solr-mergeratelimit.txt > > > add argument "maxMergeWriteMBPerSec" to Solr directory factories. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4030) Use Lucene segment merge throttling
Radim Kolar created SOLR-4030: - Summary: Use Lucene segment merge throttling Key: SOLR-4030 URL: https://issues.apache.org/jira/browse/SOLR-4030 Project: Solr Issue Type: Improvement Affects Versions: 5.0 Reporter: Radim Kolar Attachments: solr-mergeratelimit.txt add argument "maxMergeWriteMBPerSec" to Solr directory factories. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4536) Make PackedInts byte-aligned?
Adrien Grand created LUCENE-4536: Summary: Make PackedInts byte-aligned? Key: LUCENE-4536 URL: https://issues.apache.org/jira/browse/LUCENE-4536 Project: Lucene - Core Issue Type: Task Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 4.1 PackedInts are more and more used to save/restore small arrays, but given that they are long-aligned, up to 63 bits are wasted per array. We should try to make PackedInts storage byte-aligned so that only 7 bits are wasted in the worst case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2878) Allow Scorer to expose positions and payloads aka. nuke spans
[ https://issues.apache.org/jira/browse/LUCENE-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated LUCENE-2878: -- Attachment: LUCENE-2878.patch Here's a first attempt at duplicating the Span scoring in IntervalFilterQuery. It needs more tests, and the Explanation needs to be modified, but it's something :-) One thing I'm uncertain of is the algorithm being used for scoring here. It treats all matching 'spans' (or 'intervals' now, I suppose) in a document as equivalent for the purposes of scoring, weighting only by match distance, but this seems to throw away certain bits of possibly useful info - for example, if we're filtering over a BooleanQuery with a number of SHOULD clauses, then an interval that contains all of them is going to score the same as an interval that contains only two, but with the same overall match distance. This seems wrong... Or maybe I'm just misunderstanding how this gets put together. > Allow Scorer to expose positions and payloads aka. nuke spans > -- > > Key: LUCENE-2878 > URL: https://issues.apache.org/jira/browse/LUCENE-2878 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Affects Versions: Positions Branch >Reporter: Simon Willnauer >Assignee: Simon Willnauer > Labels: gsoc2011, gsoc2012, lucene-gsoc-11, lucene-gsoc-12, > mentor > Fix For: Positions Branch > > Attachments: LUCENE-2878-OR.patch, LUCENE-2878.patch, > LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, > LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, > LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, > LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, > LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, > LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, > LUCENE-2878_trunk.patch, LUCENE-2878_trunk.patch, LUCENE-2878-vs-trunk.patch, > PosHighlighter.patch, PosHighlighter.patch > > > Currently we have two somewhat separate types of queries, the one which can > make use of positions (mainly spans) and payloads (spans). Yet Span*Query > doesn't really do scoring comparable to what other queries do and at the end > of the day they are duplicating lot of code all over lucene. Span*Queries are > also limited to other Span*Query instances such that you can not use a > TermQuery or a BooleanQuery with SpanNear or anthing like that. > Beside of the Span*Query limitation other queries lacking a quiet interesting > feature since they can not score based on term proximity since scores doesn't > expose any positional information. All those problems bugged me for a while > now so I stared working on that using the bulkpostings API. I would have done > that first cut on trunk but TermScorer is working on BlockReader that do not > expose positions while the one in this branch does. I started adding a new > Positions class which users can pull from a scorer, to prevent unnecessary > positions enums I added ScorerContext#needsPositions and eventually > Scorere#needsPayloads to create the corresponding enum on demand. Yet, > currently only TermQuery / TermScorer implements this API and other simply > return null instead. > To show that the API really works and our BulkPostings work fine too with > positions I cut over TermSpanQuery to use a TermScorer under the hood and > nuked TermSpans entirely. A nice sideeffect of this was that the Position > BulkReading implementation got some exercise which now :) work all with > positions while Payloads for bulkreading are kind of experimental in the > patch and those only work with Standard codec. > So all spans now work on top of TermScorer ( I truly hate spans since today ) > including the ones that need Payloads (StandardCodec ONLY)!! I didn't bother > to implement the other codecs yet since I want to get feedback on the API and > on this first cut before I go one with it. I will upload the corresponding > patch in a minute. > I also had to cut over SpanQuery.getSpans(IR) to > SpanQuery.getSpans(AtomicReaderContext) which I should probably do on trunk > first but after that pain today I need a break first :). > The patch passes all core tests > (org.apache.lucene.search.highlight.HighlighterTest still fails but I didn't > look into the MemoryIndex BulkPostings API yet) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@luc
[jira] [Resolved] (LUCENE-4535) Make FilterIterator @lucene.internal
[ https://issues.apache.org/jira/browse/LUCENE-4535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-4535. -- Resolution: Fixed Committed to trunk (r1405655). > Make FilterIterator @lucene.internal > > > Key: LUCENE-4535 > URL: https://issues.apache.org/jira/browse/LUCENE-4535 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Fix For: 5.0 > > Attachments: LUCENE-4535.patch > > > FilterIterator has been release without the @lucene.internal tag, we should > fix it for 5.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4519) IndexDocument methods should not use wildcards in their return types
[
https://issues.apache.org/jira/browse/LUCENE-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand resolved LUCENE-4519.
--
Resolution: Fixed
Fix Version/s: 5.0
Committed to trunk (r1405639).
> IndexDocument methods should not use wildcards in their return types
>
>
> Key: LUCENE-4519
> URL: https://issues.apache.org/jira/browse/LUCENE-4519
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Trivial
> Fix For: 5.0
>
> Attachments: LUCENE-4519.patch, LUCENE-4519.patch
>
>
> {{public Iterable indexableFields()}} should be
> replaced with {{public Iterable indexableFields()}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4535) Make FilterIterator @lucene.internal
[ https://issues.apache.org/jira/browse/LUCENE-4535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-4535: - Attachment: LUCENE-4535.patch Patch. > Make FilterIterator @lucene.internal > > > Key: LUCENE-4535 > URL: https://issues.apache.org/jira/browse/LUCENE-4535 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Fix For: 5.0 > > Attachments: LUCENE-4535.patch > > > FilterIterator has been release without the @lucene.internal tag, we should > fix it for 5.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4535) Make FilterIterator @lucene.internal
[ https://issues.apache.org/jira/browse/LUCENE-4535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490310#comment-13490310 ] Uwe Schindler commented on LUCENE-4535: --- +1 > Make FilterIterator @lucene.internal > > > Key: LUCENE-4535 > URL: https://issues.apache.org/jira/browse/LUCENE-4535 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Fix For: 5.0 > > > FilterIterator has been release without the @lucene.internal tag, we should > fix it for 5.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4535) Make FilterIterator @lucene.internal
Adrien Grand created LUCENE-4535: Summary: Make FilterIterator @lucene.internal Key: LUCENE-4535 URL: https://issues.apache.org/jira/browse/LUCENE-4535 Project: Lucene - Core Issue Type: Task Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.0 FilterIterator has been release without the @lucene.internal tag, we should fix it for 5.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4527) CompressingStoredFieldsFormat: encode numStoredFields more efficiently
[
https://issues.apache.org/jira/browse/LUCENE-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490303#comment-13490303
]
Adrien Grand commented on LUCENE-4527:
--
bq. I'm not sure I like 4 vints for min and lengths? If documents (including
all fields) are largish then we might be making it worse.
I hadn't thought much of it. I assume there are 3 main cases:
1. if document lengths are larger than 16K there is no problem (when
chunkDocs==1, it only encodes 2 vints),
2. if the numbers of stored fields and document lengths vary by more than 50%,
it can waste 3 bytes (given that doc length < 2**14 and assuming
numStoredFields < 128),
3. if the number of stored fields and document lengths vary by less than 50%,
it saves at least 2 bits per document so the savings are 2 * chunkDocs - 3 * 8
bits (if docs are 8K each, this can waste 2.5 bytes, if docs are 1K each, this
can save 1 byte, if docs are 100 bytes each, this can save 38 bytes).
(I did the math while writing, please correct me if I'm wrong)
Both options seem to have pros and cons so I'm not sure which one to choose...
Which maybe means we should go for the easiest one? (without encoding the min
values as VInts)
> CompressingStoredFieldsFormat: encode numStoredFields more efficiently
> --
>
> Key: LUCENE-4527
> URL: https://issues.apache.org/jira/browse/LUCENE-4527
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.1
>
> Attachments: LUCENE-4527.patch
>
>
> Another interesting idea from Robert: many applications have a schema and all
> documents are likely to have the same number of stored fields. We could save
> space by using packed ints and the same kind of optimization as {{ForUtil}}
> (requiring only one VInt if all values are equal).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4029) Make DirectoryFactory names consistent between Solr and Lucene
[ https://issues.apache.org/jira/browse/SOLR-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated SOLR-4029: -- Labels: patch (was: ) Affects Version/s: 5.0 > Make DirectoryFactory names consistent between Solr and Lucene > -- > > Key: SOLR-4029 > URL: https://issues.apache.org/jira/browse/SOLR-4029 > Project: Solr > Issue Type: Improvement >Affects Versions: 5.0 >Reporter: Radim Kolar > Labels: patch > Attachments: solr-DFhier.txt > > > rename StandardDirectoryFactory to FSDirectory factory. It is much more > easier for user reading solr javadoc to understand whats is going there in > DirectoryFactory class hierarchy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4029) Make DirectoryFactory names consistent between Solr and Lucene
[ https://issues.apache.org/jira/browse/SOLR-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated SOLR-4029: -- Attachment: solr-DFhier.txt > Make DirectoryFactory names consistent between Solr and Lucene > -- > > Key: SOLR-4029 > URL: https://issues.apache.org/jira/browse/SOLR-4029 > Project: Solr > Issue Type: Improvement >Affects Versions: 5.0 >Reporter: Radim Kolar > Labels: patch > Attachments: solr-DFhier.txt > > > rename StandardDirectoryFactory to FSDirectory factory. It is much more > easier for user reading solr javadoc to understand whats is going there in > DirectoryFactory class hierarchy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4029) Make DirectoryFactory names consistent between Solr and Lucene
Radim Kolar created SOLR-4029: - Summary: Make DirectoryFactory names consistent between Solr and Lucene Key: SOLR-4029 URL: https://issues.apache.org/jira/browse/SOLR-4029 Project: Solr Issue Type: Improvement Reporter: Radim Kolar rename StandardDirectoryFactory to FSDirectory factory. It is much more easier for user reading solr javadoc to understand whats is going there in DirectoryFactory class hierarchy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3865) MemoryIndex does not allow user to add multiple values for a single field name
[
https://issues.apache.org/jira/browse/LUCENE-3865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer resolved LUCENE-3865.
-
Resolution: Duplicate
Fix Version/s: 5.0
4.1
Assignee: Simon Willnauer
included in LUCENE-4515
> MemoryIndex does not allow user to add multiple values for a single field name
> --
>
> Key: LUCENE-3865
> URL: https://issues.apache.org/jira/browse/LUCENE-3865
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/other
>Affects Versions: 3.5
> Environment: All
>Reporter: Dave Seltzer
>Assignee: Simon Willnauer
>Priority: Minor
> Fix For: 4.1, 5.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When using MemoryIndex.addField the following operation throws an
> IllegalArgumentException:
> index.addField("foobar", "value1", LuceneAnalyzer);
> index.addField("foobar", "value2", LuceneAnalyzer);
> This throws:
> java.lang.IllegalArgumentException: field must not be added more than once
> According to Uwe Schindler on the java-user mailing list this violates the
> IndexWriter/IndexReader contract.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3742) group.func and group.facet do not work together
[ https://issues.apache.org/jira/browse/SOLR-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490209#comment-13490209 ] Ted Strauss commented on SOLR-3742: --- Group faceting is implemented in SimpleFacets.java in the method - public int getGroupedFacetQueryCount(Query facetQuery) To generate the facets for a field, FieldCache is maintained and iterated over. So for group faceting, a field cache is maintained for group.field. Similarly a function cache needs to be maintained to be iterated over to create facets and facet counts. Presently there is no function cache implemented in Lucene > group.func and group.facet do not work together > --- > > Key: SOLR-3742 > URL: https://issues.apache.org/jira/browse/SOLR-3742 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 4.0-ALPHA, 4.0-BETA >Reporter: CP > > When doing a search like > http://localhost:8983/solr/select?group=true&group.func=product(fildname1,fieldname2)&group.facet=true&facet=true&facet.field=fieldname3 > an error is returned in response where facets are normally returned: > java.lang.ArrayIndexOutOfBoundsException: 0 at > org.apache.solr.request.SimpleFacets.getGroupedCounts(SimpleFacets.java:358) > ... > The function used can be any function, not product only. There is no such > error if group.facet is omitted or group.field is used instead of group.func. > It seems that group.field parameter is expected to be defined when > calculating grouped facets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4534) WFST/AnalyzingSuggest don't handle keys containing 0 bytes correctly
[ https://issues.apache.org/jira/browse/LUCENE-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-4534: --- Attachment: LUCENE-4534.patch Patch w/ failing test case for WFSTCompletionLookup and AnalyzingSuggester. > WFST/AnalyzingSuggest don't handle keys containing 0 bytes correctly > > > Key: LUCENE-4534 > URL: https://issues.apache.org/jira/browse/LUCENE-4534 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4534.patch > > > While binary terms w/ 0 bytes are rare, they are "allowed" but will cause > exceptions with at least WFST/AnalyzingSuggester. > I think to fix this we should pass custom Comparator to the offline sorter > that decodes each BytesRef key and does the actual comparison we want, > instead of using separator and relying on BytesRef.compareTo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (64bit/ibm-j9-jdk6) - Build # 2186 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux/2186/
Java: 64bit/ibm-j9-jdk6
-Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache/lucene/util/fst/FST;}
All tests passed
Build Log:
[...truncated 27386 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:60: The following
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build.xml:501: The
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:1961:
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:179)
at com.ibm.jsse2.b.a(b.java:42)
at com.ibm.jsse2.b.b(b.java:44)
at com.ibm.jsse2.b.a(b.java:116)
at com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:471)
at com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:426)
at com.ibm.jsse2.f.read(f.java:11)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:229)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:269)
at java.io.BufferedInputStream.read(BufferedInputStream.java:328)
at
sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:539)
at
sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:596)
at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:683)
at java.io.FilterInputStream.read(FilterInputStream.java:127)
at
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2684)
at
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2679)
at
org.apache.tools.ant.taskdefs.Get$GetThread.downloadFile(Get.java:745)
at org.apache.tools.ant.taskdefs.Get$GetThread.get(Get.java:586)
at org.apache.tools.ant.taskdefs.Get$GetThread.run(Get.java:569)
Total time: 43 minutes 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Description set: Java: 64bit/ibm-j9-jdk6
-Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache/lucene/util/fst/FST;}
Email was triggered for: Failure
Sending email for trigger: Failure
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4533) if you pass dups (same surface form) to AnalyzingSuggester it can fail to return enough results
[ https://issues.apache.org/jira/browse/LUCENE-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-4533: --- Attachment: LUCENE-4533.patch Patch w/ failing test ... it trips the assert in TopNSearcher that detects a too-small maxQueueDepth. > if you pass dups (same surface form) to AnalyzingSuggester it can fail to > return enough results > --- > > Key: LUCENE-4533 > URL: https://issues.apache.org/jira/browse/LUCENE-4533 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4533.patch > > > The problem is (again) the queue pruning we do. > I think we should de-dup the user's input (keeping highest weight for each > surface form) before adding to the FST. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4534) WFST/AnalyzingSuggest don't handle keys containing 0 bytes correctly
Michael McCandless created LUCENE-4534: -- Summary: WFST/AnalyzingSuggest don't handle keys containing 0 bytes correctly Key: LUCENE-4534 URL: https://issues.apache.org/jira/browse/LUCENE-4534 Project: Lucene - Core Issue Type: Bug Reporter: Michael McCandless Fix For: 4.1, 5.0 While binary terms w/ 0 bytes are rare, they are "allowed" but will cause exceptions with at least WFST/AnalyzingSuggester. I think to fix this we should pass custom Comparator to the offline sorter that decodes each BytesRef key and does the actual comparison we want, instead of using separator and relying on BytesRef.compareTo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-4533) if you pass dups (same surface form) to AnalyzingSuggester it can fail to return enough results
[ https://issues.apache.org/jira/browse/LUCENE-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless reassigned LUCENE-4533: -- Assignee: Michael McCandless > if you pass dups (same surface form) to AnalyzingSuggester it can fail to > return enough results > --- > > Key: LUCENE-4533 > URL: https://issues.apache.org/jira/browse/LUCENE-4533 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.1, 5.0 > > > The problem is (again) the queue pruning we do. > I think we should de-dup the user's input (keeping highest weight for each > surface form) before adding to the FST. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4533) if you pass dups (same surface form) to AnalyzingSuggester it can fail to return enough results
Michael McCandless created LUCENE-4533: -- Summary: if you pass dups (same surface form) to AnalyzingSuggester it can fail to return enough results Key: LUCENE-4533 URL: https://issues.apache.org/jira/browse/LUCENE-4533 Project: Lucene - Core Issue Type: Bug Reporter: Michael McCandless Fix For: 4.1, 5.0 The problem is (again) the queue pruning we do. I think we should de-dup the user's input (keeping highest weight for each surface form) before adding to the FST. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4519) IndexDocument methods should not use wildcards in their return types
[
https://issues.apache.org/jira/browse/LUCENE-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490195#comment-13490195
]
Uwe Schindler commented on LUCENE-4519:
---
+1
> IndexDocument methods should not use wildcards in their return types
>
>
> Key: LUCENE-4519
> URL: https://issues.apache.org/jira/browse/LUCENE-4519
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Trivial
> Attachments: LUCENE-4519.patch, LUCENE-4519.patch
>
>
> {{public Iterable indexableFields()}} should be
> replaced with {{public Iterable indexableFields()}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3967) Mapping error: langid.enforceSchema option checks source field instead of target field
[
https://issues.apache.org/jira/browse/SOLR-3967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490188#comment-13490188
]
Alexey Kudinov commented on SOLR-3967:
--
Apparently it should check the mapped field
> Mapping error: langid.enforceSchema option checks source field instead of
> target field
> --
>
> Key: SOLR-3967
> URL: https://issues.apache.org/jira/browse/SOLR-3967
> Project: Solr
> Issue Type: Bug
> Components: contrib - LangId
>Affects Versions: 4.0
>Reporter: Mateusz Matela
>
> I use LangDetect update processor with a document that has "body" field.
> LangDetect should map this field to "body_pl", "body_en" or "body_nolang". My
> schema defines fields with language suffixes, but not "body" field. When the
> processor runs, I get error:
> {quote}Unsuccessful field name mapping to body_nolang, field does not exist,
> skipping mapping.{quote}
> I looked up source code and it seems there's an error in
> {{org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.process(SolrInputDocument)}}:
> {noformat}
> String mappedOutputField = getMappedField(fieldName, fieldLang);
> if(enforceSchema && schema.getFieldOrNull(fieldName) == null) {
> log.warn("Unsuccessful field name mapping to {}, field does not
> exist, skipping mapping.", mappedOutputField, fieldName);
> mappedOutputField = fieldName;
> }
> {noformat}
> I think it should check for {{schema.getFieldOrNull(mappedOutputField)}}
> instead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4519) IndexDocument methods should not use wildcards in their return types
[
https://issues.apache.org/jira/browse/LUCENE-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-4519:
-
Attachment: LUCENE-4519.patch
New patch with improved javadocs. Does it look better?
> IndexDocument methods should not use wildcards in their return types
>
>
> Key: LUCENE-4519
> URL: https://issues.apache.org/jira/browse/LUCENE-4519
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Trivial
> Attachments: LUCENE-4519.patch, LUCENE-4519.patch
>
>
> {{public Iterable indexableFields()}} should be
> replaced with {{public Iterable indexableFields()}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4531) Does CompressingStoredFieldsFormat only support less than 2G segment, thanks.
[ https://issues.apache.org/jira/browse/LUCENE-4531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved LUCENE-4531. Resolution: Not A Problem Littlestar: Please raise this kind of question on the user's list first, JIRAs are intended for development issues/bugs, not general questions > Does CompressingStoredFieldsFormat only support less than 2G segment, thanks. > - > > Key: LUCENE-4531 > URL: https://issues.apache.org/jira/browse/LUCENE-4531 > Project: Lucene - Core > Issue Type: Bug > Components: core/codecs >Affects Versions: 4.1 > Environment: Centos >Reporter: Littlestar >Priority: Minor > Original Estimate: 120h > Remaining Estimate: 120h > > I see a note on CompressingStoredFieldsFormat.java. > > For a chunk size of chunkSize bytes, this StoredFieldsFormat does not support > documents larger than (2^31 - chunkSize) bytes. In case this is a problem, > you should use another format, such as Lucene40StoredFieldsFormat. > > Does CompressingStoredFieldsFormat only support less than 2G segment? > Is this a bug? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2526) Grouping on multiple fields
[ https://issues.apache.org/jira/browse/SOLR-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490181#comment-13490181 ] Dotan Cohen commented on SOLR-2526: --- >If people start using the grouping feature, probably this will be higher >priority. > My employer's application is using the grouping feature, and we would find this feature very useful. > Grouping on multiple fields > --- > > Key: SOLR-2526 > URL: https://issues.apache.org/jira/browse/SOLR-2526 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.0-ALPHA >Reporter: Arian Karbasi >Priority: Minor > > Grouping on multiple fields and/or ranges should be an option (X,Y) > groupings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4527) CompressingStoredFieldsFormat: encode numStoredFields more efficiently
[
https://issues.apache.org/jira/browse/LUCENE-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490179#comment-13490179
]
Robert Muir commented on LUCENE-4527:
-
And of course for this test (and any other test of compressing stored fields),
that
"fake" wikipedia corpus being used is totally invalid because all documents are
truncated to a specific length :)
> CompressingStoredFieldsFormat: encode numStoredFields more efficiently
> --
>
> Key: LUCENE-4527
> URL: https://issues.apache.org/jira/browse/LUCENE-4527
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.1
>
> Attachments: LUCENE-4527.patch
>
>
> Another interesting idea from Robert: many applications have a schema and all
> documents are likely to have the same number of stored fields. We could save
> space by using packed ints and the same kind of optimization as {{ForUtil}}
> (requiring only one VInt if all values are equal).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4527) CompressingStoredFieldsFormat: encode numStoredFields more efficiently
[
https://issues.apache.org/jira/browse/LUCENE-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490178#comment-13490178
]
Robert Muir commented on LUCENE-4527:
-
I'm not sure I like 4 vints for min and lengths? If documents (including all
fields) are largish then we might be making it worse.
Is the min really worth it? It seems like too much overhead.
> CompressingStoredFieldsFormat: encode numStoredFields more efficiently
> --
>
> Key: LUCENE-4527
> URL: https://issues.apache.org/jira/browse/LUCENE-4527
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.1
>
> Attachments: LUCENE-4527.patch
>
>
> Another interesting idea from Robert: many applications have a schema and all
> documents are likely to have the same number of stored fields. We could save
> space by using packed ints and the same kind of optimization as {{ForUtil}}
> (requiring only one VInt if all values are equal).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4519) IndexDocument methods should not use wildcards in their return types
[
https://issues.apache.org/jira/browse/LUCENE-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490177#comment-13490177
]
Uwe Schindler commented on LUCENE-4519:
---
Can you add javadocs to FilterIterator, so the generics are more clear. It is
confusing which one is the inner iterator's type and which one the outer's. I
would propose to rename the params to be more clear, too. Like
FilterIterator.
> IndexDocument methods should not use wildcards in their return types
>
>
> Key: LUCENE-4519
> URL: https://issues.apache.org/jira/browse/LUCENE-4519
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Trivial
> Attachments: LUCENE-4519.patch
>
>
> {{public Iterable indexableFields()}} should be
> replaced with {{public Iterable indexableFields()}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4519) IndexDocument methods should not use wildcards in their return types
[
https://issues.apache.org/jira/browse/LUCENE-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490176#comment-13490176
]
Uwe Schindler commented on LUCENE-4519:
---
I agree with this, the wildcard is useless here and not really user-friendly. I
think it was added to prevent some unchecked casts from different Field types,
which can still be done, if the called methods have correct generics.
I am not so happy with the FilterIterator change, but I agree that it is needed
here, otherwise it gets unchecked casts in the predicate.
> IndexDocument methods should not use wildcards in their return types
>
>
> Key: LUCENE-4519
> URL: https://issues.apache.org/jira/browse/LUCENE-4519
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Trivial
> Attachments: LUCENE-4519.patch
>
>
> {{public Iterable indexableFields()}} should be
> replaced with {{public Iterable indexableFields()}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4527) CompressingStoredFieldsFormat: encode numStoredFields more efficiently
[
https://issues.apache.org/jira/browse/LUCENE-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-4527:
-
Attachment: LUCENE-4527.patch
Patch. The number of stored fields and document lengths are encoded more
efficiently: I first compute the minimum value and then only encode the deltas.
In case documents have similar numbers of stored fields and lengths, this
should be a little more efficient.
> CompressingStoredFieldsFormat: encode numStoredFields more efficiently
> --
>
> Key: LUCENE-4527
> URL: https://issues.apache.org/jira/browse/LUCENE-4527
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.1
>
> Attachments: LUCENE-4527.patch
>
>
> Another interesting idea from Robert: many applications have a schema and all
> documents are likely to have the same number of stored fields. We could save
> space by using packed ints and the same kind of optimization as {{ForUtil}}
> (requiring only one VInt if all values are equal).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4532) TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy failure
Shai Erera created LUCENE-4532:
--
Summary:
TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy failure
Key: LUCENE-4532
URL: https://issues.apache.org/jira/browse/LUCENE-4532
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Reporter: Shai Erera
Assignee: Shai Erera
The following failure on Jenkins:
{noformat}
> Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows/1404/
> Java: 32bit/jdk1.6.0_37 -client -XX:+UseConcMarkSweepGC
>
> 1 tests failed.
> REGRESSION:
> org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy
>
> Error Message:
>
>
> Stack Trace:
> java.lang.ArrayIndexOutOfBoundsException
> at
> __randomizedtesting.SeedInfo.seed([6AB10D3E4E956CFA:BFB2863DB7E077E0]:0)
> at java.lang.System.arraycopy(Native Method)
> at
> org.apache.lucene.facet.taxonomy.directory.ParentArray.refresh(ParentArray.java:99)
> at
> org.apache.lucene.facet.taxonomy.directory.DirectoryTaxonomyReader.refresh(DirectoryTaxonomyReader.java:407)
> at
> org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.doTestReadRecreatedTaxono(TestDirectoryTaxonomyReader.java:167)
> at
> org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy(TestDirectoryTaxonomyReader.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at
> org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMa
[jira] [Commented] (LUCENE-4532) TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy failure
[
https://issues.apache.org/jira/browse/LUCENE-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490156#comment-13490156
]
Shai Erera commented on LUCENE-4532:
Hmmm ... perhaps this explains the bug and why I cannot reproduce it. Here's a
code snippet from DirTaxoReader.refresh():
{code}
String t1 =
indexReader.getIndexCommit().getUserData().get(DirectoryTaxonomyWriter.INDEX_CREATE_TIME);
String t2 =
r2.getIndexCommit().getUserData().get(DirectoryTaxonomyWriter.INDEX_CREATE_TIME);
if (t1==null) {
if (t2!=null) {
r2.close();
throw new InconsistentTaxonomyException("Taxonomy was recreated at:
"+t2);
}
} else if (!t1.equals(t2)) {
r2.close();
throw new InconsistentTaxonomyException("Taxonomy was recreated at:
"+t2+" != "+t1);
}
{code}
The code compares the commit data that is known to the indexReader instance at
hand, and the reopened one. If they do not match, it throws an exception, as
this TaxoReader cannot be refreshed.
The commit data relies on timestamp, which is a bad thing in general, even if
the timestamp is in nano-second granularity. So what happens if a machine is
able to add a category and commit DirTW in the same nano-second? Or maybe just
open DirTW with OpenMode.CREATE and close it? Or the clocks somehow get messed
up? The two timestamps in the commit data may accidentally be the same, leading
to the exception exposed by the stacktrace above.
I tried to modify the test to always use RAMDirectory() and not add any
categories, just recreate+close, but I couldn't reproduce it either. However, I
tried that on my laptop, and the timestamp is nano-second, so it may not be
fast enough.
Still, I think that that is a potential bug and may explain the errors that we
see. The test is single threaded, the seed ensures we reproduce everything
right, so all is left to blame is the machine's clock :).
I'll try to verify that a bit more, and on other machines, but I think that we
should move to store an increment version number instead of timestamp.
> TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy failure
>
>
> Key: LUCENE-4532
> URL: https://issues.apache.org/jira/browse/LUCENE-4532
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/facet
>Reporter: Shai Erera
>Assignee: Shai Erera
>
> The following failure on Jenkins:
> {noformat}
> > Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows/1404/
> > Java: 32bit/jdk1.6.0_37 -client -XX:+UseConcMarkSweepGC
> >
> > 1 tests failed.
> > REGRESSION:
> > org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy
> >
> > Error Message:
> >
> >
> > Stack Trace:
> > java.lang.ArrayIndexOutOfBoundsException
> > at
> > __randomizedtesting.SeedInfo.seed([6AB10D3E4E956CFA:BFB2863DB7E077E0]:0)
> > at java.lang.System.arraycopy(Native Method)
> > at
> > org.apache.lucene.facet.taxonomy.directory.ParentArray.refresh(ParentArray.java:99)
> > at
> > org.apache.lucene.facet.taxonomy.directory.DirectoryTaxonomyReader.refresh(DirectoryTaxonomyReader.java:407)
> > at
> > org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.doTestReadRecreatedTaxono(TestDirectoryTaxonomyReader.java:167)
> > at
> > org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy(TestDirectoryTaxonomyReader.java:130)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:597)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
> > at
> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> > at
> > org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
> > at
> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> > at
> > com.carrotsearc
[jira] [Commented] (LUCENE-4532) TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy failure
[
https://issues.apache.org/jira/browse/LUCENE-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490151#comment-13490151
]
Dawid Weiss commented on LUCENE-4532:
-
This looks like some sort of race condition -- I can't reproduce either but I
can't get the code to even enter the block which caused this failure; in
ParentArray:
{code}
int num = indexReader.maxDoc();
if (prefetchParentOrdinal==null) {
...
} else {
HERE?!
}
{code}
Perhaps if you try to make it enter that block it'll be more repeatable.
> TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy failure
>
>
> Key: LUCENE-4532
> URL: https://issues.apache.org/jira/browse/LUCENE-4532
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/facet
>Reporter: Shai Erera
>Assignee: Shai Erera
>
> The following failure on Jenkins:
> {noformat}
> > Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows/1404/
> > Java: 32bit/jdk1.6.0_37 -client -XX:+UseConcMarkSweepGC
> >
> > 1 tests failed.
> > REGRESSION:
> > org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy
> >
> > Error Message:
> >
> >
> > Stack Trace:
> > java.lang.ArrayIndexOutOfBoundsException
> > at
> > __randomizedtesting.SeedInfo.seed([6AB10D3E4E956CFA:BFB2863DB7E077E0]:0)
> > at java.lang.System.arraycopy(Native Method)
> > at
> > org.apache.lucene.facet.taxonomy.directory.ParentArray.refresh(ParentArray.java:99)
> > at
> > org.apache.lucene.facet.taxonomy.directory.DirectoryTaxonomyReader.refresh(DirectoryTaxonomyReader.java:407)
> > at
> > org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.doTestReadRecreatedTaxono(TestDirectoryTaxonomyReader.java:167)
> > at
> > org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy(TestDirectoryTaxonomyReader.java:130)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:597)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
> > at
> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> > at
> > org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
> > at
> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> > at
> > com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> > at
> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
> > at
> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
> > at
> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> > at
> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> > at
> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
> > at
> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
> > at
> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
> > at
> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> > at
> > org.apache.lucene.util.TestRuleStoreClass
[jira] [Commented] (LUCENE-4532) TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy failure
[
https://issues.apache.org/jira/browse/LUCENE-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490148#comment-13490148
]
Shai Erera commented on LUCENE-4532:
The test isn't even concurrent (!), so why can't I reproduce !? Anyway,
continue digging ...
> TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy failure
>
>
> Key: LUCENE-4532
> URL: https://issues.apache.org/jira/browse/LUCENE-4532
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/facet
>Reporter: Shai Erera
>Assignee: Shai Erera
>
> The following failure on Jenkins:
> {noformat}
> > Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows/1404/
> > Java: 32bit/jdk1.6.0_37 -client -XX:+UseConcMarkSweepGC
> >
> > 1 tests failed.
> > REGRESSION:
> > org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy
> >
> > Error Message:
> >
> >
> > Stack Trace:
> > java.lang.ArrayIndexOutOfBoundsException
> > at
> > __randomizedtesting.SeedInfo.seed([6AB10D3E4E956CFA:BFB2863DB7E077E0]:0)
> > at java.lang.System.arraycopy(Native Method)
> > at
> > org.apache.lucene.facet.taxonomy.directory.ParentArray.refresh(ParentArray.java:99)
> > at
> > org.apache.lucene.facet.taxonomy.directory.DirectoryTaxonomyReader.refresh(DirectoryTaxonomyReader.java:407)
> > at
> > org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.doTestReadRecreatedTaxono(TestDirectoryTaxonomyReader.java:167)
> > at
> > org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy(TestDirectoryTaxonomyReader.java:130)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:597)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
> > at
> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> > at
> > org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
> > at
> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> > at
> > com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> > at
> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
> > at
> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
> > at
> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> > at
> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> > at
> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
> > at
> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
> > at
> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
> > at
> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> > at
> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
> > at
> > com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> > at
> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRu
Re: [JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.8.0-ea-b58) - Build # 2179 - Failure!
As advertised: At least one slave process threw an exception, first: Forked process returned with error code: 134 Very likely a JVM crash. Process output piped in logs above. And here it comes: [junit4:junit4] JVM J0: stdout was not empty, see: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build/solr-core/test/junit4-J0-20121104_054025_029.sysout [junit4:junit4] >>> JVM J0: stdout (verbatim) [junit4:junit4] # [junit4:junit4] # A fatal error has been detected by the Java Runtime Environment: [junit4:junit4] # [junit4:junit4] # SIGSEGV (0xb) at pc=0x7f17ce62be3f, pid=3547, tid=139739614934784 [junit4:junit4] # [junit4:junit4] # JRE version: Java(TM) SE Runtime Environment (8.0-b58) [junit4:junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b02 mixed mode linux-amd64 compressed oops) [junit4:junit4] # Problematic frame: [junit4:junit4] # V [libjvm.so+0x3bfe3f] ciObjectFactory::create_new_object(Metadata*)+0x2f [junit4:junit4] # [junit4:junit4] # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again [junit4:junit4] # [junit4:junit4] # An error report file with more information is saved as: [junit4:junit4] # /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build/solr-core/test/J0/hs_err_pid3547.log [junit4:junit4] # [junit4:junit4] # If you would like to submit a bug report, please visit: [junit4:junit4] # http://bugreport.sun.com/bugreport/crash.jsp [junit4:junit4] # [junit4:junit4] <<< JVM J0: EOF D. On Sun, Nov 4, 2012 at 6:52 AM, Policeman Jenkins Server < jenk...@sd-datasolutions.de> wrote: > Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux/2179/ > Java: 64bit/jdk1.8.0-ea-b58 -XX:+UseParallelGC > > All tests passed > > Build Log: > [...truncated 8982 lines...] > [junit4:junit4] ERROR: JVM J0 ended with an exception, command line: > /mnt/ssd/jenkins/tools/java/64bit/jdk1.8.0-ea-b58/jre/bin/java > -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError > -XX:HeapDumpPath=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/heapdumps > -Dtests.prefix=tests -Dtests.seed=B5BAB12022EB667C -Xmx512M -Dtests.iters= > -Dtests.verbose=false -Dtests.infostream=false > -Dtests.lockdir=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build > -Dtests.codec=random -Dtests.postingsformat=random -Dtests.locale=random > -Dtests.timezone=random -Dtests.directory=random > -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=4.1 > -Dtests.cleanthreads=perClass > -Djava.util.logging.config.file=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/testlogging.properties > -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true > -Dtests.asserts.gracious=false -Dtests.multiplier=3 -DtempDir=. > -Djava.io.tmpdir=. > -Dtests.sandbox.dir=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build/solr-core > -Dclover.db.dir=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/clover/db > -Djava.security.manager=org.apache.lucene.util.TestSecurityManager > -Djava.security.policy=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/junit4/tests.policy > -Dlucene.version=4.1-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 > -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory > -Djava.awt.headless=true -classpath > /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build/solr-core/classes/test:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build/solr-test-framework/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build/solr-core/test-files:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/test-framework/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/codecs/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build/solr-solrj/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build/solr-core/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/analysis/common/lucene-analyzers-common-4.1-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/analysis/kuromoji/lucene-analyzers-kuromoji-4.1-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/analysis/phonetic/lucene-analyzers-phonetic-4.1-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/highlighter/lucene-highlighter-4.1-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/memory/lucene-memory-4.1-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/misc/lucene-misc-4.1-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/spatial/lucene-spatial-4.1-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/suggest/lucene-suggest-4.1-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/grouping/lucene-grouping-4.1-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/queries/lucene-
[jira] [Commented] (LUCENE-4532) TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy failure
[
https://issues.apache.org/jira/browse/LUCENE-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490147#comment-13490147
]
Shai Erera commented on LUCENE-4532:
Doesn't reproduce on my machine. I tried with -Dtests.iters=100 and still not
reproducing. Will dig in the code ...
> TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy failure
>
>
> Key: LUCENE-4532
> URL: https://issues.apache.org/jira/browse/LUCENE-4532
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/facet
>Reporter: Shai Erera
>Assignee: Shai Erera
>
> The following failure on Jenkins:
> {noformat}
> > Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows/1404/
> > Java: 32bit/jdk1.6.0_37 -client -XX:+UseConcMarkSweepGC
> >
> > 1 tests failed.
> > REGRESSION:
> > org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy
> >
> > Error Message:
> >
> >
> > Stack Trace:
> > java.lang.ArrayIndexOutOfBoundsException
> > at
> > __randomizedtesting.SeedInfo.seed([6AB10D3E4E956CFA:BFB2863DB7E077E0]:0)
> > at java.lang.System.arraycopy(Native Method)
> > at
> > org.apache.lucene.facet.taxonomy.directory.ParentArray.refresh(ParentArray.java:99)
> > at
> > org.apache.lucene.facet.taxonomy.directory.DirectoryTaxonomyReader.refresh(DirectoryTaxonomyReader.java:407)
> > at
> > org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.doTestReadRecreatedTaxono(TestDirectoryTaxonomyReader.java:167)
> > at
> > org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testRefreshReadRecreatedTaxonomy(TestDirectoryTaxonomyReader.java:130)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:597)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
> > at
> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> > at
> > org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
> > at
> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> > at
> > com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> > at
> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
> > at
> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
> > at
> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> > at
> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> > at
> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
> > at
> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
> > at
> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
> > at
> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
> > at
> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> > at
> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
> > at
> > com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> > at
> > com.carrotsearch.randomizedtesting.rules.NoShadowin
[jira] [Commented] (LUCENE-4531) Does CompressingStoredFieldsFormat only support less than 2G segment, thanks.
[ https://issues.apache.org/jira/browse/LUCENE-4531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490146#comment-13490146 ] Adrien Grand commented on LUCENE-4531: -- Hi Littlestar, ~2GB is the maximum size of one single document. Segments can grow much larger (for example we have a test that creates more than 4GB of stored fields). > Does CompressingStoredFieldsFormat only support less than 2G segment, thanks. > - > > Key: LUCENE-4531 > URL: https://issues.apache.org/jira/browse/LUCENE-4531 > Project: Lucene - Core > Issue Type: Bug > Components: core/codecs >Affects Versions: 4.1 > Environment: Centos >Reporter: Littlestar >Priority: Minor > Original Estimate: 120h > Remaining Estimate: 120h > > I see a note on CompressingStoredFieldsFormat.java. > > For a chunk size of chunkSize bytes, this StoredFieldsFormat does not support > documents larger than (2^31 - chunkSize) bytes. In case this is a problem, > you should use another format, such as Lucene40StoredFieldsFormat. > > Does CompressingStoredFieldsFormat only support less than 2G segment? > Is this a bug? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4531) Does CompressingStoredFieldsFormat only support less than 2G segment, thanks.
Littlestar created LUCENE-4531: -- Summary: Does CompressingStoredFieldsFormat only support less than 2G segment, thanks. Key: LUCENE-4531 URL: https://issues.apache.org/jira/browse/LUCENE-4531 Project: Lucene - Core Issue Type: Bug Components: core/codecs Affects Versions: 4.1 Environment: Centos Reporter: Littlestar Priority: Minor I see a note on CompressingStoredFieldsFormat.java. For a chunk size of chunkSize bytes, this StoredFieldsFormat does not support documents larger than (2^31 - chunkSize) bytes. In case this is a problem, you should use another format, such as Lucene40StoredFieldsFormat. Does CompressingStoredFieldsFormat only support less than 2G segment? Is this a bug? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
