Re: [jira] [Commented] (LUCENE-5451) Update Spatial4j to 0.4.1
Trunk & branch_4x & lucene_solr_4_7 have the new change for Spatial4j
0.4.1 committed.
JIRA is down.
On 2/18/14, 4:39 PM, "David Smiley (JIRA)" wrote:
>
>[
>https://issues.apache.org/jira/browse/LUCENE-5451?page=com.atlassian.jira.
>plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904638#co
>mment-13904638 ]
>
>David Smiley commented on LUCENE-5451:
>--
>
>I'd just like to take a moment to clarify some things for [~simonw] -- we
>were chatting in IRC but needed to sign off for the night. Others may be
>curious.
>
>Firstly, Spatial4j has its own tests using the same extensive
>randomization methodology & actual libraries (JUnit & RandomizedTesting)
>that Lucene uses, and it's run by CI -- TravisCI. I fixed the
>aforementioned bug and it has a test now to catch potential regressions.
>Even if Lucene could test this particular bug (it can't due to needing
>JTS; see next paragraph), I don't think that it's needed since it's
>already tested somewhere (Spatial4j's tests itself). That said, I'd love
>to incorporate some JTS using tests in Lucene that exercise various
>things at once (sort of an integration test) including definitely what
>this bug is related to.
>
>Until JTS is relicensed to Eclipse Public License (which is pending to
>occur sometime this year) Lucene can't use it, and AFAIK we're not even
>permitted to put it on the test classpath (right?). It wouldn't be a
>test compile-dependency; it needs to be available at runtime so Spatial4j
>can use it. Perhaps Lucene's Jenkins can put it on the classpath when it
>runs tests? [~thetaphi] what do you think? There does exist one test
>which uses {{assumeTrue(...check for JTS...);}} --
>[JtsPolygonTest|https://github.com/apache/lucene-solr/blob/trunk/lucene/sp
>atial/src/test/org/apache/lucene/spatial/prefix/JtsPolygonTest.java?source
>=cc#L52] and in practice they never get run.
>
>
>> Update Spatial4j to 0.4.1
>> -
>>
>> Key: LUCENE-5451
>> URL: https://issues.apache.org/jira/browse/LUCENE-5451
>> Project: Lucene - Core
>> Issue Type: Bug
>> Components: modules/spatial
>>Affects Versions: 4.7, 5.0
>>Reporter: David Smiley
>>Assignee: David Smiley
>>Priority: Blocker
>> Fix For: 4.7, 5.0
>>
>>
>> A user reported a fairly serious issue affecting the latest version of
>>Spatial4j 0.4
>> https://github.com/spatial4j/spatial4j/issues/72
>>"JtsSpatialContextFactory and geo=false with worldBounds fails"
>> I've already fixed this locally and I'll push out a bug-fix Spatial4j
>>0.4.1. Upgrading will be a complete drop-in replacement. Heck I could
>>do that now but as I work with the user who found the bug I want to see
>>if there's any other problem.
>
>
>
>--
>This message was sent by Atlassian JIRA
>(v6.1.5#6160)
>
>-
>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/jdk1.7.0_60-ea-b04) - Build # 9416 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9416/ Java: 64bit/jdk1.7.0_60-ea-b04 -XX:-UseCompressedOops -XX:+UseSerialGC All tests passed Build Log: [...truncated 42006 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] warning: [options] bootstrap class path not set in conjunction with -source 1.6 [javadoc] Loading source files for package org.apache.lucene... [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.analysis.tokenattributes... [javadoc] Loading source files for package org.apache.lucene.codecs... [javadoc] Loading source files for package org.apache.lucene.codecs.compressing... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene3x... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene41... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene42... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene45... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene46... [javadoc] Loading source files for package org.apache.lucene.codecs.perfield... [javadoc] Loading source files for package org.apache.lucene.document... [javadoc] Loading source files for package org.apache.lucene.index... [javadoc] Loading source files for package org.apache.lucene.search... [javadoc] Loading source files for package org.apache.lucene.search.payloads... [javadoc] Loading source files for package org.apache.lucene.search.similarities... [javadoc] Loading source files for package org.apache.lucene.search.spans... [javadoc] Loading source files for package org.apache.lucene.store... [javadoc] Loading source files for package org.apache.lucene.util... [javadoc] Loading source files for package org.apache.lucene.util.automaton... [javadoc] Loading source files for package org.apache.lucene.util.fst... [javadoc] Loading source files for package org.apache.lucene.util.mutable... [javadoc] Loading source files for package org.apache.lucene.util.packed... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_60-ea [javadoc] Building tree for all the packages and classes... [javadoc] Generating /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/org/apache/lucene/search/package-summary.html... [javadoc] Copying file /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/core/src/java/org/apache/lucene/search/doc-files/nrq-formula-2.png to directory /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/org/apache/lucene/search/doc-files... [javadoc] Copying file /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/core/src/java/org/apache/lucene/search/doc-files/nrq-formula-1.png to directory /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/org/apache/lucene/search/doc-files... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/help-doc.html... [javadoc] 1 warning [...truncated 27 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.analysis.ar... [javadoc] warning: [options] bootstrap class path not set in conjunction with -source 1.6 [javadoc] Loading source files for package org.apache.lucene.analysis.bg... [javadoc] Loading source files for package org.apache.lucene.analysis.br... [javadoc] Loading source files for package org.apache.lucene.analysis.ca... [javadoc] Loading source files for package org.apache.lucene.analysis.charfilter... [javadoc] Loading source files for package org.apache.lucene.analysis.cjk... [javadoc] Loading source files for package org.apache.lucene.analysis.ckb... [javadoc] Loading source files for package org.apache.lucene.analysis.cn... [javadoc] Loading source files for package org.apache.lucene.analysis.commongrams... [javadoc] Loading source files for package org.apache.lucene.analysis.compound... [javadoc] Loading source files for package org.apache.lucene.analysis.compound.hyphenation... [javadoc] Loading source files for package org.apache.lucene.analysis.core... [javadoc] Loading source files for package org.apache.lucene.analysis.cz... [javadoc] Loading source files for package org.apache.lucene.analysis.da... [javadoc] Loading source files for package org.apache.lucene.analysis.de... [javadoc] Loading source files for package org.apache.lucene.analysis.el... [javadoc] Loading source files for package org.apache.lucene.analysis.en... [javadoc] Loading source files for package org.apache.lucene.analysis.es... [javadoc] Loading
[jira] [Created] (LUCENE-5454) SortField for SortedSetDV
Robert Muir created LUCENE-5454: --- Summary: SortField for SortedSetDV Key: LUCENE-5454 URL: https://issues.apache.org/jira/browse/LUCENE-5454 Project: Lucene - Core Issue Type: New Feature Components: modules/other Reporter: Robert Muir Currently, its not possible to sort by a sortedsetdv (e.g. a multi-valued field). So the idea is to provide some comparators that let you do this: by choosing a selector (e.g. min/max/median type stuff) that picks a value from the set as a representative sort value. The implementation is pretty simple, just actually wrap the SortedSet in a SortedDV that does the selection, and re-use the existing TermOrdValComparator logic. One issue is that, with the current sortedset API only 'min' is a viable option because its the only one that can be done in constant time. So this patch adds an optional extension (RandomAccessOrds) for codecs that can support random access. I added this to the default codec, diskdv, and direct, as they can all easily support it. While this could be useful for other purposes (e.g. min/max as valuesource or whatever), i think its best to be optional because it prevents some forms of encoding/compression. Anyway I'm targeting lucene/sandbox with this change... -- This message was sent by Atlassian JIRA (v6.1.5#6160) - 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/jdk1.7.0_51) - Build # 9415 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9415/ Java: 64bit/jdk1.7.0_51 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 42055 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] warning: [options] bootstrap class path not set in conjunction with -source 1.6 [javadoc] Loading source files for package org.apache.lucene... [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.analysis.tokenattributes... [javadoc] Loading source files for package org.apache.lucene.codecs... [javadoc] Loading source files for package org.apache.lucene.codecs.compressing... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene3x... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene41... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene42... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene45... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene46... [javadoc] Loading source files for package org.apache.lucene.codecs.perfield... [javadoc] Loading source files for package org.apache.lucene.document... [javadoc] Loading source files for package org.apache.lucene.index... [javadoc] Loading source files for package org.apache.lucene.search... [javadoc] Loading source files for package org.apache.lucene.search.payloads... [javadoc] Loading source files for package org.apache.lucene.search.similarities... [javadoc] Loading source files for package org.apache.lucene.search.spans... [javadoc] Loading source files for package org.apache.lucene.store... [javadoc] Loading source files for package org.apache.lucene.util... [javadoc] Loading source files for package org.apache.lucene.util.automaton... [javadoc] Loading source files for package org.apache.lucene.util.fst... [javadoc] Loading source files for package org.apache.lucene.util.mutable... [javadoc] Loading source files for package org.apache.lucene.util.packed... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_51 [javadoc] Building tree for all the packages and classes... [javadoc] Generating /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/org/apache/lucene/search/package-summary.html... [javadoc] Copying file /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/core/src/java/org/apache/lucene/search/doc-files/nrq-formula-2.png to directory /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/org/apache/lucene/search/doc-files... [javadoc] Copying file /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/core/src/java/org/apache/lucene/search/doc-files/nrq-formula-1.png to directory /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/org/apache/lucene/search/doc-files... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/help-doc.html... [javadoc] 1 warning [...truncated 27 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] warning: [options] bootstrap class path not set in conjunction with -source 1.6 [javadoc] Loading source files for package org.apache.lucene.analysis.ar... [javadoc] Loading source files for package org.apache.lucene.analysis.bg... [javadoc] Loading source files for package org.apache.lucene.analysis.br... [javadoc] Loading source files for package org.apache.lucene.analysis.ca... [javadoc] Loading source files for package org.apache.lucene.analysis.charfilter... [javadoc] Loading source files for package org.apache.lucene.analysis.cjk... [javadoc] Loading source files for package org.apache.lucene.analysis.ckb... [javadoc] Loading source files for package org.apache.lucene.analysis.cn... [javadoc] Loading source files for package org.apache.lucene.analysis.commongrams... [javadoc] Loading source files for package org.apache.lucene.analysis.compound... [javadoc] Loading source files for package org.apache.lucene.analysis.compound.hyphenation... [javadoc] Loading source files for package org.apache.lucene.analysis.core... [javadoc] Loading source files for package org.apache.lucene.analysis.cz... [javadoc] Loading source files for package org.apache.lucene.analysis.da... [javadoc] Loading source files for package org.apache.lucene.analysis.de... [javadoc] Loading source files for package org.apache.lucene.analysis.el... [javadoc] Loading source files for package org.apache.lucene.analysis.en... [javadoc] Loading source files for package org.apache.lucene.analysis.es... [javadoc] Loading sou
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 1344 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1344/ Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseG1GC All tests passed Build Log: [...truncated 16976 lines...] [junit4] JVM J0: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/contrib/solr-map-reduce/test/temp/junit4-J0-20140219_033632_874.syserr [junit4] >>> JVM J0: stderr (verbatim) [junit4] 2014-02-19 03:36:48.002 java[311:6d0b] Unable to load realm info from SCDynamicStore [junit4] <<< JVM J0: EOF [...truncated 26342 lines...] BUILD FAILED /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/build.xml:453: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/build.xml:57: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build.xml:208: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build.xml:543: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/common-build.xml:2321: Can't get https://issues.apache.org/jira/rest/api/2/project/LUCENE to /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/docs/changes/jiraVersionList.json Total time: 123 minutes 51 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseG1GC Archiving artifacts Recording test results 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
[JENKINS] Solr-Artifacts-trunk - Build # 2432 - Failure
Build: https://builds.apache.org/job/Solr-Artifacts-trunk/2432/ No tests ran. Build Log: [...truncated 17172 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/solr/build.xml:434: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/solr/build.xml:332: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/solr/test-framework/build.xml:94: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/lucene/common-build.xml:499: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/lucene/common-build.xml:496: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/lucene/build.xml:543: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/lucene/common-build.xml:2321: Can't get https://issues.apache.org/jira/rest/api/2/project/LUCENE to /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/lucene/build/docs/changes/jiraVersionList.json Total time: 7 minutes 5 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Publishing Javadoc 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] [Commented] (LUCENE-5411) Upgrade to released JFlex 1.5.0
[ https://issues.apache.org/jira/browse/LUCENE-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905037#comment-13905037 ] ASF subversion and git services commented on LUCENE-5411: - Commit 1569612 from [~steve_rowe] in branch 'dev/branches/lucene_solr_4_7' [ https://svn.apache.org/r1569612 ] LUCENE-5411: Upgrade to released JFlex 1.5.0; stop requiring a locally built JFlex snapshot jar. (merged trunk r1560260) > Upgrade to released JFlex 1.5.0 > --- > > Key: LUCENE-5411 > URL: https://issues.apache.org/jira/browse/LUCENE-5411 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Steve Rowe >Assignee: Steve Rowe >Priority: Minor > Fix For: 4.7, 5.0 > > Attachments: LUCENE-5411.patch > > > The JFlex 1.5.0 release will be officially announced shortly. The jar is > already on Maven Central. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5449) Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil
[ https://issues.apache.org/jira/browse/LUCENE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905036#comment-13905036 ] ASF GitHub Bot commented on LUCENE-5449: Github user asfgit closed the pull request at: https://github.com/apache/lucene-solr/pull/36 > Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil > -- > > Key: LUCENE-5449 > URL: https://issues.apache.org/jira/browse/LUCENE-5449 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 4.6.1 >Reporter: Benson Margulies >Priority: Minor > > _TestUtil and _TestHelper begin with _ for historical reasons that don't > apply any longer. Lets eliminate those _'s. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: LUCENE-5449: Rename _TestUtil to TestUti...
Github user asfgit closed the pull request at: https://github.com/apache/lucene-solr/pull/36 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. To do so, please top-post your response. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5411) Upgrade to released JFlex 1.5.0
[ https://issues.apache.org/jira/browse/LUCENE-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905017#comment-13905017 ] ASF subversion and git services commented on LUCENE-5411: - Commit 1569610 from [~steve_rowe] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1569610 ] LUCENE-5411: Upgrade to released JFlex 1.5.0; stop requiring a locally built JFlex snapshot jar. (merged trunk r1560260) > Upgrade to released JFlex 1.5.0 > --- > > Key: LUCENE-5411 > URL: https://issues.apache.org/jira/browse/LUCENE-5411 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Steve Rowe >Assignee: Steve Rowe >Priority: Minor > Fix For: 4.7, 5.0 > > Attachments: LUCENE-5411.patch > > > The JFlex 1.5.0 release will be officially announced shortly. The jar is > already on Maven Central. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Anshum Gupta as Lucene/Solr Committer!
Welcome Anshum! -Areek On Tue, Feb 18, 2014 at 9:22 AM, Yonik Seeley wrote: > Welcome Anshum! > > > -Yonik > http://heliosearch.org - native off-heap filters and fieldcache for solr > > > On Sun, Feb 16, 2014 at 10:14 PM, Anshum Gupta > wrote: > > Thanks Mark. > > > > I spent most of my life in New Delhi, India other than short stints in > > different parts of the country (including living in a beach house on a > > tropical island for 3 years when I was young). After spending the last 3 > > years in Bangalore, I just relocated to San Francisco to be at the > > LucidWorks office in the Bay Area. Prior to this I've been a part of the > > search teams at A9 (CloudSearch), Cleartrip.com and Naukri.com where I > was > > involved in designing and developing search and recommendation engines. > > > > These days, I love contributing stuff to Solr, primarily around SolrCloud > > and hope to continue to be at least as active towards it. > > > > In my free time I love photography, traveling, eating out and drinking my > > beer. > > > > > > On Sun, Feb 16, 2014 at 2:33 PM, Mark Miller > wrote: > >> > >> Hey everybody! > >> > >> The Lucene PMC is happy to welcome Anshum Gupta as a committer on the > >> Lucene / Solr project. Anshum has contributed to a number of issues > for the > >> project, especially around SolrCloud. > >> > >> Welcome Anshum! > >> > >> It's tradition to introduce yourself with a short bio :) > >> > >> -- > >> - Mark > >> > >> http://about.me/markrmiller > > > > > > > > > > -- > > > > Anshum Gupta > > http://www.anshumgupta.net > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Updated] (SOLR-5620) Race condition while setting ZkStateReader.aliases
[ https://issues.apache.org/jira/browse/SOLR-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-5620: -- Fix Version/s: 5.0 4.7 > Race condition while setting ZkStateReader.aliases > -- > > Key: SOLR-5620 > URL: https://issues.apache.org/jira/browse/SOLR-5620 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.6 >Reporter: Ramkumar Aiyengar >Assignee: Mark Miller >Priority: Minor > Fix For: 4.7, 5.0 > > > Noticed while working on SOLR-5615, > https://github.com/apache/lucene-solr/pull/15 for a patch. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5620) Race condition while setting ZkStateReader.aliases
[ https://issues.apache.org/jira/browse/SOLR-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905003#comment-13905003 ] ASF subversion and git services commented on SOLR-5620: --- Commit 1569606 from [~markrmil...@gmail.com] in branch 'dev/branches/lucene_solr_4_7' [ https://svn.apache.org/r1569606 ] SOLR-5620: ZKStateReader.aliases should be volatile to ensure all threads see the latest aliases. > Race condition while setting ZkStateReader.aliases > -- > > Key: SOLR-5620 > URL: https://issues.apache.org/jira/browse/SOLR-5620 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.6 >Reporter: Ramkumar Aiyengar >Assignee: Mark Miller >Priority: Minor > Fix For: 4.7, 5.0 > > > Noticed while working on SOLR-5615, > https://github.com/apache/lucene-solr/pull/15 for a patch. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Created] (SOLR-5620) Race condition while setting ZkStateReader.aliases
No problem :) - Mark http://about.me/markrmiller On Feb 18, 2014, at 6:59 PM, Ramkumar R. Aiyengar wrote: > Would someone have a few minutes to validate this race condition fix? Thanks! > > -- Forwarded message -- > From: "Ramkumar Aiyengar (JIRA)" > Date: 8 Jan 2014 16:49 > Subject: [jira] [Created] (SOLR-5620) Race condition while setting > ZkStateReader.aliases > To: > Cc: > > Ramkumar Aiyengar created SOLR-5620: > --- > > Summary: Race condition while setting ZkStateReader.aliases > Key: SOLR-5620 > URL: https://issues.apache.org/jira/browse/SOLR-5620 > Project: Solr > Issue Type: Bug > Components: SolrCloud > Affects Versions: 4.6 > Reporter: Ramkumar Aiyengar > Priority: Minor > > > Noticed while working on SOLR-5615, > https://github.com/apache/lucene-solr/pull/15 for a patch. > > > > -- > This message was sent by Atlassian JIRA > (v6.1.5#6160) > > - > 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] [Commented] (SOLR-5620) Race condition while setting ZkStateReader.aliases
[ https://issues.apache.org/jira/browse/SOLR-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904996#comment-13904996 ] ASF subversion and git services commented on SOLR-5620: --- Commit 1569604 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1569604 ] SOLR-5620: ZKStateReader.aliases should be volatile to ensure all threads see the latest aliases. > Race condition while setting ZkStateReader.aliases > -- > > Key: SOLR-5620 > URL: https://issues.apache.org/jira/browse/SOLR-5620 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.6 >Reporter: Ramkumar Aiyengar >Assignee: Mark Miller >Priority: Minor > > Noticed while working on SOLR-5615, > https://github.com/apache/lucene-solr/pull/15 for a patch. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5620) Race condition while setting ZkStateReader.aliases
[ https://issues.apache.org/jira/browse/SOLR-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904992#comment-13904992 ] ASF subversion and git services commented on SOLR-5620: --- Commit 1569603 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1569603 ] SOLR-5620: ZKStateReader.aliases should be volatile to ensure all threads see the latest aliases. > Race condition while setting ZkStateReader.aliases > -- > > Key: SOLR-5620 > URL: https://issues.apache.org/jira/browse/SOLR-5620 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.6 >Reporter: Ramkumar Aiyengar >Assignee: Mark Miller >Priority: Minor > > Noticed while working on SOLR-5615, > https://github.com/apache/lucene-solr/pull/15 for a patch. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Refactoring code through Github pull requests
See https://wiki.apache.org/lucene-java/BensonMargulies/GitSvnWorkflow for an experiment with git svn. On Tue, Feb 18, 2014 at 1:47 PM, Benson Margulies wrote: > Once I have transported a change from branch to branch via diff\apply, git > stops discussing a rename at all. > > On February 18, 2014 9:06:30 AM EST, Thomas Matthijs > wrote: >> >> Unfortunately i can't find a way to make it explicitly show it will do a >> svn rename, but it does do it, so that makes this solution not very useful >> either i guess. >> >> >> --- git --- >> [master svntest] % git status >> On branch master >> Changes to be committed: >> (use "git reset HEAD ..." to unstage) >> >> renamed:test -> moo >> >> [master svntest] % git commit -m "woof" >> [master 6e2c0b3] woof >> 1 file changed, 0 insertions(+), 0 deletions(-) >> rename test => moo (100%) >> [master svntest] % git svn dcommit >> Committing to https://.../trunk ... >> R test => moo >> Committed r3 >> D test >> A moo >> W: -empty_dir: trunk/test >> r3 = 0ae41e170cf7d07ec3679eb85d55c068617e0a66 (refs/remotes/trunk) >> >> >> - svn --- >> >> [trunk] % svn log --diff -v >> >> r3 | thomas | 2014-02-18 14:32:07 +0100 (Tue, 18 Feb 2014) | 1 line >> Changed paths: >>A /trunk/moo (from /trunk/test:2) >>D /trunk/test >> >> woof >> >> >> On Tue, Feb 18, 2014 at 2:22 PM, Benson Margulies >> wrote: >>> >>> Let me be specific. If I am sitting in a git clone that has been set >>> up with git svn, and I use git apply to apply the output of git >>> format-patch, if I dcommit, is the autodetection going to result in an >>> svn mv? >>> >>> >>> On Tue, Feb 18, 2014 at 8:20 AM, Thomas Matthijs >>> wrote: >>> > Git does not track renames, but can show/detect it, the magic options >>> > are -C >>> > and -M for diff/show etc >>> > >>> > >>> > >>> > On Tue, Feb 18, 2014 at 2:16 PM, Benson Margulies >>> > >>> > wrote: >>> >> >>> >> I tried using git apply on a patch (from github's .patch URL) that >>> >> included a rename. no sign of a rename; just a delete and an add. I >>> >> feel like I'm missing something. >>> >> >>> >> On Tue, Feb 18, 2014 at 7:36 AM, Shai Erera wrote: >>> >> > The problem I see is that if you generate a patch using 'git diff', >>> >> > it >>> >> > applies just fine to svn (if you generate it w/ --no-prefix) without >>> >> > any >>> >> > warnings about missing files due the rename. Wanted to warn the >>> >> > community >>> >> > about it, so that when committers assign themselves to PRs, they >>> >> > review >>> >> > the >>> >> > patch closer and detect manually if a rename as happened. >>> >> > >>> >> > We could decide that renames are done in a separate commit, but it's >>> >> > not >>> >> > always possible. >>> >> > >>> >> > So mainly, FYI. >>> >> > >>> >> > And if someone has an idea for a script/ant-target we could write to >>> >> > detect >>> >> > this case, that would be awesome. >>> >> > >>> >> > Shai >>> >> > >>> >> > >>> >> > On Tue, Feb 18, 2014 at 2:31 PM, Thomas Matthijs >>> >> > wrote: >>> >> >> >>> >> >> Github pull requests can be treated as individual cherry picked >>> >> >> patch >>> >> >> sets >>> >> >> really, not branch merges ? (ie rebased) from there on out you're >>> >> >> in >>> >> >> svn >>> >> >> land. No need to "merge". >>> >> >> >>> >> >> But indeed, it tries to detect it based on the file content, and >>> >> >> doesn't >>> >> >> work 100% as manual svn moves. >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Tue, Feb 18, 2014 at 1:27 PM, Benson Margulies >>> >> >> >>> >> >> wrote: >>> >> >>> >>> >> >>> Well, git-svn has a heap of warnings against using it for merges; >>> >> >>> it's >>> >> >>> also a really bad idea when renaming a whole package, as it does >>> >> >>> it >>> >> >>> one-file-at-a-time. >>> >> >>> >>> >> >>> If you have a workflow that works with the ASF mirror and svn, >>> >> >>> please >>> >> >>> write it up on the Wiki! >>> >> >>> >>> >> >>> >>> >> >>> On Tue, Feb 18, 2014 at 7:23 AM, Thomas Matthijs >>> >> >>> >>> >> >>> wrote: >>> >> >>> > >>> >> >>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera >>> >> >>> > wrote: >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> Second, has anyone perhaps found a way to overcome that issue? >>> >> >>> >> I >>> >> >>> >> thought >>> >> >>> >> about maybe writing a script to detect that, looking at the >>> >> >>> >> patch >>> >> >>> >> file, but >>> >> >>> >> it seems hard to detect that the deleted Foo is the new Bar. If >>> >> >>> >> it's >>> >> >>> >> just >>> >> >>> >> rename, maybe, but if part of the rename the code changed a lot >>> >> >>> >> ... >>> >> >>> >> it >>> >> >>> >> becomes harder. >>> >> >>> > >>> >> >>> > >>> >> >>> > Probably not the answer you want but >>> >> >>> > If you use the git-svn bridge it should detect the rename and >>> >> >>> > commit >>> >> >>> > it >>> >> >>> > in >>> >> >>> > svn as a move/copy >>> >> >>> > >>> >> >>> > https://www.kernel.org/pub/software/scm/git/docs/gi
[jira] [Commented] (LUCENE-5447) StandardTokenizer should break at consecutive chars matching Word_Break = MidLetter, MidNum and/or MidNumLet
[
https://issues.apache.org/jira/browse/LUCENE-5447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904984#comment-13904984
]
ASF subversion and git services commented on LUCENE-5447:
-
Commit 1569601 from [~steve_rowe] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1569601 ]
LUCENE-5447: StandardTokenizer should break at consecutive chars matching
Word_Break = MidLetter, MidNum and/or MidNumLet (merged trunk r1569586)
> StandardTokenizer should break at consecutive chars matching Word_Break =
> MidLetter, MidNum and/or MidNumLet
>
>
> Key: LUCENE-5447
> URL: https://issues.apache.org/jira/browse/LUCENE-5447
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Affects Versions: 4.6.1
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 4.7, 5.0
>
> Attachments: LUCENE-5447-test.patch, LUCENE-5447.patch,
> LUCENE-5447.patch
>
>
> StandardTokenizer should split all of the following sequences into two tokens
> each, but they are all instead kept intact and output as single tokens:
> {noformat}
> "A::B" (':' is in \p{Word_Break = MidLetter})
> "1..2", "A..B" ('.' is in \p{Word_Break = MidNumLet})
> "A.:B"
> "A:.B"
> "1,,2" (',' is in \p{Word_Break = MidNum})
> "1,.2"
> "1.,2"
> {noformat}
> Unfortunately, the word break test data released with Unicode, e.g. for
> Unicode 6.3
> [http://www.unicode.org/Public/6.3.0/ucd/auxiliary/WordBreakTest.txt], and
> incorporated into a versioned Lucene test, e.g.
> {{WordBreakTestUnicode_6_3_0}}, doesn't cover these cases.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5615) Deadlock while trying to recover after a ZK session expiry
[ https://issues.apache.org/jira/browse/SOLR-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-5615. --- Resolution: Fixed > Deadlock while trying to recover after a ZK session expiry > -- > > Key: SOLR-5615 > URL: https://issues.apache.org/jira/browse/SOLR-5615 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.4, 4.5, 4.6 >Reporter: Ramkumar Aiyengar >Assignee: Mark Miller > Fix For: 5.0, 4.6.1 > > Attachments: SOLR-5615.patch, SOLR-5615.patch, SOLR-5615.patch > > > The sequence of events which might trigger this is as follows: > - Leader of a shard, say OL, has a ZK expiry > - The new leader, NL, starts the election process > - NL, through Overseer, clears the current leader (OL) for the shard from > the cluster state > - OL reconnects to ZK, calls onReconnect from event thread (main-EventThread) > - OL marks itself down > - OL sets up watches for cluster state, and then retrieves it (with no > leader for this shard) > - NL, through Overseer, updates cluster state to mark itself leader for the > shard > - OL tries to register itself as a replica, and waits till the cluster state > is updated >with the new leader from event thread > - ZK sends a watch update to OL, but it is blocked on the event thread > waiting for it. > Oops. This finally breaks out after trying to register itself as replica > times out after 20 mins. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5620) Race condition while setting ZkStateReader.aliases
[ https://issues.apache.org/jira/browse/SOLR-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904979#comment-13904979 ] Mark Miller commented on SOLR-5620: --- I think it's actually just left over from back when nodes updated cluster state via retries directly to zk rather than going through the overseer. I think that protected all reads and sets of the state? I'm not sure, I'd have to spend some more time on it. Someone else was involved in a lot of that refactoring, so I don't have a complete memory of it. Not positive if it was even need for the reads then, but who knows what all the code look like at the time. I can't see how we need it for reading the aliases though - but we do want that volatile of course. > Race condition while setting ZkStateReader.aliases > -- > > Key: SOLR-5620 > URL: https://issues.apache.org/jira/browse/SOLR-5620 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.6 >Reporter: Ramkumar Aiyengar >Assignee: Mark Miller >Priority: Minor > > Noticed while working on SOLR-5615, > https://github.com/apache/lucene-solr/pull/15 for a patch. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5449) Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil
[ https://issues.apache.org/jira/browse/LUCENE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904976#comment-13904976 ] ASF subversion and git services commented on LUCENE-5449: - Commit 1569599 from [~bmargulies] in branch 'dev/trunk' [ https://svn.apache.org/r1569599 ] LUCENE-5449: add CHANGES.txt. This closes #36. > Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil > -- > > Key: LUCENE-5449 > URL: https://issues.apache.org/jira/browse/LUCENE-5449 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 4.6.1 >Reporter: Benson Margulies >Priority: Minor > > _TestUtil and _TestHelper begin with _ for historical reasons that don't > apply any longer. Lets eliminate those _'s. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5449) Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil
[ https://issues.apache.org/jira/browse/LUCENE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904973#comment-13904973 ] ASF subversion and git services commented on LUCENE-5449: - Commit 1569598 from [~bmargulies] in branch 'dev/trunk' [ https://svn.apache.org/r1569598 ] LUCENE-5449: _TestHelper -> TestHelper. > Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil > -- > > Key: LUCENE-5449 > URL: https://issues.apache.org/jira/browse/LUCENE-5449 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 4.6.1 >Reporter: Benson Margulies >Priority: Minor > > _TestUtil and _TestHelper begin with _ for historical reasons that don't > apply any longer. Lets eliminate those _'s. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5449) Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil
[ https://issues.apache.org/jira/browse/LUCENE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904971#comment-13904971 ] ASF subversion and git services commented on LUCENE-5449: - Commit 1569597 from [~bmargulies] in branch 'dev/trunk' [ https://svn.apache.org/r1569597 ] LUCENE-5449: Rename _TestUtil to TestUtil. > Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil > -- > > Key: LUCENE-5449 > URL: https://issues.apache.org/jira/browse/LUCENE-5449 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 4.6.1 >Reporter: Benson Margulies >Priority: Minor > > _TestUtil and _TestHelper begin with _ for historical reasons that don't > apply any longer. Lets eliminate those _'s. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-5620) Race condition while setting ZkStateReader.aliases
[ https://issues.apache.org/jira/browse/SOLR-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-5620: - Assignee: Mark Miller > Race condition while setting ZkStateReader.aliases > -- > > Key: SOLR-5620 > URL: https://issues.apache.org/jira/browse/SOLR-5620 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.6 >Reporter: Ramkumar Aiyengar >Assignee: Mark Miller >Priority: Minor > > Noticed while working on SOLR-5615, > https://github.com/apache/lucene-solr/pull/15 for a patch. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5447) StandardTokenizer should break at consecutive chars matching Word_Break = MidLetter, MidNum and/or MidNumLet
[
https://issues.apache.org/jira/browse/LUCENE-5447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904947#comment-13904947
]
ASF subversion and git services commented on LUCENE-5447:
-
Commit 1569586 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1569586 ]
LUCENE-5447: StandardTokenizer should break at consecutive chars matching
Word_Break = MidLetter, MidNum and/or MidNumLet
> StandardTokenizer should break at consecutive chars matching Word_Break =
> MidLetter, MidNum and/or MidNumLet
>
>
> Key: LUCENE-5447
> URL: https://issues.apache.org/jira/browse/LUCENE-5447
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Affects Versions: 4.6.1
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 4.7, 5.0
>
> Attachments: LUCENE-5447-test.patch, LUCENE-5447.patch,
> LUCENE-5447.patch
>
>
> StandardTokenizer should split all of the following sequences into two tokens
> each, but they are all instead kept intact and output as single tokens:
> {noformat}
> "A::B" (':' is in \p{Word_Break = MidLetter})
> "1..2", "A..B" ('.' is in \p{Word_Break = MidNumLet})
> "A.:B"
> "A:.B"
> "1,,2" (',' is in \p{Word_Break = MidNum})
> "1,.2"
> "1.,2"
> {noformat}
> Unfortunately, the word break test data released with Unicode, e.g. for
> Unicode 6.3
> [http://www.unicode.org/Public/6.3.0/ucd/auxiliary/WordBreakTest.txt], and
> incorporated into a versioned Lucene test, e.g.
> {{WordBreakTestUnicode_6_3_0}}, doesn't cover these cases.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5447) StandardTokenizer should break at consecutive chars matching Word_Break = MidLetter, MidNum and/or MidNumLet
[
https://issues.apache.org/jira/browse/LUCENE-5447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated LUCENE-5447:
---
Attachment: LUCENE-5447.patch
Final patch, adding a test for UAX29URLEmailTokenizer and a CHANGES.txt entry.
> StandardTokenizer should break at consecutive chars matching Word_Break =
> MidLetter, MidNum and/or MidNumLet
>
>
> Key: LUCENE-5447
> URL: https://issues.apache.org/jira/browse/LUCENE-5447
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Affects Versions: 4.6.1
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 4.7, 5.0
>
> Attachments: LUCENE-5447-test.patch, LUCENE-5447.patch,
> LUCENE-5447.patch
>
>
> StandardTokenizer should split all of the following sequences into two tokens
> each, but they are all instead kept intact and output as single tokens:
> {noformat}
> "A::B" (':' is in \p{Word_Break = MidLetter})
> "1..2", "A..B" ('.' is in \p{Word_Break = MidNumLet})
> "A.:B"
> "A:.B"
> "1,,2" (',' is in \p{Word_Break = MidNum})
> "1,.2"
> "1.,2"
> {noformat}
> Unfortunately, the word break test data released with Unicode, e.g. for
> Unicode 6.3
> [http://www.unicode.org/Public/6.3.0/ucd/auxiliary/WordBreakTest.txt], and
> incorporated into a versioned Lucene test, e.g.
> {{WordBreakTestUnicode_6_3_0}}, doesn't cover these cases.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5447) StandardTokenizer should break at consecutive chars matching Word_Break = MidLetter, MidNum and/or MidNumLet
[
https://issues.apache.org/jira/browse/LUCENE-5447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated LUCENE-5447:
---
Fix Version/s: 5.0
4.7
> StandardTokenizer should break at consecutive chars matching Word_Break =
> MidLetter, MidNum and/or MidNumLet
>
>
> Key: LUCENE-5447
> URL: https://issues.apache.org/jira/browse/LUCENE-5447
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Affects Versions: 4.6.1
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 4.7, 5.0
>
> Attachments: LUCENE-5447-test.patch, LUCENE-5447.patch
>
>
> StandardTokenizer should split all of the following sequences into two tokens
> each, but they are all instead kept intact and output as single tokens:
> {noformat}
> "A::B" (':' is in \p{Word_Break = MidLetter})
> "1..2", "A..B" ('.' is in \p{Word_Break = MidNumLet})
> "A.:B"
> "A:.B"
> "1,,2" (',' is in \p{Word_Break = MidNum})
> "1,.2"
> "1.,2"
> {noformat}
> Unfortunately, the word break test data released with Unicode, e.g. for
> Unicode 6.3
> [http://www.unicode.org/Public/6.3.0/ucd/auxiliary/WordBreakTest.txt], and
> incorporated into a versioned Lucene test, e.g.
> {{WordBreakTestUnicode_6_3_0}}, doesn't cover these cases.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5447) StandardTokenizer should break at consecutive chars matching Word_Break = MidLetter, MidNum and/or MidNumLet
[
https://issues.apache.org/jira/browse/LUCENE-5447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated LUCENE-5447:
---
Attachment: LUCENE-5447.patch
Patch fixing the issue; includes LUCENE-5447-test.patch.
Committing shortly.
> StandardTokenizer should break at consecutive chars matching Word_Break =
> MidLetter, MidNum and/or MidNumLet
>
>
> Key: LUCENE-5447
> URL: https://issues.apache.org/jira/browse/LUCENE-5447
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Affects Versions: 4.6.1
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: LUCENE-5447-test.patch, LUCENE-5447.patch
>
>
> StandardTokenizer should split all of the following sequences into two tokens
> each, but they are all instead kept intact and output as single tokens:
> {noformat}
> "A::B" (':' is in \p{Word_Break = MidLetter})
> "1..2", "A..B" ('.' is in \p{Word_Break = MidNumLet})
> "A.:B"
> "A:.B"
> "1,,2" (',' is in \p{Word_Break = MidNum})
> "1,.2"
> "1.,2"
> {noformat}
> Unfortunately, the word break test data released with Unicode, e.g. for
> Unicode 6.3
> [http://www.unicode.org/Public/6.3.0/ucd/auxiliary/WordBreakTest.txt], and
> incorporated into a versioned Lucene test, e.g.
> {{WordBreakTestUnicode_6_3_0}}, doesn't cover these cases.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5746) solr.xml parsing of "str" vs "int" vs "bool" is brittle; fails silently; expects odd type for "shareSchema"
[
https://issues.apache.org/jira/browse/SOLR-5746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904881#comment-13904881
]
Hoss Man commented on SOLR-5746:
I think what we should do is...
* change the parsing logic to be more like solrconfig.xml and build a NamedList
for each section of solr.xml
** convert each NamedList to SolrParams when possible for easy value type
checkig & conversion (i think this would work for each section in solr.xml
today - but some future sections might need to be more complicated)
* remove each known config option from the params
* error if any unexpected values are found in the config, so typos in config
option names aren't silently ignored.
> solr.xml parsing of "str" vs "int" vs "bool" is brittle; fails silently;
> expects odd type for "shareSchema"
> --
>
> Key: SOLR-5746
> URL: https://issues.apache.org/jira/browse/SOLR-5746
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.3, 4.4, 4.5, 4.6
>Reporter: Hoss Man
>
> A comment in the ref guide got me looking at ConfigSolrXml.java and noticing
> that the parsing of solr.xml options here is very brittle and confusing. In
> particular:
> * if a boolean option "foo" is expected along the lines of {{ name="foo">true}} it will silently ignore {{ name="foo">true}}
> * likewise for an int option {{32}} vs {{ name="bar">32}}
> ... this is inconsistent with the way solrconfig.xml is parsed. In
> solrconfig.xml, the xml nodes are parsed into a NamedList, and the above
> options will work in either form, but an invalid value such as {{ name="foo">NOT A BOOLEAN}} will generate an error earlier (when
> parsing config) then {{NOT A BOOLEAN}} (attempt to
> parse the string as a bool the first time the config value is needed)
> In addition, i notice this really confusing line...
> {code}
> propMap.put(CfgProp.SOLR_SHARESCHEMA,
> doSub("solr/str[@name='shareSchema']"));
> {code}
> "shareSchema" is used internally as a boolean option, but as written the
> parsing code will ignore it unless the user explicitly configures it as a
> {{}}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5746) solr.xml parsing of "str" vs "int" vs "bool" is brittle; fails silently; expects odd type for "shareSchema"
Hoss Man created SOLR-5746:
--
Summary: solr.xml parsing of "str" vs "int" vs "bool" is brittle;
fails silently; expects odd type for "shareSchema"
Key: SOLR-5746
URL: https://issues.apache.org/jira/browse/SOLR-5746
Project: Solr
Issue Type: Bug
Affects Versions: 4.6, 4.5, 4.4, 4.3
Reporter: Hoss Man
A comment in the ref guide got me looking at ConfigSolrXml.java and noticing
that the parsing of solr.xml options here is very brittle and confusing. In
particular:
* if a boolean option "foo" is expected along the lines of {{true}} it will silently ignore {{true}}
* likewise for an int option {{32}} vs {{32}}
... this is inconsistent with the way solrconfig.xml is parsed. In
solrconfig.xml, the xml nodes are parsed into a NamedList, and the above
options will work in either form, but an invalid value such as {{NOT A BOOLEAN}} will generate an error earlier (when parsing
config) then {{NOT A BOOLEAN}} (attempt to parse the
string as a bool the first time the config value is needed)
In addition, i notice this really confusing line...
{code}
propMap.put(CfgProp.SOLR_SHARESCHEMA,
doSub("solr/str[@name='shareSchema']"));
{code}
"shareSchema" is used internally as a boolean option, but as written the
parsing code will ignore it unless the user explicitly configures it as a
{{}}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Fwd: [jira] [Created] (SOLR-5620) Race condition while setting ZkStateReader.aliases
Would someone have a few minutes to validate this race condition fix? Thanks! -- Forwarded message -- From: "Ramkumar Aiyengar (JIRA)" Date: 8 Jan 2014 16:49 Subject: [jira] [Created] (SOLR-5620) Race condition while setting ZkStateReader.aliases To: Cc: Ramkumar Aiyengar created SOLR-5620: > --- > > Summary: Race condition while setting ZkStateReader.aliases > Key: SOLR-5620 > URL: https://issues.apache.org/jira/browse/SOLR-5620 > Project: Solr > Issue Type: Bug > Components: SolrCloud > Affects Versions: 4.6 > Reporter: Ramkumar Aiyengar > Priority: Minor > > > Noticed while working on SOLR-5615, > https://github.com/apache/lucene-solr/pull/15 for a patch. > > > > -- > This message was sent by Atlassian JIRA > (v6.1.5#6160) > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Updated] (SOLR-4470) Support for basic http auth in internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-4470: -- Fix Version/s: (was: 4.7) 5.0 > Support for basic http auth in internal solr requests > - > > Key: SOLR-4470 > URL: https://issues.apache.org/jira/browse/SOLR-4470 > Project: Solr > Issue Type: New Feature > Components: clients - java, multicore, replication (java), SolrCloud >Affects Versions: 4.0 >Reporter: Per Steffensen >Assignee: Jan Høydahl > Labels: authentication, https, solrclient, solrcloud, ssl > Fix For: 5.0 > > Attachments: SOLR-4470.patch, SOLR-4470.patch, > SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch, > SOLR-4470_branch_4x_r145.patch, SOLR-4470_trunk_r1568857.patch > > > We want to protect any HTTP-resource (url). We want to require credentials no > matter what kind of HTTP-request you make to a Solr-node. > It can faily easy be acheived as described on > http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes > also make "internal" request to other Solr-nodes, and for it to work > credentials need to be provided here also. > Ideally we would like to "forward" credentials from a particular request to > all the "internal" sub-requests it triggers. E.g. for search and update > request. > But there are also "internal" requests > * that only indirectly/asynchronously triggered from "outside" requests (e.g. > shard creation/deletion/etc based on calls to the "Collection API") > * that do not in any way have relation to an "outside" "super"-request (e.g. > replica synching stuff) > We would like to aim at a solution where "original" credentials are > "forwarded" when a request directly/synchronously trigger a subrequest, and > fallback to a configured "internal credentials" for the > asynchronous/non-rooted requests. > In our solution we would aim at only supporting basic http auth, but we would > like to make a "framework" around it, so that not to much refactoring is > needed if you later want to make support for other kinds of auth (e.g. digest) > We will work at a solution but create this JIRA issue early in order to get > input/comments from the community as early as possible. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5453) some trivial refactoring to postingshighlighter
[ https://issues.apache.org/jira/browse/LUCENE-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5453: Attachment: LUCENE-5453.patch simple patch > some trivial refactoring to postingshighlighter > --- > > Key: LUCENE-5453 > URL: https://issues.apache.org/jira/browse/LUCENE-5453 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/highlighter >Reporter: Robert Muir > Attachments: LUCENE-5453.patch > > > As mentioned on LUCENE-5452, its hard to see whats going on in > highlightFields (e.g. the termsenum reuse). I think thats just because the > code needs to be re-arranged a little bit and a few comments added. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5453) some trivial refactoring to postingshighlighter
Robert Muir created LUCENE-5453: --- Summary: some trivial refactoring to postingshighlighter Key: LUCENE-5453 URL: https://issues.apache.org/jira/browse/LUCENE-5453 Project: Lucene - Core Issue Type: Improvement Components: modules/highlighter Reporter: Robert Muir Attachments: LUCENE-5453.patch As mentioned on LUCENE-5452, its hard to see whats going on in highlightFields (e.g. the termsenum reuse). I think thats just because the code needs to be re-arranged a little bit and a few comments added. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5452) Combine matches from multiple fields into one with the postings highlighter
[ https://issues.apache.org/jira/browse/LUCENE-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904675#comment-13904675 ] Robert Muir commented on LUCENE-5452: - Cool, maybe we can actually optimize the existing PQ stuff anyway (its not super-huper-duper optimized). But in general its bounded towards the number of matching sentences per doc, which is presumably quite small (there is some paper suggesting more than 5 is not that useful, so I assumed that). I'll take a look. The other thing that concerned me (and it may be just fine in your patch), is i couldn't tell if there was a little O(n^2) as far as fields go (fieldsIn * fieldsToMatchedFields), and the termsenum/docsenum/etc reuse across same segment became even more hairier than it is now (and its definitely ugly now). The final advantage of the "level above" would be, the multi-term highlighting etc would work for free. I'm gonna open a separate issue to try to improve some of this existing code, it was confusing to me just looking at it. > Combine matches from multiple fields into one with the postings highlighter > --- > > Key: LUCENE-5452 > URL: https://issues.apache.org/jira/browse/LUCENE-5452 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Nik Everett >Priority: Minor > Attachments: LUCENE-5452.patch > > > Like you can do with the FVH, it'd be nice to be able combine matches from > multiple fields with the postings highlighter. > Note that the postings highlighter doesn't do phrase matching and doesn't use > term boosts so some of the FVH's field combining features won't work. It'd > be nice to get some of them, though. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5451) Update Spatial4j to 0.4.1
[
https://issues.apache.org/jira/browse/LUCENE-5451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904638#comment-13904638
]
David Smiley commented on LUCENE-5451:
--
I'd just like to take a moment to clarify some things for [~simonw] -- we were
chatting in IRC but needed to sign off for the night. Others may be curious.
Firstly, Spatial4j has its own tests using the same extensive randomization
methodology & actual libraries (JUnit & RandomizedTesting) that Lucene uses,
and it's run by CI -- TravisCI. I fixed the aforementioned bug and it has a
test now to catch potential regressions. Even if Lucene could test this
particular bug (it can't due to needing JTS; see next paragraph), I don't think
that it's needed since it's already tested somewhere (Spatial4j's tests
itself). That said, I'd love to incorporate some JTS using tests in Lucene
that exercise various things at once (sort of an integration test) including
definitely what this bug is related to.
Until JTS is relicensed to Eclipse Public License (which is pending to occur
sometime this year) Lucene can't use it, and AFAIK we're not even permitted to
put it on the test classpath (right?). It wouldn't be a test
compile-dependency; it needs to be available at runtime so Spatial4j can use
it. Perhaps Lucene's Jenkins can put it on the classpath when it runs tests?
[~thetaphi] what do you think? There does exist one test which uses
{{assumeTrue(...check for JTS...);}} --
[JtsPolygonTest|https://github.com/apache/lucene-solr/blob/trunk/lucene/spatial/src/test/org/apache/lucene/spatial/prefix/JtsPolygonTest.java?source=cc#L52]
and in practice they never get run.
> Update Spatial4j to 0.4.1
> -
>
> Key: LUCENE-5451
> URL: https://issues.apache.org/jira/browse/LUCENE-5451
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial
>Affects Versions: 4.7, 5.0
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Blocker
> Fix For: 4.7, 5.0
>
>
> A user reported a fairly serious issue affecting the latest version of
> Spatial4j 0.4
> https://github.com/spatial4j/spatial4j/issues/72 "JtsSpatialContextFactory
> and geo=false with worldBounds fails"
> I've already fixed this locally and I'll push out a bug-fix Spatial4j 0.4.1.
> Upgrading will be a complete drop-in replacement. Heck I could do that now
> but as I work with the user who found the bug I want to see if there's any
> other problem.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5452) Combine matches from multiple fields into one with the postings highlighter
[ https://issues.apache.org/jira/browse/LUCENE-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904610#comment-13904610 ] Nik Everett commented on LUCENE-5452: - I hadn't really thought of doing it a level above. I like the idea. The only thing that jumps out at me about doing it this way is that there is only a single priority queue rather than multiple that have to be maintained and merged. I'm not sure if that outweighs the extra api complexity this adds. I'm also pretty sure the higher level approach is more likely to keep the careful linear reads that the PostingsHighlighter does. > Combine matches from multiple fields into one with the postings highlighter > --- > > Key: LUCENE-5452 > URL: https://issues.apache.org/jira/browse/LUCENE-5452 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Nik Everett >Priority: Minor > Attachments: LUCENE-5452.patch > > > Like you can do with the FVH, it'd be nice to be able combine matches from > multiple fields with the postings highlighter. > Note that the postings highlighter doesn't do phrase matching and doesn't use > term boosts so some of the FVH's field combining features won't work. It'd > be nice to get some of them, though. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5205) [PATCH] SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904569#comment-13904569 ] David Smiley commented on LUCENE-5205: -- FWIW my concern with any new query parser, particularly big ones like this which will have a non-trivial maintenance burden, is... how many query parsers do we want to ship & support with Lucene? Instead can we make an existing one better with the new capabilities you’ve added? > [PATCH] SpanQueryParser with recursion, analysis and syntax very similar to > classic QueryParser > --- > > Key: LUCENE-5205 > URL: https://issues.apache.org/jira/browse/LUCENE-5205 > Project: Lucene - Core > Issue Type: Improvement > Components: core/queryparser >Reporter: Tim Allison > Labels: patch > Fix For: 4.7 > > Attachments: LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, > LUCENE_5205.patch, SpanQueryParser_v1.patch.gz, patch.txt > > > This parser extends QueryParserBase and includes functionality from: > * Classic QueryParser: most of its syntax > * SurroundQueryParser: recursive parsing for "near" and "not" clauses. > * ComplexPhraseQueryParser: can handle "near" queries that include multiterms > (wildcard, fuzzy, regex, prefix), > * AnalyzingQueryParser: has an option to analyze multiterms. > At a high level, there's a first pass BooleanQuery/field parser and then a > span query parser handles all terminal nodes and phrases. > Same as classic syntax: > * term: test > * fuzzy: roam~0.8, roam~2 > * wildcard: te?t, test*, t*st > * regex: /\[mb\]oat/ > * phrase: "jakarta apache" > * phrase with slop: "jakarta apache"~3 > * default "or" clause: jakarta apache > * grouping "or" clause: (jakarta apache) > * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta > * multiple fields: title:lucene author:hatcher > > Main additions in SpanQueryParser syntax vs. classic syntax: > * Can require "in order" for phrases with slop with the \~> operator: > "jakarta apache"\~>3 > * Can specify "not near": "fever bieber"!\~3,10 :: > find "fever" but not if "bieber" appears within 3 words before or 10 > words after it. > * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta > apache\]~3 lucene\]\~>4 :: > find "jakarta" within 3 words of "apache", and that hit has to be within > four words before "lucene" > * Can also use \[\] for single level phrasal queries instead of " as in: > \[jakarta apache\] > * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 > :: find "apache" and then either "lucene" or "solr" within three words. > * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2 > * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ > /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two > words of "ap*che" and that hit has to be within ten words of something like > "solr" or that "lucene" regex. > * Can require at least x number of hits at boolean level: "apache AND (lucene > solr tika)~2 > * Can use negative only query: -jakarta :: Find all docs that don't contain > "jakarta" > * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of > potential performance issues!). > Trivial additions: > * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, > prefix =2) > * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance > <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein) > This parser can be very useful for concordance tasks (see also LUCENE-5317 > and LUCENE-5318) and for analytical search. > Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery. > Most of the documentation is in the javadoc for SpanQueryParser. > Any and all feedback is welcome. Thank you. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5720) Add ExpandComponent, which expands results collapsed by the CollapsingQParserPlugin
[
https://issues.apache.org/jira/browse/SOLR-5720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-5720:
-
Attachment: SOLR-5720.patch
New patch using fieldType.indexedToReadable(bytesRef, charsRef) when outputing
the group names to handle non-string fields properly.
> Add ExpandComponent, which expands results collapsed by the
> CollapsingQParserPlugin
> ---
>
> Key: SOLR-5720
> URL: https://issues.apache.org/jira/browse/SOLR-5720
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 4.7, 5.0
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 4.7, 5.0
>
> Attachments: SOLR-5720.patch, SOLR-5720.patch, SOLR-5720.patch,
> SOLR-5720.patch, SOLR-5720.patch, SOLR-5720.patch, SOLR-5720.patch,
> SOLR-5720.patch
>
>
> This ticket introduces a new search component called the ExpandComponent. The
> expand component expands a single page of results collapsed by the
> CollapsingQParserPlugin.
> Sample syntax:
> {code}
> q=*:*&fq={!collapse
> field=fieldA}&expand=true&expand.sort=fieldB+asc&expand.rows=10
> {code}
> In the above query the results are collapsed on "fieldA" with the
> CollapsingQParserPlugin. The expand component expands the current page of
> collapsed results.
> The initial implementation of the ExpandComponent takes three parameters:
> *expand=true* (Turns on the ExpandComponent)
> *expand.sort=fieldB+asc,fieldC+desc* (Sorts the documents based on a sort
> spec. If none is specified the documents are sorted by relevance based on the
> main query.)
> *expand.rows=10* (Sets the numbers of rows that groups are expanded to).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5452) Combine matches from multiple fields into one with the postings highlighter
[ https://issues.apache.org/jira/browse/LUCENE-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904559#comment-13904559 ] Robert Muir commented on LUCENE-5452: - Hi Nik, is there an advantage with the current patch over doing this "a level above" (e.g. combining after-the-fact?) A custom passage formatter has access to the score, so an alternative would be do this with a formatter+highlightFieldsAsObject? > Combine matches from multiple fields into one with the postings highlighter > --- > > Key: LUCENE-5452 > URL: https://issues.apache.org/jira/browse/LUCENE-5452 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Nik Everett >Priority: Minor > Attachments: LUCENE-5452.patch > > > Like you can do with the FVH, it'd be nice to be able combine matches from > multiple fields with the postings highlighter. > Note that the postings highlighter doesn't do phrase matching and doesn't use > term boosts so some of the FVH's field combining features won't work. It'd > be nice to get some of them, though. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5452) Combine matches from multiple fields into one with the postings highlighter
[ https://issues.apache.org/jira/browse/LUCENE-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nik Everett updated LUCENE-5452: Attachment: LUCENE-5452.patch Basic implementation that doesn't properly handle multi-term queries. > Combine matches from multiple fields into one with the postings highlighter > --- > > Key: LUCENE-5452 > URL: https://issues.apache.org/jira/browse/LUCENE-5452 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Nik Everett >Priority: Minor > Attachments: LUCENE-5452.patch > > > Like you can do with the FVH, it'd be nice to be able combine matches from > multiple fields with the postings highlighter. > Note that the postings highlighter doesn't do phrase matching and doesn't use > term boosts so some of the FVH's field combining features won't work. It'd > be nice to get some of them, though. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5452) Combine matches from multiple fields into one with the postings highlighter
Nik Everett created LUCENE-5452: --- Summary: Combine matches from multiple fields into one with the postings highlighter Key: LUCENE-5452 URL: https://issues.apache.org/jira/browse/LUCENE-5452 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Nik Everett Priority: Minor Like you can do with the FVH, it'd be nice to be able combine matches from multiple fields with the postings highlighter. Note that the postings highlighter doesn't do phrase matching and doesn't use term boosts so some of the FVH's field combining features won't work. It'd be nice to get some of them, though. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Lucey updated SOLR-2894: -- Attachment: SOLR-2894.patch This is the updated version of our implementation of Pivot Facets, as mentioned by Trey. We have significantly improved performance for cases which involve a large number of shards through changing the underlying data structure and the way that data from the shards is merged together. > Implement distributed pivot faceting > > > Key: SOLR-2894 > URL: https://issues.apache.org/jira/browse/SOLR-2894 > Project: Solr > Issue Type: Improvement >Reporter: Erik Hatcher > Fix For: 4.7 > > Attachments: SOLR-2894-reworked.patch, SOLR-2894.patch, > SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, > SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, > SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, > SOLR-2894.patch, SOLR-2894.patch > > > Following up on SOLR-792, pivot faceting currently only supports > undistributed mode. Distributed pivot faceting needs to be implemented. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5450) NPE and Illegal Argument Exception in wrapped SpanMultiTerms with no matches
[
https://issues.apache.org/jira/browse/LUCENE-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-5450.
-
Resolution: Fixed
Fix Version/s: 5.0
4.8
Thanks Tim!
> NPE and Illegal Argument Exception in wrapped SpanMultiTerms with no matches
>
>
> Key: LUCENE-5450
> URL: https://issues.apache.org/jira/browse/LUCENE-5450
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: 5.0
>Reporter: Tim Allison
> Fix For: 4.8, 5.0
>
> Attachments: LUCENE-5450.patch, LUCENE-5450.patch
>
>
> There are problems with the handling of wrapped span multiterms that don't
> have any matches.
> 1) In the test framework, when AssertingIndexSearcher does a rewrite and then
> checks for equality, there's an NPE for SpanNear and SpanOr:
> {noformat}
> java.lang.NullPointerException
> at
> __randomizedtesting.SeedInfo.seed([8E96A398C89A703B:338EB53A2EDBE8CC]:0)
> at
> org.apache.lucene.search.spans.SpanOrQuery.addClause(SpanOrQuery.java:57)
> at
> org.apache.lucene.search.spans.SpanOrQuery.(SpanOrQuery.java:49)
> at org.apache.lucene.search.spans.SpanOrQuery.clone(SpanOrQuery.java:86)
> at org.apache.lucene.search.spans.SpanOrQuery.clone(SpanOrQuery.java:39)
> at
> org.apache.lucene.search.QueryUtils.checkHashEquals(QueryUtils.java:57)
> at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:52)
> at
> org.apache.lucene.search.AssertingIndexSearcher.rewrite(AssertingIndexSearcher.java:80)
> at
> org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
> at
> org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261)
> at
> org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper.testNoSuchMultiTermsInOr(TestSpanMultiTermQueryWrapper.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
> ...
> {noformat}
> 2) The same issue is causing a "Clauses must have same field" illegal
> argument exception in a SpanNotQuery.
> {noformat}
> java.lang.IllegalArgumentException: Clauses must have same field.
> at
> __randomizedtesting.SeedInfo.seed([779E5DD7E7523C72:4C2ECAAB938038F9]:0)
> at
> org.apache.lucene.search.spans.SpanNotQuery.(SpanNotQuery.java:66)
> at
> org.apache.lucene.search.spans.SpanNotQuery.clone(SpanNotQuery.java:99)
> at
> org.apache.lucene.search.spans.SpanNotQuery.clone(SpanNotQuery.java:36)
> at
> org.apache.lucene.search.QueryUtils.checkHashEquals(QueryUtils.java:57)
> at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:52)
> at
> org.apache.lucene.search.AssertingIndexSearcher.rewrite(AssertingIndexSearcher.java:80)
> at
> org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
> at
> org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261)
> at
> org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper.testNoSuchMultiTermsInNotNear(TestSpanMultiTermQueryWrapper.java:144)
> ...
> {noformat}
> The basic problem is that an empty SpanQuery (SpanOrQuery with zero clauses)
> does not have a field, and much of our code assumes that the field is not
> null.
> Test case and patch on way.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5450) NPE and Illegal Argument Exception in wrapped SpanMultiTerms with no matches
[
https://issues.apache.org/jira/browse/LUCENE-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904506#comment-13904506
]
ASF subversion and git services commented on LUCENE-5450:
-
Commit 1569513 from [~rcmuir] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1569513 ]
LUCENE-5450: fix getField() NPE issues with span queries that have empty clauses
> NPE and Illegal Argument Exception in wrapped SpanMultiTerms with no matches
>
>
> Key: LUCENE-5450
> URL: https://issues.apache.org/jira/browse/LUCENE-5450
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: 5.0
>Reporter: Tim Allison
> Attachments: LUCENE-5450.patch, LUCENE-5450.patch
>
>
> There are problems with the handling of wrapped span multiterms that don't
> have any matches.
> 1) In the test framework, when AssertingIndexSearcher does a rewrite and then
> checks for equality, there's an NPE for SpanNear and SpanOr:
> {noformat}
> java.lang.NullPointerException
> at
> __randomizedtesting.SeedInfo.seed([8E96A398C89A703B:338EB53A2EDBE8CC]:0)
> at
> org.apache.lucene.search.spans.SpanOrQuery.addClause(SpanOrQuery.java:57)
> at
> org.apache.lucene.search.spans.SpanOrQuery.(SpanOrQuery.java:49)
> at org.apache.lucene.search.spans.SpanOrQuery.clone(SpanOrQuery.java:86)
> at org.apache.lucene.search.spans.SpanOrQuery.clone(SpanOrQuery.java:39)
> at
> org.apache.lucene.search.QueryUtils.checkHashEquals(QueryUtils.java:57)
> at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:52)
> at
> org.apache.lucene.search.AssertingIndexSearcher.rewrite(AssertingIndexSearcher.java:80)
> at
> org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
> at
> org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261)
> at
> org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper.testNoSuchMultiTermsInOr(TestSpanMultiTermQueryWrapper.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
> ...
> {noformat}
> 2) The same issue is causing a "Clauses must have same field" illegal
> argument exception in a SpanNotQuery.
> {noformat}
> java.lang.IllegalArgumentException: Clauses must have same field.
> at
> __randomizedtesting.SeedInfo.seed([779E5DD7E7523C72:4C2ECAAB938038F9]:0)
> at
> org.apache.lucene.search.spans.SpanNotQuery.(SpanNotQuery.java:66)
> at
> org.apache.lucene.search.spans.SpanNotQuery.clone(SpanNotQuery.java:99)
> at
> org.apache.lucene.search.spans.SpanNotQuery.clone(SpanNotQuery.java:36)
> at
> org.apache.lucene.search.QueryUtils.checkHashEquals(QueryUtils.java:57)
> at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:52)
> at
> org.apache.lucene.search.AssertingIndexSearcher.rewrite(AssertingIndexSearcher.java:80)
> at
> org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
> at
> org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261)
> at
> org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper.testNoSuchMultiTermsInNotNear(TestSpanMultiTermQueryWrapper.java:144)
> ...
> {noformat}
> The basic problem is that an empty SpanQuery (SpanOrQuery with zero clauses)
> does not have a field, and much of our code assumes that the field is not
> null.
> Test case and patch on way.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5745) Add an UpdateRequest parameter that lets request wait until no searchers are warming before committing
Colin Bartolome created SOLR-5745:
-
Summary: Add an UpdateRequest parameter that lets request wait
until no searchers are warming before committing
Key: SOLR-5745
URL: https://issues.apache.org/jira/browse/SOLR-5745
Project: Solr
Issue Type: New Feature
Components: clients - java
Affects Versions: 4.2.1
Reporter: Colin Bartolome
Priority: Minor
In order to avoid "Overlapping onDeckSearchers=2" warnings, we'd like to set
{{maxWarmingSearchers=1}} in {{solrconfig.xml}}. If we do that, though, and
happen to request a hard commit while an automatic soft commit is already
processing, we get an error like this:
{code}
Error opening new searcher. exceeded limit of maxWarmingSearchers=1, try again
later.
{code}
and the request fails.
What we'd like to see is for {{UpdateRequest}} to support a parameter, similar
to the existing {{waitSearcher}} parameter, that instructs the server to hold
the request until no other searchers were currently warming. (Or, more
precisely, until the request could proceed without exceeding
{{maxWarmingSearchers}}.)
It seems something like this could eliminate the performance penalty of having
multiple on-deck searchers without the unpredictable errors caused by setting
{{maxWarmingSearchers=1}}. The performance penalty moves to a place that
expects it: the code that requested a commit and said it was willing to wait.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5450) NPE and Illegal Argument Exception in wrapped SpanMultiTerms with no matches
[
https://issues.apache.org/jira/browse/LUCENE-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904469#comment-13904469
]
ASF subversion and git services commented on LUCENE-5450:
-
Commit 1569503 from [~rcmuir] in branch 'dev/trunk'
[ https://svn.apache.org/r1569503 ]
LUCENE-5450: fix getField() NPE issues with span queries that have empty clauses
> NPE and Illegal Argument Exception in wrapped SpanMultiTerms with no matches
>
>
> Key: LUCENE-5450
> URL: https://issues.apache.org/jira/browse/LUCENE-5450
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: 5.0
>Reporter: Tim Allison
> Attachments: LUCENE-5450.patch, LUCENE-5450.patch
>
>
> There are problems with the handling of wrapped span multiterms that don't
> have any matches.
> 1) In the test framework, when AssertingIndexSearcher does a rewrite and then
> checks for equality, there's an NPE for SpanNear and SpanOr:
> {noformat}
> java.lang.NullPointerException
> at
> __randomizedtesting.SeedInfo.seed([8E96A398C89A703B:338EB53A2EDBE8CC]:0)
> at
> org.apache.lucene.search.spans.SpanOrQuery.addClause(SpanOrQuery.java:57)
> at
> org.apache.lucene.search.spans.SpanOrQuery.(SpanOrQuery.java:49)
> at org.apache.lucene.search.spans.SpanOrQuery.clone(SpanOrQuery.java:86)
> at org.apache.lucene.search.spans.SpanOrQuery.clone(SpanOrQuery.java:39)
> at
> org.apache.lucene.search.QueryUtils.checkHashEquals(QueryUtils.java:57)
> at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:52)
> at
> org.apache.lucene.search.AssertingIndexSearcher.rewrite(AssertingIndexSearcher.java:80)
> at
> org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
> at
> org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261)
> at
> org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper.testNoSuchMultiTermsInOr(TestSpanMultiTermQueryWrapper.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
> ...
> {noformat}
> 2) The same issue is causing a "Clauses must have same field" illegal
> argument exception in a SpanNotQuery.
> {noformat}
> java.lang.IllegalArgumentException: Clauses must have same field.
> at
> __randomizedtesting.SeedInfo.seed([779E5DD7E7523C72:4C2ECAAB938038F9]:0)
> at
> org.apache.lucene.search.spans.SpanNotQuery.(SpanNotQuery.java:66)
> at
> org.apache.lucene.search.spans.SpanNotQuery.clone(SpanNotQuery.java:99)
> at
> org.apache.lucene.search.spans.SpanNotQuery.clone(SpanNotQuery.java:36)
> at
> org.apache.lucene.search.QueryUtils.checkHashEquals(QueryUtils.java:57)
> at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:52)
> at
> org.apache.lucene.search.AssertingIndexSearcher.rewrite(AssertingIndexSearcher.java:80)
> at
> org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
> at
> org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261)
> at
> org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper.testNoSuchMultiTermsInNotNear(TestSpanMultiTermQueryWrapper.java:144)
> ...
> {noformat}
> The basic problem is that an empty SpanQuery (SpanOrQuery with zero clauses)
> does not have a field, and much of our code assumes that the field is not
> null.
> Test case and patch on way.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5450) NPE and Illegal Argument Exception in wrapped SpanMultiTerms with no matches
[
https://issues.apache.org/jira/browse/LUCENE-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904456#comment-13904456
]
Michael McCandless commented on LUCENE-5450:
+1
> NPE and Illegal Argument Exception in wrapped SpanMultiTerms with no matches
>
>
> Key: LUCENE-5450
> URL: https://issues.apache.org/jira/browse/LUCENE-5450
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: 5.0
>Reporter: Tim Allison
> Attachments: LUCENE-5450.patch, LUCENE-5450.patch
>
>
> There are problems with the handling of wrapped span multiterms that don't
> have any matches.
> 1) In the test framework, when AssertingIndexSearcher does a rewrite and then
> checks for equality, there's an NPE for SpanNear and SpanOr:
> {noformat}
> java.lang.NullPointerException
> at
> __randomizedtesting.SeedInfo.seed([8E96A398C89A703B:338EB53A2EDBE8CC]:0)
> at
> org.apache.lucene.search.spans.SpanOrQuery.addClause(SpanOrQuery.java:57)
> at
> org.apache.lucene.search.spans.SpanOrQuery.(SpanOrQuery.java:49)
> at org.apache.lucene.search.spans.SpanOrQuery.clone(SpanOrQuery.java:86)
> at org.apache.lucene.search.spans.SpanOrQuery.clone(SpanOrQuery.java:39)
> at
> org.apache.lucene.search.QueryUtils.checkHashEquals(QueryUtils.java:57)
> at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:52)
> at
> org.apache.lucene.search.AssertingIndexSearcher.rewrite(AssertingIndexSearcher.java:80)
> at
> org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
> at
> org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261)
> at
> org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper.testNoSuchMultiTermsInOr(TestSpanMultiTermQueryWrapper.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
> ...
> {noformat}
> 2) The same issue is causing a "Clauses must have same field" illegal
> argument exception in a SpanNotQuery.
> {noformat}
> java.lang.IllegalArgumentException: Clauses must have same field.
> at
> __randomizedtesting.SeedInfo.seed([779E5DD7E7523C72:4C2ECAAB938038F9]:0)
> at
> org.apache.lucene.search.spans.SpanNotQuery.(SpanNotQuery.java:66)
> at
> org.apache.lucene.search.spans.SpanNotQuery.clone(SpanNotQuery.java:99)
> at
> org.apache.lucene.search.spans.SpanNotQuery.clone(SpanNotQuery.java:36)
> at
> org.apache.lucene.search.QueryUtils.checkHashEquals(QueryUtils.java:57)
> at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:52)
> at
> org.apache.lucene.search.AssertingIndexSearcher.rewrite(AssertingIndexSearcher.java:80)
> at
> org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
> at
> org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261)
> at
> org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper.testNoSuchMultiTermsInNotNear(TestSpanMultiTermQueryWrapper.java:144)
> ...
> {noformat}
> The basic problem is that an empty SpanQuery (SpanOrQuery with zero clauses)
> does not have a field, and much of our code assumes that the field is not
> null.
> Test case and patch on way.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5438) add near-real-time replication
[ https://issues.apache.org/jira/browse/LUCENE-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904449#comment-13904449 ] ASF subversion and git services commented on LUCENE-5438: - Commit 1569499 from [~mikemccand] in branch 'dev/branches/lucene5438' [ https://svn.apache.org/r1569499 ] LUCENE-5438: fix javadoc > add near-real-time replication > -- > > Key: LUCENE-5438 > URL: https://issues.apache.org/jira/browse/LUCENE-5438 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/replicator >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.7, 5.0 > > Attachments: LUCENE-5438.patch, LUCENE-5438.patch > > > Lucene's replication module makes it easy to incrementally sync index > changes from a master index to any number of replicas, and it > handles/abstracts all the underlying complexity of holding a > time-expiring snapshot, finding which files need copying, syncing more > than one index (e.g., taxo + index), etc. > But today you must first commit on the master, and then again the > replica's copied files are fsync'd, because the code operates on > commit points. But this isn't "technically" necessary, and it mixes > up durability and fast turnaround time. > Long ago we added near-real-time readers to Lucene, for the same > reason: you shouldn't have to commit just to see the new index > changes. > I think we should do the same for replication: allow the new segments > to be copied out to replica(s), and new NRT readers to be opened, to > fully decouple committing from visibility. This way apps can then > separately choose when to replicate (for freshness), and when to > commit (for durability). > I think for some apps this could be a compelling alternative to the > "re-index all documents on each shard" approach that Solr Cloud / > ElasticSearch implement today, and it may also mean that the > transaction log can remain external to / above the cluster. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5438) add near-real-time replication
[ https://issues.apache.org/jira/browse/LUCENE-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904442#comment-13904442 ] ASF subversion and git services commented on LUCENE-5438: - Commit 1569489 from [~mikemccand] in branch 'dev/branches/lucene5438' [ https://svn.apache.org/r1569489 ] LUCENE-5438: commit current state > add near-real-time replication > -- > > Key: LUCENE-5438 > URL: https://issues.apache.org/jira/browse/LUCENE-5438 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/replicator >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.7, 5.0 > > Attachments: LUCENE-5438.patch, LUCENE-5438.patch > > > Lucene's replication module makes it easy to incrementally sync index > changes from a master index to any number of replicas, and it > handles/abstracts all the underlying complexity of holding a > time-expiring snapshot, finding which files need copying, syncing more > than one index (e.g., taxo + index), etc. > But today you must first commit on the master, and then again the > replica's copied files are fsync'd, because the code operates on > commit points. But this isn't "technically" necessary, and it mixes > up durability and fast turnaround time. > Long ago we added near-real-time readers to Lucene, for the same > reason: you shouldn't have to commit just to see the new index > changes. > I think we should do the same for replication: allow the new segments > to be copied out to replica(s), and new NRT readers to be opened, to > fully decouple committing from visibility. This way apps can then > separately choose when to replicate (for freshness), and when to > commit (for durability). > I think for some apps this could be a compelling alternative to the > "re-index all documents on each shard" approach that Solr Cloud / > ElasticSearch implement today, and it may also mean that the > transaction log can remain external to / above the cluster. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5438) add near-real-time replication
[ https://issues.apache.org/jira/browse/LUCENE-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904436#comment-13904436 ] ASF subversion and git services commented on LUCENE-5438: - Commit 1569488 from [~mikemccand] in branch 'dev/branches/lucene5438' [ https://svn.apache.org/r1569488 ] LUCENE-5438: make branch > add near-real-time replication > -- > > Key: LUCENE-5438 > URL: https://issues.apache.org/jira/browse/LUCENE-5438 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/replicator >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.7, 5.0 > > Attachments: LUCENE-5438.patch, LUCENE-5438.patch > > > Lucene's replication module makes it easy to incrementally sync index > changes from a master index to any number of replicas, and it > handles/abstracts all the underlying complexity of holding a > time-expiring snapshot, finding which files need copying, syncing more > than one index (e.g., taxo + index), etc. > But today you must first commit on the master, and then again the > replica's copied files are fsync'd, because the code operates on > commit points. But this isn't "technically" necessary, and it mixes > up durability and fast turnaround time. > Long ago we added near-real-time readers to Lucene, for the same > reason: you shouldn't have to commit just to see the new index > changes. > I think we should do the same for replication: allow the new segments > to be copied out to replica(s), and new NRT readers to be opened, to > fully decouple committing from visibility. This way apps can then > separately choose when to replicate (for freshness), and when to > commit (for durability). > I think for some apps this could be a compelling alternative to the > "re-index all documents on each shard" approach that Solr Cloud / > ElasticSearch implement today, and it may also mean that the > transaction log can remain external to / above the cluster. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5451) Update Spatial4j to 0.4.1
David Smiley created LUCENE-5451: Summary: Update Spatial4j to 0.4.1 Key: LUCENE-5451 URL: https://issues.apache.org/jira/browse/LUCENE-5451 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Affects Versions: 4.7, 5.0 Reporter: David Smiley Assignee: David Smiley Priority: Blocker Fix For: 4.7, 5.0 A user reported a fairly serious issue affecting the latest version of Spatial4j 0.4 https://github.com/spatial4j/spatial4j/issues/72 "JtsSpatialContextFactory and geo=false with worldBounds fails" I've already fixed this locally and I'll push out a bug-fix Spatial4j 0.4.1. Upgrading will be a complete drop-in replacement. Heck I could do that now but as I work with the user who found the bug I want to see if there's any other problem. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5450) NPE and Illegal Argument Exception in wrapped SpanMultiTerms with no matches
[
https://issues.apache.org/jira/browse/LUCENE-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904424#comment-13904424
]
Tim Allison commented on LUCENE-5450:
-
Looks great. Much simpler. Thank you!
> NPE and Illegal Argument Exception in wrapped SpanMultiTerms with no matches
>
>
> Key: LUCENE-5450
> URL: https://issues.apache.org/jira/browse/LUCENE-5450
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: 5.0
>Reporter: Tim Allison
> Attachments: LUCENE-5450.patch, LUCENE-5450.patch
>
>
> There are problems with the handling of wrapped span multiterms that don't
> have any matches.
> 1) In the test framework, when AssertingIndexSearcher does a rewrite and then
> checks for equality, there's an NPE for SpanNear and SpanOr:
> {noformat}
> java.lang.NullPointerException
> at
> __randomizedtesting.SeedInfo.seed([8E96A398C89A703B:338EB53A2EDBE8CC]:0)
> at
> org.apache.lucene.search.spans.SpanOrQuery.addClause(SpanOrQuery.java:57)
> at
> org.apache.lucene.search.spans.SpanOrQuery.(SpanOrQuery.java:49)
> at org.apache.lucene.search.spans.SpanOrQuery.clone(SpanOrQuery.java:86)
> at org.apache.lucene.search.spans.SpanOrQuery.clone(SpanOrQuery.java:39)
> at
> org.apache.lucene.search.QueryUtils.checkHashEquals(QueryUtils.java:57)
> at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:52)
> at
> org.apache.lucene.search.AssertingIndexSearcher.rewrite(AssertingIndexSearcher.java:80)
> at
> org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
> at
> org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261)
> at
> org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper.testNoSuchMultiTermsInOr(TestSpanMultiTermQueryWrapper.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
> ...
> {noformat}
> 2) The same issue is causing a "Clauses must have same field" illegal
> argument exception in a SpanNotQuery.
> {noformat}
> java.lang.IllegalArgumentException: Clauses must have same field.
> at
> __randomizedtesting.SeedInfo.seed([779E5DD7E7523C72:4C2ECAAB938038F9]:0)
> at
> org.apache.lucene.search.spans.SpanNotQuery.(SpanNotQuery.java:66)
> at
> org.apache.lucene.search.spans.SpanNotQuery.clone(SpanNotQuery.java:99)
> at
> org.apache.lucene.search.spans.SpanNotQuery.clone(SpanNotQuery.java:36)
> at
> org.apache.lucene.search.QueryUtils.checkHashEquals(QueryUtils.java:57)
> at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:52)
> at
> org.apache.lucene.search.AssertingIndexSearcher.rewrite(AssertingIndexSearcher.java:80)
> at
> org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
> at
> org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261)
> at
> org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper.testNoSuchMultiTermsInNotNear(TestSpanMultiTermQueryWrapper.java:144)
> ...
> {noformat}
> The basic problem is that an empty SpanQuery (SpanOrQuery with zero clauses)
> does not have a field, and much of our code assumes that the field is not
> null.
> Test case and patch on way.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5450) NPE and Illegal Argument Exception in wrapped SpanMultiTerms with no matches
[
https://issues.apache.org/jira/browse/LUCENE-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-5450:
Attachment: LUCENE-5450.patch
Here's what i was thinking (your tests and existing tests seem to pass). Let me
know what you think.
> NPE and Illegal Argument Exception in wrapped SpanMultiTerms with no matches
>
>
> Key: LUCENE-5450
> URL: https://issues.apache.org/jira/browse/LUCENE-5450
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: 5.0
>Reporter: Tim Allison
> Attachments: LUCENE-5450.patch, LUCENE-5450.patch
>
>
> There are problems with the handling of wrapped span multiterms that don't
> have any matches.
> 1) In the test framework, when AssertingIndexSearcher does a rewrite and then
> checks for equality, there's an NPE for SpanNear and SpanOr:
> {noformat}
> java.lang.NullPointerException
> at
> __randomizedtesting.SeedInfo.seed([8E96A398C89A703B:338EB53A2EDBE8CC]:0)
> at
> org.apache.lucene.search.spans.SpanOrQuery.addClause(SpanOrQuery.java:57)
> at
> org.apache.lucene.search.spans.SpanOrQuery.(SpanOrQuery.java:49)
> at org.apache.lucene.search.spans.SpanOrQuery.clone(SpanOrQuery.java:86)
> at org.apache.lucene.search.spans.SpanOrQuery.clone(SpanOrQuery.java:39)
> at
> org.apache.lucene.search.QueryUtils.checkHashEquals(QueryUtils.java:57)
> at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:52)
> at
> org.apache.lucene.search.AssertingIndexSearcher.rewrite(AssertingIndexSearcher.java:80)
> at
> org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
> at
> org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261)
> at
> org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper.testNoSuchMultiTermsInOr(TestSpanMultiTermQueryWrapper.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
> ...
> {noformat}
> 2) The same issue is causing a "Clauses must have same field" illegal
> argument exception in a SpanNotQuery.
> {noformat}
> java.lang.IllegalArgumentException: Clauses must have same field.
> at
> __randomizedtesting.SeedInfo.seed([779E5DD7E7523C72:4C2ECAAB938038F9]:0)
> at
> org.apache.lucene.search.spans.SpanNotQuery.(SpanNotQuery.java:66)
> at
> org.apache.lucene.search.spans.SpanNotQuery.clone(SpanNotQuery.java:99)
> at
> org.apache.lucene.search.spans.SpanNotQuery.clone(SpanNotQuery.java:36)
> at
> org.apache.lucene.search.QueryUtils.checkHashEquals(QueryUtils.java:57)
> at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:52)
> at
> org.apache.lucene.search.AssertingIndexSearcher.rewrite(AssertingIndexSearcher.java:80)
> at
> org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
> at
> org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261)
> at
> org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper.testNoSuchMultiTermsInNotNear(TestSpanMultiTermQueryWrapper.java:144)
> ...
> {noformat}
> The basic problem is that an empty SpanQuery (SpanOrQuery with zero clauses)
> does not have a field, and much of our code assumes that the field is not
> null.
> Test case and patch on way.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5450) NPE and Illegal Argument Exception in wrapped SpanMultiTerms with no matches
[
https://issues.apache.org/jira/browse/LUCENE-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904405#comment-13904405
]
Robert Muir commented on LUCENE-5450:
-
Hi Tim, thanks for reporting the bug.
Personally, i don't like the use of the static isEmpty method with instanceofs,
because it makes it harder for people to implement their own queries.
An alternative solution (that is no change in behavior and no api change today,
since getField() is currently null in those cases) is to just add the proper
null checks?
> NPE and Illegal Argument Exception in wrapped SpanMultiTerms with no matches
>
>
> Key: LUCENE-5450
> URL: https://issues.apache.org/jira/browse/LUCENE-5450
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: 5.0
>Reporter: Tim Allison
> Attachments: LUCENE-5450.patch, LUCENE-5450.patch
>
>
> There are problems with the handling of wrapped span multiterms that don't
> have any matches.
> 1) In the test framework, when AssertingIndexSearcher does a rewrite and then
> checks for equality, there's an NPE for SpanNear and SpanOr:
> {noformat}
> java.lang.NullPointerException
> at
> __randomizedtesting.SeedInfo.seed([8E96A398C89A703B:338EB53A2EDBE8CC]:0)
> at
> org.apache.lucene.search.spans.SpanOrQuery.addClause(SpanOrQuery.java:57)
> at
> org.apache.lucene.search.spans.SpanOrQuery.(SpanOrQuery.java:49)
> at org.apache.lucene.search.spans.SpanOrQuery.clone(SpanOrQuery.java:86)
> at org.apache.lucene.search.spans.SpanOrQuery.clone(SpanOrQuery.java:39)
> at
> org.apache.lucene.search.QueryUtils.checkHashEquals(QueryUtils.java:57)
> at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:52)
> at
> org.apache.lucene.search.AssertingIndexSearcher.rewrite(AssertingIndexSearcher.java:80)
> at
> org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
> at
> org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261)
> at
> org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper.testNoSuchMultiTermsInOr(TestSpanMultiTermQueryWrapper.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
> ...
> {noformat}
> 2) The same issue is causing a "Clauses must have same field" illegal
> argument exception in a SpanNotQuery.
> {noformat}
> java.lang.IllegalArgumentException: Clauses must have same field.
> at
> __randomizedtesting.SeedInfo.seed([779E5DD7E7523C72:4C2ECAAB938038F9]:0)
> at
> org.apache.lucene.search.spans.SpanNotQuery.(SpanNotQuery.java:66)
> at
> org.apache.lucene.search.spans.SpanNotQuery.clone(SpanNotQuery.java:99)
> at
> org.apache.lucene.search.spans.SpanNotQuery.clone(SpanNotQuery.java:36)
> at
> org.apache.lucene.search.QueryUtils.checkHashEquals(QueryUtils.java:57)
> at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:52)
> at
> org.apache.lucene.search.AssertingIndexSearcher.rewrite(AssertingIndexSearcher.java:80)
> at
> org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
> at
> org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261)
> at
> org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper.testNoSuchMultiTermsInNotNear(TestSpanMultiTermQueryWrapper.java:144)
> ...
> {noformat}
> The basic problem is that an empty SpanQuery (SpanOrQuery with zero clauses)
> does not have a field, and much of our code assumes that the field is not
> null.
> Test case and patch on way.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Building an RC for Lucene / Solr 4.7
huge +1 to marking it - I dont' like to ignore failing tests but it's hard to tell if you are not close to it! On Tue, Feb 18, 2014 at 7:16 PM, Steve Molloy wrote: > I agree ignoring tests isn't a good idea, but someone from outside should be > able to determine if a failing test is critical or not. Maybe the solution > would be to keep running them, but have the failure message specify the Jira > entry associated with it. Then whoever runs the test, to build RC or for > another reason, can see it is a know issue that will eventually get addressed > and from Jira entry should be able to assess whether or not it's acceptable > for the context. > > My 2 cents. :) > > Steve > > From: Mark Miller [markrmil...@gmail.com] > Sent: February 18, 2014 11:48 AM > To: Lucene/Solr dev > Subject: Re: Building an RC for Lucene / Solr 4.7 > > Depends on your situation. For me, I can run the tests and have them pass 6 > times in a row. It it was otherwise, I would fix the issue, as I have for > years now. > > When I see a test failing commonly for another dev, I’ll also often jump in > and help fix the issue. As I have for years now. > > I’ll also work on tests in general pretty much off and on all the time. Not a > lot of other guys doing it, so sometimes I’m more ahead or behind than other > times. > > Should we ignore them? I don’t think so. We should keep fixing them. Removing > them would remove critical coverage. The fails in general, are known - > tracked in JIRA or logged by jenkins. I know if it’s something thats likely > test related and I know if it’s something knew or something existing. If one > of them annoys people, please jump in! I don’t know half the code or features > I end up jumping in to help with. > > It’s also not necessarily the same tests or the same issues. I’ve fixed > hundreds of issues. The code keeps changing, the environments and number of > tests threads used and number of contributors keep changing. > > The rational is I have a *very* close, *very* informed view on the Solr > tests. I read every fail, I run my own Jenkins server, I’m not some third > party who wonders what these fails mean. Someone else might not be so > informed. But unless they are helping to work on the tests, filing JIRA > issues, adding to existing JIRA issues, or emailing the list for help, those > people are pretty much on their own. > > They will have to wait until I can make every tests run in any env with any > computing power without fail even as tests are added to and the code is > changed for a very large distributed system. > > > - Mark > > http://about.me/markrmiller > > On Feb 18, 2014, at 8:41 AM, Simon Willnauer > wrote: > >> Hmm I am not sure if I understand that rational. Anyway wouldn't it be >> better to @Ignore the tests and re-enable once they are fixed? I just >> wonder how I can tell if I broke something in solr while working on >> lucene and I am supposed to ignore failing tests? >> >> simon >> >> On Tue, Feb 18, 2014 at 2:36 PM, Mark Miller wrote: >>> Because we run those tests locally and see the results on Jenkins and have >>> an understanding what the issues are. Perhaps you don't, but the Solr >>> people do. That's how we can release. >>> >>> That script shouldn't run the solr tests. >>> >>> - Mark >>> On Feb 18, 2014, at 8:28 AM, Simon Willnauer wrote: it is not the smoke test - I ran this: python3.2 -u buildAndPushRelease.py -prepare -push simonw -sign ECA39416 /home/simon/work/projects/lucene/lucene_solr_4_7/ 4.7.0 0 compared to this: python3.2 -u buildAndPushRelease.py -prepare -push simonw -sign ECA39416 -smoke /tmp/lucene_solr_4_7_smoke /home/simon/work/projects/lucene/lucene_solr_4_7/ 4.7.0 0 the first cmd runs the tests before it builds the release. I disabled the tests by applying -smoke which skips the test run. This is still freaking odd - how can I publish a release if the test don't pass a single time out of 6 runs? simon > On Tue, Feb 18, 2014 at 1:59 PM, Mark Miller > wrote: > Weird. The smoke script has always had solr tests disabled. Who enabled > it? Those fails in general have JIRA issues as far as I remember. > > - Mark > >> On Feb 18, 2014, at 7:24 AM, Simon Willnauer >> wrote: >> >> hey folks, >> >> I try to build an RC to checkout if everything goes alright and I now >> spend 4 hours already without luck. The release script runs the solr >> tests but they never pass. I tried it 6 times now and each time a >> different test breaks. I am going to disable the solr test run in the >> release script for now to actually run an RC build but this is very >> concerning IMO. I tried to reproduce the failures each time but they >> don't reproduce. Its mainly: >> >> org.apache.solr.cloud.OverseerTest.testShard
Re: Building an RC for Lucene / Solr 4.7
On Feb 18, 2014, at 1:16 PM, Steve Molloy wrote: > Maybe the solution would be to keep running them, but have the failure > message specify the Jira entry associated with it. Yeah, it’s not a bad idea for long running issues. Your not necessarily running into long running issues though. For example, we recently enabled SSL on a ton of tests. In some cases, running a bunch of embedded jetties with SSL can be ridiculously slow compared to not using SSL. A change like that will take time to stabilize across all envs, it makes sense to just address each issue rather than add output to the fail. A lot of the timeouts we used for example, need to be adjusted. If you followed my Solr trail, you would know I have been working on raising timeouts and adjusting things for the new issues around randomly using SSL. Things are in constant flux. The point of randomizing tests and constantly running them is to get fails. Unless you are paying attention, how do you know they are not new fails from new code? Because that is expected - we randomize, we run in different envs, it’s expected that we will find issues with a complicated test in some new random situation on some different env. Then we have to fix them in our copious fix test time. There are issues that are a little longer running, just because perhaps it looks like a test issue and just hasn't had the priority or other reasons. Like the Overseer test fail. I’m +1 on adding the JIRA to the fail output for tests like that. Those fails should be fairly rare though - if a fail occurs frequently for everyone, it needs to be addressed. But to my knowledge, we do that. And we keep developing and finding new things - often new things in the same tests. Because they are useful tests. You have to be paying attention to Solr to know whats going though. - Mark http://about.me/markrmiller - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Building an RC for Lucene / Solr 4.7
I'd like to see some sort of dashboard that would make clear at a glance when something goes from failing rarely to failing frequently. Anyone know how to get this reporting out of Jenkins? -Yonik http://heliosearch.org - native off-heap filters and fieldcache for solr On Tue, Feb 18, 2014 at 1:16 PM, Steve Molloy wrote: > I agree ignoring tests isn't a good idea, but someone from outside should be > able to determine if a failing test is critical or not. Maybe the solution > would be to keep running them, but have the failure message specify the Jira > entry associated with it. Then whoever runs the test, to build RC or for > another reason, can see it is a know issue that will eventually get addressed > and from Jira entry should be able to assess whether or not it's acceptable > for the context. > > My 2 cents. :) > > Steve > > From: Mark Miller [markrmil...@gmail.com] > Sent: February 18, 2014 11:48 AM > To: Lucene/Solr dev > Subject: Re: Building an RC for Lucene / Solr 4.7 > > Depends on your situation. For me, I can run the tests and have them pass 6 > times in a row. It it was otherwise, I would fix the issue, as I have for > years now. > > When I see a test failing commonly for another dev, I'll also often jump in > and help fix the issue. As I have for years now. > > I'll also work on tests in general pretty much off and on all the time. Not a > lot of other guys doing it, so sometimes I'm more ahead or behind than other > times. > > Should we ignore them? I don't think so. We should keep fixing them. Removing > them would remove critical coverage. The fails in general, are known - > tracked in JIRA or logged by jenkins. I know if it's something thats likely > test related and I know if it's something knew or something existing. If one > of them annoys people, please jump in! I don't know half the code or features > I end up jumping in to help with. > > It's also not necessarily the same tests or the same issues. I've fixed > hundreds of issues. The code keeps changing, the environments and number of > tests threads used and number of contributors keep changing. > > The rational is I have a *very* close, *very* informed view on the Solr > tests. I read every fail, I run my own Jenkins server, I'm not some third > party who wonders what these fails mean. Someone else might not be so > informed. But unless they are helping to work on the tests, filing JIRA > issues, adding to existing JIRA issues, or emailing the list for help, those > people are pretty much on their own. > > They will have to wait until I can make every tests run in any env with any > computing power without fail even as tests are added to and the code is > changed for a very large distributed system. > > > - Mark > > http://about.me/markrmiller > > On Feb 18, 2014, at 8:41 AM, Simon Willnauer > wrote: > >> Hmm I am not sure if I understand that rational. Anyway wouldn't it be >> better to @Ignore the tests and re-enable once they are fixed? I just >> wonder how I can tell if I broke something in solr while working on >> lucene and I am supposed to ignore failing tests? >> >> simon >> >> On Tue, Feb 18, 2014 at 2:36 PM, Mark Miller wrote: >>> Because we run those tests locally and see the results on Jenkins and have >>> an understanding what the issues are. Perhaps you don't, but the Solr >>> people do. That's how we can release. >>> >>> That script shouldn't run the solr tests. >>> >>> - Mark >>> On Feb 18, 2014, at 8:28 AM, Simon Willnauer wrote: it is not the smoke test - I ran this: python3.2 -u buildAndPushRelease.py -prepare -push simonw -sign ECA39416 /home/simon/work/projects/lucene/lucene_solr_4_7/ 4.7.0 0 compared to this: python3.2 -u buildAndPushRelease.py -prepare -push simonw -sign ECA39416 -smoke /tmp/lucene_solr_4_7_smoke /home/simon/work/projects/lucene/lucene_solr_4_7/ 4.7.0 0 the first cmd runs the tests before it builds the release. I disabled the tests by applying -smoke which skips the test run. This is still freaking odd - how can I publish a release if the test don't pass a single time out of 6 runs? simon > On Tue, Feb 18, 2014 at 1:59 PM, Mark Miller > wrote: > Weird. The smoke script has always had solr tests disabled. Who enabled > it? Those fails in general have JIRA issues as far as I remember. > > - Mark > >> On Feb 18, 2014, at 7:24 AM, Simon Willnauer >> wrote: >> >> hey folks, >> >> I try to build an RC to checkout if everything goes alright and I now >> spend 4 hours already without luck. The release script runs the solr >> tests but they never pass. I tried it 6 times now and each time a >> different test breaks. I am going to disable the solr test run in the >> release script for now to actually run an RC build but this is very >> co
[jira] [Commented] (LUCENE-1486) Wildcards, ORs etc inside Phrase queries
[
https://issues.apache.org/jira/browse/LUCENE-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904399#comment-13904399
]
Tim Allison commented on LUCENE-1486:
-
Attached update with tests from TestComplexPhraseQuery to LUCENE-5205.
> Wildcards, ORs etc inside Phrase queries
>
>
> Key: LUCENE-1486
> URL: https://issues.apache.org/jira/browse/LUCENE-1486
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/queryparser
>Affects Versions: 2.4
>Reporter: Mark Harwood
>Priority: Minor
> Fix For: 4.7
>
> Attachments: ComplexPhraseQueryParser.java, LUCENE-1486.patch,
> LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch,
> LUCENE-1486.patch, LUCENE-1486.patch, Lucene-1486 non default field.patch,
> TestComplexPhraseQuery.java, junit_complex_phrase_qp_07_21_2009.patch,
> junit_complex_phrase_qp_07_22_2009.patch
>
>
> An extension to the default QueryParser that overrides the parsing of
> PhraseQueries to allow more complex syntax e.g. wildcards in phrase queries.
> The implementation feels a little hacky - this is arguably better handled in
> QueryParser itself. This works as a proof of concept for much of the query
> parser syntax. Examples from the Junit test include:
> checkMatches("\"j* smyth~\"", "1,2"); //wildcards and fuzzies
> are OK in phrases
> checkMatches("\"(jo* -john) smith\"", "2"); // boolean logic
> works
> checkMatches("\"jo* smith\"~2", "1,2,3"); // position logic
> works.
>
> checkBadQuery("\"jo* id:1 smith\""); //mixing fields in a
> phrase is bad
> checkBadQuery("\"jo* \"smith\" \""); //phrases inside phrases
> is bad
> checkBadQuery("\"jo* [sma TO smZ]\" \""); //range queries
> inside phrases not supported
> Code plus Junit test to follow...
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5205) [PATCH] SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Allison updated LUCENE-5205: Attachment: LUCENE-5205.patch.gz Thanks to [~iorixxx]'s recommendation, I added tests from TestComplexPhraseQuery. This revealed LUCENE-5450. I had to make some small tweaks to the syntax of NOTs within phrases. If the community thinks this functionality is worthwhile, and if a kind committer would be willing to work with me to get this into shape, I'm happy to make modifications. Thank you. > [PATCH] SpanQueryParser with recursion, analysis and syntax very similar to > classic QueryParser > --- > > Key: LUCENE-5205 > URL: https://issues.apache.org/jira/browse/LUCENE-5205 > Project: Lucene - Core > Issue Type: Improvement > Components: core/queryparser >Reporter: Tim Allison > Labels: patch > Fix For: 4.7 > > Attachments: LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, > LUCENE_5205.patch, SpanQueryParser_v1.patch.gz, patch.txt > > > This parser extends QueryParserBase and includes functionality from: > * Classic QueryParser: most of its syntax > * SurroundQueryParser: recursive parsing for "near" and "not" clauses. > * ComplexPhraseQueryParser: can handle "near" queries that include multiterms > (wildcard, fuzzy, regex, prefix), > * AnalyzingQueryParser: has an option to analyze multiterms. > At a high level, there's a first pass BooleanQuery/field parser and then a > span query parser handles all terminal nodes and phrases. > Same as classic syntax: > * term: test > * fuzzy: roam~0.8, roam~2 > * wildcard: te?t, test*, t*st > * regex: /\[mb\]oat/ > * phrase: "jakarta apache" > * phrase with slop: "jakarta apache"~3 > * default "or" clause: jakarta apache > * grouping "or" clause: (jakarta apache) > * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta > * multiple fields: title:lucene author:hatcher > > Main additions in SpanQueryParser syntax vs. classic syntax: > * Can require "in order" for phrases with slop with the \~> operator: > "jakarta apache"\~>3 > * Can specify "not near": "fever bieber"!\~3,10 :: > find "fever" but not if "bieber" appears within 3 words before or 10 > words after it. > * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta > apache\]~3 lucene\]\~>4 :: > find "jakarta" within 3 words of "apache", and that hit has to be within > four words before "lucene" > * Can also use \[\] for single level phrasal queries instead of " as in: > \[jakarta apache\] > * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 > :: find "apache" and then either "lucene" or "solr" within three words. > * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2 > * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ > /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two > words of "ap*che" and that hit has to be within ten words of something like > "solr" or that "lucene" regex. > * Can require at least x number of hits at boolean level: "apache AND (lucene > solr tika)~2 > * Can use negative only query: -jakarta :: Find all docs that don't contain > "jakarta" > * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of > potential performance issues!). > Trivial additions: > * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, > prefix =2) > * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance > <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein) > This parser can be very useful for concordance tasks (see also LUCENE-5317 > and LUCENE-5318) and for analytical search. > Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery. > Most of the documentation is in the javadoc for SpanQueryParser. > Any and all feedback is welcome. Thank you. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Refactoring code through Github pull requests
Once I have transported a change from branch to branch via diff\apply, git stops discussing a rename at all. On February 18, 2014 9:06:30 AM EST, Thomas Matthijs wrote: >Unfortunately i can't find a way to make it explicitly show it will do >a >svn rename, but it does do it, so that makes this solution not very >useful >either i guess. > > >--- git --- >[master svntest] % git status >On branch master >Changes to be committed: > (use "git reset HEAD ..." to unstage) > >renamed:test -> moo > >[master svntest] % git commit -m "woof" >[master 6e2c0b3] woof > 1 file changed, 0 insertions(+), 0 deletions(-) > rename test => moo (100%) >[master svntest] % git svn dcommit >Committing to https://.../trunk ... >R test => moo >Committed r3 >D test >A moo >W: -empty_dir: trunk/test >r3 = 0ae41e170cf7d07ec3679eb85d55c068617e0a66 (refs/remotes/trunk) > > >- svn --- > >[trunk] % svn log --diff -v > >r3 | thomas | 2014-02-18 14:32:07 +0100 (Tue, 18 Feb 2014) | 1 line >Changed paths: > A /trunk/moo (from /trunk/test:2) > D /trunk/test > >woof > > >On Tue, Feb 18, 2014 at 2:22 PM, Benson Margulies >wrote: > >> Let me be specific. If I am sitting in a git clone that has been set >> up with git svn, and I use git apply to apply the output of git >> format-patch, if I dcommit, is the autodetection going to result in >an >> svn mv? >> >> >> On Tue, Feb 18, 2014 at 8:20 AM, Thomas Matthijs >wrote: >> > Git does not track renames, but can show/detect it, the magic >options >> are -C >> > and -M for diff/show etc >> > >> > >> > >> > On Tue, Feb 18, 2014 at 2:16 PM, Benson Margulies >> > >> > wrote: >> >> >> >> I tried using git apply on a patch (from github's .patch URL) >that >> >> included a rename. no sign of a rename; just a delete and an add. >I >> >> feel like I'm missing something. >> >> >> >> On Tue, Feb 18, 2014 at 7:36 AM, Shai Erera >wrote: >> >> > The problem I see is that if you generate a patch using 'git >diff', it >> >> > applies just fine to svn (if you generate it w/ --no-prefix) >without >> any >> >> > warnings about missing files due the rename. Wanted to warn the >> >> > community >> >> > about it, so that when committers assign themselves to PRs, they >> review >> >> > the >> >> > patch closer and detect manually if a rename as happened. >> >> > >> >> > We could decide that renames are done in a separate commit, but >it's >> not >> >> > always possible. >> >> > >> >> > So mainly, FYI. >> >> > >> >> > And if someone has an idea for a script/ant-target we could >write to >> >> > detect >> >> > this case, that would be awesome. >> >> > >> >> > Shai >> >> > >> >> > >> >> > On Tue, Feb 18, 2014 at 2:31 PM, Thomas Matthijs > >> >> > wrote: >> >> >> >> >> >> Github pull requests can be treated as individual cherry picked >patch >> >> >> sets >> >> >> really, not branch merges ? (ie rebased) from there on out >you're in >> >> >> svn >> >> >> land. No need to "merge". >> >> >> >> >> >> But indeed, it tries to detect it based on the file content, >and >> >> >> doesn't >> >> >> work 100% as manual svn moves. >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Feb 18, 2014 at 1:27 PM, Benson Margulies >> >> >> >> >> >> wrote: >> >> >>> >> >> >>> Well, git-svn has a heap of warnings against using it for >merges; >> it's >> >> >>> also a really bad idea when renaming a whole package, as it >does it >> >> >>> one-file-at-a-time. >> >> >>> >> >> >>> If you have a workflow that works with the ASF mirror and svn, >> please >> >> >>> write it up on the Wiki! >> >> >>> >> >> >>> >> >> >>> On Tue, Feb 18, 2014 at 7:23 AM, Thomas Matthijs > >> >> >>> wrote: >> >> >>> > >> >> >>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera > >> >> >>> > wrote: >> >> >>> >> >> >> >>> >> >> >> >>> >> Second, has anyone perhaps found a way to overcome that >issue? I >> >> >>> >> thought >> >> >>> >> about maybe writing a script to detect that, looking at the >patch >> >> >>> >> file, but >> >> >>> >> it seems hard to detect that the deleted Foo is the new >Bar. If >> >> >>> >> it's >> >> >>> >> just >> >> >>> >> rename, maybe, but if part of the rename the code changed a >lot >> ... >> >> >>> >> it >> >> >>> >> becomes harder. >> >> >>> > >> >> >>> > >> >> >>> > Probably not the answer you want but >> >> >>> > If you use the git-svn bridge it should detect the rename >and >> commit >> >> >>> > it >> >> >>> > in >> >> >>> > svn as a move/copy >> >> >>> > >> >> >>> > >https://www.kernel.org/pub/software/scm/git/docs/git-svn.html >> >> >>> >> >> >>> >> - >> >> >>> 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: de
[jira] [Updated] (LUCENE-5450) NPE and Illegal Argument Exception in wrapped SpanMultiTerms with no matches
[
https://issues.apache.org/jira/browse/LUCENE-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Allison updated LUCENE-5450:
Attachment: LUCENE-5450.patch
Test case and v1 of patch attached.
> NPE and Illegal Argument Exception in wrapped SpanMultiTerms with no matches
>
>
> Key: LUCENE-5450
> URL: https://issues.apache.org/jira/browse/LUCENE-5450
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: 5.0
>Reporter: Tim Allison
> Attachments: LUCENE-5450.patch
>
>
> There are problems with the handling of wrapped span multiterms that don't
> have any matches.
> 1) In the test framework, when AssertingIndexSearcher does a rewrite and then
> checks for equality, there's an NPE for SpanNear and SpanOr:
> {noformat}
> java.lang.NullPointerException
> at
> __randomizedtesting.SeedInfo.seed([8E96A398C89A703B:338EB53A2EDBE8CC]:0)
> at
> org.apache.lucene.search.spans.SpanOrQuery.addClause(SpanOrQuery.java:57)
> at
> org.apache.lucene.search.spans.SpanOrQuery.(SpanOrQuery.java:49)
> at org.apache.lucene.search.spans.SpanOrQuery.clone(SpanOrQuery.java:86)
> at org.apache.lucene.search.spans.SpanOrQuery.clone(SpanOrQuery.java:39)
> at
> org.apache.lucene.search.QueryUtils.checkHashEquals(QueryUtils.java:57)
> at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:52)
> at
> org.apache.lucene.search.AssertingIndexSearcher.rewrite(AssertingIndexSearcher.java:80)
> at
> org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
> at
> org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261)
> at
> org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper.testNoSuchMultiTermsInOr(TestSpanMultiTermQueryWrapper.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
> ...
> {noformat}
> 2) The same issue is causing a "Clauses must have same field" illegal
> argument exception in a SpanNotQuery.
> {noformat}
> java.lang.IllegalArgumentException: Clauses must have same field.
> at
> __randomizedtesting.SeedInfo.seed([779E5DD7E7523C72:4C2ECAAB938038F9]:0)
> at
> org.apache.lucene.search.spans.SpanNotQuery.(SpanNotQuery.java:66)
> at
> org.apache.lucene.search.spans.SpanNotQuery.clone(SpanNotQuery.java:99)
> at
> org.apache.lucene.search.spans.SpanNotQuery.clone(SpanNotQuery.java:36)
> at
> org.apache.lucene.search.QueryUtils.checkHashEquals(QueryUtils.java:57)
> at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:52)
> at
> org.apache.lucene.search.AssertingIndexSearcher.rewrite(AssertingIndexSearcher.java:80)
> at
> org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
> at
> org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261)
> at
> org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper.testNoSuchMultiTermsInNotNear(TestSpanMultiTermQueryWrapper.java:144)
> ...
> {noformat}
> The basic problem is that an empty SpanQuery (SpanOrQuery with zero clauses)
> does not have a field, and much of our code assumes that the field is not
> null.
> Test case and patch on way.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5450) NPE and Illegal Argument Exception in wrapped SpanMultiTerms with no matches
Tim Allison created LUCENE-5450:
---
Summary: NPE and Illegal Argument Exception in wrapped
SpanMultiTerms with no matches
Key: LUCENE-5450
URL: https://issues.apache.org/jira/browse/LUCENE-5450
Project: Lucene - Core
Issue Type: Bug
Components: core/search
Affects Versions: 5.0
Reporter: Tim Allison
There are problems with the handling of wrapped span multiterms that don't have
any matches.
1) In the test framework, when AssertingIndexSearcher does a rewrite and then
checks for equality, there's an NPE for SpanNear and SpanOr:
{noformat}
java.lang.NullPointerException
at
__randomizedtesting.SeedInfo.seed([8E96A398C89A703B:338EB53A2EDBE8CC]:0)
at
org.apache.lucene.search.spans.SpanOrQuery.addClause(SpanOrQuery.java:57)
at
org.apache.lucene.search.spans.SpanOrQuery.(SpanOrQuery.java:49)
at org.apache.lucene.search.spans.SpanOrQuery.clone(SpanOrQuery.java:86)
at org.apache.lucene.search.spans.SpanOrQuery.clone(SpanOrQuery.java:39)
at
org.apache.lucene.search.QueryUtils.checkHashEquals(QueryUtils.java:57)
at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:52)
at
org.apache.lucene.search.AssertingIndexSearcher.rewrite(AssertingIndexSearcher.java:80)
at
org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
at
org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261)
at
org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper.testNoSuchMultiTermsInOr(TestSpanMultiTermQueryWrapper.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
...
{noformat}
2) The same issue is causing a "Clauses must have same field" illegal argument
exception in a SpanNotQuery.
{noformat}
java.lang.IllegalArgumentException: Clauses must have same field.
at
__randomizedtesting.SeedInfo.seed([779E5DD7E7523C72:4C2ECAAB938038F9]:0)
at
org.apache.lucene.search.spans.SpanNotQuery.(SpanNotQuery.java:66)
at
org.apache.lucene.search.spans.SpanNotQuery.clone(SpanNotQuery.java:99)
at
org.apache.lucene.search.spans.SpanNotQuery.clone(SpanNotQuery.java:36)
at
org.apache.lucene.search.QueryUtils.checkHashEquals(QueryUtils.java:57)
at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:52)
at
org.apache.lucene.search.AssertingIndexSearcher.rewrite(AssertingIndexSearcher.java:80)
at
org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
at
org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261)
at
org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper.testNoSuchMultiTermsInNotNear(TestSpanMultiTermQueryWrapper.java:144)
...
{noformat}
The basic problem is that an empty SpanQuery (SpanOrQuery with zero clauses)
does not have a field, and much of our code assumes that the field is not null.
Test case and patch on way.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Building an RC for Lucene / Solr 4.7
I agree ignoring tests isn't a good idea, but someone from outside should be able to determine if a failing test is critical or not. Maybe the solution would be to keep running them, but have the failure message specify the Jira entry associated with it. Then whoever runs the test, to build RC or for another reason, can see it is a know issue that will eventually get addressed and from Jira entry should be able to assess whether or not it's acceptable for the context. My 2 cents. :) Steve From: Mark Miller [markrmil...@gmail.com] Sent: February 18, 2014 11:48 AM To: Lucene/Solr dev Subject: Re: Building an RC for Lucene / Solr 4.7 Depends on your situation. For me, I can run the tests and have them pass 6 times in a row. It it was otherwise, I would fix the issue, as I have for years now. When I see a test failing commonly for another dev, I’ll also often jump in and help fix the issue. As I have for years now. I’ll also work on tests in general pretty much off and on all the time. Not a lot of other guys doing it, so sometimes I’m more ahead or behind than other times. Should we ignore them? I don’t think so. We should keep fixing them. Removing them would remove critical coverage. The fails in general, are known - tracked in JIRA or logged by jenkins. I know if it’s something thats likely test related and I know if it’s something knew or something existing. If one of them annoys people, please jump in! I don’t know half the code or features I end up jumping in to help with. It’s also not necessarily the same tests or the same issues. I’ve fixed hundreds of issues. The code keeps changing, the environments and number of tests threads used and number of contributors keep changing. The rational is I have a *very* close, *very* informed view on the Solr tests. I read every fail, I run my own Jenkins server, I’m not some third party who wonders what these fails mean. Someone else might not be so informed. But unless they are helping to work on the tests, filing JIRA issues, adding to existing JIRA issues, or emailing the list for help, those people are pretty much on their own. They will have to wait until I can make every tests run in any env with any computing power without fail even as tests are added to and the code is changed for a very large distributed system. - Mark http://about.me/markrmiller On Feb 18, 2014, at 8:41 AM, Simon Willnauer wrote: > Hmm I am not sure if I understand that rational. Anyway wouldn't it be > better to @Ignore the tests and re-enable once they are fixed? I just > wonder how I can tell if I broke something in solr while working on > lucene and I am supposed to ignore failing tests? > > simon > > On Tue, Feb 18, 2014 at 2:36 PM, Mark Miller wrote: >> Because we run those tests locally and see the results on Jenkins and have >> an understanding what the issues are. Perhaps you don't, but the Solr people >> do. That's how we can release. >> >> That script shouldn't run the solr tests. >> >> - Mark >> >>> On Feb 18, 2014, at 8:28 AM, Simon Willnauer >>> wrote: >>> >>> it is not the smoke test - I ran this: >>> >>> python3.2 -u buildAndPushRelease.py -prepare -push simonw -sign >>> ECA39416 /home/simon/work/projects/lucene/lucene_solr_4_7/ 4.7.0 0 >>> >>> compared to this: >>> >>> python3.2 -u buildAndPushRelease.py -prepare -push simonw -sign >>> ECA39416 -smoke /tmp/lucene_solr_4_7_smoke >>> /home/simon/work/projects/lucene/lucene_solr_4_7/ 4.7.0 0 >>> >>> the first cmd runs the tests before it builds the release. I disabled >>> the tests by applying -smoke which skips the test run. This is still >>> freaking odd - how can I publish a release if the test don't pass a >>> single time out of 6 runs? >>> >>> simon >>> >>> On Tue, Feb 18, 2014 at 1:59 PM, Mark Miller wrote: Weird. The smoke script has always had solr tests disabled. Who enabled it? Those fails in general have JIRA issues as far as I remember. - Mark > On Feb 18, 2014, at 7:24 AM, Simon Willnauer > wrote: > > hey folks, > > I try to build an RC to checkout if everything goes alright and I now > spend 4 hours already without luck. The release script runs the solr > tests but they never pass. I tried it 6 times now and each time a > different test breaks. I am going to disable the solr test run in the > release script for now to actually run an RC build but this is very > concerning IMO. I tried to reproduce the failures each time but they > don't reproduce. Its mainly: > > org.apache.solr.cloud.OverseerTest.testShardAssignmentBigger > org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSearch > org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch > > any ideas? > > I mean looking at the CI builds those failures are no news are they? > > simon > > -
Re: [JENKINS-MAVEN] Lucene-Solr-Maven-4.x #593: POMs out of sync
I turned off SSL for BasicDistributedZk2Test for now. - Mark On Feb 18, 2014, at 12:17 PM, Mark Miller wrote: > I may end up turning off SSL for these tests for a while. Until I have some > time to go in and figure out where the slowness is screwing the test. > > - Mark > > http://about.me/markrmiller > > On Feb 18, 2014, at 9:59 AM, Apache Jenkins Server > wrote: > >> Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/593/ >> >> 2 tests failed. >> REGRESSION: org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSearch >> >> Error Message: >> No live SolrServers available to handle this >> request:[https://127.0.0.1:18844/collection1, >> https://127.0.0.1:60023/collection1] >> >> Stack Trace: >> org.apache.solr.client.solrj.SolrServerException: No live SolrServers >> available to handle this request:[https://127.0.0.1:18844/collection1, >> https://127.0.0.1:60023/collection1] >> at >> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:495) >> at >> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:199) >> at >> org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:302) >> at >> org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:635) >> at >> org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:90) >> at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) >> at >> org.apache.solr.cloud.AbstractFullDistribZkTestBase.queryServer(AbstractFullDistribZkTestBase.java:1427) >> at >> org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:563) >> at >> org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:545) >> at >> org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:524) >> at >> org.apache.solr.cloud.BasicDistributedZk2Test.brindDownShardIndexSomeDocsAndRecover(BasicDistributedZk2Test.java:290) >> at >> org.apache.solr.cloud.BasicDistributedZk2Test.doTest(BasicDistributedZk2Test.java:107) >> >> >> FAILED: >> org.apache.solr.client.solrj.impl.BasicHttpSolrServerTest.testConnectionRefused >> >> Error Message: >> null >> >> Stack Trace: >> java.lang.AssertionError: null >> at >> __randomizedtesting.SeedInfo.seed([BB33CDB6E2E10843:949A69A7356E4747]:0) >> at org.junit.Assert.fail(Assert.java:92) >> at org.junit.Assert.assertTrue(Assert.java:43) >> at org.junit.Assert.assertTrue(Assert.java:54) >> at >> org.apache.solr.client.solrj.impl.BasicHttpSolrServerTest.testConnectionRefused(BasicHttpSolrServerTest.java:158) >> >> >> >> >> Build Log: >> [...truncated 52479 lines...] >> BUILD FAILED >> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/build.xml:482: >> The following error occurred while executing this line: >> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/build.xml:176: >> The following error occurred while executing this line: >> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/extra-targets.xml:77: >> Java returned: 1 >> >> Total time: 140 minutes 29 seconds >> Build step 'Invoke Ant' marked build as failure >> Recording test results >> 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 > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5609) Don't let cores create slices/named replicas
[
https://issues.apache.org/jira/browse/SOLR-5609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-5609:
-
Attachment: SOLR-5609_5130.patch
OverseerCollectionProcessorTest was failing
> Don't let cores create slices/named replicas
>
>
> Key: SOLR-5609
> URL: https://issues.apache.org/jira/browse/SOLR-5609
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 4.7, 5.0
>
> Attachments: SOLR-5609_5130.patch, SOLR-5609_5130.patch,
> SOLR-5609_5130.patch
>
>
> In SolrCloud, it is possible for a core to come up in any node , and register
> itself with an arbitrary slice/coreNodeName. This is a legacy requirement and
> we would like to make it only possible for Overseer to initiate creation of
> slice/replicas
> We plan to introduce cluster level properties at the top level
> /cluster-props.json
> {code:javascript}
> {
> "noSliceOrReplicaByCores":true"
> }
> {code}
> If this property is set to true, cores won't be able to send STATE commands
> with unknown slice/coreNodeName . Those commands will fail at Overseer. This
> is useful for SOLR-5310 / SOLR-5311 where a core/replica is deleted by a
> command and it comes up later and tries to create a replica/slice
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5709) Highlighting grouped duplicate docs from different shards with group.limit > 1 throws ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/SOLR-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904280#comment-13904280
]
Rob Tulloh commented on SOLR-5709:
--
Thanks for reminding to look back at the documentation. I agree that the
duplicates are likely the cause of the unexpected counts because the duplicates
live on different shards. The field collapsing wiki does document this
limitation.
> Highlighting grouped duplicate docs from different shards with group.limit >
> 1 throws ArrayIndexOutOfBoundsException
>
>
> Key: SOLR-5709
> URL: https://issues.apache.org/jira/browse/SOLR-5709
> Project: Solr
> Issue Type: Bug
> Components: highlighter
>Affects Versions: 4.3, 4.4, 4.5, 4.6, 5.0
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 4.7, 5.0
>
> Attachments: SOLR-5709.patch
>
>
> In a sharded (non-SolrCloud) deployment, if you index a document with the
> same unique key value into more than one shard, and then try to highlight
> grouped docs with more than one doc per group, where the grouped docs contain
> at least one duplicate doc pair, you get an AIOOBE.
> Here's the stack trace I got from such a situation, with 1 doc indexed into
> each shard in a 2-shard index, with {{group.limit=2}}:
> {noformat}
> ERROR null:java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.apache.solr.handler.component.HighlightComponent.finishStage(HighlightComponent.java:185)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:328)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1916)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:758)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:412)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:202)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> at
> org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:136)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at
> org.eclipse.jetty.server.handler.GzipHandler.handle(GzipHandler.java:301)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1077)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:368)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
> at
> org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
> at java.lang.Thread.run(Thread.java:724)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---
Re: [JENKINS-MAVEN] Lucene-Solr-Maven-4.x #593: POMs out of sync
I may end up turning off SSL for these tests for a while. Until I have some time to go in and figure out where the slowness is screwing the test. - Mark http://about.me/markrmiller On Feb 18, 2014, at 9:59 AM, Apache Jenkins Server wrote: > Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/593/ > > 2 tests failed. > REGRESSION: org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSearch > > Error Message: > No live SolrServers available to handle this > request:[https://127.0.0.1:18844/collection1, > https://127.0.0.1:60023/collection1] > > Stack Trace: > org.apache.solr.client.solrj.SolrServerException: No live SolrServers > available to handle this request:[https://127.0.0.1:18844/collection1, > https://127.0.0.1:60023/collection1] > at > org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:495) > at > org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:199) > at > org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:302) > at > org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:635) > at > org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:90) > at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) > at > org.apache.solr.cloud.AbstractFullDistribZkTestBase.queryServer(AbstractFullDistribZkTestBase.java:1427) > at > org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:563) > at > org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:545) > at > org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:524) > at > org.apache.solr.cloud.BasicDistributedZk2Test.brindDownShardIndexSomeDocsAndRecover(BasicDistributedZk2Test.java:290) > at > org.apache.solr.cloud.BasicDistributedZk2Test.doTest(BasicDistributedZk2Test.java:107) > > > FAILED: > org.apache.solr.client.solrj.impl.BasicHttpSolrServerTest.testConnectionRefused > > Error Message: > null > > Stack Trace: > java.lang.AssertionError: null > at > __randomizedtesting.SeedInfo.seed([BB33CDB6E2E10843:949A69A7356E4747]:0) > at org.junit.Assert.fail(Assert.java:92) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.junit.Assert.assertTrue(Assert.java:54) > at > org.apache.solr.client.solrj.impl.BasicHttpSolrServerTest.testConnectionRefused(BasicHttpSolrServerTest.java:158) > > > > > Build Log: > [...truncated 52479 lines...] > BUILD FAILED > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/build.xml:482: > The following error occurred while executing this line: > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/build.xml:176: > The following error occurred while executing this line: > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/extra-targets.xml:77: > Java returned: 1 > > Total time: 140 minutes 29 seconds > Build step 'Invoke Ant' marked build as failure > Recording test results > 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 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5727) LBHttpSolrServer should only retry on Connection exceptions when sending updates.
[ https://issues.apache.org/jira/browse/SOLR-5727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-5727. --- Resolution: Fixed This has worked out nicely so far. If someone wants to do a closer review of the code that would be great. Resolving for the moment unless someone speaks up. > LBHttpSolrServer should only retry on Connection exceptions when sending > updates. > - > > Key: SOLR-5727 > URL: https://issues.apache.org/jira/browse/SOLR-5727 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.7, 5.0 > > > You don't know if the request was successful or not and so its better to > error to the user than retry, especially because forwards to a shard leader > can be retried internally. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_60-ea-b04) - Build # 9410 - Still Failing!
I committed a fix for this - sorry for the noise here! On Tue, Feb 18, 2014 at 6:04 PM, Mark Miller wrote: > Fail is: > > /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build.xml:240: Some > example solrconfig.xml files do not refer to the correct luceneMatchVersion: > 4.8 > > - Mark > > http://about.me/markrmiller > > On Feb 18, 2014, at 12:00 PM, Policeman Jenkins Server > wrote: > >> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9410/ >> Java: 32bit/jdk1.7.0_60-ea-b04 -client -XX:+UseParallelGC >> >> All tests passed >> >> Build Log: >> [...truncated 28008 lines...] >> BUILD FAILED >> /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:459: The >> following error occurred while executing this line: >> /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:64: The following >> error occurred while executing this line: >> /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build.xml:240: Some >> example solrconfig.xml files do not refer to the correct luceneMatchVersion: >> 4.8 >> >> Total time: 58 minutes 12 seconds >> Build step 'Invoke Ant' marked build as failure >> Description set: Java: 32bit/jdk1.7.0_60-ea-b04 -client -XX:+UseParallelGC >> Archiving artifacts >> Recording test results >> 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 > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_60-ea-b04) - Build # 9410 - Still Failing!
Fail is: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build.xml:240: Some example solrconfig.xml files do not refer to the correct luceneMatchVersion: 4.8 - Mark http://about.me/markrmiller On Feb 18, 2014, at 12:00 PM, Policeman Jenkins Server wrote: > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9410/ > Java: 32bit/jdk1.7.0_60-ea-b04 -client -XX:+UseParallelGC > > All tests passed > > Build Log: > [...truncated 28008 lines...] > BUILD FAILED > /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:459: The following > error occurred while executing this line: > /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:64: The following > error occurred while executing this line: > /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build.xml:240: Some > example solrconfig.xml files do not refer to the correct luceneMatchVersion: > 4.8 > > Total time: 58 minutes 12 seconds > Build step 'Invoke Ant' marked build as failure > Description set: Java: 32bit/jdk1.7.0_60-ea-b04 -client -XX:+UseParallelGC > Archiving artifacts > Recording test results > 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 - 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 (32bit/jdk1.7.0_60-ea-b04) - Build # 9410 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9410/ Java: 32bit/jdk1.7.0_60-ea-b04 -client -XX:+UseParallelGC All tests passed Build Log: [...truncated 28008 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:459: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:64: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build.xml:240: Some example solrconfig.xml files do not refer to the correct luceneMatchVersion: 4.8 Total time: 58 minutes 12 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 32bit/jdk1.7.0_60-ea-b04 -client -XX:+UseParallelGC Archiving artifacts Recording test results 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
Re: Building an RC for Lucene / Solr 4.7
Depends on your situation. For me, I can run the tests and have them pass 6 times in a row. It it was otherwise, I would fix the issue, as I have for years now. When I see a test failing commonly for another dev, I’ll also often jump in and help fix the issue. As I have for years now. I’ll also work on tests in general pretty much off and on all the time. Not a lot of other guys doing it, so sometimes I’m more ahead or behind than other times. Should we ignore them? I don’t think so. We should keep fixing them. Removing them would remove critical coverage. The fails in general, are known - tracked in JIRA or logged by jenkins. I know if it’s something thats likely test related and I know if it’s something knew or something existing. If one of them annoys people, please jump in! I don’t know half the code or features I end up jumping in to help with. It’s also not necessarily the same tests or the same issues. I’ve fixed hundreds of issues. The code keeps changing, the environments and number of tests threads used and number of contributors keep changing. The rational is I have a *very* close, *very* informed view on the Solr tests. I read every fail, I run my own Jenkins server, I’m not some third party who wonders what these fails mean. Someone else might not be so informed. But unless they are helping to work on the tests, filing JIRA issues, adding to existing JIRA issues, or emailing the list for help, those people are pretty much on their own. They will have to wait until I can make every tests run in any env with any computing power without fail even as tests are added to and the code is changed for a very large distributed system. - Mark http://about.me/markrmiller On Feb 18, 2014, at 8:41 AM, Simon Willnauer wrote: > Hmm I am not sure if I understand that rational. Anyway wouldn't it be > better to @Ignore the tests and re-enable once they are fixed? I just > wonder how I can tell if I broke something in solr while working on > lucene and I am supposed to ignore failing tests? > > simon > > On Tue, Feb 18, 2014 at 2:36 PM, Mark Miller wrote: >> Because we run those tests locally and see the results on Jenkins and have >> an understanding what the issues are. Perhaps you don't, but the Solr people >> do. That's how we can release. >> >> That script shouldn't run the solr tests. >> >> - Mark >> >>> On Feb 18, 2014, at 8:28 AM, Simon Willnauer >>> wrote: >>> >>> it is not the smoke test - I ran this: >>> >>> python3.2 -u buildAndPushRelease.py -prepare -push simonw -sign >>> ECA39416 /home/simon/work/projects/lucene/lucene_solr_4_7/ 4.7.0 0 >>> >>> compared to this: >>> >>> python3.2 -u buildAndPushRelease.py -prepare -push simonw -sign >>> ECA39416 -smoke /tmp/lucene_solr_4_7_smoke >>> /home/simon/work/projects/lucene/lucene_solr_4_7/ 4.7.0 0 >>> >>> the first cmd runs the tests before it builds the release. I disabled >>> the tests by applying -smoke which skips the test run. This is still >>> freaking odd - how can I publish a release if the test don't pass a >>> single time out of 6 runs? >>> >>> simon >>> >>> On Tue, Feb 18, 2014 at 1:59 PM, Mark Miller wrote: Weird. The smoke script has always had solr tests disabled. Who enabled it? Those fails in general have JIRA issues as far as I remember. - Mark > On Feb 18, 2014, at 7:24 AM, Simon Willnauer > wrote: > > hey folks, > > I try to build an RC to checkout if everything goes alright and I now > spend 4 hours already without luck. The release script runs the solr > tests but they never pass. I tried it 6 times now and each time a > different test breaks. I am going to disable the solr test run in the > release script for now to actually run an RC build but this is very > concerning IMO. I tried to reproduce the failures each time but they > don't reproduce. Its mainly: > > org.apache.solr.cloud.OverseerTest.testShardAssignmentBigger > org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSearch > org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch > > any ideas? > > I mean looking at the CI builds those failures are no news are they? > > simon > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >> - >> To unsub
Re: Ensuring a test uses a codec supporting DocValues
: >just put this annotation at the class level:
: >
: >@SuppressCodecs("Lucene3x")
Be aware of subtleties though... Just because a codec supports docvalues
doesn't mean it supports *all* of the docvalue features you need.
Example: the cursor tests failed in extremeley weird non-reproducible ways
when using some of the Lucene 4 codecs because they created DocValue
fields w/o requiring a value in every doc, and that caused
non-deterministic behavior at query time. So in that case we had to
supress more then just Lucene3x.
-Hoss
http://www.lucidworks.com/
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5744) Solrj configuerd with BinaryRequestWriter throws NullpointerException if LangDetectLanguageIdentifierUpdateProcessorFactory is configuerd
Günther Ruck created SOLR-5744:
--
Summary: Solrj configuerd with BinaryRequestWriter throws
NullpointerException if LangDetectLanguageIdentifierUpdateProcessorFactory is
configuerd
Key: SOLR-5744
URL: https://issues.apache.org/jira/browse/SOLR-5744
Project: Solr
Issue Type: Bug
Components: clients - java
Affects Versions: 4.6.1
Environment: Windows 7 64 bit
Reporter: Günther Ruck
Priority: Minor
# create a read and an update server conection (solrj 4.6.1)
{{serverRead = new HttpSolrServer(solrUrl);}}
{{serverUpdate = new
ConcurrentUpdateSolrServer(solrUrl,serverRead.getHttpClient(),100,3);}}
# set binary request writer
{{serverRead.setRequestWriter(new BinaryRequestWriter());}}
{{serverUpdate.setRequestWriter(new BinaryRequestWriter());}}
# configure language detection in solrconfig.xml
{{}}
{{
[JENKINS-MAVEN] Lucene-Solr-Maven-4.x #593: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/593/ 2 tests failed. REGRESSION: org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSearch Error Message: No live SolrServers available to handle this request:[https://127.0.0.1:18844/collection1, https://127.0.0.1:60023/collection1] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[https://127.0.0.1:18844/collection1, https://127.0.0.1:60023/collection1] at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:495) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:199) at org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:302) at org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:635) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:90) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.queryServer(AbstractFullDistribZkTestBase.java:1427) at org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:563) at org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:545) at org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:524) at org.apache.solr.cloud.BasicDistributedZk2Test.brindDownShardIndexSomeDocsAndRecover(BasicDistributedZk2Test.java:290) at org.apache.solr.cloud.BasicDistributedZk2Test.doTest(BasicDistributedZk2Test.java:107) FAILED: org.apache.solr.client.solrj.impl.BasicHttpSolrServerTest.testConnectionRefused Error Message: null Stack Trace: java.lang.AssertionError: null at __randomizedtesting.SeedInfo.seed([BB33CDB6E2E10843:949A69A7356E4747]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.impl.BasicHttpSolrServerTest.testConnectionRefused(BasicHttpSolrServerTest.java:158) Build Log: [...truncated 52479 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/build.xml:482: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/build.xml:176: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/extra-targets.xml:77: Java returned: 1 Total time: 140 minutes 29 seconds Build step 'Invoke Ant' marked build as failure Recording test results 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
Re: Ensuring a test uses a codec supporting DocValues
Thanks Simon.
On 2/17/14, 4:50 AM, "Simon Willnauer" wrote:
>just put this annotation at the class level:
>
>@SuppressCodecs("Lucene3x")
>
>simon
>
>On Mon, Feb 17, 2014 at 4:56 AM, Smiley, David W.
>wrote:
>> I wrote a test that requires DocValues. It failed on me once because of
>>the
>> Codec randomization chose Lucene3x which doesn’t support DocValues.
>>What’s
>> the best way to adjust my test to assure this doesn’t happen?
>>
>> What I ended up doing was this:
>> indexWriterConfig.setCodec( _TestUtil.alwaysDocValuesFormat(new
>> Lucene45DocValuesFormat()));
>> But I don’t like that I hard-coded a particular format.
>> (FYI the source file is an abstract base test class: SpatialTestCase,
>>method
>> newIndexWriterConfig )
>>
>> Another approach might be to call:
>> assumeTrue(defaultCodecSupportsDocValues())
>> Although sometimes the test of course won’t be run at all instead of it
>> preferably forcing a compatible format.
>>
>> Thoughts?
>>
>> ~ David
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>For additional commands, e-mail: dev-h...@lucene.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: What's up w/ our github clone?
Yes, sorry forgot to update. I opened an issue for INFRA and they fixed it. Our mirror was locked because of a failed update or something. This is something we should be aware and monitor from time to time... Shai On Tue, Feb 18, 2014 at 4:49 PM, Yonik Seeley wrote: > Looks fixed now... > > -Yonik > http://heliosearch.org - native off-heap filters and fieldcache for solr > > > On Mon, Feb 17, 2014 at 10:37 AM, Mark Miller > wrote: > > Yup, something seems wrong. Supposed to be fast mirroring. We probably > have to reach out to infra if we want to know anything. > > > > - Mark > > > > http://about.me/markrmiller > > > > On Feb 17, 2014, at 8:10 AM, Shai Erera wrote: > > > >> Hi > >> > >> Does anybody know what's up w/ our github clone? According to this: > https://github.com/apache/lucene-solr, the last commit was 3 days ago... > >> > >> Shai > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: What's up w/ our github clone?
Looks fixed now... -Yonik http://heliosearch.org - native off-heap filters and fieldcache for solr On Mon, Feb 17, 2014 at 10:37 AM, Mark Miller wrote: > Yup, something seems wrong. Supposed to be fast mirroring. We probably have > to reach out to infra if we want to know anything. > > - Mark > > http://about.me/markrmiller > > On Feb 17, 2014, at 8:10 AM, Shai Erera wrote: > >> Hi >> >> Does anybody know what's up w/ our github clone? According to this: >> https://github.com/apache/lucene-solr, the last commit was 3 days ago... >> >> Shai > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Getting ready for Lucene/Solr 4.7
FYI, I build a RC from revision 1569289 and you can download it here [1] to run / test it use the smoke tester here [2] I also added a 4_7 only build to my jenkins to run tests on the release branch [3] [1] http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC0-rev1569289/ [2] python3.2 -u dev-tools/scripts/smokeTestRelease.py http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC0-rev1569289/ 1569289 4.7.0 /tmp/smoke_test_4_7 [3] http://builds.flonkings.com/job/Lucene-4.7_Release_Branch_Linux-Java6-64-test-only/ NOTE: this is not a RC that we vote on it just to catch stuff early! simon On Tue, Feb 18, 2014 at 11:55 AM, Simon Willnauer wrote: > before anybody jumps the gun - I am working on updateing the branch_4x > version wise (uwe take it easy one thing a time :) > > On Tue, Feb 18, 2014 at 11:50 AM, Simon Willnauer > wrote: >> Folks, >> >> I created a release branch for 4.7 >> https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_7 >> Please backport stuff that should go into the branch until tomorrow >> noon CEST. I'd appreciate if large changes could wait until 4.8 to >> not unnecessarily destabilize 4.8. I will build an RC0 today to check >> if something is broken, once I am done I will post the link here such >> that folks can take a look at it and maybe this time it doesn't take 4 >> RCs to get it done. >> >> >> thanks, >> >> simon >> >> >> On Sat, Feb 15, 2014 at 11:58 PM, Chris Hostetter >> wrote: >>> >>> : I am assuming the snapshot of the ref guide is also taken for the release, >>> : so does that mean changes in ref guide has to be made before the snapshot >>> : (of the release)? or is the ref guide snapshot taken seperately from the >>> : release snapshot? >>> >>> They are done independently since they come from seperate "sources of >>> truth" and as a result have seperate VOTE threads. We usually try to cut >>> an RC of the ref guide just after the first RC of the code -- but there's >>> no hard and fast rule aout timing. People *should* be docing things in >>> the ref guide as they commit to 4x, but if voting is in progress on a code >>> RC and folks want to keep working on the ref guide to polish things up >>> then (in my opinion) it's worth it to delay the ref guide release a few >>> days while doing so. >>> >>> >>> -Hoss >>> http://www.lucidworks.com/ >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Anshum Gupta as Lucene/Solr Committer!
Welcome Anshum! -Yonik http://heliosearch.org - native off-heap filters and fieldcache for solr On Sun, Feb 16, 2014 at 10:14 PM, Anshum Gupta wrote: > Thanks Mark. > > I spent most of my life in New Delhi, India other than short stints in > different parts of the country (including living in a beach house on a > tropical island for 3 years when I was young). After spending the last 3 > years in Bangalore, I just relocated to San Francisco to be at the > LucidWorks office in the Bay Area. Prior to this I've been a part of the > search teams at A9 (CloudSearch), Cleartrip.com and Naukri.com where I was > involved in designing and developing search and recommendation engines. > > These days, I love contributing stuff to Solr, primarily around SolrCloud > and hope to continue to be at least as active towards it. > > In my free time I love photography, traveling, eating out and drinking my > beer. > > > On Sun, Feb 16, 2014 at 2:33 PM, Mark Miller wrote: >> >> Hey everybody! >> >> The Lucene PMC is happy to welcome Anshum Gupta as a committer on the >> Lucene / Solr project. Anshum has contributed to a number of issues for the >> project, especially around SolrCloud. >> >> Welcome Anshum! >> >> It's tradition to introduce yourself with a short bio :) >> >> -- >> - Mark >> >> http://about.me/markrmiller > > > > > -- > > Anshum Gupta > http://www.anshumgupta.net - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4479) TermVectorComponent NPE when running Solr Cloud
[ https://issues.apache.org/jira/browse/SOLR-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904079#comment-13904079 ] Raúl Grande commented on SOLR-4479: --- Thanks a lot! It worked fine with that param! > TermVectorComponent NPE when running Solr Cloud > --- > > Key: SOLR-4479 > URL: https://issues.apache.org/jira/browse/SOLR-4479 > Project: Solr > Issue Type: Bug >Affects Versions: 4.1 >Reporter: Vitali Kviatkouski > > When running Solr Cloud (just simply 2 shards - as described in wiki), got NPE > java.lang.NullPointerException > at > org.apache.solr.handler.component.TermVectorComponent.finishStage(TermVectorComponent.java:437) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:317) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at > org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.handleRequest(RequestHandlers.java:242) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:448) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:269) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1307) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:453) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:560) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1072) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:382) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1006) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) > . Skipped > To reproduce, follow the guide in wiki > (http://wiki.apache.org/solr/SolrCloud), add some documents and then request > http://localhost:8983/solr/collection1/tvrh?q=*%3A* > If I include term search vector component in search handler, I get (on second > shard): > SEVERE: null:java.lang.NullPointerException > at > org.apache.solr.handler.component.TermVectorComponent.process(TermVectorComponent.java:321) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:206) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1699) -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5609) Don't let cores create slices/named replicas
[
https://issues.apache.org/jira/browse/SOLR-5609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-5609:
-
Attachment: SOLR-5609_5130.patch
more testcases
re-enabled the DeleteInactiveReplica test which was Ignored earlier
> Don't let cores create slices/named replicas
>
>
> Key: SOLR-5609
> URL: https://issues.apache.org/jira/browse/SOLR-5609
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 4.7, 5.0
>
> Attachments: SOLR-5609_5130.patch, SOLR-5609_5130.patch
>
>
> In SolrCloud, it is possible for a core to come up in any node , and register
> itself with an arbitrary slice/coreNodeName. This is a legacy requirement and
> we would like to make it only possible for Overseer to initiate creation of
> slice/replicas
> We plan to introduce cluster level properties at the top level
> /cluster-props.json
> {code:javascript}
> {
> "noSliceOrReplicaByCores":true"
> }
> {code}
> If this property is set to true, cores won't be able to send STATE commands
> with unknown slice/coreNodeName . Those commands will fail at Overseer. This
> is useful for SOLR-5310 / SOLR-5311 where a core/replica is deleted by a
> command and it comes up later and tries to create a replica/slice
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Refactoring code through Github pull requests
Unfortunately i can't find a way to make it explicitly show it will do a svn rename, but it does do it, so that makes this solution not very useful either i guess. --- git --- [master svntest] % git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) renamed:test -> moo [master svntest] % git commit -m "woof" [master 6e2c0b3] woof 1 file changed, 0 insertions(+), 0 deletions(-) rename test => moo (100%) [master svntest] % git svn dcommit Committing to https://.../trunk ... R test => moo Committed r3 D test A moo W: -empty_dir: trunk/test r3 = 0ae41e170cf7d07ec3679eb85d55c068617e0a66 (refs/remotes/trunk) - svn --- [trunk] % svn log --diff -v r3 | thomas | 2014-02-18 14:32:07 +0100 (Tue, 18 Feb 2014) | 1 line Changed paths: A /trunk/moo (from /trunk/test:2) D /trunk/test woof On Tue, Feb 18, 2014 at 2:22 PM, Benson Margulies wrote: > Let me be specific. If I am sitting in a git clone that has been set > up with git svn, and I use git apply to apply the output of git > format-patch, if I dcommit, is the autodetection going to result in an > svn mv? > > > On Tue, Feb 18, 2014 at 8:20 AM, Thomas Matthijs wrote: > > Git does not track renames, but can show/detect it, the magic options > are -C > > and -M for diff/show etc > > > > > > > > On Tue, Feb 18, 2014 at 2:16 PM, Benson Margulies > > > wrote: > >> > >> I tried using git apply on a patch (from github's .patch URL) that > >> included a rename. no sign of a rename; just a delete and an add. I > >> feel like I'm missing something. > >> > >> On Tue, Feb 18, 2014 at 7:36 AM, Shai Erera wrote: > >> > The problem I see is that if you generate a patch using 'git diff', it > >> > applies just fine to svn (if you generate it w/ --no-prefix) without > any > >> > warnings about missing files due the rename. Wanted to warn the > >> > community > >> > about it, so that when committers assign themselves to PRs, they > review > >> > the > >> > patch closer and detect manually if a rename as happened. > >> > > >> > We could decide that renames are done in a separate commit, but it's > not > >> > always possible. > >> > > >> > So mainly, FYI. > >> > > >> > And if someone has an idea for a script/ant-target we could write to > >> > detect > >> > this case, that would be awesome. > >> > > >> > Shai > >> > > >> > > >> > On Tue, Feb 18, 2014 at 2:31 PM, Thomas Matthijs > >> > wrote: > >> >> > >> >> Github pull requests can be treated as individual cherry picked patch > >> >> sets > >> >> really, not branch merges ? (ie rebased) from there on out you're in > >> >> svn > >> >> land. No need to "merge". > >> >> > >> >> But indeed, it tries to detect it based on the file content, and > >> >> doesn't > >> >> work 100% as manual svn moves. > >> >> > >> >> > >> >> > >> >> On Tue, Feb 18, 2014 at 1:27 PM, Benson Margulies > >> >> > >> >> wrote: > >> >>> > >> >>> Well, git-svn has a heap of warnings against using it for merges; > it's > >> >>> also a really bad idea when renaming a whole package, as it does it > >> >>> one-file-at-a-time. > >> >>> > >> >>> If you have a workflow that works with the ASF mirror and svn, > please > >> >>> write it up on the Wiki! > >> >>> > >> >>> > >> >>> On Tue, Feb 18, 2014 at 7:23 AM, Thomas Matthijs > >> >>> wrote: > >> >>> > > >> >>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera > >> >>> > wrote: > >> >>> >> > >> >>> >> > >> >>> >> Second, has anyone perhaps found a way to overcome that issue? I > >> >>> >> thought > >> >>> >> about maybe writing a script to detect that, looking at the patch > >> >>> >> file, but > >> >>> >> it seems hard to detect that the deleted Foo is the new Bar. If > >> >>> >> it's > >> >>> >> just > >> >>> >> rename, maybe, but if part of the rename the code changed a lot > ... > >> >>> >> it > >> >>> >> becomes harder. > >> >>> > > >> >>> > > >> >>> > Probably not the answer you want but > >> >>> > If you use the git-svn bridge it should detect the rename and > commit > >> >>> > it > >> >>> > in > >> >>> > svn as a move/copy > >> >>> > > >> >>> > https://www.kernel.org/pub/software/scm/git/docs/git-svn.html > >> >>> > >> >>> > - > >> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> >>> For additional commands, e-mail: dev-h...@lucene.apache.org > >> >>> > >> >> > >> > > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Commented] (SOLR-5709) Highlighting grouped duplicate docs from different shards with group.limit > 1 throws ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/SOLR-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904063#comment-13904063
]
Steve Rowe commented on SOLR-5709:
--
Rob,
I see what you mean: ngroups should be the same as the number of groups. This
problem still happens when I don't request highlighting, so it appears to be a
problem with grouping only.
This may be related to a known issue - from the {{group.ngroups}} description
on [http://wiki.apache.org/solr/FieldCollapsing]:
{quote}
WARNING: If this parameter is set to true on a sharded environment, all the
documents that belong to the same group have to be located in the same shard,
otherwise the count will be incorrect. If you are using SolrCloud, consider
using "custom hashing"
{quote}
I'll do some more testing.
> Highlighting grouped duplicate docs from different shards with group.limit >
> 1 throws ArrayIndexOutOfBoundsException
>
>
> Key: SOLR-5709
> URL: https://issues.apache.org/jira/browse/SOLR-5709
> Project: Solr
> Issue Type: Bug
> Components: highlighter
>Affects Versions: 4.3, 4.4, 4.5, 4.6, 5.0
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 4.7, 5.0
>
> Attachments: SOLR-5709.patch
>
>
> In a sharded (non-SolrCloud) deployment, if you index a document with the
> same unique key value into more than one shard, and then try to highlight
> grouped docs with more than one doc per group, where the grouped docs contain
> at least one duplicate doc pair, you get an AIOOBE.
> Here's the stack trace I got from such a situation, with 1 doc indexed into
> each shard in a 2-shard index, with {{group.limit=2}}:
> {noformat}
> ERROR null:java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.apache.solr.handler.component.HighlightComponent.finishStage(HighlightComponent.java:185)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:328)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1916)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:758)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:412)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:202)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> at
> org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:136)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at
> org.eclipse.jetty.server.handler.GzipHandler.handle(GzipHandler.java:301)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1077)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:368)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
> at
> org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.ja
[jira] [Commented] (SOLR-4479) TermVectorComponent NPE when running Solr Cloud
[ https://issues.apache.org/jira/browse/SOLR-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904053#comment-13904053 ] Stanislav Sandalnikov commented on SOLR-4479: - Hi Raul, In our case this was solved by adding shards.qt=/tvrh to the query. > TermVectorComponent NPE when running Solr Cloud > --- > > Key: SOLR-4479 > URL: https://issues.apache.org/jira/browse/SOLR-4479 > Project: Solr > Issue Type: Bug >Affects Versions: 4.1 >Reporter: Vitali Kviatkouski > > When running Solr Cloud (just simply 2 shards - as described in wiki), got NPE > java.lang.NullPointerException > at > org.apache.solr.handler.component.TermVectorComponent.finishStage(TermVectorComponent.java:437) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:317) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at > org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.handleRequest(RequestHandlers.java:242) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:448) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:269) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1307) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:453) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:560) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1072) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:382) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1006) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) > . Skipped > To reproduce, follow the guide in wiki > (http://wiki.apache.org/solr/SolrCloud), add some documents and then request > http://localhost:8983/solr/collection1/tvrh?q=*%3A* > If I include term search vector component in search handler, I get (on second > shard): > SEVERE: null:java.lang.NullPointerException > at > org.apache.solr.handler.component.TermVectorComponent.process(TermVectorComponent.java:321) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:206) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1699) -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Building an RC for Lucene / Solr 4.7
Hmm I am not sure if I understand that rational. Anyway wouldn't it be better to @Ignore the tests and re-enable once they are fixed? I just wonder how I can tell if I broke something in solr while working on lucene and I am supposed to ignore failing tests? simon On Tue, Feb 18, 2014 at 2:36 PM, Mark Miller wrote: > Because we run those tests locally and see the results on Jenkins and have an > understanding what the issues are. Perhaps you don't, but the Solr people do. > That's how we can release. > > That script shouldn't run the solr tests. > > - Mark > >> On Feb 18, 2014, at 8:28 AM, Simon Willnauer >> wrote: >> >> it is not the smoke test - I ran this: >> >> python3.2 -u buildAndPushRelease.py -prepare -push simonw -sign >> ECA39416 /home/simon/work/projects/lucene/lucene_solr_4_7/ 4.7.0 0 >> >> compared to this: >> >> python3.2 -u buildAndPushRelease.py -prepare -push simonw -sign >> ECA39416 -smoke /tmp/lucene_solr_4_7_smoke >> /home/simon/work/projects/lucene/lucene_solr_4_7/ 4.7.0 0 >> >> the first cmd runs the tests before it builds the release. I disabled >> the tests by applying -smoke which skips the test run. This is still >> freaking odd - how can I publish a release if the test don't pass a >> single time out of 6 runs? >> >> simon >> >> >>> On Tue, Feb 18, 2014 at 1:59 PM, Mark Miller wrote: >>> Weird. The smoke script has always had solr tests disabled. Who enabled it? >>> Those fails in general have JIRA issues as far as I remember. >>> >>> - Mark >>> On Feb 18, 2014, at 7:24 AM, Simon Willnauer wrote: hey folks, I try to build an RC to checkout if everything goes alright and I now spend 4 hours already without luck. The release script runs the solr tests but they never pass. I tried it 6 times now and each time a different test breaks. I am going to disable the solr test run in the release script for now to actually run an RC build but this is very concerning IMO. I tried to reproduce the failures each time but they don't reproduce. Its mainly: org.apache.solr.cloud.OverseerTest.testShardAssignmentBigger org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSearch org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch any ideas? I mean looking at the CI builds those failures are no news are they? simon - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Building an RC for Lucene / Solr 4.7
Because we run those tests locally and see the results on Jenkins and have an understanding what the issues are. Perhaps you don't, but the Solr people do. That's how we can release. That script shouldn't run the solr tests. - Mark > On Feb 18, 2014, at 8:28 AM, Simon Willnauer > wrote: > > it is not the smoke test - I ran this: > > python3.2 -u buildAndPushRelease.py -prepare -push simonw -sign > ECA39416 /home/simon/work/projects/lucene/lucene_solr_4_7/ 4.7.0 0 > > compared to this: > > python3.2 -u buildAndPushRelease.py -prepare -push simonw -sign > ECA39416 -smoke /tmp/lucene_solr_4_7_smoke > /home/simon/work/projects/lucene/lucene_solr_4_7/ 4.7.0 0 > > the first cmd runs the tests before it builds the release. I disabled > the tests by applying -smoke which skips the test run. This is still > freaking odd - how can I publish a release if the test don't pass a > single time out of 6 runs? > > simon > > >> On Tue, Feb 18, 2014 at 1:59 PM, Mark Miller wrote: >> Weird. The smoke script has always had solr tests disabled. Who enabled it? >> Those fails in general have JIRA issues as far as I remember. >> >> - Mark >> >>> On Feb 18, 2014, at 7:24 AM, Simon Willnauer >>> wrote: >>> >>> hey folks, >>> >>> I try to build an RC to checkout if everything goes alright and I now >>> spend 4 hours already without luck. The release script runs the solr >>> tests but they never pass. I tried it 6 times now and each time a >>> different test breaks. I am going to disable the solr test run in the >>> release script for now to actually run an RC build but this is very >>> concerning IMO. I tried to reproduce the failures each time but they >>> don't reproduce. Its mainly: >>> >>> org.apache.solr.cloud.OverseerTest.testShardAssignmentBigger >>> org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSearch >>> org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch >>> >>> any ideas? >>> >>> I mean looking at the CI builds those failures are no news are they? >>> >>> simon >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4479) TermVectorComponent NPE when running Solr Cloud
[ https://issues.apache.org/jira/browse/SOLR-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904036#comment-13904036 ] Raúl Grande commented on SOLR-4479: --- Hi, We have the same problem using SolrCloud v. 4.6.1 Any solution to this so far? > TermVectorComponent NPE when running Solr Cloud > --- > > Key: SOLR-4479 > URL: https://issues.apache.org/jira/browse/SOLR-4479 > Project: Solr > Issue Type: Bug >Affects Versions: 4.1 >Reporter: Vitali Kviatkouski > > When running Solr Cloud (just simply 2 shards - as described in wiki), got NPE > java.lang.NullPointerException > at > org.apache.solr.handler.component.TermVectorComponent.finishStage(TermVectorComponent.java:437) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:317) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at > org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.handleRequest(RequestHandlers.java:242) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:448) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:269) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1307) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:453) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:560) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1072) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:382) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1006) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) > . Skipped > To reproduce, follow the guide in wiki > (http://wiki.apache.org/solr/SolrCloud), add some documents and then request > http://localhost:8983/solr/collection1/tvrh?q=*%3A* > If I include term search vector component in search handler, I get (on second > shard): > SEVERE: null:java.lang.NullPointerException > at > org.apache.solr.handler.component.TermVectorComponent.process(TermVectorComponent.java:321) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:206) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1699) -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Building an RC for Lucene / Solr 4.7
it is not the smoke test - I ran this: python3.2 -u buildAndPushRelease.py -prepare -push simonw -sign ECA39416 /home/simon/work/projects/lucene/lucene_solr_4_7/ 4.7.0 0 compared to this: python3.2 -u buildAndPushRelease.py -prepare -push simonw -sign ECA39416 -smoke /tmp/lucene_solr_4_7_smoke /home/simon/work/projects/lucene/lucene_solr_4_7/ 4.7.0 0 the first cmd runs the tests before it builds the release. I disabled the tests by applying -smoke which skips the test run. This is still freaking odd - how can I publish a release if the test don't pass a single time out of 6 runs? simon On Tue, Feb 18, 2014 at 1:59 PM, Mark Miller wrote: > Weird. The smoke script has always had solr tests disabled. Who enabled it? > Those fails in general have JIRA issues as far as I remember. > > - Mark > >> On Feb 18, 2014, at 7:24 AM, Simon Willnauer >> wrote: >> >> hey folks, >> >> I try to build an RC to checkout if everything goes alright and I now >> spend 4 hours already without luck. The release script runs the solr >> tests but they never pass. I tried it 6 times now and each time a >> different test breaks. I am going to disable the solr test run in the >> release script for now to actually run an RC build but this is very >> concerning IMO. I tried to reproduce the failures each time but they >> don't reproduce. Its mainly: >> >> org.apache.solr.cloud.OverseerTest.testShardAssignmentBigger >> org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSearch >> org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch >> >> any ideas? >> >> I mean looking at the CI builds those failures are no news are they? >> >> simon >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Refactoring code through Github pull requests
On Tue, Feb 18, 2014 at 8:24 AM, Uwe Schindler wrote: > Hi Beson, > > The problem is that by this approach the rename gets a delete and add with > full file content, versus a native SVN rename (which is a svn cp followed by > a delete of the original file). By this the history is lost, because for SVN > you patch looks like a complete removal of the original file and a later > addition of a totally new file. With a native SVN rename, you would see > changes to the old file also in the history of the new file. You would even > see the file content changes of the commit renaming the file in svn's diff. > Now you cannot see the differences between old and new file, because its just > a big blob removed/added. Uwe, that's precisely what I'm chasing. I thought, some years ago, that I'd seen git svn do a real svn mv, but this morning's experiments do not lead me to believe that this can be arranged with the tools at hand. > > Uwe > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > >> -Original Message- >> From: Benson Margulies [mailto:bimargul...@gmail.com] >> Sent: Tuesday, February 18, 2014 2:17 PM >> To: dev@lucene.apache.org >> Subject: Re: Refactoring code through Github pull requests >> >> I tried using git apply on a patch (from github's .patch URL) that included >> a >> rename. no sign of a rename; just a delete and an add. I feel like I'm >> missing >> something. >> >> On Tue, Feb 18, 2014 at 7:36 AM, Shai Erera wrote: >> > The problem I see is that if you generate a patch using 'git diff', it >> > applies just fine to svn (if you generate it w/ --no-prefix) without >> > any warnings about missing files due the rename. Wanted to warn the >> > community about it, so that when committers assign themselves to PRs, >> > they review the patch closer and detect manually if a rename as happened. >> > >> > We could decide that renames are done in a separate commit, but it's >> > not always possible. >> > >> > So mainly, FYI. >> > >> > And if someone has an idea for a script/ant-target we could write to >> > detect this case, that would be awesome. >> > >> > Shai >> > >> > >> > On Tue, Feb 18, 2014 at 2:31 PM, Thomas Matthijs >> wrote: >> >> >> >> Github pull requests can be treated as individual cherry picked patch >> >> sets really, not branch merges ? (ie rebased) from there on out >> >> you're in svn land. No need to "merge". >> >> >> >> But indeed, it tries to detect it based on the file content, and >> >> doesn't work 100% as manual svn moves. >> >> >> >> >> >> >> >> On Tue, Feb 18, 2014 at 1:27 PM, Benson Margulies >> >> >> >> wrote: >> >>> >> >>> Well, git-svn has a heap of warnings against using it for merges; >> >>> it's also a really bad idea when renaming a whole package, as it >> >>> does it one-file-at-a-time. >> >>> >> >>> If you have a workflow that works with the ASF mirror and svn, >> >>> please write it up on the Wiki! >> >>> >> >>> >> >>> On Tue, Feb 18, 2014 at 7:23 AM, Thomas Matthijs >> >>> wrote: >> >>> > >> >>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera >> wrote: >> >>> >> >> >>> >> >> >>> >> Second, has anyone perhaps found a way to overcome that issue? I >> >>> >> thought about maybe writing a script to detect that, looking at >> >>> >> the patch file, but it seems hard to detect that the deleted Foo >> >>> >> is the new Bar. If it's just rename, maybe, but if part of the >> >>> >> rename the code changed a lot ... it becomes harder. >> >>> > >> >>> > >> >>> > Probably not the answer you want but If you use the git-svn bridge >> >>> > it should detect the rename and commit it in svn as a move/copy >> >>> > >> >>> > https://www.kernel.org/pub/software/scm/git/docs/git-svn.html >> >>> >> >>> >> >>> - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For >> >>> additional commands, e-mail: dev-h...@lucene.apache.org >> >>> >> >> >> > >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional >> commands, e-mail: dev-h...@lucene.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Refactoring code through Github pull requests
Oh sorry, you were in GIT world. My response does not apply for you :-) Regards, Uwe (GIT ignorant) - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Tuesday, February 18, 2014 2:24 PM > To: dev@lucene.apache.org > Subject: RE: Refactoring code through Github pull requests > > Hi Beson, > > The problem is that by this approach the rename gets a delete and add with > full file content, versus a native SVN rename (which is a svn cp followed by a > delete of the original file). By this the history is lost, because for SVN you > patch looks like a complete removal of the original file and a later addition > of > a totally new file. With a native SVN rename, you would see changes to the > old file also in the history of the new file. You would even see the file > content > changes of the commit renaming the file in svn's diff. Now you cannot see > the differences between old and new file, because its just a big blob > removed/added. > > Uwe > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > > -Original Message- > > From: Benson Margulies [mailto:bimargul...@gmail.com] > > Sent: Tuesday, February 18, 2014 2:17 PM > > To: dev@lucene.apache.org > > Subject: Re: Refactoring code through Github pull requests > > > > I tried using git apply on a patch (from github's .patch URL) that > > included a rename. no sign of a rename; just a delete and an add. I > > feel like I'm missing something. > > > > On Tue, Feb 18, 2014 at 7:36 AM, Shai Erera wrote: > > > The problem I see is that if you generate a patch using 'git diff', > > > it applies just fine to svn (if you generate it w/ --no-prefix) > > > without any warnings about missing files due the rename. Wanted to > > > warn the community about it, so that when committers assign > > > themselves to PRs, they review the patch closer and detect manually if a > rename as happened. > > > > > > We could decide that renames are done in a separate commit, but it's > > > not always possible. > > > > > > So mainly, FYI. > > > > > > And if someone has an idea for a script/ant-target we could write to > > > detect this case, that would be awesome. > > > > > > Shai > > > > > > > > > On Tue, Feb 18, 2014 at 2:31 PM, Thomas Matthijs > > wrote: > > >> > > >> Github pull requests can be treated as individual cherry picked > > >> patch sets really, not branch merges ? (ie rebased) from there on > > >> out you're in svn land. No need to "merge". > > >> > > >> But indeed, it tries to detect it based on the file content, and > > >> doesn't work 100% as manual svn moves. > > >> > > >> > > >> > > >> On Tue, Feb 18, 2014 at 1:27 PM, Benson Margulies > > >> > > >> wrote: > > >>> > > >>> Well, git-svn has a heap of warnings against using it for merges; > > >>> it's also a really bad idea when renaming a whole package, as it > > >>> does it one-file-at-a-time. > > >>> > > >>> If you have a workflow that works with the ASF mirror and svn, > > >>> please write it up on the Wiki! > > >>> > > >>> > > >>> On Tue, Feb 18, 2014 at 7:23 AM, Thomas Matthijs > > >>> > > >>> wrote: > > >>> > > > >>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera > > wrote: > > >>> >> > > >>> >> > > >>> >> Second, has anyone perhaps found a way to overcome that issue? > > >>> >> I thought about maybe writing a script to detect that, looking > > >>> >> at the patch file, but it seems hard to detect that the deleted > > >>> >> Foo is the new Bar. If it's just rename, maybe, but if part of > > >>> >> the rename the code changed a lot ... it becomes harder. > > >>> > > > >>> > > > >>> > Probably not the answer you want but If you use the git-svn > > >>> > bridge it should detect the rename and commit it in svn as a > > >>> > move/copy > > >>> > > > >>> > https://www.kernel.org/pub/software/scm/git/docs/git-svn.html > > >>> > > >>> -- > > >>> -- > > >>> - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For > > >>> additional commands, e-mail: dev-h...@lucene.apache.org > > >>> > > >> > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For > > additional commands, e-mail: dev-h...@lucene.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Refactoring code through Github pull requests
Hi Beson, The problem is that by this approach the rename gets a delete and add with full file content, versus a native SVN rename (which is a svn cp followed by a delete of the original file). By this the history is lost, because for SVN you patch looks like a complete removal of the original file and a later addition of a totally new file. With a native SVN rename, you would see changes to the old file also in the history of the new file. You would even see the file content changes of the commit renaming the file in svn's diff. Now you cannot see the differences between old and new file, because its just a big blob removed/added. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Benson Margulies [mailto:bimargul...@gmail.com] > Sent: Tuesday, February 18, 2014 2:17 PM > To: dev@lucene.apache.org > Subject: Re: Refactoring code through Github pull requests > > I tried using git apply on a patch (from github's .patch URL) that included a > rename. no sign of a rename; just a delete and an add. I feel like I'm missing > something. > > On Tue, Feb 18, 2014 at 7:36 AM, Shai Erera wrote: > > The problem I see is that if you generate a patch using 'git diff', it > > applies just fine to svn (if you generate it w/ --no-prefix) without > > any warnings about missing files due the rename. Wanted to warn the > > community about it, so that when committers assign themselves to PRs, > > they review the patch closer and detect manually if a rename as happened. > > > > We could decide that renames are done in a separate commit, but it's > > not always possible. > > > > So mainly, FYI. > > > > And if someone has an idea for a script/ant-target we could write to > > detect this case, that would be awesome. > > > > Shai > > > > > > On Tue, Feb 18, 2014 at 2:31 PM, Thomas Matthijs > wrote: > >> > >> Github pull requests can be treated as individual cherry picked patch > >> sets really, not branch merges ? (ie rebased) from there on out > >> you're in svn land. No need to "merge". > >> > >> But indeed, it tries to detect it based on the file content, and > >> doesn't work 100% as manual svn moves. > >> > >> > >> > >> On Tue, Feb 18, 2014 at 1:27 PM, Benson Margulies > >> > >> wrote: > >>> > >>> Well, git-svn has a heap of warnings against using it for merges; > >>> it's also a really bad idea when renaming a whole package, as it > >>> does it one-file-at-a-time. > >>> > >>> If you have a workflow that works with the ASF mirror and svn, > >>> please write it up on the Wiki! > >>> > >>> > >>> On Tue, Feb 18, 2014 at 7:23 AM, Thomas Matthijs > >>> wrote: > >>> > > >>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera > wrote: > >>> >> > >>> >> > >>> >> Second, has anyone perhaps found a way to overcome that issue? I > >>> >> thought about maybe writing a script to detect that, looking at > >>> >> the patch file, but it seems hard to detect that the deleted Foo > >>> >> is the new Bar. If it's just rename, maybe, but if part of the > >>> >> rename the code changed a lot ... it becomes harder. > >>> > > >>> > > >>> > Probably not the answer you want but If you use the git-svn bridge > >>> > it should detect the rename and commit it in svn as a move/copy > >>> > > >>> > https://www.kernel.org/pub/software/scm/git/docs/git-svn.html > >>> > >>> > >>> - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For > >>> additional commands, e-mail: dev-h...@lucene.apache.org > >>> > >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Refactoring code through Github pull requests
Let me be specific. If I am sitting in a git clone that has been set up with git svn, and I use git apply to apply the output of git format-patch, if I dcommit, is the autodetection going to result in an svn mv? On Tue, Feb 18, 2014 at 8:20 AM, Thomas Matthijs wrote: > Git does not track renames, but can show/detect it, the magic options are -C > and -M for diff/show etc > > > > On Tue, Feb 18, 2014 at 2:16 PM, Benson Margulies > wrote: >> >> I tried using git apply on a patch (from github's .patch URL) that >> included a rename. no sign of a rename; just a delete and an add. I >> feel like I'm missing something. >> >> On Tue, Feb 18, 2014 at 7:36 AM, Shai Erera wrote: >> > The problem I see is that if you generate a patch using 'git diff', it >> > applies just fine to svn (if you generate it w/ --no-prefix) without any >> > warnings about missing files due the rename. Wanted to warn the >> > community >> > about it, so that when committers assign themselves to PRs, they review >> > the >> > patch closer and detect manually if a rename as happened. >> > >> > We could decide that renames are done in a separate commit, but it's not >> > always possible. >> > >> > So mainly, FYI. >> > >> > And if someone has an idea for a script/ant-target we could write to >> > detect >> > this case, that would be awesome. >> > >> > Shai >> > >> > >> > On Tue, Feb 18, 2014 at 2:31 PM, Thomas Matthijs >> > wrote: >> >> >> >> Github pull requests can be treated as individual cherry picked patch >> >> sets >> >> really, not branch merges ? (ie rebased) from there on out you're in >> >> svn >> >> land. No need to "merge". >> >> >> >> But indeed, it tries to detect it based on the file content, and >> >> doesn't >> >> work 100% as manual svn moves. >> >> >> >> >> >> >> >> On Tue, Feb 18, 2014 at 1:27 PM, Benson Margulies >> >> >> >> wrote: >> >>> >> >>> Well, git-svn has a heap of warnings against using it for merges; it's >> >>> also a really bad idea when renaming a whole package, as it does it >> >>> one-file-at-a-time. >> >>> >> >>> If you have a workflow that works with the ASF mirror and svn, please >> >>> write it up on the Wiki! >> >>> >> >>> >> >>> On Tue, Feb 18, 2014 at 7:23 AM, Thomas Matthijs >> >>> wrote: >> >>> > >> >>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera >> >>> > wrote: >> >>> >> >> >>> >> >> >>> >> Second, has anyone perhaps found a way to overcome that issue? I >> >>> >> thought >> >>> >> about maybe writing a script to detect that, looking at the patch >> >>> >> file, but >> >>> >> it seems hard to detect that the deleted Foo is the new Bar. If >> >>> >> it's >> >>> >> just >> >>> >> rename, maybe, but if part of the rename the code changed a lot ... >> >>> >> it >> >>> >> becomes harder. >> >>> > >> >>> > >> >>> > Probably not the answer you want but >> >>> > If you use the git-svn bridge it should detect the rename and commit >> >>> > it >> >>> > in >> >>> > svn as a move/copy >> >>> > >> >>> > https://www.kernel.org/pub/software/scm/git/docs/git-svn.html >> >>> >> >>> - >> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >>> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>> >> >> >> > >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Refactoring code through Github pull requests
Git does not track renames, but can show/detect it, the magic options are -C and -M for diff/show etc On Tue, Feb 18, 2014 at 2:16 PM, Benson Margulies wrote: > I tried using git apply on a patch (from github's .patch URL) that > included a rename. no sign of a rename; just a delete and an add. I > feel like I'm missing something. > > On Tue, Feb 18, 2014 at 7:36 AM, Shai Erera wrote: > > The problem I see is that if you generate a patch using 'git diff', it > > applies just fine to svn (if you generate it w/ --no-prefix) without any > > warnings about missing files due the rename. Wanted to warn the community > > about it, so that when committers assign themselves to PRs, they review > the > > patch closer and detect manually if a rename as happened. > > > > We could decide that renames are done in a separate commit, but it's not > > always possible. > > > > So mainly, FYI. > > > > And if someone has an idea for a script/ant-target we could write to > detect > > this case, that would be awesome. > > > > Shai > > > > > > On Tue, Feb 18, 2014 at 2:31 PM, Thomas Matthijs > wrote: > >> > >> Github pull requests can be treated as individual cherry picked patch > sets > >> really, not branch merges ? (ie rebased) from there on out you're in svn > >> land. No need to "merge". > >> > >> But indeed, it tries to detect it based on the file content, and doesn't > >> work 100% as manual svn moves. > >> > >> > >> > >> On Tue, Feb 18, 2014 at 1:27 PM, Benson Margulies < > bimargul...@gmail.com> > >> wrote: > >>> > >>> Well, git-svn has a heap of warnings against using it for merges; it's > >>> also a really bad idea when renaming a whole package, as it does it > >>> one-file-at-a-time. > >>> > >>> If you have a workflow that works with the ASF mirror and svn, please > >>> write it up on the Wiki! > >>> > >>> > >>> On Tue, Feb 18, 2014 at 7:23 AM, Thomas Matthijs > >>> wrote: > >>> > > >>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera > wrote: > >>> >> > >>> >> > >>> >> Second, has anyone perhaps found a way to overcome that issue? I > >>> >> thought > >>> >> about maybe writing a script to detect that, looking at the patch > >>> >> file, but > >>> >> it seems hard to detect that the deleted Foo is the new Bar. If it's > >>> >> just > >>> >> rename, maybe, but if part of the rename the code changed a lot ... > it > >>> >> becomes harder. > >>> > > >>> > > >>> > Probably not the answer you want but > >>> > If you use the git-svn bridge it should detect the rename and commit > it > >>> > in > >>> > svn as a move/copy > >>> > > >>> > https://www.kernel.org/pub/software/scm/git/docs/git-svn.html > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>> For additional commands, e-mail: dev-h...@lucene.apache.org > >>> > >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Refactoring code through Github pull requests
I tried using git apply on a patch (from github's .patch URL) that included a rename. no sign of a rename; just a delete and an add. I feel like I'm missing something. On Tue, Feb 18, 2014 at 7:36 AM, Shai Erera wrote: > The problem I see is that if you generate a patch using 'git diff', it > applies just fine to svn (if you generate it w/ --no-prefix) without any > warnings about missing files due the rename. Wanted to warn the community > about it, so that when committers assign themselves to PRs, they review the > patch closer and detect manually if a rename as happened. > > We could decide that renames are done in a separate commit, but it's not > always possible. > > So mainly, FYI. > > And if someone has an idea for a script/ant-target we could write to detect > this case, that would be awesome. > > Shai > > > On Tue, Feb 18, 2014 at 2:31 PM, Thomas Matthijs wrote: >> >> Github pull requests can be treated as individual cherry picked patch sets >> really, not branch merges ? (ie rebased) from there on out you're in svn >> land. No need to "merge". >> >> But indeed, it tries to detect it based on the file content, and doesn't >> work 100% as manual svn moves. >> >> >> >> On Tue, Feb 18, 2014 at 1:27 PM, Benson Margulies >> wrote: >>> >>> Well, git-svn has a heap of warnings against using it for merges; it's >>> also a really bad idea when renaming a whole package, as it does it >>> one-file-at-a-time. >>> >>> If you have a workflow that works with the ASF mirror and svn, please >>> write it up on the Wiki! >>> >>> >>> On Tue, Feb 18, 2014 at 7:23 AM, Thomas Matthijs >>> wrote: >>> > >>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera wrote: >>> >> >>> >> >>> >> Second, has anyone perhaps found a way to overcome that issue? I >>> >> thought >>> >> about maybe writing a script to detect that, looking at the patch >>> >> file, but >>> >> it seems hard to detect that the deleted Foo is the new Bar. If it's >>> >> just >>> >> rename, maybe, but if part of the rename the code changed a lot ... it >>> >> becomes harder. >>> > >>> > >>> > Probably not the answer you want but >>> > If you use the git-svn bridge it should detect the rename and commit it >>> > in >>> > svn as a move/copy >>> > >>> > https://www.kernel.org/pub/software/scm/git/docs/git-svn.html >>> >>> - >>> 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] (SOLR-5720) Add ExpandComponent, which expands results collapsed by the CollapsingQParserPlugin
[
https://issues.apache.org/jira/browse/SOLR-5720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-5720:
-
Attachment: SOLR-5720.patch
New patch, handles the zero result case and added tests for zero results and
zero expand results.
> Add ExpandComponent, which expands results collapsed by the
> CollapsingQParserPlugin
> ---
>
> Key: SOLR-5720
> URL: https://issues.apache.org/jira/browse/SOLR-5720
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 4.7, 5.0
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 4.7, 5.0
>
> Attachments: SOLR-5720.patch, SOLR-5720.patch, SOLR-5720.patch,
> SOLR-5720.patch, SOLR-5720.patch, SOLR-5720.patch, SOLR-5720.patch
>
>
> This ticket introduces a new search component called the ExpandComponent. The
> expand component expands a single page of results collapsed by the
> CollapsingQParserPlugin.
> Sample syntax:
> {code}
> q=*:*&fq={!collapse
> field=fieldA}&expand=true&expand.sort=fieldB+asc&expand.rows=10
> {code}
> In the above query the results are collapsed on "fieldA" with the
> CollapsingQParserPlugin. The expand component expands the current page of
> collapsed results.
> The initial implementation of the ExpandComponent takes three parameters:
> *expand=true* (Turns on the ExpandComponent)
> *expand.sort=fieldB+asc,fieldC+desc* (Sorts the documents based on a sort
> spec. If none is specified the documents are sorted by relevance based on the
> main query.)
> *expand.rows=10* (Sets the numbers of rows that groups are expanded to).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Building an RC for Lucene / Solr 4.7
Weird. The smoke script has always had solr tests disabled. Who enabled it? Those fails in general have JIRA issues as far as I remember. - Mark > On Feb 18, 2014, at 7:24 AM, Simon Willnauer > wrote: > > hey folks, > > I try to build an RC to checkout if everything goes alright and I now > spend 4 hours already without luck. The release script runs the solr > tests but they never pass. I tried it 6 times now and each time a > different test breaks. I am going to disable the solr test run in the > release script for now to actually run an RC build but this is very > concerning IMO. I tried to reproduce the failures each time but they > don't reproduce. Its mainly: > > org.apache.solr.cloud.OverseerTest.testShardAssignmentBigger > org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSearch > org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch > > any ideas? > > I mean looking at the CI builds those failures are no news are they? > > simon > > - > 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] [Commented] (LUCENE-5000) Query serialization using ObjectInput/OutputStream
[ https://issues.apache.org/jira/browse/LUCENE-5000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904010#comment-13904010 ] Greg Visotski commented on LUCENE-5000: --- Hi Karl, I picked up your patch and have been testing it with Lucene 4.3.1. It works perfectly, and I'd love to see it committed. Thank you! > Query serialization using ObjectInput/OutputStream > -- > > Key: LUCENE-5000 > URL: https://issues.apache.org/jira/browse/LUCENE-5000 > Project: Lucene - Core > Issue Type: New Feature > Components: core/search >Affects Versions: 4.3 >Reporter: Karl Wettin >Priority: Trivial > Attachments: LuceneQuerySerializer.java, > TestLuceneQuerySerializer.java > > > Reads and writes queries on ObjectInput/OutputStream. > No support for ConstantScoreQuery (no serialization for Filter) nor > PayloadNearQuery and PayloadTermQuery (no serialization for PayloadFunction). > I might have missed to implement support for some core Queries. Currently > supported are: TermQuery, BooleanQuery, WildcardQuery, PhraseQuery, > MultiPhraseQuery, FuzzyQuery, RegexpQuery, TermRangeQuery, NumericRangeQuery, > DisjunctionMaxQuery, MatchAllDocsQuery, SpanTermQuery, > SpanMultiTermQueryWrapper, SpanNearQuery, SpanNotQuery, SpanOrQuery, > FieldMaskingSpanQuery, SpanFirstQuery, SpanPositionRangeQuery, > SpanPayloadCheckQuery and SpanNearPayloadCheckQuery. > Users are allowed to implement and register strategies for their own queries. > This will not allow you to serialize any object graph with aggregated Query > instances e.g. Map, that would require a new implementation of > ObjectOutputStream (one could base that on the GPL2 code from OpenJDK) or > instrument the existing implementations to handle Query in private > writeObjectA and similar methods. > There's a bit of reflection glue in this code in order to read private fields > in query implementation. Not too happy about that, but not much to do unless > one is to expose a bunch of new getters in all those classes. > The class is places in o.a.l.search in order to access package visible fields > without getters. If moving to another package this would have to be handled > using reflection as with above mentioned private fields. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5449) Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil
[ https://issues.apache.org/jira/browse/LUCENE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904007#comment-13904007 ] Uwe Schindler commented on LUCENE-5449: --- +1 to commit. I hope you get the file rename managed :-) (see [~shaie]'s mail on dev list). > Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil > -- > > Key: LUCENE-5449 > URL: https://issues.apache.org/jira/browse/LUCENE-5449 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 4.6.1 >Reporter: Benson Margulies >Priority: Minor > > _TestUtil and _TestHelper begin with _ for historical reasons that don't > apply any longer. Lets eliminate those _'s. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
