[jira] [Commented] (SOLR-5437) DeleteReplicaTest fails constantly both locally and in jenkins
[ https://issues.apache.org/jira/browse/SOLR-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13821020#comment-13821020 ] ASF subversion and git services commented on SOLR-5437: --- Commit 1541405 from [~noble.paul] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1541405 ] SOLR-5437 > DeleteReplicaTest fails constantly both locally and in jenkins > -- > > Key: SOLR-5437 > URL: https://issues.apache.org/jira/browse/SOLR-5437 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir >Assignee: Noble Paul > Fix For: 4.6 > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5428) new statistics results to StatsComponent - distinctValues and countDistinct
[ https://issues.apache.org/jira/browse/SOLR-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13821019#comment-13821019 ] Elran Dvir commented on SOLR-5428: -- Yes, as far as I know. If there aren't any bugs in distributed queries in StatsComponent, this feature works as others. > new statistics results to StatsComponent - distinctValues and countDistinct > --- > > Key: SOLR-5428 > URL: https://issues.apache.org/jira/browse/SOLR-5428 > Project: Solr > Issue Type: New Feature >Reporter: Elran Dvir > Attachments: SOLR-5428.patch > > > I thought it would be very useful to display the distinct values (and the > count) of a field among other statistics. Attached a patch implementing this > in StatsComponent. > Added results : > "distinctValues" - list of all distnict values > "countDistinct" - distnict values count. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5437) DeleteReplicaTest fails constantly both locally and in jenkins
[ https://issues.apache.org/jira/browse/SOLR-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13821018#comment-13821018 ] ASF subversion and git services commented on SOLR-5437: --- Commit 1541404 from [~noble.paul] in branch 'dev/trunk' [ https://svn.apache.org/r1541404 ] SOLR-5437 > DeleteReplicaTest fails constantly both locally and in jenkins > -- > > Key: SOLR-5437 > URL: https://issues.apache.org/jira/browse/SOLR-5437 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir >Assignee: Noble Paul > Fix For: 4.6 > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-4.x - Build # 125 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-4.x/125/ No tests ran. Build Log: [...truncated 36610 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/build.xml:333: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/solr/build.xml:589: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/solr/build.xml:580: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/solr/common-build.xml:439: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/solr/common-build.xml:314: java.lang.OutOfMemoryError: PermGen space at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:634) at org.apache.tools.ant.AntClassLoader.defineClassFromData(AntClassLoader.java:1124) at org.apache.tools.ant.AntClassLoader.getClassFromStream(AntClassLoader.java:1295) at org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1351) at org.apache.tools.ant.AntClassLoader.findClass(AntClassLoader.java:1311) at org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:1064) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) at org.codehaus.groovy.classgen.asm.BytecodeHelper.(BytecodeHelper.java:37) at org.codehaus.groovy.classgen.Verifier.visitClass(Verifier.java:152) at org.codehaus.groovy.control.CompilationUnit$15.call(CompilationUnit.java:757) at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1036) at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:572) at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:550) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:527) at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:279) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:258) at groovy.lang.GroovyShell.parseClass(GroovyShell.java:613) at groovy.lang.GroovyShell.parse(GroovyShell.java:625) at groovy.lang.GroovyShell.parse(GroovyShell.java:652) at org.codehaus.groovy.ant.Groovy.parseAndRunScript(Groovy.java:485) at org.codehaus.groovy.ant.Groovy.execGroovy(Groovy.java:444) at org.codehaus.groovy.ant.Groovy.execute(Groovy.java:309) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor450.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) Total time: 23 minutes 44 seconds Build step 'Invoke Ant' marked build as failure 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] [Resolved] (LUCENE-5337) Add Payload support to FileDictionary (Suggest) and make it more configurable
[ https://issues.apache.org/jira/browse/LUCENE-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved LUCENE-5337. Resolution: Fixed Fix Version/s: 4.7 5.0 Thanks Areek! > Add Payload support to FileDictionary (Suggest) and make it more configurable > - > > Key: LUCENE-5337 > URL: https://issues.apache.org/jira/browse/LUCENE-5337 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Areek Zillur > Fix For: 5.0, 4.7 > > Attachments: LUCENE-5337.patch, LUCENE-5337.patch, LUCENE-5337.patch > > > It would be nice to add payload support to FileDictionary, so user can pass > in associated payload with suggestion entries. > Currently the FileDictionary has a hard-coded field-delimiter (TAB), it would > be nice to let the users configure the field delimiter as well. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5287) Allow at least solrconfig.xml and schema.xml to be edited via the admin screen
[ https://issues.apache.org/jira/browse/SOLR-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-5287: - Attachment: SOLR-5287.patch Well, this is scary. I hacked together a butchery of ShowFileRequestHandler (so far only local no ZK support). The most work was refactoring this a bit so I could re-use some of the work already there. But it...works. Even updating files in subdirectories of conf, e.g. velocity. It turns out that ShowFileRequestHandler _already_ lists the contents of a directory if it is a directory. So something like: http://localhost:8983/solr/collection1/admin/file?file=velocity will list the contents of the conf/velocity, and http://localhost:8983/solr/collection1/admin/file will list the contents of the conf directory itself. So, adding a param "op=write" and "file=whatever" and posting a stream to Solr "just works". These two curl commands did the trick, giving me a stream to work with: curl -X POST --form "fileupload=@schema.eoe" 'http://localhost:8983/solr/collection1/admin/file?op=write&file=schema.xml' curl -X POST --form "fileupload=@eoe.vm" 'http://localhost:8983/solr/collection1/admin/file?op=write&file=velocity/error.vm' [~steffkes] Is this enough to see if this could work from the admin UI? Everyone: Mostly I'm putting this up to see what people think. [~sarowe] and I chatted this evening, there are still some questions about how this and managed schemas should interact when both are active at once. You can also hide files if you so choose, the code already does that. If the UI gives you a set of files to choose from you just wouldn't see one to try to change although you could still cURL stuff if you wanted, but this is the admin UI after all. If you opened a binary file, I assume you'd see garbage and wouldn't want to proceed anyway, but that's a bit of a hole. We should post a warning indicating that the changes won't take effect until after a core reload. I'm reluctant to actually reload automatically on the theory that one might want to make a series of related changes and apply them all at once. Perhaps [~steffkes] (or someone) could put a button on whatever page we come up with rather than making the user go to the cores page after editing? What would be _really cool_ is if there were an easy way to tell if at least the xml was well-formed before saving, but that's a bell and whistle. One thing that we may get "for free" is editing these even if the core fails to load. But I have to check that out when the admin UI is operational. And I still have to check whether lazily-loaded cores work, but this is enough for tonight. And, as usual at this point, I haven't checked things over very carefully, run precommit or test yet. Mostly I'm wondering what people think of the approach. Let me know... > Allow at least solrconfig.xml and schema.xml to be edited via the admin screen > -- > > Key: SOLR-5287 > URL: https://issues.apache.org/jira/browse/SOLR-5287 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis, web gui >Affects Versions: 4.5, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson > Attachments: SOLR-5287.patch > > > A user asking a question on the Solr list got me to thinking about editing > the main config files from the Solr admin screen. I chatted briefly with > [~steffkes] about the mechanics of this on the browser side, he doesn't see a > problem on that end. His comment is there's no end point that'll write the > file back. > Am I missing something here or is this actually not a hard problem? I see a > couple of issues off the bat, neither of which seem troublesome. > 1> file permissions. I'd imagine lots of installations will get file > permission exceptions if Solr tries to write the file out. Well, do a > chmod/chown. > 2> screwing up the system maliciously or not. I don't think this is an issue, > this would be part of the admin handler after all. > Does anyone have objections to the idea? And how does this fit into the work > that [~sar...@syr.edu] has been doing? > I can imagine this extending to SolrCloud with a "push this to ZK" option or > something like that, perhaps not in V1 unless it's easy. > Of course any pointers gratefully received. Especially ones that start with > "Don't waste your effort, it'll never work (or be accepted)"... > Because what scares me is this seems like such an easy thing to do that would > be a significant ease-of-use improvement, so there _has_ to be something I'm > missing. > So if we go forward with this we'll make this the umbrella JIRA, the two > immediate sub-JIRAs that spring to mind will be the UI work and the endpoints > for the UI work to use. > I think there are
[jira] [Commented] (LUCENE-5337) Add Payload support to FileDictionary (Suggest) and make it more configurable
[ https://issues.apache.org/jira/browse/LUCENE-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820866#comment-13820866 ] Erick Erickson commented on LUCENE-5337: Robert: You're right, of course. Thanks! I'll fix momentarily. > Add Payload support to FileDictionary (Suggest) and make it more configurable > - > > Key: LUCENE-5337 > URL: https://issues.apache.org/jira/browse/LUCENE-5337 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Areek Zillur > Attachments: LUCENE-5337.patch, LUCENE-5337.patch, LUCENE-5337.patch > > > It would be nice to add payload support to FileDictionary, so user can pass > in associated payload with suggestion entries. > Currently the FileDictionary has a hard-coded field-delimiter (TAB), it would > be nice to let the users configure the field delimiter as well. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5337) Add Payload support to FileDictionary (Suggest) and make it more configurable
[ https://issues.apache.org/jira/browse/LUCENE-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820846#comment-13820846 ] ASF subversion and git services commented on LUCENE-5337: - Commit 1541360 from [~erickoerickson] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1541360 ] LUCENE-5337 Add Payload support to FileDictionary (Suggest) and make it more configurable > Add Payload support to FileDictionary (Suggest) and make it more configurable > - > > Key: LUCENE-5337 > URL: https://issues.apache.org/jira/browse/LUCENE-5337 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Areek Zillur > Attachments: LUCENE-5337.patch, LUCENE-5337.patch, LUCENE-5337.patch > > > It would be nice to add payload support to FileDictionary, so user can pass > in associated payload with suggestion entries. > Currently the FileDictionary has a hard-coded field-delimiter (TAB), it would > be nice to let the users configure the field delimiter as well. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5322) Clean up / simplify Maven-related Ant targets
[ https://issues.apache.org/jira/browse/LUCENE-5322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820841#comment-13820841 ] ASF subversion and git services commented on LUCENE-5322: - Commit 1541357 from [~steve_rowe] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1541357 ] Backport LUCENE-5217 and LUCENE-5322 to branch_4x > Clean up / simplify Maven-related Ant targets > - > > Key: LUCENE-5322 > URL: https://issues.apache.org/jira/browse/LUCENE-5322 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Steve Rowe >Assignee: Steve Rowe >Priority: Minor > Fix For: 4.6, 5.0 > > Attachments: LUCENE-5322.patch, > LUCENE-5322.validate-maven-artifacts.patch > > > Many Maven-related Ant targets are public when they don't need to be, e.g. > dist-maven and filter-pom-templates, m2-deploy-lucene-parent-pom, etc. > The arrangement of these targets could be simplified if the directories that > have public entry points were minimized. > generate-maven-artifacts should be runnable from the top level and from > lucene/ and solr/. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5217) disable transitive dependencies in maven config
[ https://issues.apache.org/jira/browse/LUCENE-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820840#comment-13820840 ] ASF subversion and git services commented on LUCENE-5217: - Commit 1541357 from [~steve_rowe] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1541357 ] Backport LUCENE-5217 and LUCENE-5322 to branch_4x > disable transitive dependencies in maven config > --- > > Key: LUCENE-5217 > URL: https://issues.apache.org/jira/browse/LUCENE-5217 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Assignee: Steve Rowe > Fix For: 4.6, 5.0 > > Attachments: LUCENE-5217.patch, LUCENE-5217.patch, LUCENE-5217.patch, > LUCENE-5217.patch > > > Our ivy configuration does this: each dependency is specified and so we know > what will happen. Unfortunately the maven setup is not configured the same > way. > Instead the maven setup is configured to download the internet: and it > excludes certain things specifically. > This is really hard to configure and maintain: we added a > 'validate-maven-dependencies' that tries to fail on any extra jars, but all > it really does is run a license check after maven "runs". It wouldnt find > unnecessary dependencies being dragged in if something else in lucene was > using them and thus they had a license file. > Since maven supports wildcard exclusions: MNG-3832, we can disable this > transitive shit completely. > We should do this, so its configuration is the exact parallel of ivy. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5322) Clean up / simplify Maven-related Ant targets
[ https://issues.apache.org/jira/browse/LUCENE-5322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820833#comment-13820833 ] ASF subversion and git services commented on LUCENE-5322: - Commit 1541355 from [~steve_rowe] in branch 'dev/trunk' [ https://svn.apache.org/r1541355 ] Move LUCENE-5217 and LUCENE-5322 entries to the 4.7 section > Clean up / simplify Maven-related Ant targets > - > > Key: LUCENE-5322 > URL: https://issues.apache.org/jira/browse/LUCENE-5322 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Steve Rowe >Assignee: Steve Rowe >Priority: Minor > Fix For: 4.6, 5.0 > > Attachments: LUCENE-5322.patch, > LUCENE-5322.validate-maven-artifacts.patch > > > Many Maven-related Ant targets are public when they don't need to be, e.g. > dist-maven and filter-pom-templates, m2-deploy-lucene-parent-pom, etc. > The arrangement of these targets could be simplified if the directories that > have public entry points were minimized. > generate-maven-artifacts should be runnable from the top level and from > lucene/ and solr/. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5217) disable transitive dependencies in maven config
[ https://issues.apache.org/jira/browse/LUCENE-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820832#comment-13820832 ] ASF subversion and git services commented on LUCENE-5217: - Commit 1541355 from [~steve_rowe] in branch 'dev/trunk' [ https://svn.apache.org/r1541355 ] Move LUCENE-5217 and LUCENE-5322 entries to the 4.7 section > disable transitive dependencies in maven config > --- > > Key: LUCENE-5217 > URL: https://issues.apache.org/jira/browse/LUCENE-5217 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Assignee: Steve Rowe > Fix For: 4.6, 5.0 > > Attachments: LUCENE-5217.patch, LUCENE-5217.patch, LUCENE-5217.patch, > LUCENE-5217.patch > > > Our ivy configuration does this: each dependency is specified and so we know > what will happen. Unfortunately the maven setup is not configured the same > way. > Instead the maven setup is configured to download the internet: and it > excludes certain things specifically. > This is really hard to configure and maintain: we added a > 'validate-maven-dependencies' that tries to fail on any extra jars, but all > it really does is run a license check after maven "runs". It wouldnt find > unnecessary dependencies being dragged in if something else in lucene was > using them and thus they had a license file. > Since maven supports wildcard exclusions: MNG-3832, we can disable this > transitive shit completely. > We should do this, so its configuration is the exact parallel of ivy. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5337) Add Payload support to FileDictionary (Suggest) and make it more configurable
[ https://issues.apache.org/jira/browse/LUCENE-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820796#comment-13820796 ] Robert Muir commented on LUCENE-5337: - Does this one really go in 4.6.0? Seems like this was just a mistake and it should be 4.7.0? Note: I created 4.7.0 section of CHANGES already and branch_4x is set for 4.7.0. So i think the CHANGES entry just needs to be moved. > Add Payload support to FileDictionary (Suggest) and make it more configurable > - > > Key: LUCENE-5337 > URL: https://issues.apache.org/jira/browse/LUCENE-5337 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Areek Zillur > Attachments: LUCENE-5337.patch, LUCENE-5337.patch, LUCENE-5337.patch > > > It would be nice to add payload support to FileDictionary, so user can pass > in associated payload with suggestion entries. > Currently the FileDictionary has a hard-coded field-delimiter (TAB), it would > be nice to let the users configure the field delimiter as well. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5337) Add Payload support to FileDictionary (Suggest) and make it more configurable
[ https://issues.apache.org/jira/browse/LUCENE-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820757#comment-13820757 ] ASF subversion and git services commented on LUCENE-5337: - Commit 1541341 from [~erickoerickson] in branch 'dev/trunk' [ https://svn.apache.org/r1541341 ] LUCENE-5337 Add Payload support to FileDictionary (Suggest) and make it more configurable > Add Payload support to FileDictionary (Suggest) and make it more configurable > - > > Key: LUCENE-5337 > URL: https://issues.apache.org/jira/browse/LUCENE-5337 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Areek Zillur > Attachments: LUCENE-5337.patch, LUCENE-5337.patch, LUCENE-5337.patch > > > It would be nice to add payload support to FileDictionary, so user can pass > in associated payload with suggestion entries. > Currently the FileDictionary has a hard-coded field-delimiter (TAB), it would > be nice to let the users configure the field delimiter as well. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 1013 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1013/ Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 10035 lines...] [junit4] JVM J0: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/temp/junit4-J0-20131113_000940_422.syserr [junit4] >>> JVM J0: stderr (verbatim) [junit4] java(287,0x130443000) malloc: *** error for object 0x2130431e90: pointer being freed was not allocated [junit4] *** set a breakpoint in malloc_error_break to debug [junit4] <<< JVM J0: EOF [...truncated 1 lines...] [junit4] ERROR: JVM J0 ended with an exception, command line: /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/bin/java -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/heapdumps -Dtests.prefix=tests -Dtests.seed=58426B9B97062A82 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.0 -Dtests.cleanthreads=perClass -Djava.util.logging.config.file=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/tools/junit4/logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true -Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. -Djava.io.tmpdir=. -Djunit4.tempDir=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/temp -Dclover.db.dir=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/clover/db -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Djava.security.policy=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/tools/junit4/tests.policy -Dlucene.version=5.0-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Dtests.disableHdfs=true -Dfile.encoding=ISO-8859-1 -classpath /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/classes/test:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-test-framework/classes/java:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/test-framework/lib/junit4-ant-2.0.13.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test-files:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/test-framework/classes/java:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/codecs/classes/java:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-solrj/classes/java:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/classes/java:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/analysis/common/lucene-analyzers-common-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/analysis/kuromoji/lucene-analyzers-kuromoji-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/analysis/phonetic/lucene-analyzers-phonetic-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/codecs/lucene-codecs-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/highlighter/lucene-highlighter-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/memory/lucene-memory-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/misc/lucene-misc-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/spatial/lucene-spatial-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/suggest/lucene-suggest-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/grouping/lucene-grouping-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/queries/lucene-queries-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/queryparser/lucene-queryparser-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/join/lucene-join-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/lib/commons-cli-1.2.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/lib/commons-codec-1.7.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/lib/commons-configuration-1.6.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/lib/commons-fileupload-1.2.1.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/lib/commons-lang-2.6.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/lib/concurrentlinkedhashmap-lru-1.2.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/lib/dom4j-1.6.1.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/lib/guava-1
[jira] [Resolved] (SOLR-5247) Support for custom per core properties missing with new-style solr.xml
[ https://issues.apache.org/jira/browse/SOLR-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-5247. -- Resolution: Fixed Fix Version/s: 4.5 5.0 [~n0v1] I just tried this and it seems to work fine for core creation on 4.5 and 4x. I know there has been quite a bit of work in this area _right_ after the 4.4 Solr was cut so I'm going to say it's fixed. If anyone finds out differently, we can re-open this JIRA or open a new one. > Support for custom per core properties missing with new-style solr.xml > -- > > Key: SOLR-5247 > URL: https://issues.apache.org/jira/browse/SOLR-5247 > Project: Solr > Issue Type: Bug > Components: multicore >Affects Versions: 4.4 >Reporter: Chris F >Assignee: Erick Erickson >Priority: Trivial > Labels: 4.4, core.properties, discovery, new-style, property, > solr.xml > Fix For: 5.0, 4.5 > > > This part has been solved. See comments > When using old-style solr.xml I can define custom properties per core like so: > {code:xml} > >schema="schema.xml"> > > > > {code} > I can then use the property "foo" in schema.xml or solrconfig.xml like this: > {code:xml} > ${foo} > {code} > After switching to the new-style solr.xml with separate core.properties files > per core this does not work anymore. > I guess the corresponding core.properties file should look like this: > {code} > config=solrconfig.xml > name=core1 > schema=schema.xml > foo=bar > {code} > (I also tried property.foo=bar) > With that, I get the following error when reloading the core: > {code} > org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: No > system property or default value specified for foo value:${foo} > {code} > I can successfully reload the core if I use $\{foo:undefined\} but the value > of "foo" will always be "undefined" then. > When trying to create a new core with an url like this: > {code} > http://localhost:8080/solr/admin/cores?action=CREATE&name=core2&instanceDir=core2&config=solrconfig.xml&schema=schema.xml&property.foo=bar&persist=true > {code} > the property "foo" will not appear in core.properties. However, I can use it > in schema.xml. But only until restarting the servlet container. After that, > the property is lost. > Possibly related to > [SOLR-5208|https://issues.apache.org/jira/browse/SOLR-5208]? -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5438) DebugComponent throws NPE when used with grouping
[ https://issues.apache.org/jira/browse/SOLR-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomás Fernández Löbbe updated SOLR-5438: Attachment: SOLR-5438.patch The problem seems to be when getting the doc explain. This can be done in the last grouping phase. > DebugComponent throws NPE when used with grouping > - > > Key: SOLR-5438 > URL: https://issues.apache.org/jira/browse/SOLR-5438 > Project: Solr > Issue Type: Bug >Reporter: Tomás Fernández Löbbe > Attachments: SOLR-5438.patch > > > To Reproduce: > start trunk example > Run query: > http://localhost:8983/solr/select?q=test&debug=true&group=true&group.field=inStock&distrib=true&shards=localhost:8983/solr,localhost:8983/solr > DebugComponent throws a NPE like: > {noformat} > 83841 [qtp1070887245-16] ERROR org.apache.solr.servlet.SolrDispatchFilter – > null:java.lang.NullPointerException > at > org.apache.solr.handler.component.DebugComponent.process(DebugComponent.java:66) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:216) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195) > 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.handler.ScopedHandler.handle(ScopedHandler.java:137) > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075) > 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.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154) > 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.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) > at > org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953) > at > org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014) > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861) > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240) > at > org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) > at > org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) > 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:722) > {noformat} > Seems like some internal requests when using grouping don't populate > ResponseBuilder.results. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5438) DebugComponent throws NPE when used with grouping
Tomás Fernández Löbbe created SOLR-5438: --- Summary: DebugComponent throws NPE when used with grouping Key: SOLR-5438 URL: https://issues.apache.org/jira/browse/SOLR-5438 Project: Solr Issue Type: Bug Reporter: Tomás Fernández Löbbe To Reproduce: start trunk example Run query: http://localhost:8983/solr/select?q=test&debug=true&group=true&group.field=inStock&distrib=true&shards=localhost:8983/solr,localhost:8983/solr DebugComponent throws a NPE like: {noformat} 83841 [qtp1070887245-16] ERROR org.apache.solr.servlet.SolrDispatchFilter – null:java.lang.NullPointerException at org.apache.solr.handler.component.DebugComponent.process(DebugComponent.java:66) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:216) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195) 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.handler.ScopedHandler.handle(ScopedHandler.java:137) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075) 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.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154) 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.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) 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:722) {noformat} Seems like some internal requests when using grouping don't populate ResponseBuilder.results. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5339) Simplify the facet module APIs
[ https://issues.apache.org/jira/browse/LUCENE-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-5339: --- Attachment: LUCENE-5339.patch Starting patch. > Simplify the facet module APIs > -- > > Key: LUCENE-5339 > URL: https://issues.apache.org/jira/browse/LUCENE-5339 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/facet >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: LUCENE-5339.patch > > > I'd like to explore simplifications to the facet module's APIs: I > think the current APIs are complex, and the addition of a new feature > (sparse faceting, LUCENE-5333) threatens to add even more classes > (e.g., FacetRequestBuilder). I think we can do better. > So, I've been prototyping some drastic changes; this is very > early/exploratory and I'm not sure where it'll wind up but I think the > new approach shows promise. > The big changes are: > * Instead of *FacetRequest/Params/Result, you directly instantiate > the classes that do facet counting (currently TaxonomyFacetCounts, > RangeFacetCounts or SortedSetDVFacetCounts), passing in the > SimpleFacetsCollector, and then you interact with those classes to > pull labels + values (topN under a path, sparse, specific labels). > * At index time, no more FacetIndexingParams/CategoryListParams; > instead, you make a new SimpleFacetFields and pass it the field it > should store facets + drill downs under. If you want more than > one CLI you create more than one instance of SimpleFacetFields. > * I added a simple schema, where you state which dimensions are > hierarchical or multi-valued. From this we decide how to index > the ordinals (no more OrdinalPolicy). > Sparse faceting is just another method (getAllDims), on both taxonomy > & ssdv facet classes. > I haven't created a common base class / interface for all of the > search-time facet classes, but I think this may be possible/clean, and > perhaps useful for drill sideways. > All the new classes are under oal.facet.simple.*. > Lots of things that don't work yet: drill sideways, complements, > associations, sampling, partitions, etc. This is just a start ... -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5339) Simplify the facet module APIs
Michael McCandless created LUCENE-5339: -- Summary: Simplify the facet module APIs Key: LUCENE-5339 URL: https://issues.apache.org/jira/browse/LUCENE-5339 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Reporter: Michael McCandless Assignee: Michael McCandless I'd like to explore simplifications to the facet module's APIs: I think the current APIs are complex, and the addition of a new feature (sparse faceting, LUCENE-5333) threatens to add even more classes (e.g., FacetRequestBuilder). I think we can do better. So, I've been prototyping some drastic changes; this is very early/exploratory and I'm not sure where it'll wind up but I think the new approach shows promise. The big changes are: * Instead of *FacetRequest/Params/Result, you directly instantiate the classes that do facet counting (currently TaxonomyFacetCounts, RangeFacetCounts or SortedSetDVFacetCounts), passing in the SimpleFacetsCollector, and then you interact with those classes to pull labels + values (topN under a path, sparse, specific labels). * At index time, no more FacetIndexingParams/CategoryListParams; instead, you make a new SimpleFacetFields and pass it the field it should store facets + drill downs under. If you want more than one CLI you create more than one instance of SimpleFacetFields. * I added a simple schema, where you state which dimensions are hierarchical or multi-valued. From this we decide how to index the ordinals (no more OrdinalPolicy). Sparse faceting is just another method (getAllDims), on both taxonomy & ssdv facet classes. I haven't created a common base class / interface for all of the search-time facet classes, but I think this may be possible/clean, and perhaps useful for drill sideways. All the new classes are under oal.facet.simple.*. Lots of things that don't work yet: drill sideways, complements, associations, sampling, partitions, etc. This is just a start ... -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-4.x-Java7 - Build # 1754 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java7/1754/ All tests passed Build Log: [...truncated 32812 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_25 [javadoc] Building tree for all the packages and classes... [javadoc] Generating /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/lucene/build/docs/core/org/apache/lucene/search/package-summary.html... [javadoc] Copying file /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/lucene/core/src/java/org/apache/lucene/search/doc-files/nrq-formula-2.png to directory /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/lucene/build/docs/core/org/apache/lucene/search/doc-files... [javadoc] Copying file /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/lucene/core/src/java/org/apache/lucene/search/doc-files/nrq-formula-1.png to directory /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/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 /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/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.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 source files for package org.apach
[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820575#comment-13820575 ] ASF subversion and git services commented on SOLR-5408: --- Commit 1541277 from [~joel.bernstein] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1541277 ] SOLR-5408 Fixed issue with scorer > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: CollapsingQParserPlugin.java, > CollapsingQParserPlugin.java, SOLR-5027.patch, SOLR-5408.2.patch, > SOLR-5408.patch, SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820569#comment-13820569 ] Joel Bernstein commented on SOLR-5408: -- Brandon, I put a file up for you to test. I don't have the same build as you have anymore so I won't be able to compile and test. But the changes were very small, so I suspect they will work. Joel > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: CollapsingQParserPlugin.java, > CollapsingQParserPlugin.java, SOLR-5027.patch, SOLR-5408.2.patch, > SOLR-5408.patch, SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-5408: - Attachment: CollapsingQParserPlugin.java > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: CollapsingQParserPlugin.java, > CollapsingQParserPlugin.java, SOLR-5027.patch, SOLR-5408.2.patch, > SOLR-5408.patch, SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5399) Improve DebugComponent for distributed requests
[ https://issues.apache.org/jira/browse/SOLR-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820523#comment-13820523 ] Ryan Ernst commented on SOLR-5399: -- This looks very useful for debugging distributed requests! A couple minor thoughts on the patch: * It looks like there is a typo "tack" vs track, in DebugComponentTest. * In testModifyRequestTrack() and testPrepare(), it would be nice to add a loop so a couple variations can be tested in a single test run (just less reliance on jenkins coming up with seeds that will hit possible bugs). * The REQUEST_PURPOSE parameter name is in CamelCase, but it seems like the other request parameters are lowercase. Maybe make it match stylistically? +1 in general though. > Improve DebugComponent for distributed requests > --- > > Key: SOLR-5399 > URL: https://issues.apache.org/jira/browse/SOLR-5399 > Project: Solr > Issue Type: Improvement >Affects Versions: 5.0 >Reporter: Tomás Fernández Löbbe > Attachments: SOLR-5399.patch, SOLR-5399.patch > > > I'm working on extending the DebugComponent for adding some useful > information to be able to track distributed requests better. I'm adding two > different things, first, the request can generate a "request ID" that will be > printed in the logs for the main query and all the different internal > requests to the different shards. This should make it easier to find the > different parts of a single user request in the logs. It would also add the > "purpose" of each internal request to the logs, like: > RequestPurpose=GET_FIELDS,GET_DEBUG or RequestPurpose=GET_TOP_IDS. > Also, I'm adding a "track" section to the debug info where to add information > about the different phases of the distributed request (right now, I'm only > including QTime, but could eventually include more information) like: > {code:xml} > > > > QTime: 10 > QTime: 25 > > > QTime: 1 > > > > {code} > To get this, debugQuery must be set to true, or debug must include > "debug=track". This information is only added to distributed requests. I > would like to get feedback on this. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Chapman updated SOLR-5408: -- Attachment: CollapsingQParserPlugin.java attaching java file instead of patch > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: CollapsingQParserPlugin.java, SOLR-5027.patch, > SOLR-5408.2.patch, SOLR-5408.patch, SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820505#comment-13820505 ] Joel Bernstein commented on SOLR-5408: -- Brandon, I'll edit your version of the CollapsingQParserPlugin directly and post that back to the ticket. So just attach the CollapserQParserPlugin.java file. Joel > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: SOLR-5027.patch, SOLR-5408.2.patch, SOLR-5408.patch, > SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Chapman updated SOLR-5408: -- Attachment: SOLR-5027.patch Attached patch that we are using. > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: SOLR-5027.patch, SOLR-5408.2.patch, SOLR-5408.patch, > SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820449#comment-13820449 ] ASF subversion and git services commented on SOLR-5408: --- Commit 1541232 from [~joel.bernstein] in branch 'dev/trunk' [ https://svn.apache.org/r1541232 ] SOLR-5408 Fixed issue with scorer > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: SOLR-5408.2.patch, SOLR-5408.patch, SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820434#comment-13820434 ] Joel Bernstein commented on SOLR-5408: -- Brandon, If you want to post your version of the CollapsingQParserPlugin directly to this ticket. I will make the changes to the version you have and post it back. Otherwise, I will shortly be committing this fix to trunk and 4x so you could replace your version with the latest version. > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: SOLR-5408.2.patch, SOLR-5408.patch, SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820431#comment-13820431 ] Joel Bernstein edited comment on SOLR-5408 at 11/12/13 8:45 PM: I just posted a new patch. This patch makes a change to the "dummy" scorer that is passed down to the delegate collector. The issue was that certain priority queue implementations wrap the scorer in a cache that saves the score for the last docId. For this cache to work properly the dummy scorer needed to implement the docID() method properly. This patch does that. Not all the priority queue implementations use this technique, so depending on how the query is executed you may or may not hit the bug. was (Author: joel.bernstein): I just posted new patch. This patch makes a change to the "dummy" scorer that is passed down to the delegate collector. The issue was that certain priority queue implementations wrap the scorer in a cache that saves the score for the last docId. For this cache to work properly the dummy scorer needed to implement the docID() method properly. This patch does that. Not all the priority queue implementations use this technique, so depending on how the query is executed you may or may not hit the bug. > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: SOLR-5408.2.patch, SOLR-5408.patch, SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820431#comment-13820431 ] Joel Bernstein commented on SOLR-5408: -- I just posted new patch. This patch makes a change to the "dummy" scorer that is passed down to the delegate collector. The issue was that certain priority queue implementations wrap the scorer in a cache that saves the score for the last docId. For this cache to work properly the dummy scorer needed to implement the docID() method properly. This patch does that. Not all the priority queue implementations use this technique, so depending on how the query is executed you may or may not hit the bug. > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: SOLR-5408.2.patch, SOLR-5408.patch, SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-5408: - Attachment: SOLR-5408.2.patch > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: SOLR-5408.2.patch, SOLR-5408.patch, SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820424#comment-13820424 ] Joel Bernstein edited comment on SOLR-5408 at 11/12/13 8:38 PM: When I started testing with a larger dataset (millions) it become apparent pretty quickly that things were still broken with the score sorting when other criteria is used. I'm about to post the fix that worked on the larger data set. I'll have to give some thought into how get this to break with a small test case. was (Author: joel.bernstein): When I started testing with a larger dataset (millions) it become apparent pretty quickly that things will still broken with the score sorting when other criteria is used. I'm about to post the fix that worked on the larger data set. I'll have to give some thought into how get this to break with a small test case. > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: SOLR-5408.patch, SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820424#comment-13820424 ] Joel Bernstein commented on SOLR-5408: -- When I started testing with a larger dataset (millions) it become apparent pretty quickly that things will still broken with the score sorting when other criteria is used. I'm about to post the fix that worked on the larger data set. I'll have to give some thought into how get this to break with a small test case. > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: SOLR-5408.patch, SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820400#comment-13820400 ] Erik Hatcher commented on SOLR-5408: bq. Further testing shows the bug is still present after this patch. Under what conditions? Can you post a failing test case? > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: SOLR-5408.patch, SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820397#comment-13820397 ] Erik Hatcher commented on SOLR-5408: bq. Only one concern and that is the assertion of 5 segments... All we need is there to be more then 1 segment to ensure the test is valid. +1, by all means modify the test to whatever makes sense here. Maybe {code}assertTrue("Must be more than one segment", searcherRef.get().getIndexReader().leaves().size() > 1){code} or something like that? > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: SOLR-5408.patch, SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820368#comment-13820368 ] Joel Bernstein commented on SOLR-5408: -- Further testing shows the bug is still present after this patch. Continuing to investigate... > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: SOLR-5408.patch, SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene / Solr 4.6
FYI I won't be able to kick this off today so I am building an RC tomorrow CEST On Tue, Nov 12, 2013 at 5:23 PM, Dawid Weiss wrote: >> A few days ago Dawid Weiss upgraded the randomized-testing and junit4-ant >> dependencies in the Ant build, but not in the Maven build, > > Umm, that's odd, I typically remember about that. [checking]. Yeah -- > sorry about that, I merged changes from trunk automatically and didn't > notice that single-props file is not backported to 4x... My apologies > and thanks for fixing this, Steve. > > Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820279#comment-13820279 ] Joel Bernstein commented on SOLR-5408: -- Erick, I like the a test case. Only one concern and that is the assertion of 5 segments. Could be a race condition here where a background merge gets done in between commits, causing there to be fewer then 5 segments. I was thinking about just taking out this assertion and using the rest of the test. All we need is there to be more then 1 segment to ensure the test is valid. Let me know what you think, Thanks, Joel > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: SOLR-5408.patch, SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Adding preserveOriginal Capability to EdgeNGramFilterFactory
Can EdgeNGramFilterFactory handle the cases where we need to skip/consider the "n" words from the start or end? For example: Title: big bang theory field1: populate full ngrams field2: populate ngrams for "bang theory" = skipping the first word "big" field3: populate ngrams for "big" = considering only the first word "big" field4: populate ngrams for "theory" = considering only the last word "theory" and at query time, I would like to apply field level boosting to rank the results. Thanks, Kranti K. Parisa http://www.linkedin.com/in/krantiparisa On Sun, Nov 10, 2013 at 5:51 PM, Furkan KAMACI wrote: > Hi; > > There were two issues about adding preserveOriginal capability to > EdgeNGramFilterFactory and I've made a patch about it. You can check and > test it from here: https://issues.apache.org/jira/browse/SOLR-5152 This > is the related issue that can be marked as duplicated: > https://issues.apache.org/jira/browse/SOLR-5332 > > Thanks; > Furkan KAMACI >
[jira] [Assigned] (SOLR-5437) DeleteReplicaTest fails constantly both locally and in jenkins
[ https://issues.apache.org/jira/browse/SOLR-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-5437: --- Assignee: Noble Paul > DeleteReplicaTest fails constantly both locally and in jenkins > -- > > Key: SOLR-5437 > URL: https://issues.apache.org/jira/browse/SOLR-5437 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir >Assignee: Noble Paul > Fix For: 4.6 > > -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5336) Add a simple QueryParser to parse human-entered queries.
[ https://issues.apache.org/jira/browse/LUCENE-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-5336. - Resolution: Fixed Fix Version/s: 4.7 5.0 Thanks Jack! > Add a simple QueryParser to parse human-entered queries. > > > Key: LUCENE-5336 > URL: https://issues.apache.org/jira/browse/LUCENE-5336 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jack Conradson > Fix For: 5.0, 4.7 > > Attachments: LUCENE-5336.patch, LUCENE-5336.patch, LUCENE-5336.patch > > > I would like to add a new simple QueryParser to Lucene that is designed to > parse human-entered queries. This parser will operate on an entire entered > query using a specified single field or a set of weighted fields (using term > boost). > All features/operations in this parser can be enabled or disabled depending > on what is necessary for the user. A default operator may be specified as > either 'MUST' representing 'and' or 'SHOULD' representing 'or.' The > features/operations that this parser will include are the following: > * AND specified as '+' > * OR specified as '|' > * NOT specified as '-' > * PHRASE surrounded by double quotes > * PREFIX specified as '*' > * PRECEDENCE surrounded by '(' and ')' > * WHITESPACE specified as ' ' '\n' '\r' and '\t' will cause the default > operator to be used > * ESCAPE specified as '\' will allow operators to be used in terms > The key differences between this parser and other existing parsers will be > the following: > * No exceptions will be thrown, and errors in syntax will be ignored. The > parser will do a best-effort interpretation of any query entered. > * It uses minimal syntax to express queries. All available operators are > single characters or pairs of single characters. > * The parser is hand-written and in a single Java file making it easy to > modify. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5336) Add a simple QueryParser to parse human-entered queries.
[ https://issues.apache.org/jira/browse/LUCENE-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820254#comment-13820254 ] ASF subversion and git services commented on LUCENE-5336: - Commit 1541158 from [~rcmuir] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1541158 ] LUCENE-5336: add SimpleQueryParser for human-entered queries > Add a simple QueryParser to parse human-entered queries. > > > Key: LUCENE-5336 > URL: https://issues.apache.org/jira/browse/LUCENE-5336 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jack Conradson > Attachments: LUCENE-5336.patch, LUCENE-5336.patch, LUCENE-5336.patch > > > I would like to add a new simple QueryParser to Lucene that is designed to > parse human-entered queries. This parser will operate on an entire entered > query using a specified single field or a set of weighted fields (using term > boost). > All features/operations in this parser can be enabled or disabled depending > on what is necessary for the user. A default operator may be specified as > either 'MUST' representing 'and' or 'SHOULD' representing 'or.' The > features/operations that this parser will include are the following: > * AND specified as '+' > * OR specified as '|' > * NOT specified as '-' > * PHRASE surrounded by double quotes > * PREFIX specified as '*' > * PRECEDENCE surrounded by '(' and ')' > * WHITESPACE specified as ' ' '\n' '\r' and '\t' will cause the default > operator to be used > * ESCAPE specified as '\' will allow operators to be used in terms > The key differences between this parser and other existing parsers will be > the following: > * No exceptions will be thrown, and errors in syntax will be ignored. The > parser will do a best-effort interpretation of any query entered. > * It uses minimal syntax to express queries. All available operators are > single characters or pairs of single characters. > * The parser is hand-written and in a single Java file making it easy to > modify. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5336) Add a simple QueryParser to parse human-entered queries.
[ https://issues.apache.org/jira/browse/LUCENE-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820251#comment-13820251 ] ASF subversion and git services commented on LUCENE-5336: - Commit 1541151 from [~rcmuir] in branch 'dev/trunk' [ https://svn.apache.org/r1541151 ] LUCENE-5336: add SimpleQueryParser for human-entered queries > Add a simple QueryParser to parse human-entered queries. > > > Key: LUCENE-5336 > URL: https://issues.apache.org/jira/browse/LUCENE-5336 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jack Conradson > Attachments: LUCENE-5336.patch, LUCENE-5336.patch, LUCENE-5336.patch > > > I would like to add a new simple QueryParser to Lucene that is designed to > parse human-entered queries. This parser will operate on an entire entered > query using a specified single field or a set of weighted fields (using term > boost). > All features/operations in this parser can be enabled or disabled depending > on what is necessary for the user. A default operator may be specified as > either 'MUST' representing 'and' or 'SHOULD' representing 'or.' The > features/operations that this parser will include are the following: > * AND specified as '+' > * OR specified as '|' > * NOT specified as '-' > * PHRASE surrounded by double quotes > * PREFIX specified as '*' > * PRECEDENCE surrounded by '(' and ')' > * WHITESPACE specified as ' ' '\n' '\r' and '\t' will cause the default > operator to be used > * ESCAPE specified as '\' will allow operators to be used in terms > The key differences between this parser and other existing parsers will be > the following: > * No exceptions will be thrown, and errors in syntax will be ignored. The > parser will do a best-effort interpretation of any query entered. > * It uses minimal syntax to express queries. All available operators are > single characters or pairs of single characters. > * The parser is hand-written and in a single Java file making it easy to > modify. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5437) DeleteReplicaTest fails constantly both locally and in jenkins
Robert Muir created SOLR-5437: - Summary: DeleteReplicaTest fails constantly both locally and in jenkins Key: SOLR-5437 URL: https://issues.apache.org/jira/browse/SOLR-5437 Project: Solr Issue Type: Bug Reporter: Robert Muir Fix For: 4.6 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr Release Management Process
Any ideas about it? 2013/11/11 Furkan KAMACI > Hi; > > I've resolved 2 issues last week. One of them is created by me and one of > them was an existence issue. Also there is an 3rd issue that is a > duplication of the second one. > > When I create an issue I have a right to edit Fix Version/s. I've written > 4.6 for fix version of first issue. Second issue was not created by me so I > can not edit the Fix Version/s. > > I just wonder and want to learn commitment process of Solr project. What > committers do before a new release process start? If they filter the > resolved issues that has a Fix Version/s of new release they will not able > to see resolved issues. If they filter the issues resolved since the last > release then they are not using the benefits of Fix Version/s section. > People have a right to edit Fix Version/s section when they create an issue > but does not have a right to edit existence one (ones are created by other > people) > > There are many issues at Solr project and frequent commits every day. > Should I point the user at comments (with an @ tag) for such kind of > situations (I follow who is responsible for next release from dev-list) or > do you handle it yourself (as like how you handled it since this time). > > I just wanted to learn the internal process of release management. > > Thanks; > Furkan KAMACI > > > >
[jira] [Commented] (SOLR-5436) Eliminate the 1500ms wait in overseer loop
[ https://issues.apache.org/jira/browse/SOLR-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820228#comment-13820228 ] Noble Paul commented on SOLR-5436: -- [~shalinmangar] Originally we did not have a blocking lookup of the queue. that was also one of the reasons. > Eliminate the 1500ms wait in overseer loop > -- > > Key: SOLR-5436 > URL: https://issues.apache.org/jira/browse/SOLR-5436 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > > The Overseer thread waits 1500 ms before it polls for new events. The wait > should be eliminated and it should just wait for new events till they come > the way it is done in OverseerCollectionProcessor -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene / Solr 4.6
> A few days ago Dawid Weiss upgraded the randomized-testing and junit4-ant > dependencies in the Ant build, but not in the Maven build, Umm, that's odd, I typically remember about that. [checking]. Yeah -- sorry about that, I merged changes from trunk automatically and didn't notice that single-props file is not backported to 4x... My apologies and thanks for fixing this, Steve. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5336) Add a simple QueryParser to parse human-entered queries.
[ https://issues.apache.org/jira/browse/LUCENE-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820218#comment-13820218 ] Adrien Grand commented on LUCENE-5336: -- +1 > Add a simple QueryParser to parse human-entered queries. > > > Key: LUCENE-5336 > URL: https://issues.apache.org/jira/browse/LUCENE-5336 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jack Conradson > Attachments: LUCENE-5336.patch, LUCENE-5336.patch, LUCENE-5336.patch > > > I would like to add a new simple QueryParser to Lucene that is designed to > parse human-entered queries. This parser will operate on an entire entered > query using a specified single field or a set of weighted fields (using term > boost). > All features/operations in this parser can be enabled or disabled depending > on what is necessary for the user. A default operator may be specified as > either 'MUST' representing 'and' or 'SHOULD' representing 'or.' The > features/operations that this parser will include are the following: > * AND specified as '+' > * OR specified as '|' > * NOT specified as '-' > * PHRASE surrounded by double quotes > * PREFIX specified as '*' > * PRECEDENCE surrounded by '(' and ')' > * WHITESPACE specified as ' ' '\n' '\r' and '\t' will cause the default > operator to be used > * ESCAPE specified as '\' will allow operators to be used in terms > The key differences between this parser and other existing parsers will be > the following: > * No exceptions will be thrown, and errors in syntax will be ignored. The > parser will do a best-effort interpretation of any query entered. > * It uses minimal syntax to express queries. All available operators are > single characters or pairs of single characters. > * The parser is hand-written and in a single Java file making it easy to > modify. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene / Solr 4.6
I upgraded the randomized-testing dependency in the Maven build on branch_4x and lucene_solr_4_6 (4.6 branch: r1541117). (The junit4-ant dependency isn’t used by the Maven build, so nothing needed to change for it.) ‘ant validate-maven-dependencies' failed locally for me before this change, and succeeded afterward. Sorry for the disruption, Simon, please go ahead with building the RC. Steve On Nov 12, 2013, at 10:33 AM, Steve Rowe wrote: > Simon, > > A few days ago Dawid Weiss upgraded the randomized-testing and junit4-ant > dependencies in the Ant build, but not in the Maven build, and as a result > validate-maven-dependencies is failing now on branch_4x - I can’t get to the > build log for the Jenkins run this showed up on, yesterday I think: the site > keeps giving me Proxy Error pages when I try to look. > > Anyway, I’ll commit a fix shortly - please hold off building an RC until I do. > > Also, FYI, I don’t plan on committing LUCENE-5217 and LUCENE-5322 (which draw > dependencies and their versions from the Ant build, and streamline > Maven-related Ant build targets, respectively) to the 4.6 release branch - I > plan on committing tbem later today to branch_4x only. > > Steve > > On Nov 12, 2013, at 9:32 AM, Simon Willnauer > wrote: > >> FYI I just started a release branch http://svn.apache.org/r1541081 >> >> On Thu, Nov 7, 2013 at 2:01 PM, Simon Willnauer >> wrote: >>> Mark, I can do the release if you are busy or so I don't mind lemme >>> know if you wanna do it >>> >>> simon >>> >>> On Thu, Nov 7, 2013 at 1:09 PM, Mark Miller wrote: Next Tuesday sounds good to me. On Thu, Nov 7, 2013 at 9:06 AM, Simon Willnauer wrote: > > hey folks, > > I think it's time to get this going. Mark I can do the release as well > do we wanna set a date? IMO I'd love to start tomorrow but I guess I > will get some "I wanna get featrue XYZ in" emails so what about > cutting the RC next week Tuesday? > > simon > > On Fri, Oct 25, 2013 at 5:22 AM, Otis Gospodnetic > wrote: >> Awesome, if you ask me. I want to try a number of new changes. >> >> Otis >> Solr & ElasticSearch Support >> http://sematext.com/ >> >> On Oct 24, 2013 10:14 AM, "Mark Miller" wrote: >>> >>> I think releasing once a month when we can is great - putting features >>> into users hands faster is a dream come true :) Glad we even have the >>> option >>> now. We have had that cadence breifly before, and when we don’t, it’s >>> usually just a lack of a volunteer. >>> >>> Personally, I want to get out some changes that I’ve worked on. >>> >>> I love release often. The stuff that doesn’t make it in will come in >>> 4.7, >>> which can also be not long after 4.6. >>> >>> I just also like a little warning first. >>> >>> - Mark >>> >>> On Oct 24, 2013, at 10:03 AM, Shai Erera wrote: >>> >>> Is there any reason to rush? We've released 4.5.0 just 3 weeks ago. >>> >>> Shai >>> >>> >>> On Thu, Oct 24, 2013 at 4:54 PM, Adrien Grand >>> wrote: +1 -- Adrien - 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 > -- - Mark >> >> - >> 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-4260) Inconsistent numDocs between leader and replica
[ https://issues.apache.org/jira/browse/SOLR-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820205#comment-13820205 ] Markus Jelsma commented on SOLR-4260: - I can confirm as well that is issue still exists. Since yesterday one of a shard's replica has one document less than it should have. Solr doesn't notice this and makes no attempt in recovering this issue. Around the time when i noticed it first we were shutting down and restarting nodes, it's likely that at that time some documents got indexed as well. > Inconsistent numDocs between leader and replica > --- > > Key: SOLR-4260 > URL: https://issues.apache.org/jira/browse/SOLR-4260 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 5.0 > Environment: 5.0.0.2013.01.04.15.31.51 >Reporter: Markus Jelsma >Priority: Critical > Fix For: 5.0 > > Attachments: 192.168.20.102-replica1.png, > 192.168.20.104-replica2.png, clusterstate.png > > > After wiping all cores and reindexing some 3.3 million docs from Nutch using > CloudSolrServer we see inconsistencies between the leader and replica for > some shards. > Each core hold about 3.3k documents. For some reason 5 out of 10 shards have > a small deviation in then number of documents. The leader and slave deviate > for roughly 10-20 documents, not more. > Results hopping ranks in the result set for identical queries got my > attention, there were small IDF differences for exactly the same record > causing a record to shift positions in the result set. During those tests no > records were indexed. Consecutive catch all queries also return different > number of numDocs. > We're running a 10 node test cluster with 10 shards and a replication factor > of two and frequently reindex using a fresh build from trunk. I've not seen > this issue for quite some time until a few days ago. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5283) Fail the build if ant test didn't execute any tests (everything filtered out).
[ https://issues.apache.org/jira/browse/LUCENE-5283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820204#comment-13820204 ] ASF subversion and git services commented on LUCENE-5283: - Commit 1541117 from [~steve_rowe] in branch 'dev/branches/lucene_solr_4_6' [ https://svn.apache.org/r1541117 ] LUCENE-5283: Maven config (merged branch_4x r1541116) > Fail the build if ant test didn't execute any tests (everything filtered out). > -- > > Key: LUCENE-5283 > URL: https://issues.apache.org/jira/browse/LUCENE-5283 > Project: Lucene - Core > Issue Type: Wish >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: 4.6, 5.0 > > Attachments: LUCENE-5283-permgen.patch, LUCENE-5283.patch, > LUCENE-5283.patch, LUCENE-5283.patch > > > This should be an optional setting that defaults to 'false' (the build > proceeds). -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5283) Fail the build if ant test didn't execute any tests (everything filtered out).
[ https://issues.apache.org/jira/browse/LUCENE-5283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820202#comment-13820202 ] ASF subversion and git services commented on LUCENE-5283: - Commit 1541116 from [~steve_rowe] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1541116 ] LUCENE-5283: Maven config > Fail the build if ant test didn't execute any tests (everything filtered out). > -- > > Key: LUCENE-5283 > URL: https://issues.apache.org/jira/browse/LUCENE-5283 > Project: Lucene - Core > Issue Type: Wish >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: 4.6, 5.0 > > Attachments: LUCENE-5283-permgen.patch, LUCENE-5283.patch, > LUCENE-5283.patch, LUCENE-5283.patch > > > This should be an optional setting that defaults to 'false' (the build > proceeds). -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-4852) If sharedLib is set to lib, classloader fails to find classes in lib
[ https://issues.apache.org/jira/browse/SOLR-4852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820197#comment-13820197 ] Shawn Heisey edited comment on SOLR-4852 at 11/12/13 3:41 PM: -- There may be some confusion about what's going on with this issue. This issue affects 4.3 and later. Summary: If you are putting jars in solrhome/lib then you must remove any sharedLib setting that points at this directory, either with "lib" or an explicit path. Also, you cannot put some jars in solrhome/lib and others in a location specified by sharedLib - they must all be in the same location. The same config won't work on 4.2.1 and earlier if you are putting jars in solrhome/lib. The sharedLib attribute must exist and point at that location, or you will see that the classloader loads the jars, but the classes in those jars are not found when the config or schema tries to use them. This part is something I learned today while trying to work with the older version. I've been told that the behavior documented in this issue is not actually a problem. I personally disagree with that assessment, but there is a workaround available. We probably need some minor documentation changes. was (Author: elyograg): There may be some confusion about what's going on with this issue. This issue affects 4.3 and later. Summary: If you are putting jars in solrhome/lib then you must remove any sharedLib setting that points at this directory, either with "lib" or an explicit path. Also, you cannot put some jars in solrhome/lib and others in a location specified by sharedLib - they must all be in the same location. The same config won't work on 4.2.1 and earlier if you are putting jars in solrhome/lib. The sharedLib attribute must exist and point at that location, or you will see that the classloader loads the jars, but the classes in those jars are not found when the config or schema tries to use them. This part is something I learned today while trying to work with the older version. > If sharedLib is set to lib, classloader fails to find classes in lib > > > Key: SOLR-4852 > URL: https://issues.apache.org/jira/browse/SOLR-4852 > Project: Solr > Issue Type: Bug >Affects Versions: 4.4 > Environment: Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1 > SMP Wed Apr 24 03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux > java version "1.7.0_21" > Java(TM) SE Runtime Environment (build 1.7.0_21-b11) > Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode) >Reporter: Shawn Heisey > Fix For: 4.6 > > Attachments: SOLR-4852-test-failhard.txt, SOLR-4852.patch, > SOLR-4852.patch > > > I have some jars in the lib directory under solr.solr.home - DIH, ICU, and > MySQL. If I set sharedLib in solr.xml to "lib" then the ICUTokenizer class > is not found, even though the jar is loaded (twice) during Solr startup. If > I set sharedLib to another location that doesn't exist, the jars are only > loaded once and there is no problem. > I'm using the old-style solr.xml on branch_4x revision 1485566. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4852) If sharedLib is set to lib, classloader fails to find classes in lib
[ https://issues.apache.org/jira/browse/SOLR-4852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820197#comment-13820197 ] Shawn Heisey commented on SOLR-4852: There may be some confusion about what's going on with this issue. This issue affects 4.3 and later. Summary: If you are putting jars in solrhome/lib then you must remove any sharedLib setting that points at this directory, either with "lib" or an explicit path. Also, you cannot put some jars in solrhome/lib and others in a location specified by sharedLib - they must all be in the same location. The same config won't work on 4.2.1 and earlier if you are putting jars in solrhome/lib. The sharedLib attribute must exist and point at that location, or you will see that the classloader loads the jars, but the classes in those jars are not found when the config or schema tries to use them. This part is something I learned today while trying to work with the older version. > If sharedLib is set to lib, classloader fails to find classes in lib > > > Key: SOLR-4852 > URL: https://issues.apache.org/jira/browse/SOLR-4852 > Project: Solr > Issue Type: Bug >Affects Versions: 4.4 > Environment: Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1 > SMP Wed Apr 24 03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux > java version "1.7.0_21" > Java(TM) SE Runtime Environment (build 1.7.0_21-b11) > Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode) >Reporter: Shawn Heisey > Fix For: 4.6 > > Attachments: SOLR-4852-test-failhard.txt, SOLR-4852.patch, > SOLR-4852.patch > > > I have some jars in the lib directory under solr.solr.home - DIH, ICU, and > MySQL. If I set sharedLib in solr.xml to "lib" then the ICUTokenizer class > is not found, even though the jar is loaded (twice) during Solr startup. If > I set sharedLib to another location that doesn't exist, the jars are only > loaded once and there is no problem. > I'm using the old-style solr.xml on branch_4x revision 1485566. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5336) Add a simple QueryParser to parse human-entered queries.
[ https://issues.apache.org/jira/browse/LUCENE-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820196#comment-13820196 ] Michael McCandless commented on LUCENE-5336: +1, javadocs and the new test look great! > Add a simple QueryParser to parse human-entered queries. > > > Key: LUCENE-5336 > URL: https://issues.apache.org/jira/browse/LUCENE-5336 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jack Conradson > Attachments: LUCENE-5336.patch, LUCENE-5336.patch, LUCENE-5336.patch > > > I would like to add a new simple QueryParser to Lucene that is designed to > parse human-entered queries. This parser will operate on an entire entered > query using a specified single field or a set of weighted fields (using term > boost). > All features/operations in this parser can be enabled or disabled depending > on what is necessary for the user. A default operator may be specified as > either 'MUST' representing 'and' or 'SHOULD' representing 'or.' The > features/operations that this parser will include are the following: > * AND specified as '+' > * OR specified as '|' > * NOT specified as '-' > * PHRASE surrounded by double quotes > * PREFIX specified as '*' > * PRECEDENCE surrounded by '(' and ')' > * WHITESPACE specified as ' ' '\n' '\r' and '\t' will cause the default > operator to be used > * ESCAPE specified as '\' will allow operators to be used in terms > The key differences between this parser and other existing parsers will be > the following: > * No exceptions will be thrown, and errors in syntax will be ignored. The > parser will do a best-effort interpretation of any query entered. > * It uses minimal syntax to express queries. All available operators are > single characters or pairs of single characters. > * The parser is hand-written and in a single Java file making it easy to > modify. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene / Solr 4.6
Simon, A few days ago Dawid Weiss upgraded the randomized-testing and junit4-ant dependencies in the Ant build, but not in the Maven build, and as a result validate-maven-dependencies is failing now on branch_4x - I can’t get to the build log for the Jenkins run this showed up on, yesterday I think: the site keeps giving me Proxy Error pages when I try to look. Anyway, I’ll commit a fix shortly - please hold off building an RC until I do. Also, FYI, I don’t plan on committing LUCENE-5217 and LUCENE-5322 (which draw dependencies and their versions from the Ant build, and streamline Maven-related Ant build targets, respectively) to the 4.6 release branch - I plan on committing tbem later today to branch_4x only. Steve On Nov 12, 2013, at 9:32 AM, Simon Willnauer wrote: > FYI I just started a release branch http://svn.apache.org/r1541081 > > On Thu, Nov 7, 2013 at 2:01 PM, Simon Willnauer > wrote: >> Mark, I can do the release if you are busy or so I don't mind lemme >> know if you wanna do it >> >> simon >> >> On Thu, Nov 7, 2013 at 1:09 PM, Mark Miller wrote: >>> Next Tuesday sounds good to me. >>> >>> >>> On Thu, Nov 7, 2013 at 9:06 AM, Simon Willnauer >>> wrote: hey folks, I think it's time to get this going. Mark I can do the release as well do we wanna set a date? IMO I'd love to start tomorrow but I guess I will get some "I wanna get featrue XYZ in" emails so what about cutting the RC next week Tuesday? simon On Fri, Oct 25, 2013 at 5:22 AM, Otis Gospodnetic wrote: > Awesome, if you ask me. I want to try a number of new changes. > > Otis > Solr & ElasticSearch Support > http://sematext.com/ > > On Oct 24, 2013 10:14 AM, "Mark Miller" wrote: >> >> I think releasing once a month when we can is great - putting features >> into users hands faster is a dream come true :) Glad we even have the >> option >> now. We have had that cadence breifly before, and when we don’t, it’s >> usually just a lack of a volunteer. >> >> Personally, I want to get out some changes that I’ve worked on. >> >> I love release often. The stuff that doesn’t make it in will come in >> 4.7, >> which can also be not long after 4.6. >> >> I just also like a little warning first. >> >> - Mark >> >> On Oct 24, 2013, at 10:03 AM, Shai Erera wrote: >> >> Is there any reason to rush? We've released 4.5.0 just 3 weeks ago. >> >> Shai >> >> >> On Thu, Oct 24, 2013 at 4:54 PM, Adrien Grand >> wrote: >>> >>> +1 >>> >>> -- >>> Adrien >>> >>> - >>> 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 >>> >>> >>> >>> -- >>> - Mark > > - > 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-5428) new statistics results to StatsComponent - distinctValues and countDistinct
[ https://issues.apache.org/jira/browse/SOLR-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820159#comment-13820159 ] Yago Riveiro commented on SOLR-5428: This patch works in distribute queries? > new statistics results to StatsComponent - distinctValues and countDistinct > --- > > Key: SOLR-5428 > URL: https://issues.apache.org/jira/browse/SOLR-5428 > Project: Solr > Issue Type: New Feature >Reporter: Elran Dvir > Attachments: SOLR-5428.patch > > > I thought it would be very useful to display the distinct values (and the > count) of a field among other statistics. Attached a patch implementing this > in StatsComponent. > Added results : > "distinctValues" - list of all distnict values > "countDistinct" - distnict values count. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5336) Add a simple QueryParser to parse human-entered queries.
[ https://issues.apache.org/jira/browse/LUCENE-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5336: Attachment: LUCENE-5336.patch I took a swipe at trying to make the javadocs easier to read (just different layout). Also folded in Adrien's fix. > Add a simple QueryParser to parse human-entered queries. > > > Key: LUCENE-5336 > URL: https://issues.apache.org/jira/browse/LUCENE-5336 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jack Conradson > Attachments: LUCENE-5336.patch, LUCENE-5336.patch, LUCENE-5336.patch > > > I would like to add a new simple QueryParser to Lucene that is designed to > parse human-entered queries. This parser will operate on an entire entered > query using a specified single field or a set of weighted fields (using term > boost). > All features/operations in this parser can be enabled or disabled depending > on what is necessary for the user. A default operator may be specified as > either 'MUST' representing 'and' or 'SHOULD' representing 'or.' The > features/operations that this parser will include are the following: > * AND specified as '+' > * OR specified as '|' > * NOT specified as '-' > * PHRASE surrounded by double quotes > * PREFIX specified as '*' > * PRECEDENCE surrounded by '(' and ')' > * WHITESPACE specified as ' ' '\n' '\r' and '\t' will cause the default > operator to be used > * ESCAPE specified as '\' will allow operators to be used in terms > The key differences between this parser and other existing parsers will be > the following: > * No exceptions will be thrown, and errors in syntax will be ignored. The > parser will do a best-effort interpretation of any query entered. > * It uses minimal syntax to express queries. All available operators are > single characters or pairs of single characters. > * The parser is hand-written and in a single Java file making it easy to > modify. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene / Solr 4.6
FYI I just started a release branch http://svn.apache.org/r1541081 On Thu, Nov 7, 2013 at 2:01 PM, Simon Willnauer wrote: > Mark, I can do the release if you are busy or so I don't mind lemme > know if you wanna do it > > simon > > On Thu, Nov 7, 2013 at 1:09 PM, Mark Miller wrote: >> Next Tuesday sounds good to me. >> >> >> On Thu, Nov 7, 2013 at 9:06 AM, Simon Willnauer >> wrote: >>> >>> hey folks, >>> >>> I think it's time to get this going. Mark I can do the release as well >>> do we wanna set a date? IMO I'd love to start tomorrow but I guess I >>> will get some "I wanna get featrue XYZ in" emails so what about >>> cutting the RC next week Tuesday? >>> >>> simon >>> >>> On Fri, Oct 25, 2013 at 5:22 AM, Otis Gospodnetic >>> wrote: >>> > Awesome, if you ask me. I want to try a number of new changes. >>> > >>> > Otis >>> > Solr & ElasticSearch Support >>> > http://sematext.com/ >>> > >>> > On Oct 24, 2013 10:14 AM, "Mark Miller" wrote: >>> >> >>> >> I think releasing once a month when we can is great - putting features >>> >> into users hands faster is a dream come true :) Glad we even have the >>> >> option >>> >> now. We have had that cadence breifly before, and when we don’t, it’s >>> >> usually just a lack of a volunteer. >>> >> >>> >> Personally, I want to get out some changes that I’ve worked on. >>> >> >>> >> I love release often. The stuff that doesn’t make it in will come in >>> >> 4.7, >>> >> which can also be not long after 4.6. >>> >> >>> >> I just also like a little warning first. >>> >> >>> >> - Mark >>> >> >>> >> On Oct 24, 2013, at 10:03 AM, Shai Erera wrote: >>> >> >>> >> Is there any reason to rush? We've released 4.5.0 just 3 weeks ago. >>> >> >>> >> Shai >>> >> >>> >> >>> >> On Thu, Oct 24, 2013 at 4:54 PM, Adrien Grand >>> >> wrote: >>> >>> >>> >>> +1 >>> >>> >>> >>> -- >>> >>> Adrien >>> >>> >>> >>> - >>> >>> 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 >>> >> >> >> >> -- >> - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module
[ https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820115#comment-13820115 ] Joern Kottmann commented on LUCENE-2899: UIMA based NLP pipelines can use components like Solrcas or Lucas to write their results to an index. This works really well in my experience. > Add OpenNLP Analysis capabilities as a module > - > > Key: LUCENE-2899 > URL: https://issues.apache.org/jira/browse/LUCENE-2899 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 4.6 > > Attachments: LUCENE-2899-RJN.patch, LUCENE-2899.patch, > OpenNLPFilter.java, OpenNLPTokenizer.java > > > Now that OpenNLP is an ASF project and has a nice license, it would be nice > to have a submodule (under analysis) that exposed capabilities for it. Drew > Farris, Tom Morton and I have code that does: > * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it > would have to change slightly to buffer tokens) > * NamedEntity recognition as a TokenFilter > We are also planning a Tokenizer/TokenFilter that can put parts of speech as > either payloads (PartOfSpeechAttribute?) on a token or at the same position. > I'd propose it go under: > modules/analysis/opennlp -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5301) All PackedInts APIs should share a common interface for random-access reads
[ https://issues.apache.org/jira/browse/LUCENE-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820106#comment-13820106 ] ASF subversion and git services commented on LUCENE-5301: - Commit 1541064 from [~jpountz] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1541064 ] LUCENE-5301: Add a common interface to PackedInts data-structures, which extends NumericDocValues. > All PackedInts APIs should share a common interface for random-access reads > --- > > Key: LUCENE-5301 > URL: https://issues.apache.org/jira/browse/LUCENE-5301 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Fix For: 4.6 > > Attachments: LUCENE-5301.patch, LUCENE-5301.patch > > > It would be convenient if all PackedInts had a super-class with the {{long > get(long index)}} method. Maybe this super-class could even be > NumericDocValues so that doc values formats don't need to wrap eg. > BlockPackedReader into this kind of construct: > {code} > final BlockPackedReader reader = new BlockPackedReader(data, > entry.packedIntsVersion, entry.blockSize, entry.count, true); > return new LongNumericDocValues() { > @Override > public long get(long id) { > return reader.get(id); > } > }; > {code} > Instead, they could just > {code} > return new BlockPackedReader(data, entry.packedIntsVersion, > entry.blockSize, entry.count, true); > {code} -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5301) All PackedInts APIs should share a common interface for random-access reads
[ https://issues.apache.org/jira/browse/LUCENE-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-5301. -- Resolution: Fixed Fix Version/s: 4.6 > All PackedInts APIs should share a common interface for random-access reads > --- > > Key: LUCENE-5301 > URL: https://issues.apache.org/jira/browse/LUCENE-5301 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Fix For: 4.6 > > Attachments: LUCENE-5301.patch, LUCENE-5301.patch > > > It would be convenient if all PackedInts had a super-class with the {{long > get(long index)}} method. Maybe this super-class could even be > NumericDocValues so that doc values formats don't need to wrap eg. > BlockPackedReader into this kind of construct: > {code} > final BlockPackedReader reader = new BlockPackedReader(data, > entry.packedIntsVersion, entry.blockSize, entry.count, true); > return new LongNumericDocValues() { > @Override > public long get(long id) { > return reader.get(id); > } > }; > {code} > Instead, they could just > {code} > return new BlockPackedReader(data, entry.packedIntsVersion, > entry.blockSize, entry.count, true); > {code} -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5301) All PackedInts APIs should share a common interface for random-access reads
[ https://issues.apache.org/jira/browse/LUCENE-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820099#comment-13820099 ] ASF subversion and git services commented on LUCENE-5301: - Commit 1541063 from [~jpountz] in branch 'dev/trunk' [ https://svn.apache.org/r1541063 ] LUCENE-5301: Add a common interface to PackedInts data-structures, which extends NumericDocValues. > All PackedInts APIs should share a common interface for random-access reads > --- > > Key: LUCENE-5301 > URL: https://issues.apache.org/jira/browse/LUCENE-5301 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Attachments: LUCENE-5301.patch, LUCENE-5301.patch > > > It would be convenient if all PackedInts had a super-class with the {{long > get(long index)}} method. Maybe this super-class could even be > NumericDocValues so that doc values formats don't need to wrap eg. > BlockPackedReader into this kind of construct: > {code} > final BlockPackedReader reader = new BlockPackedReader(data, > entry.packedIntsVersion, entry.blockSize, entry.count, true); > return new LongNumericDocValues() { > @Override > public long get(long id) { > return reader.get(id); > } > }; > {code} > Instead, they could just > {code} > return new BlockPackedReader(data, entry.packedIntsVersion, > entry.blockSize, entry.count, true); > {code} -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module
[ https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820093#comment-13820093 ] Christian Moen commented on LUCENE-2899: bq. Stuff like this NER should NOT be in the analysis chain. as i said, its more useful in the "document build" phase anyway. +1 Benson, as far as I understand, ES doesn't have the concept by design. > Add OpenNLP Analysis capabilities as a module > - > > Key: LUCENE-2899 > URL: https://issues.apache.org/jira/browse/LUCENE-2899 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 4.6 > > Attachments: LUCENE-2899-RJN.patch, LUCENE-2899.patch, > OpenNLPFilter.java, OpenNLPTokenizer.java > > > Now that OpenNLP is an ASF project and has a nice license, it would be nice > to have a submodule (under analysis) that exposed capabilities for it. Drew > Farris, Tom Morton and I have code that does: > * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it > would have to change slightly to buffer tokens) > * NamedEntity recognition as a TokenFilter > We are also planning a Tokenizer/TokenFilter that can put parts of speech as > either payloads (PartOfSpeechAttribute?) on a token or at the same position. > I'd propose it go under: > modules/analysis/opennlp -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5336) Add a simple QueryParser to parse human-entered queries.
[ https://issues.apache.org/jira/browse/LUCENE-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820091#comment-13820091 ] Adrien Grand commented on LUCENE-5336: -- Javadocs and code seem to disagree on the default operator: javadocs say {{The default operator is AND if no other operator is specified.}} while the code has {{private BooleanClause.Occur defaultOperator = BooleanClause.Occur.SHOULD;}}? Otherwise I agree with Mike that this new query parser is awesome. I will certainly use it! > Add a simple QueryParser to parse human-entered queries. > > > Key: LUCENE-5336 > URL: https://issues.apache.org/jira/browse/LUCENE-5336 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jack Conradson > Attachments: LUCENE-5336.patch, LUCENE-5336.patch > > > I would like to add a new simple QueryParser to Lucene that is designed to > parse human-entered queries. This parser will operate on an entire entered > query using a specified single field or a set of weighted fields (using term > boost). > All features/operations in this parser can be enabled or disabled depending > on what is necessary for the user. A default operator may be specified as > either 'MUST' representing 'and' or 'SHOULD' representing 'or.' The > features/operations that this parser will include are the following: > * AND specified as '+' > * OR specified as '|' > * NOT specified as '-' > * PHRASE surrounded by double quotes > * PREFIX specified as '*' > * PRECEDENCE surrounded by '(' and ')' > * WHITESPACE specified as ' ' '\n' '\r' and '\t' will cause the default > operator to be used > * ESCAPE specified as '\' will allow operators to be used in terms > The key differences between this parser and other existing parsers will be > the following: > * No exceptions will be thrown, and errors in syntax will be ignored. The > parser will do a best-effort interpretation of any query entered. > * It uses minimal syntax to express queries. All available operators are > single characters or pairs of single characters. > * The parser is hand-written and in a single Java file making it easy to > modify. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module
[ https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820085#comment-13820085 ] Benson Margulies commented on LUCENE-2899: -- Fair enough. Solr URP's do this very well upstream of analysis. ES doesn't have the concept, perhaps it should. It clarifies the situation nicely to think of Lucene as serial token operations. > Add OpenNLP Analysis capabilities as a module > - > > Key: LUCENE-2899 > URL: https://issues.apache.org/jira/browse/LUCENE-2899 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 4.6 > > Attachments: LUCENE-2899-RJN.patch, LUCENE-2899.patch, > OpenNLPFilter.java, OpenNLPTokenizer.java > > > Now that OpenNLP is an ASF project and has a nice license, it would be nice > to have a submodule (under analysis) that exposed capabilities for it. Drew > Farris, Tom Morton and I have code that does: > * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it > would have to change slightly to buffer tokens) > * NamedEntity recognition as a TokenFilter > We are also planning a Tokenizer/TokenFilter that can put parts of speech as > either payloads (PartOfSpeechAttribute?) on a token or at the same position. > I'd propose it go under: > modules/analysis/opennlp -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5436) Eliminate the 1500ms wait in overseer loop
[ https://issues.apache.org/jira/browse/SOLR-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820082#comment-13820082 ] Shalin Shekhar Mangar commented on SOLR-5436: - As I understand it, the reason behind the wait are to group the processing of multiple events together so that the cluster state change is not broadcasted to all watching nodes too many times. But this can work along with splitting the cluster state in SOLR-5381. > Eliminate the 1500ms wait in overseer loop > -- > > Key: SOLR-5436 > URL: https://issues.apache.org/jira/browse/SOLR-5436 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > > The Overseer thread waits 1500 ms before it polls for new events. The wait > should be eliminated and it should just wait for new events till they come > the way it is done in OverseerCollectionProcessor -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module
[ https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820083#comment-13820083 ] Robert Muir commented on LUCENE-2899: - I don't think we should expand the analysis protocol: I think its actually already more complicated than it needs to be. It doesnt need to work across multiple fields or support things like NER. I know people disagree, but i dont care (typically they dont do a lot of work to maintain this code). I'll fight it to the death: Lucene's analysis is about doing information retrieval (search and query), and its already overly complex. It should stay per-field, it should stay like a state machine it is. Stuff like this NER should *NOT* be in the analysis chain. as i said, its more useful in the "document build" phase anyway. > Add OpenNLP Analysis capabilities as a module > - > > Key: LUCENE-2899 > URL: https://issues.apache.org/jira/browse/LUCENE-2899 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 4.6 > > Attachments: LUCENE-2899-RJN.patch, LUCENE-2899.patch, > OpenNLPFilter.java, OpenNLPTokenizer.java > > > Now that OpenNLP is an ASF project and has a nice license, it would be nice > to have a submodule (under analysis) that exposed capabilities for it. Drew > Farris, Tom Morton and I have code that does: > * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it > would have to change slightly to buffer tokens) > * NamedEntity recognition as a TokenFilter > We are also planning a Tokenizer/TokenFilter that can put parts of speech as > either payloads (PartOfSpeechAttribute?) on a token or at the same position. > I'd propose it go under: > modules/analysis/opennlp -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5428) new statistics results to StatsComponent - distinctValues and countDistinct
[ https://issues.apache.org/jira/browse/SOLR-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5428: - Description: I thought it would be very useful to display the distinct values (and the count) of a field among other statistics. Attached a patch implementing this in StatsComponent. Added results : "distinctValues" - list of all distnict values "countDistinct" - distnict values count. was: Added new statistics results to StatsComponent : distinctValues - list of all distnict values countDistinct - distnict values count > new statistics results to StatsComponent - distinctValues and countDistinct > --- > > Key: SOLR-5428 > URL: https://issues.apache.org/jira/browse/SOLR-5428 > Project: Solr > Issue Type: New Feature >Reporter: Elran Dvir > Attachments: SOLR-5428.patch > > > I thought it would be very useful to display the distinct values (and the > count) of a field among other statistics. Attached a patch implementing this > in StatsComponent. > Added results : > "distinctValues" - list of all distnict values > "countDistinct" - distnict values count. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5436) Eliminate the 1500ms wait in overseer loop
[ https://issues.apache.org/jira/browse/SOLR-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-5436: - Description: The Overseer thread waits 1500 ms before it polls for new events. The wait should be eliminated and it should just wait for new events till they come the way it is done in OverseerCollectionProcessor was:The Overseer thread waits 1500 ms before it polls for new events. IT should be eliminated and it should just wait for new events till they come > Eliminate the 1500ms wait in overseer loop > -- > > Key: SOLR-5436 > URL: https://issues.apache.org/jira/browse/SOLR-5436 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > > The Overseer thread waits 1500 ms before it polls for new events. The wait > should be eliminated and it should just wait for new events till they come > the way it is done in OverseerCollectionProcessor -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5436) Eliminate the 1500ms wait in overseer loop
Noble Paul created SOLR-5436: Summary: Eliminate the 1500ms wait in overseer loop Key: SOLR-5436 URL: https://issues.apache.org/jira/browse/SOLR-5436 Project: Solr Issue Type: Improvement Reporter: Noble Paul Assignee: Noble Paul Priority: Minor The Overseer thread waits 1500 ms before it polls for new events. IT should be eliminated and it should just wait for new events till they come -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module
[ https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820031#comment-13820031 ] Benson Margulies commented on LUCENE-2899: -- I know of an NER model that looks at the entire text to bias towards consistent tagging of entities in larger units. However, I agree that crocks are bad. Perhaps this is an opportunity to think about how to expand the analysis protocol to support this sort of thing more smoothly? It would be desirable if this integration were to start with a set of Token Attributes that could be used in any number of analysis components, inside or outside of Lucene, that were in a position to deliver similar items. I suppose I'm late to ask for this, as the UIMA component must pose the same question. In some languages, NER is very clumsy as a token filter, because entities don't obey token boundaries very well. Also, in my experience, entities aren't useful as additional tokens in the same field as their source text, but rather in their own field (where they can be facetted upon, for example). Is there any appetite to look at Lucene support for a stream that delivers to more than one field? Or is there such a thing and I've missed it? I agree with Rob about UIMA because I think that Lucene analysis attributes are a weak data model for interconnecting NLP modules and flowing data through them -- and one frequently needs to do that. > Add OpenNLP Analysis capabilities as a module > - > > Key: LUCENE-2899 > URL: https://issues.apache.org/jira/browse/LUCENE-2899 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 4.6 > > Attachments: LUCENE-2899-RJN.patch, LUCENE-2899.patch, > OpenNLPFilter.java, OpenNLPTokenizer.java > > > Now that OpenNLP is an ASF project and has a nice license, it would be nice > to have a submodule (under analysis) that exposed capabilities for it. Drew > Farris, Tom Morton and I have code that does: > * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it > would have to change slightly to buffer tokens) > * NamedEntity recognition as a TokenFilter > We are also planning a Tokenizer/TokenFilter that can put parts of speech as > either payloads (PartOfSpeechAttribute?) on a token or at the same position. > I'd propose it go under: > modules/analysis/opennlp -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5434) Create minimal solrcloud example directory
[ https://issues.apache.org/jira/browse/SOLR-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13819968#comment-13819968 ] Alan Woodward commented on SOLR-5434: - Thinking further, maybe an even nicer way to start things up would be to have a default new-style solr.xml that can be overridden by environment variables. Then you just tell new users to start solr up with -DzkRun -Dsolr.solr.home=/path/to/where/I/want/data/stored, and it should Just Work. No need to copy example directories anywhere. > Create minimal solrcloud example directory > -- > > Key: SOLR-5434 > URL: https://issues.apache.org/jira/browse/SOLR-5434 > Project: Solr > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Fix For: 4.6, 5.0 > > > The various "intro to solr cloud" pages (for example > https://cwiki.apache.org/confluence/display/solr/Getting+Started+with+SolrCloud) > currently tell new users to use the example/ directory as a basis for > setting up new cloud instances. These directories contain, under the default > solr/ solr home directory, a single core, defined to point to the collection1 > collection. > It's not at all obvious that, to change the name of your collection, you have > to go and edit the core.properties file underneath the solr/ directory. A > lot of users on the mailing list also seem to get confused by having to > include bootstrap_confdir and numShards the first time they run solr, but not > afterwards. So here's a suggestion: > * Have a new solrcloud/ directory in the example webapp that just contains a > solr.xml file > * Change the startup example code to just include -Dsolr.solr.home and -DzkRun > * Tell the user to then run zkcli to bootstrap their configuration (solr > startup and configuration loading are kept separate) > * Tell the users to use the collections API to create a new collection, > naming it however they want (confignames, collection names and core names are > all kept separate) > This way, there's a lot less 'magic' and hidden defaults involved, and all > the steps to get a cloud up and running (start processes, upload > configuration, create collection) are made distinguishable. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org