[jira] [Resolved] (SOLR-13549) Maven build fails to build Solr core tests due to missing dependency
[ https://issues.apache.org/jira/browse/SOLR-13549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins resolved SOLR-13549. --- Resolution: Fixed Fix Version/s: 8.2 master (9.0) The patch was merged as part of SOLR-13434, so this is fixed. > Maven build fails to build Solr core tests due to missing dependency > > > Key: SOLR-13549 > URL: https://issues.apache.org/jira/browse/SOLR-13549 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: master (9.0), 8.2 >Reporter: Daniel Collins >Priority: Minor > Fix For: master (9.0), 8.2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > If I run > ant get-maven-poms > mvn -f maven-build/pom.xml install -DskipTests > On master or branch_8x, it fails to build the Solr tests due to a dependency > on opentracing-mock. Eclipse builds fine (because it uses a single classpath > with everything in it), and not entirely sure how ant builds... > But the solr/core/ivy.xml doesn't have a dependency on opentracing-mock > (though it has all the other opentracing modules) > [https://github.com/apache/lucene-solr/pull/720] for the fix > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865061#comment-16865061 ] Daniel Collins commented on SOLR-13434: --- [https://github.com/apache/lucene-solr/pull/720] might help, I entered that for SOLR-13549, which was specifically about the Solr tests not building due to a dependency on opentracking-mock. Currently my branch_8x isn't building with Maven due to forbiddenapi issues, but I'll try again later > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 7h 40m > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13549) Maven build fails to build Solr core tests due to missing dependency
[ https://issues.apache.org/jira/browse/SOLR-13549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated SOLR-13549: -- Description: If I run ant get-maven-poms mvn -f maven-build/pom.xml install -DskipTests On master or branch_8x, it fails to build the Solr tests due to a dependency on opentracing-mock. Eclipse builds fine (because it uses a single classpath with everything in it), and not entirely sure how ant builds... But the solr/core/ivy.xml doesn't have a dependency on opentracing-mock (though it has all the other opentracing modules) [https://github.com/apache/lucene-solr/pull/720] for the fix was: If I run ant get-maven-poms mvn -f maven-build/pom.xml install -DskipTests On master or branch_8x, it fails to build the Solr tests due to a dependency on opentracing-mock. Eclipse builds fine (because it uses a single classpath with everything in it), and not entirely sure how ant builds... But the solr/core/ivy.xml doesn't have a dependency on opentracing-mock (though it has all the other opentracing modules) Will create a simple PR to add that dependency. > Maven build fails to build Solr core tests due to missing dependency > > > Key: SOLR-13549 > URL: https://issues.apache.org/jira/browse/SOLR-13549 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: master (9.0), 8.2 >Reporter: Daniel Collins >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > If I run > ant get-maven-poms > mvn -f maven-build/pom.xml install -DskipTests > On master or branch_8x, it fails to build the Solr tests due to a dependency > on opentracing-mock. Eclipse builds fine (because it uses a single classpath > with everything in it), and not entirely sure how ant builds... > But the solr/core/ivy.xml doesn't have a dependency on opentracing-mock > (though it has all the other opentracing modules) > [https://github.com/apache/lucene-solr/pull/720] for the fix > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13549) Maven build fails to build Solr core tests due to missing dependency
Daniel Collins created SOLR-13549: - Summary: Maven build fails to build Solr core tests due to missing dependency Key: SOLR-13549 URL: https://issues.apache.org/jira/browse/SOLR-13549 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: Build Affects Versions: master (9.0), 8.2 Reporter: Daniel Collins If I run ant get-maven-poms mvn -f maven-build/pom.xml install -DskipTests On master or branch_8x, it fails to build the Solr tests due to a dependency on opentracing-mock. Eclipse builds fine (because it uses a single classpath with everything in it), and not entirely sure how ant builds... But the solr/core/ivy.xml doesn't have a dependency on opentracing-mock (though it has all the other opentracing modules) Will create a simple PR to add that dependency. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8766) Add Luwak as a lucene module
[ https://issues.apache.org/jira/browse/LUCENE-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829019#comment-16829019 ] Daniel Collins commented on LUCENE-8766: [~romseygeek], [https://github.com/romseygeek/lucene-solr/pull/5] adds Maven build support and fixes some unused imports to this PR. > Add Luwak as a lucene module > > > Key: LUCENE-8766 > URL: https://issues.apache.org/jira/browse/LUCENE-8766 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Luwak [https://github.com/flaxsearch/luwak] is a stored query engine, > allowing users to efficiently match a stream of documents against a large set > of queries. It's only dependency is lucene, and most recent updates have > just been upgrading the version of lucene against which it can run. > It's a generally useful piece of software, and already licensed as Apache 2. > The maintainers would like to donate it to the ASF, and merge it in to the > lucene-solr project. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8782) Maven build has a typo when building Backwards Codecs
[ https://issues.apache.org/jira/browse/LUCENE-8782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated LUCENE-8782: --- Lucene Fields: New,Patch Available (was: New) > Maven build has a typo when building Backwards Codecs > - > > Key: LUCENE-8782 > URL: https://issues.apache.org/jira/browse/LUCENE-8782 > Project: Lucene - Core > Issue Type: Bug > Components: core/codecs, general/build >Affects Versions: master (9.0) >Reporter: Daniel Collins >Priority: Trivial > > Noticed a trivial naming issue in the maven build, it builds "Lucene memory" > twice! > [INFO] Reactor Build Order: > [INFO] > [INFO] Grandparent POM for Apache Lucene Core and Apache Solr [pom] > [INFO] Lucene parent POM [pom] > [INFO] Lucene Core [jar] > [INFO] Lucene codecs [jar] > [INFO] Lucene Test Framework [jar] > [INFO] Lucene Core tests [jar] > [INFO] Lucene Core aggregator POM [pom] > [INFO] Lucene Memory [jar] > [INFO] Lucene codecs tests [jar] > ... > [INFO] Lucene QueryParsers [jar] > [INFO] Lucene Memory [jar] > [INFO] Lucene Highlighter [jar] > > Turned out that backwards codecs has a typo in its pom.xml.template. > Attached a trivial patch to fix that. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8782) Maven build has a typo when building Backwards Codecs
Daniel Collins created LUCENE-8782: -- Summary: Maven build has a typo when building Backwards Codecs Key: LUCENE-8782 URL: https://issues.apache.org/jira/browse/LUCENE-8782 Project: Lucene - Core Issue Type: Bug Components: core/codecs, general/build Affects Versions: master (9.0) Reporter: Daniel Collins Noticed a trivial naming issue in the maven build, it builds "Lucene memory" twice! [INFO] Reactor Build Order: [INFO] [INFO] Grandparent POM for Apache Lucene Core and Apache Solr [pom] [INFO] Lucene parent POM [pom] [INFO] Lucene Core [jar] [INFO] Lucene codecs [jar] [INFO] Lucene Test Framework [jar] [INFO] Lucene Core tests [jar] [INFO] Lucene Core aggregator POM [pom] [INFO] Lucene Memory [jar] [INFO] Lucene codecs tests [jar] ... [INFO] Lucene QueryParsers [jar] [INFO] Lucene Memory [jar] [INFO] Lucene Highlighter [jar] Turned out that backwards codecs has a typo in its pom.xml.template. Attached a trivial patch to fix that. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11579) Building Solr (master) using Java 11 with Maven has some old plugins
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825819#comment-16825819 ] Daniel Collins commented on SOLR-11579: --- The only remaining item here is patching the last few Maven modules (maven-surefire-plugin, and maven-bundle-plugin), and switching gmaven plugin to groovy-maven-plugin. Other than that, all the old issues are now resolved. [~erickerickson] should I just withdraw this and create a new one with the small patch (this ticket has kind of gone full circle!) or should we still keep it as part of this? > Building Solr (master) using Java 11 with Maven has some old plugins > > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 8.0 > Environment: Apache Maven 3.6.0 > (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T19:41:47+01:00) > Maven home: C:\Users\CollinsDaniel\Utils\apache-maven-3.6.0\bin\.. > Java version: 11.0.2, vendor: Oracle Corporation, runtime: > C:\Users\CollinsDaniel\Utils\jdk-11.0.2 > Default locale: en_GB, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > openjdk version "11.0.2" 2019-01-15 > OpenJDK Runtime Environment 18.9 (build 11.0.2+9) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579.patch > > > I'm calling this minor as I don't believe we officially support Java 11 (but > correct me if I'm wrong), and I've only tried on master > Several issues/notes: > # -enforcer plugin breaks if you try to do mvn install- > # -javadoc plugin breaks if you try to do mvn javadoc:jar (on Windows)- > # warnings from groovy-maven-plugin (TODO) > # -a lot of the maven plugins are quite old- > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > There is a patch for 3 now -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11579) Building Solr (master) using Java 11 and Maven has some issues
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated SOLR-11579: -- Attachment: (was: SOLR-11579_4) > Building Solr (master) using Java 11 and Maven has some issues > -- > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 8.0 > Environment: Apache Maven 3.6.0 > (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T19:41:47+01:00) > Maven home: C:\Users\CollinsDaniel\Utils\apache-maven-3.6.0\bin\.. > Java version: 11.0.2, vendor: Oracle Corporation, runtime: > C:\Users\CollinsDaniel\Utils\jdk-11.0.2 > Default locale: en_GB, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > openjdk version "11.0.2" 2019-01-15 > OpenJDK Runtime Environment 18.9 (build 11.0.2+9) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579.patch > > > I'm calling this minor as I don't believe we officially support Java 11 (but > correct me if I'm wrong), and I've only tried on master > Several issues/notes: > # -enforcer plugin breaks if you try to do mvn install- > # -javadoc plugin breaks if you try to do mvn javadoc:jar (on Windows)- > # warnings from groovy-maven-plugin (TODO) > # -a lot of the maven plugins are quite old- > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11579) Building Solr (master) using Java 11 with Maven has some old plugins
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated SOLR-11579: -- Summary: Building Solr (master) using Java 11 with Maven has some old plugins (was: Building Solr (master) using Java 11 and Maven has some issues) > Building Solr (master) using Java 11 with Maven has some old plugins > > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 8.0 > Environment: Apache Maven 3.6.0 > (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T19:41:47+01:00) > Maven home: C:\Users\CollinsDaniel\Utils\apache-maven-3.6.0\bin\.. > Java version: 11.0.2, vendor: Oracle Corporation, runtime: > C:\Users\CollinsDaniel\Utils\jdk-11.0.2 > Default locale: en_GB, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > openjdk version "11.0.2" 2019-01-15 > OpenJDK Runtime Environment 18.9 (build 11.0.2+9) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579.patch > > > I'm calling this minor as I don't believe we officially support Java 11 (but > correct me if I'm wrong), and I've only tried on master > Several issues/notes: > # -enforcer plugin breaks if you try to do mvn install- > # -javadoc plugin breaks if you try to do mvn javadoc:jar (on Windows)- > # warnings from groovy-maven-plugin (TODO) > # -a lot of the maven plugins are quite old- > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11579) Building Solr (master) using Java 11 and Maven has some issues
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated SOLR-11579: -- Attachment: SOLR-11579.patch > Building Solr (master) using Java 11 and Maven has some issues > -- > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 8.0 > Environment: Apache Maven 3.6.0 > (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T19:41:47+01:00) > Maven home: C:\Users\CollinsDaniel\Utils\apache-maven-3.6.0\bin\.. > Java version: 11.0.2, vendor: Oracle Corporation, runtime: > C:\Users\CollinsDaniel\Utils\jdk-11.0.2 > Default locale: en_GB, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > openjdk version "11.0.2" 2019-01-15 > OpenJDK Runtime Environment 18.9 (build 11.0.2+9) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579.patch > > > I'm calling this minor as I don't believe we officially support Java 11 (but > correct me if I'm wrong), and I've only tried on master > Several issues/notes: > # -enforcer plugin breaks if you try to do mvn install- > # -javadoc plugin breaks if you try to do mvn javadoc:jar (on Windows)- > # warnings from groovy-maven-plugin (TODO) > # -a lot of the maven plugins are quite old- > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11579) Building Solr (master) using Java 11 and Maven has some issues
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated SOLR-11579: -- Attachment: (was: SOLR-11579_2) > Building Solr (master) using Java 11 and Maven has some issues > -- > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 8.0 > Environment: Apache Maven 3.6.0 > (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T19:41:47+01:00) > Maven home: C:\Users\CollinsDaniel\Utils\apache-maven-3.6.0\bin\.. > Java version: 11.0.2, vendor: Oracle Corporation, runtime: > C:\Users\CollinsDaniel\Utils\jdk-11.0.2 > Default locale: en_GB, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > openjdk version "11.0.2" 2019-01-15 > OpenJDK Runtime Environment 18.9 (build 11.0.2+9) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579.patch > > > I'm calling this minor as I don't believe we officially support Java 11 (but > correct me if I'm wrong), and I've only tried on master > Several issues/notes: > # -enforcer plugin breaks if you try to do mvn install- > # -javadoc plugin breaks if you try to do mvn javadoc:jar (on Windows)- > # warnings from groovy-maven-plugin (TODO) > # -a lot of the maven plugins are quite old- > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11579) Building Solr (master) using Java 11 with Maven has some old plugins
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated SOLR-11579: -- Description: I'm calling this minor as I don't believe we officially support Java 11 (but correct me if I'm wrong), and I've only tried on master Several issues/notes: # -enforcer plugin breaks if you try to do mvn install- # -javadoc plugin breaks if you try to do mvn javadoc:jar (on Windows)- # warnings from groovy-maven-plugin (TODO) # -a lot of the maven plugins are quite old- # forbiddenapis has some issues with Solr (I assume due to module split-up, javax is no longer part of core) (TODO) There is a patch for 3 now was: I'm calling this minor as I don't believe we officially support Java 11 (but correct me if I'm wrong), and I've only tried on master Several issues/notes: # -enforcer plugin breaks if you try to do mvn install- # -javadoc plugin breaks if you try to do mvn javadoc:jar (on Windows)- # warnings from groovy-maven-plugin (TODO) # -a lot of the maven plugins are quite old- # forbiddenapis has some issues with Solr (I assume due to module split-up, javax is no longer part of core) (TODO) I have patches for 1, 2, and 4. Still working on 3 and 5. > Building Solr (master) using Java 11 with Maven has some old plugins > > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 8.0 > Environment: Apache Maven 3.6.0 > (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T19:41:47+01:00) > Maven home: C:\Users\CollinsDaniel\Utils\apache-maven-3.6.0\bin\.. > Java version: 11.0.2, vendor: Oracle Corporation, runtime: > C:\Users\CollinsDaniel\Utils\jdk-11.0.2 > Default locale: en_GB, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > openjdk version "11.0.2" 2019-01-15 > OpenJDK Runtime Environment 18.9 (build 11.0.2+9) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579.patch > > > I'm calling this minor as I don't believe we officially support Java 11 (but > correct me if I'm wrong), and I've only tried on master > Several issues/notes: > # -enforcer plugin breaks if you try to do mvn install- > # -javadoc plugin breaks if you try to do mvn javadoc:jar (on Windows)- > # warnings from groovy-maven-plugin (TODO) > # -a lot of the maven plugins are quite old- > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > There is a patch for 3 now -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11579) Building Solr (master) using Java 11 and Maven has some issues
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16824914#comment-16824914 ] Daniel Collins commented on SOLR-11579: --- I now have openjdk 11 on both Linux and Windows. The javadoc plugin issue has gone away (mvn javadoc:jar fails on Windows for some other reason, still trying to work out what that is, but it works on Linux and ant documentation works on Windows). Most of the plugins are now updated, there are a few left, so I'll put a small patch together for that. > Building Solr (master) using Java 11 and Maven has some issues > -- > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 8.0 > Environment: Apache Maven 3.6.0 > (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T19:41:47+01:00) > Maven home: C:\Users\CollinsDaniel\Utils\apache-maven-3.6.0\bin\.. > Java version: 11.0.2, vendor: Oracle Corporation, runtime: > C:\Users\CollinsDaniel\Utils\jdk-11.0.2 > Default locale: en_GB, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > openjdk version "11.0.2" 2019-01-15 > OpenJDK Runtime Environment 18.9 (build 11.0.2+9) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579_2, SOLR-11579_4 > > > I'm calling this minor as I don't believe we officially support Java 11 (but > correct me if I'm wrong), and I've only tried on master > Several issues/notes: > # -enforcer plugin breaks if you try to do mvn install- > # -javadoc plugin breaks if you try to do mvn javadoc:jar (on Windows)- > # warnings from groovy-maven-plugin (TODO) > # -a lot of the maven plugins are quite old- > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11579) Building Solr (master) using Java 11 and Maven has some issues
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated SOLR-11579: -- Description: I'm calling this minor as I don't believe we officially support Java 11 (but correct me if I'm wrong), and I've only tried on master Several issues/notes: # -enforcer plugin breaks if you try to do mvn install- # -javadoc plugin breaks if you try to do mvn javadoc:jar (on Windows)- # warnings from groovy-maven-plugin (TODO) # -a lot of the maven plugins are quite old- # forbiddenapis has some issues with Solr (I assume due to module split-up, javax is no longer part of core) (TODO) I have patches for 1, 2, and 4. Still working on 3 and 5. was: I'm calling this minor as I don't believe we officially support Java 11 (but correct me if I'm wrong), and I've only tried on master Several issues/notes: # -enforcer plugin breaks if you try to do mvn install- # -javadoc plugin breaks if you try to do mvn javadoc:jar (on Windows)- # warnings from groovy-maven-plugin (TODO) # a lot of the maven plugins are quite old # forbiddenapis has some issues with Solr (I assume due to module split-up, javax is no longer part of core) (TODO) I have patches for 1, 2, and 4. Still working on 3 and 5. > Building Solr (master) using Java 11 and Maven has some issues > -- > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 8.0 > Environment: Apache Maven 3.6.0 > (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T19:41:47+01:00) > Maven home: C:\Users\CollinsDaniel\Utils\apache-maven-3.6.0\bin\.. > Java version: 11.0.2, vendor: Oracle Corporation, runtime: > C:\Users\CollinsDaniel\Utils\jdk-11.0.2 > Default locale: en_GB, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > openjdk version "11.0.2" 2019-01-15 > OpenJDK Runtime Environment 18.9 (build 11.0.2+9) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579_2, SOLR-11579_4 > > > I'm calling this minor as I don't believe we officially support Java 11 (but > correct me if I'm wrong), and I've only tried on master > Several issues/notes: > # -enforcer plugin breaks if you try to do mvn install- > # -javadoc plugin breaks if you try to do mvn javadoc:jar (on Windows)- > # warnings from groovy-maven-plugin (TODO) > # -a lot of the maven plugins are quite old- > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11579) Building Solr (master) using Java 11 and Maven has some issues
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated SOLR-11579: -- Description: I'm calling this minor as I don't believe we officially support Java 11 (but correct me if I'm wrong), and I've only tried on master Several issues/notes: # -enforcer plugin breaks if you try to do mvn install- # -javadoc plugin breaks if you try to do mvn javadoc:jar (on Windows)- # warnings from groovy-maven-plugin (TODO) # a lot of the maven plugins are quite old # forbiddenapis has some issues with Solr (I assume due to module split-up, javax is no longer part of core) (TODO) I have patches for 1, 2, and 4. Still working on 3 and 5. was: I'm calling this minor as I don't believe we officially support Java 11 (but correct me if I'm wrong), and I've only tried on master Several issues/notes: # -enforcer plugin breaks if you try to do mvn install- # javadoc plugin breaks if you try to do mvn javadoc:jar (on Windows) # warnings from groovy-maven-plugin (TODO) # a lot of the maven plugins are quite old # forbiddenapis has some issues with Solr (I assume due to module split-up, javax is no longer part of core) (TODO) I have patches for 1, 2, and 4. Still working on 3 and 5. > Building Solr (master) using Java 11 and Maven has some issues > -- > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 8.0 > Environment: Apache Maven 3.6.0 > (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T19:41:47+01:00) > Maven home: C:\Users\CollinsDaniel\Utils\apache-maven-3.6.0\bin\.. > Java version: 11.0.2, vendor: Oracle Corporation, runtime: > C:\Users\CollinsDaniel\Utils\jdk-11.0.2 > Default locale: en_GB, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > openjdk version "11.0.2" 2019-01-15 > OpenJDK Runtime Environment 18.9 (build 11.0.2+9) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579_2, SOLR-11579_4 > > > I'm calling this minor as I don't believe we officially support Java 11 (but > correct me if I'm wrong), and I've only tried on master > Several issues/notes: > # -enforcer plugin breaks if you try to do mvn install- > # -javadoc plugin breaks if you try to do mvn javadoc:jar (on Windows)- > # warnings from groovy-maven-plugin (TODO) > # a lot of the maven plugins are quite old > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8766) Add Luwak as a lucene module
[ https://issues.apache.org/jira/browse/LUCENE-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819816#comment-16819816 ] Daniel Collins commented on LUCENE-8766: +1 from me, we use Luwak in several places within my organisation and trying to keep it in sync with Lucene is a challenge. > Add Luwak as a lucene module > > > Key: LUCENE-8766 > URL: https://issues.apache.org/jira/browse/LUCENE-8766 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Luwak [https://github.com/flaxsearch/luwak] is a stored query engine, > allowing users to efficiently match a stream of documents against a large set > of queries. It's only dependency is lucene, and most recent updates have > just been upgrading the version of lucene against which it can run. > It's a generally useful piece of software, and already licensed as Apache 2. > The maintainers would like to donate it to the ASF, and merge it in to the > lucene-solr project. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11579) Building Solr (master) using Java 11 and Maven has some issues
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated SOLR-11579: -- Summary: Building Solr (master) using Java 11 and Maven has some issues (was: Building Solr using Java 9 and Maven doesn't work) > Building Solr (master) using Java 11 and Maven has some issues > -- > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 8.0 > Environment: Apache Maven 3.6.0 > (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T19:41:47+01:00) > Maven home: C:\Users\CollinsDaniel\Utils\apache-maven-3.6.0\bin\.. > Java version: 11.0.2, vendor: Oracle Corporation, runtime: > C:\Users\CollinsDaniel\Utils\jdk-11.0.2 > Default locale: en_GB, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > openjdk version "11.0.2" 2019-01-15 > OpenJDK Runtime Environment 18.9 (build 11.0.2+9) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579_2, SOLR-11579_4 > > > I'm calling this minor as I don't believe we officially support Java 11 (but > correct me if I'm wrong), and I've only tried on master > Several issues/notes: > # -enforcer plugin breaks if you try to do mvn install- > # javadoc plugin breaks if you try to do mvn javadoc:jar (on Windows) > # warnings from groovy-maven-plugin (TODO) > # a lot of the maven plugins are quite old > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11579) Building Solr using Java 9 and Maven doesn't work
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated SOLR-11579: -- Description: I'm calling this minor as I don't believe we officially support Java 11 (but correct me if I'm wrong), and I've only tried on master Several issues/notes: # -enforcer plugin breaks if you try to do mvn install- # javadoc plugin breaks if you try to do mvn javadoc:jar (on Windows) # warnings from groovy-maven-plugin (TODO) # a lot of the maven plugins are quite old # forbiddenapis has some issues with Solr (I assume due to module split-up, javax is no longer part of core) (TODO) I have patches for 1, 2, and 4. Still working on 3 and 5. was: I'm calling this minor as I don't believe we officially support Java 9 (but correct me if I'm wrong), and I've only tried on master (again, I don't *think* branch_7x is setup for Java 9?) Several issues/notes: # -enforcer plugin breaks if you try to do mvn install- # javadoc plugin breaks if you try to do mvn javadoc:jar # warnings from groovy-maven-plugin (TODO) # a lot of the maven plugins are quite old # forbiddenapis has some issues with Solr (I assume due to module split-up, javax is no longer part of core) (TODO) I have patches for 1, 2, and 4. Still working on 3 and 5. > Building Solr using Java 9 and Maven doesn't work > - > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 8.0 > Environment: Apache Maven 3.6.0 > (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T19:41:47+01:00) > Maven home: C:\Users\CollinsDaniel\Utils\apache-maven-3.6.0\bin\.. > Java version: 11.0.2, vendor: Oracle Corporation, runtime: > C:\Users\CollinsDaniel\Utils\jdk-11.0.2 > Default locale: en_GB, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > openjdk version "11.0.2" 2019-01-15 > OpenJDK Runtime Environment 18.9 (build 11.0.2+9) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579_2, SOLR-11579_4 > > > I'm calling this minor as I don't believe we officially support Java 11 (but > correct me if I'm wrong), and I've only tried on master > Several issues/notes: > # -enforcer plugin breaks if you try to do mvn install- > # javadoc plugin breaks if you try to do mvn javadoc:jar (on Windows) > # warnings from groovy-maven-plugin (TODO) > # a lot of the maven plugins are quite old > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11579) Building Solr using Java 9 and Maven doesn't work
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated SOLR-11579: -- Attachment: (was: SOLR-11579_1) > Building Solr using Java 9 and Maven doesn't work > - > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 8.0 > Environment: Apache Maven 3.6.0 > (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T19:41:47+01:00) > Maven home: C:\Users\CollinsDaniel\Utils\apache-maven-3.6.0\bin\.. > Java version: 11.0.2, vendor: Oracle Corporation, runtime: > C:\Users\CollinsDaniel\Utils\jdk-11.0.2 > Default locale: en_GB, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > openjdk version "11.0.2" 2019-01-15 > OpenJDK Runtime Environment 18.9 (build 11.0.2+9) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579_2, SOLR-11579_4 > > > I'm calling this minor as I don't believe we officially support Java 9 (but > correct me if I'm wrong), and I've only tried on master (again, I don't > *think* branch_7x is setup for Java 9?) > Several issues/notes: > # -enforcer plugin breaks if you try to do mvn install- > # javadoc plugin breaks if you try to do mvn javadoc:jar > # warnings from groovy-maven-plugin (TODO) > # a lot of the maven plugins are quite old > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11579) Building Solr using Java 9 and Maven doesn't work
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806577#comment-16806577 ] Daniel Collins commented on SOLR-11579: --- Ok, using openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4) OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, mixed mode) On Linux, the javadoc target works fine. However, on Windows (as above), it doesn't work with the existing plugin version. Switching the plugin version to 3.x seems to work, I'll update the patch for that. > Building Solr using Java 9 and Maven doesn't work > - > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 8.0 > Environment: Apache Maven 3.6.0 > (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T19:41:47+01:00) > Maven home: C:\Users\CollinsDaniel\Utils\apache-maven-3.6.0\bin\.. > Java version: 11.0.2, vendor: Oracle Corporation, runtime: > C:\Users\CollinsDaniel\Utils\jdk-11.0.2 > Default locale: en_GB, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > openjdk version "11.0.2" 2019-01-15 > OpenJDK Runtime Environment 18.9 (build 11.0.2+9) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579_1, SOLR-11579_2, SOLR-11579_4 > > > I'm calling this minor as I don't believe we officially support Java 9 (but > correct me if I'm wrong), and I've only tried on master (again, I don't > *think* branch_7x is setup for Java 9?) > Several issues/notes: > # -enforcer plugin breaks if you try to do mvn install- > # javadoc plugin breaks if you try to do mvn javadoc:jar > # warnings from groovy-maven-plugin (TODO) > # a lot of the maven plugins are quite old > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11579) Building Solr using Java 9 and Maven doesn't work
[
https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806017#comment-16806017
]
Daniel Collins edited comment on SOLR-11579 at 4/1/19 9:01 AM:
---
mvn install seems okay on master with openjdk "11.0.2" for windows) so
withdrawing that item.
mvn javadoc:jar (on master with openjdk version "11.0.2" for windows) still
fails
{{[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar (default-cli) on
project lucene-core: MavenReportException: Error while creating archive:}}
{{[ERROR] Exit code: 1 - javadoc: error - The code being documented uses
modules but the packages defined in [http://docs.oracle.com/javase/7/docs/api/]
are in the unnamed module.
{{[ERROR]}}
{{[ERROR] Command line was:
C:\Users\CollinsDaniel\Utils\jdk-11.0.2\bin\javadoc.exe @options @packages}}
{{[ERROR]}}
{{[ERROR] Refer to the generated Javadoc files in
'C:\Users\CollinsDaniel\Work\3rdparty\lucene-solr-7\maven-build\lucene\core\src\java\target\apidocs'
dir.}}
was (Author: dancollins):
mvn install seems okay on master with openjdk "11.0.2" for windows) so
withdrawing that issue.
mvn javadoc:jar (on master with openjdk version "11.0.2" for windows) still
fails
{{[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar (default-cli) on
project lucene-core: MavenReportException: Error while creating archive:}}
{{[ERROR] Exit code: 1 - javadoc: error - The code being documented uses
modules but the packages defined in [http://docs.oracle.com/javase/7/docs/api/]
are in the unnamed module.
{{[ERROR]}}
{{[ERROR] Command line was:
C:\Users\CollinsDaniel\Utils\jdk-11.0.2\bin\javadoc.exe @options @packages}}
{{[ERROR]}}
{{[ERROR] Refer to the generated Javadoc files in
'C:\Users\CollinsDaniel\Work\3rdparty\lucene-solr-7\maven-build\lucene\core\src\java\target\apidocs'
dir.}}
> Building Solr using Java 9 and Maven doesn't work
> -
>
> Key: SOLR-11579
> URL: https://issues.apache.org/jira/browse/SOLR-11579
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Affects Versions: 8.0
> Environment: Apache Maven 3.6.0
> (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T19:41:47+01:00)
> Maven home: C:\Users\CollinsDaniel\Utils\apache-maven-3.6.0\bin\..
> Java version: 11.0.2, vendor: Oracle Corporation, runtime:
> C:\Users\CollinsDaniel\Utils\jdk-11.0.2
> Default locale: en_GB, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> openjdk version "11.0.2" 2019-01-15
> OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
> OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
>Reporter: Daniel Collins
>Priority: Minor
> Labels: maven, maven-enforcer-plugin
> Attachments: SOLR-11579_1, SOLR-11579_2, SOLR-11579_4
>
>
> I'm calling this minor as I don't believe we officially support Java 9 (but
> correct me if I'm wrong), and I've only tried on master (again, I don't
> *think* branch_7x is setup for Java 9?)
> Several issues/notes:
> # -enforcer plugin breaks if you try to do mvn install-
> # javadoc plugin breaks if you try to do mvn javadoc:jar
> # warnings from groovy-maven-plugin (TODO)
> # a lot of the maven plugins are quite old
> # forbiddenapis has some issues with Solr (I assume due to module split-up,
> javax is no longer part of core) (TODO)
> I have patches for 1, 2, and 4. Still working on 3 and 5.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11579) Building Solr using Java 9 and Maven doesn't work
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated SOLR-11579: -- Environment: Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T19:41:47+01:00) Maven home: C:\Users\CollinsDaniel\Utils\apache-maven-3.6.0\bin\.. Java version: 11.0.2, vendor: Oracle Corporation, runtime: C:\Users\CollinsDaniel\Utils\jdk-11.0.2 Default locale: en_GB, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" openjdk version "11.0.2" 2019-01-15 OpenJDK Runtime Environment 18.9 (build 11.0.2+9) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) was: Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T20:39:06+01:00) Maven home: /Users/dcollins53/Utils/apache-maven-3.5.0 Java version: 9, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home Default locale: en_GB, platform encoding: UTF-8 OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac" java version "9" Java(TM) SE Runtime Environment (build 9+181) Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) > Building Solr using Java 9 and Maven doesn't work > - > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 8.0 > Environment: Apache Maven 3.6.0 > (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T19:41:47+01:00) > Maven home: C:\Users\CollinsDaniel\Utils\apache-maven-3.6.0\bin\.. > Java version: 11.0.2, vendor: Oracle Corporation, runtime: > C:\Users\CollinsDaniel\Utils\jdk-11.0.2 > Default locale: en_GB, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > openjdk version "11.0.2" 2019-01-15 > OpenJDK Runtime Environment 18.9 (build 11.0.2+9) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579_1, SOLR-11579_2, SOLR-11579_4 > > > I'm calling this minor as I don't believe we officially support Java 9 (but > correct me if I'm wrong), and I've only tried on master (again, I don't > *think* branch_7x is setup for Java 9?) > Several issues/notes: > # -enforcer plugin breaks if you try to do mvn install- > # javadoc plugin breaks if you try to do mvn javadoc:jar > # warnings from groovy-maven-plugin (TODO) > # a lot of the maven plugins are quite old > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11579) Building Solr using Java 9 and Maven doesn't work
[
https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806017#comment-16806017
]
Daniel Collins edited comment on SOLR-11579 at 3/30/19 11:02 PM:
-
mvn install seems okay on master with openjdk "11.0.2" for windows) so
withdrawing that issue.
mvn javadoc:jar (on master with openjdk version "11.0.2" for windows) still
fails
{{[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar (default-cli) on
project lucene-core: MavenReportException: Error while creating archive:}}
{{[ERROR] Exit code: 1 - javadoc: error - The code being documented uses
modules but the packages defined in [http://docs.oracle.com/javase/7/docs/api/]
are in the unnamed module.
{{[ERROR]}}
{{[ERROR] Command line was:
C:\Users\CollinsDaniel\Utils\jdk-11.0.2\bin\javadoc.exe @options @packages}}
{{[ERROR]}}
{{[ERROR] Refer to the generated Javadoc files in
'C:\Users\CollinsDaniel\Work\3rdparty\lucene-solr-7\maven-build\lucene\core\src\java\target\apidocs'
dir.}}
was (Author: dancollins):
mvn install seems okay on master with openjdk "11.0.2" for windows) so
withdrawing that issue.
mvn javadoc:jar (on master with openjdk version "11.0.2" for windows) still
fails
{{[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar (default-cli) on
project lucene-core: MavenReportException: Error while creating archive:}}
{{ [ERROR] Exit code: 1 - javadoc: error - The code being documented uses
modules but the packages defined in [http://docs.oracle.com/javase/7/docs/api/]
are in the unnamed module.}}
{{ [ERROR]}}
{{ [ERROR] Command line was:
C:\Users\CollinsDaniel\Utils\jdk-11.0.2\bin\javadoc.exe @options @packages}}
{{ [ERROR]}}
{{ [ERROR] Refer to the generated Javadoc files in
'C:\Users\CollinsDaniel\Work\3rdparty\lucene-solr-7\maven-build\lucene\core\src\java\target\apidocs'
dir.}}
> Building Solr using Java 9 and Maven doesn't work
> -
>
> Key: SOLR-11579
> URL: https://issues.apache.org/jira/browse/SOLR-11579
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Affects Versions: 8.0
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T20:39:06+01:00)
> Maven home: /Users/dcollins53/Utils/apache-maven-3.5.0
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
> java version "9"
> Java(TM) SE Runtime Environment (build 9+181)
> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>Reporter: Daniel Collins
>Priority: Minor
> Labels: maven, maven-enforcer-plugin
> Attachments: SOLR-11579_1, SOLR-11579_2, SOLR-11579_4
>
>
> I'm calling this minor as I don't believe we officially support Java 9 (but
> correct me if I'm wrong), and I've only tried on master (again, I don't
> *think* branch_7x is setup for Java 9?)
> Several issues/notes:
> # -enforcer plugin breaks if you try to do mvn install-
> # javadoc plugin breaks if you try to do mvn javadoc:jar
> # warnings from groovy-maven-plugin (TODO)
> # a lot of the maven plugins are quite old
> # forbiddenapis has some issues with Solr (I assume due to module split-up,
> javax is no longer part of core) (TODO)
> I have patches for 1, 2, and 4. Still working on 3 and 5.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11579) Building Solr using Java 9 and Maven doesn't work
[
https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806017#comment-16806017
]
Daniel Collins edited comment on SOLR-11579 at 3/30/19 11:02 PM:
-
mvn install seems okay on master with openjdk "11.0.2" for windows) so
withdrawing that issue.
mvn javadoc:jar (on master with openjdk version "11.0.2" for windows) still
fails
{{[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar (default-cli) on
project lucene-core: MavenReportException: Error while creating archive:}}
{{ [ERROR] Exit code: 1 - javadoc: error - The code being documented uses
modules but the packages defined in [http://docs.oracle.com/javase/7/docs/api/]
are in the unnamed module.}}
{{ [ERROR]}}
{{ [ERROR] Command line was:
C:\Users\CollinsDaniel\Utils\jdk-11.0.2\bin\javadoc.exe @options @packages}}
{{ [ERROR]}}
{{ [ERROR] Refer to the generated Javadoc files in
'C:\Users\CollinsDaniel\Work\3rdparty\lucene-solr-7\maven-build\lucene\core\src\java\target\apidocs'
dir.}}
was (Author: dancollins):
mvn install seems okay on master with openjdk "11.0.2" for windows) so
withdrawing that issue.
mvn javadoc:jar (on master with openjdk version "11.0.2" for windows) still
fails
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar (default-cli) on
project lucene-core: MavenReportException: Error while creating archive:
[ERROR] Exit code: 1 - javadoc: error - The code being documented uses modules
but the packages defined in http://docs.oracle.com/javase/7/docs/api/ are in
the unnamed module.
[ERROR]
[ERROR] Command line was:
C:\Users\CollinsDaniel\Utils\jdk-11.0.2\bin\javadoc.exe @options @packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in
'C:\Users\CollinsDaniel\Work\3rdparty\lucene-solr-7\maven-build\lucene\core\src\java\target\apidocs'
dir.
> Building Solr using Java 9 and Maven doesn't work
> -
>
> Key: SOLR-11579
> URL: https://issues.apache.org/jira/browse/SOLR-11579
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Affects Versions: 8.0
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T20:39:06+01:00)
> Maven home: /Users/dcollins53/Utils/apache-maven-3.5.0
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
> java version "9"
> Java(TM) SE Runtime Environment (build 9+181)
> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>Reporter: Daniel Collins
>Priority: Minor
> Labels: maven, maven-enforcer-plugin
> Attachments: SOLR-11579_1, SOLR-11579_2, SOLR-11579_4
>
>
> I'm calling this minor as I don't believe we officially support Java 9 (but
> correct me if I'm wrong), and I've only tried on master (again, I don't
> *think* branch_7x is setup for Java 9?)
> Several issues/notes:
> # -enforcer plugin breaks if you try to do mvn install-
> # javadoc plugin breaks if you try to do mvn javadoc:jar
> # warnings from groovy-maven-plugin (TODO)
> # a lot of the maven plugins are quite old
> # forbiddenapis has some issues with Solr (I assume due to module split-up,
> javax is no longer part of core) (TODO)
> I have patches for 1, 2, and 4. Still working on 3 and 5.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11579) Building Solr using Java 9 and Maven doesn't work
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806017#comment-16806017 ] Daniel Collins commented on SOLR-11579: --- mvn install seems okay on master with openjdk "11.0.2" for windows) so withdrawing that issue. mvn javadoc:jar (on master with openjdk version "11.0.2" for windows) still fails [ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar (default-cli) on project lucene-core: MavenReportException: Error while creating archive: [ERROR] Exit code: 1 - javadoc: error - The code being documented uses modules but the packages defined in http://docs.oracle.com/javase/7/docs/api/ are in the unnamed module. [ERROR] [ERROR] Command line was: C:\Users\CollinsDaniel\Utils\jdk-11.0.2\bin\javadoc.exe @options @packages [ERROR] [ERROR] Refer to the generated Javadoc files in 'C:\Users\CollinsDaniel\Work\3rdparty\lucene-solr-7\maven-build\lucene\core\src\java\target\apidocs' dir. > Building Solr using Java 9 and Maven doesn't work > - > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 8.0 > Environment: Apache Maven 3.5.0 > (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T20:39:06+01:00) > Maven home: /Users/dcollins53/Utils/apache-maven-3.5.0 > Java version: 9, vendor: Oracle Corporation > Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac" > java version "9" > Java(TM) SE Runtime Environment (build 9+181) > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579_1, SOLR-11579_2, SOLR-11579_4 > > > I'm calling this minor as I don't believe we officially support Java 9 (but > correct me if I'm wrong), and I've only tried on master (again, I don't > *think* branch_7x is setup for Java 9?) > Several issues/notes: > # -enforcer plugin breaks if you try to do mvn install- > # javadoc plugin breaks if you try to do mvn javadoc:jar > # warnings from groovy-maven-plugin (TODO) > # a lot of the maven plugins are quite old > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11579) Building Solr using Java 9 and Maven doesn't work
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated SOLR-11579: -- Description: I'm calling this minor as I don't believe we officially support Java 9 (but correct me if I'm wrong), and I've only tried on master (again, I don't *think* branch_7x is setup for Java 9?) Several issues/notes: # -enforcer plugin breaks if you try to do mvn install- # javadoc plugin breaks if you try to do mvn javadoc:jar # warnings from groovy-maven-plugin (TODO) # a lot of the maven plugins are quite old # forbiddenapis has some issues with Solr (I assume due to module split-up, javax is no longer part of core) (TODO) I have patches for 1, 2, and 4. Still working on 3 and 5. was: I'm calling this minor as I don't believe we officially support Java 9 (but correct me if I'm wrong), and I've only tried on master (again, I don't *think* branch_7x is setup for Java 9?) Several issues/notes: # enforcer plugin breaks if you try to do mvn install # javadoc plugin breaks if you try to do mvn javadoc:jar # warnings from groovy-maven-plugin (TODO) # a lot of the maven plugins are quite old # forbiddenapis has some issues with Solr (I assume due to module split-up, javax is no longer part of core) (TODO) I have patches for 1, 2, and 4. Still working on 3 and 5. > Building Solr using Java 9 and Maven doesn't work > - > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 8.0 > Environment: Apache Maven 3.5.0 > (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T20:39:06+01:00) > Maven home: /Users/dcollins53/Utils/apache-maven-3.5.0 > Java version: 9, vendor: Oracle Corporation > Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac" > java version "9" > Java(TM) SE Runtime Environment (build 9+181) > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579_1, SOLR-11579_2, SOLR-11579_4 > > > I'm calling this minor as I don't believe we officially support Java 9 (but > correct me if I'm wrong), and I've only tried on master (again, I don't > *think* branch_7x is setup for Java 9?) > Several issues/notes: > # -enforcer plugin breaks if you try to do mvn install- > # javadoc plugin breaks if you try to do mvn javadoc:jar > # warnings from groovy-maven-plugin (TODO) > # a lot of the maven plugins are quite old > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11579) Building Solr using Java 9 and Maven doesn't work
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806013#comment-16806013 ] Daniel Collins commented on SOLR-11579: --- [~erickerickson], I still have a few local branches, which I keep up to date with master, I'll try to re-create the patches. I don't use Java 9 any more, bu I'll test with what I have which is: openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4) OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, mixed mode) which is the latest "official" package on Ubuntu. Give me a few days to try and find some time to do that and I'll update this accordingly. > Building Solr using Java 9 and Maven doesn't work > - > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 8.0 > Environment: Apache Maven 3.5.0 > (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T20:39:06+01:00) > Maven home: /Users/dcollins53/Utils/apache-maven-3.5.0 > Java version: 9, vendor: Oracle Corporation > Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac" > java version "9" > Java(TM) SE Runtime Environment (build 9+181) > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579_1, SOLR-11579_2, SOLR-11579_4 > > > I'm calling this minor as I don't believe we officially support Java 9 (but > correct me if I'm wrong), and I've only tried on master (again, I don't > *think* branch_7x is setup for Java 9?) > Several issues/notes: > # enforcer plugin breaks if you try to do mvn install > # javadoc plugin breaks if you try to do mvn javadoc:jar > # warnings from groovy-maven-plugin (TODO) > # a lot of the maven plugins are quite old > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8616) Maven build: Simplify the way transitive dependency resolution is disabled, and increase the minimum supported Maven from 2.2.1 to 3.2.1
[
https://issues.apache.org/jira/browse/LUCENE-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726076#comment-16726076
]
Daniel Collins commented on LUCENE-8616:
https://issues.apache.org/jira/browse/SOLR-11579 was a related ticket for
upgrading all the maven plug-ins, will try to update the patches for that
tonight.
> Maven build: Simplify the way transitive dependency resolution is disabled,
> and increase the minimum supported Maven from 2.2.1 to 3.2.1
>
>
> Key: LUCENE-8616
> URL: https://issues.apache.org/jira/browse/LUCENE-8616
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
>
> Right now the Maven build disables transitive dependency resolution for all
> dependencies by listing each dependency's dependencies in a nested
> {{}} section in the grandparent POM's {{}}
> section.
> As of Maven 3.2.1, it's possible to use a wildcard syntax in nested
> {{}} sections to exclude all transitive deps: MNG-2315. This
> would make the grandparent POM much smaller and make the intent much clearer.
> We would have to increase our minimum supported Maven (currently 2.2.1), but
> that seems reasonable, given that Maven 2.x has been EOL'd:
> https://maven.apache.org/maven-2.x-eol.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8611) Update randomizedtesting to 2.7.2, JUnit to 4.12, add hamcrest-core dependency
[ https://issues.apache.org/jira/browse/LUCENE-8611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726075#comment-16726075 ] Daniel Collins commented on LUCENE-8611: Whilst we are in related territory, I did start SOLR-11579 about a year ago,which was my attempt to bring all the plug-ins "up to date" for (at the time!) Java 9. I really need to update those patches for Java 11, but maybe that item should merge into LUCENE-8616? > Update randomizedtesting to 2.7.2, JUnit to 4.12, add hamcrest-core dependency > -- > > Key: LUCENE-8611 > URL: https://issues.apache.org/jira/browse/LUCENE-8611 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: 7.7 > > Attachments: LUCENE-8611-fix-maven.patch, LUCENE-8611.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8611) Update randomizedtesting to 2.7.2, JUnit to 4.12, add hamcrest-core dependency
[ https://issues.apache.org/jira/browse/LUCENE-8611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725755#comment-16725755 ] Daniel Collins commented on LUCENE-8611: I was just about the log the same issue as [~steve_rowe], we use the maven build internally (as we build other applications that use Lucene and Solr jars, e.g. Luwak). I had an alternate fix which was to explicitly add hamcrest dependencies to all the various ivy.xml files which now have a dependency on it, but I had planned to ask if the real intent was that any test should be be able to use the dependencies from test-framework (which is the direction [~steve_rowe]'s patch is going), so that answers that. :) Does this patch apply to both branch_7x and master? > Update randomizedtesting to 2.7.2, JUnit to 4.12, add hamcrest-core dependency > -- > > Key: LUCENE-8611 > URL: https://issues.apache.org/jira/browse/LUCENE-8611 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: 7.7 > > Attachments: LUCENE-8611-fix-maven.patch, LUCENE-8611.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13000) log4j-slf4j-impl jar (inadvertently?) missing in solrj/lib
[
https://issues.apache.org/jira/browse/SOLR-13000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702871#comment-16702871
]
Daniel Collins commented on SOLR-13000:
---
The Prometheus Exporter is a stand-alone tool so it requires a logging
implementation, and since it is shipped with Solr, it seems reasonable for it
to use the same logging implementation that Solr uses.
So I guess the plan is to withdraw this (I'll confirm with [~cpoerschke] when
she's back from vacation next week)?
> log4j-slf4j-impl jar (inadvertently?) missing in solrj/lib
> --
>
> Key: SOLR-13000
> URL: https://issues.apache.org/jira/browse/SOLR-13000
> Project: Solr
> Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13000.patch
>
>
> My colleague [~ajhalani] noticed that declaring a {{solr-solrj}} dependency
> alone when configuring {{-Dlog4j.configurationFile}} for a project is not
> sufficient.
> I looked into further and it seems that the {{log4j-slf4j-impl}} jar is
> (inadvertently?) missing in {{solrj/lib}} in the release?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13000) log4j-slf4j-impl jar (inadvertently?) missing in solrj/lib
[
https://issues.apache.org/jira/browse/SOLR-13000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16692972#comment-16692972
]
Daniel Collins commented on SOLR-13000:
---
Log4J2 is a stated requirement for Solr server, since it is a standalone
application. SolrJ is a library that is expected to be embedded in a larger
application, so should the choice of actual logging implementation be under the
control of the application developer?
> log4j-slf4j-impl jar (inadvertently?) missing in solrj/lib
> --
>
> Key: SOLR-13000
> URL: https://issues.apache.org/jira/browse/SOLR-13000
> Project: Solr
> Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13000.patch
>
>
> My colleague [~ajhalani] noticed that declaring a {{solr-solrj}} dependency
> alone when configuring {{-Dlog4j.configurationFile}} for a project is not
> sufficient.
> I looked into further and it seems that the {{log4j-slf4j-impl}} jar is
> (inadvertently?) missing in {{solrj/lib}} in the release?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12454) tweak Overseer leadership transition related logging
[ https://issues.apache.org/jira/browse/SOLR-12454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16502988#comment-16502988 ] Daniel Collins commented on SOLR-12454: --- The nature of Overseer problems we have seen, is that by the time we realize we have lost the overseer, there is nothing more to do other than bounce to regain a new one. What we need is logging before/during the loss of overseer. [~janhoy], by on demand, did you mean dynamically after the fact, or just we should have a custom logging configuration which would set those particular debug statements to log permanently in our setup? The former wouldn't work (see above), but I that latter might be something we could look at. I'm curious how others deal with these kinds of issues, or do they fortunately not have them :). > tweak Overseer leadership transition related logging > > > Key: SOLR-12454 > URL: https://issues.apache.org/jira/browse/SOLR-12454 > Project: Solr > Issue Type: Task >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-12454.patch > > > Proposed patch to follow. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12205) SOLR-7887 broke javadoc:jar in maven
Daniel Collins created SOLR-12205:
-
Summary: SOLR-7887 broke javadoc:jar in maven
Key: SOLR-12205
URL: https://issues.apache.org/jira/browse/SOLR-12205
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: Build
Affects Versions: 7.3, master (8.0)
Reporter: Daniel Collins
Commit 27e5c8dd31 added the -proc:none option both to the compiler and to the
javadoc command line. That is not a javadoc option, so mvn javadoc:jar fails
both on master and branch_7x.
The following fix works for me:
{code:java}
diff --git a/dev-tools/maven/pom.xml.template b/dev-tools/maven/pom.xml.template
index 4e21ca0e13..50299a3cda 100644
--- a/dev-tools/maven/pom.xml.template
+++ b/dev-tools/maven/pom.xml.template
@@ -238,7 +238,6 @@
true
-Xdoclint:all
-Xdoclint:-missing
- -proc:none
{code}
The ant build is fine, its just the maven build which is affected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11579) Building Solr using Java 9 and Maven doesn't work
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated SOLR-11579: -- Attachment: SOLR-11579_1 SOLR-11579_2 SOLR-11579_4 Patch 1 is just for the enforcer plugin, patch 2 is for Javadoc, and patch 4 just updates ALL the plugins to their latest and greatest (it works for me, but not sure what other implications of that there are) > Building Solr using Java 9 and Maven doesn't work > - > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: master (8.0) > Environment: Apache Maven 3.5.0 > (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T20:39:06+01:00) > Maven home: /Users/dcollins53/Utils/apache-maven-3.5.0 > Java version: 9, vendor: Oracle Corporation > Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac" > java version "9" > Java(TM) SE Runtime Environment (build 9+181) > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579_1, SOLR-11579_2, SOLR-11579_4 > > > I'm calling this minor as I don't believe we officially support Java 9 (but > correct me if I'm wrong), and I've only tried on master (again, I don't > *think* branch_7x is setup for Java 9?) > Several issues/notes: > # enforcer plugin breaks if you try to do mvn install > # javadoc plugin breaks if you try to do mvn javadoc:jar > # warnings from groovy-maven-plugin (TODO) > # a lot of the maven plugins are quite old > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11579) Building Solr using Java 9 and Maven doesn't work
Daniel Collins created SOLR-11579: - Summary: Building Solr using Java 9 and Maven doesn't work Key: SOLR-11579 URL: https://issues.apache.org/jira/browse/SOLR-11579 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Components: Build Affects Versions: master (8.0) Environment: Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T20:39:06+01:00) Maven home: /Users/dcollins53/Utils/apache-maven-3.5.0 Java version: 9, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home Default locale: en_GB, platform encoding: UTF-8 OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac" java version "9" Java(TM) SE Runtime Environment (build 9+181) Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) Reporter: Daniel Collins Priority: Minor I'm calling this minor as I don't believe we officially support Java 9 (but correct me if I'm wrong), and I've only tried on master (again, I don't *think* branch_7x is setup for Java 9?) Several issues/notes: # enforcer plugin breaks as soon if you try to do mvn install # javadoc plugin breaks if you try to do mvn javadoc:jar # warnings from groovy-maven-plugin (TODO) # a lot of the maven plugins are quite old # forbiddenapis has some issues with Solr (I assume due to module split-up, javax is no longer part of core) (TODO) I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11579) Building Solr using Java 9 and Maven doesn't work
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated SOLR-11579: -- Description: I'm calling this minor as I don't believe we officially support Java 9 (but correct me if I'm wrong), and I've only tried on master (again, I don't *think* branch_7x is setup for Java 9?) Several issues/notes: # enforcer plugin breaks if you try to do mvn install # javadoc plugin breaks if you try to do mvn javadoc:jar # warnings from groovy-maven-plugin (TODO) # a lot of the maven plugins are quite old # forbiddenapis has some issues with Solr (I assume due to module split-up, javax is no longer part of core) (TODO) I have patches for 1, 2, and 4. Still working on 3 and 5. was: I'm calling this minor as I don't believe we officially support Java 9 (but correct me if I'm wrong), and I've only tried on master (again, I don't *think* branch_7x is setup for Java 9?) Several issues/notes: # enforcer plugin breaks as soon if you try to do mvn install # javadoc plugin breaks if you try to do mvn javadoc:jar # warnings from groovy-maven-plugin (TODO) # a lot of the maven plugins are quite old # forbiddenapis has some issues with Solr (I assume due to module split-up, javax is no longer part of core) (TODO) I have patches for 1, 2, and 4. Still working on 3 and 5. > Building Solr using Java 9 and Maven doesn't work > - > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: master (8.0) > Environment: Apache Maven 3.5.0 > (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T20:39:06+01:00) > Maven home: /Users/dcollins53/Utils/apache-maven-3.5.0 > Java version: 9, vendor: Oracle Corporation > Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac" > java version "9" > Java(TM) SE Runtime Environment (build 9+181) > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > > I'm calling this minor as I don't believe we officially support Java 9 (but > correct me if I'm wrong), and I've only tried on master (again, I don't > *think* branch_7x is setup for Java 9?) > Several issues/notes: > # enforcer plugin breaks if you try to do mvn install > # javadoc plugin breaks if you try to do mvn javadoc:jar > # warnings from groovy-maven-plugin (TODO) > # a lot of the maven plugins are quite old > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6673) Maven build fails for target javadoc:jar on trunk/Java8
[ https://issues.apache.org/jira/browse/LUCENE-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16182148#comment-16182148 ] Daniel Collins commented on LUCENE-6673: Any blockers here? Patch still holds, it matches the settings that common-build.xml uses (for ant). We are trying to move to branch_7x and test on master, and without this we can't build javadocs (fails at the first hurdle of Lucene core) > Maven build fails for target javadoc:jar on trunk/Java8 > --- > > Key: LUCENE-6673 > URL: https://issues.apache.org/jira/browse/LUCENE-6673 > Project: Lucene - Core > Issue Type: Bug > Components: general/build >Reporter: Daniel Collins >Assignee: Ramkumar Aiyengar >Priority: Minor > Attachments: LUCENE-6673.patch > > > We currently disable missing checks for doclint, but the maven poms don't > have it, as a result javadoc:jar fails. > (thanks to [~dancollins] for spotting this) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (LUCENE-7977) LUCENE-7951 broke the maven build
[ https://issues.apache.org/jira/browse/LUCENE-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins closed LUCENE-7977. -- Resolution: Cannot Reproduce SOLR-11382 had a subsequent fix to correct this, both master and branch_7x are good now. > LUCENE-7951 broke the maven build > - > > Key: LUCENE-7977 > URL: https://issues.apache.org/jira/browse/LUCENE-7977 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial-extras, modules/spatial3d >Affects Versions: master (8.0), 7.1 > Environment: Development only (not an issue with the binary release) >Reporter: Daniel Collins >Priority: Minor > Labels: build > Attachments: LUCENE-7977.patch > > > Trying to build Lucene/Solr using maven currently fails on branch_7x and > master. The spatial-extras module has a dependency on test code from > spatial-3d, but the spatial-3d module doesn't produce a test-jar. > ant handles this implicitly by allowing the modules to add specific > directories to classpaths, but maven requires that all dependent code is in a > jar. > I have a patch which I will upload. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7977) LUCENE-7951 broke the maven build
[ https://issues.apache.org/jira/browse/LUCENE-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16180660#comment-16180660 ] Daniel Collins commented on LUCENE-7977: Looks like SOLR-11382 actually had an update to fix this. Do we mark as a duplicate or just withdraw? > LUCENE-7951 broke the maven build > - > > Key: LUCENE-7977 > URL: https://issues.apache.org/jira/browse/LUCENE-7977 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial-extras, modules/spatial3d >Affects Versions: master (8.0), 7.1 > Environment: Development only (not an issue with the binary release) >Reporter: Daniel Collins >Priority: Minor > Labels: build > Attachments: LUCENE-7977.patch > > > Trying to build Lucene/Solr using maven currently fails on branch_7x and > master. The spatial-extras module has a dependency on test code from > spatial-3d, but the spatial-3d module doesn't produce a test-jar. > ant handles this implicitly by allowing the modules to add specific > directories to classpaths, but maven requires that all dependent code is in a > jar. > I have a patch which I will upload. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7977) LUCENE-7951 broke the maven build
[ https://issues.apache.org/jira/browse/LUCENE-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated LUCENE-7977: --- Attachment: LUCENE-7977.patch This is a patch against master, but it applies cleanly to branch_7x as well. The fix is actually for the spatial3d module to make it build a test-jar. > LUCENE-7951 broke the maven build > - > > Key: LUCENE-7977 > URL: https://issues.apache.org/jira/browse/LUCENE-7977 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial-extras, modules/spatial3d >Affects Versions: master (8.0), 7.1 > Environment: Development only (not an issue with the binary release) >Reporter: Daniel Collins >Priority: Minor > Labels: build > Attachments: LUCENE-7977.patch > > > Trying to build Lucene/Solr using maven currently fails on branch_7x and > master. The spatial-extras module has a dependency on test code from > spatial-3d, but the spatial-3d module doesn't produce a test-jar. > ant handles this implicitly by allowing the modules to add specific > directories to classpaths, but maven requires that all dependent code is in a > jar. > I have a patch which I will upload. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7977) LUCENE-7951 broke the maven build
Daniel Collins created LUCENE-7977: -- Summary: LUCENE-7951 broke the maven build Key: LUCENE-7977 URL: https://issues.apache.org/jira/browse/LUCENE-7977 Project: Lucene - Core Issue Type: Bug Components: modules/spatial-extras, modules/spatial3d Affects Versions: master (8.0), 7.1 Environment: Development only (not an issue with the binary release) Reporter: Daniel Collins Priority: Minor Trying to build Lucene/Solr using maven currently fails on branch_7x and master. The spatial-extras module has a dependency on test code from spatial-3d, but the spatial-3d module doesn't produce a test-jar. ant handles this implicitly by allowing the modules to add specific directories to classpaths, but maven requires that all dependent code is in a jar. I have a patch which I will upload. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7583) Can we improve OutputStreamIndexOutput's byte buffering when writing each BKD leaf block?
[
https://issues.apache.org/jira/browse/LUCENE-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15733619#comment-15733619
]
Daniel Collins commented on LUCENE-7583:
Note: this breaks my eclipse build (on 6x at least, and I presume master)
because
lucene/core/src/java/org/apache/lucene/util/GrowableByteArrayDataOutput.java
claims to be in package org.apache.lucene.store, but is actually in the util
dir.
Ant compile is fine, but I guess Eclipse is more pedantic.
> Can we improve OutputStreamIndexOutput's byte buffering when writing each BKD
> leaf block?
> -
>
> Key: LUCENE-7583
> URL: https://issues.apache.org/jira/browse/LUCENE-7583
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
> Fix For: master (7.0), 6.4
>
> Attachments: LUCENE-7583-hardcode-writeVInt.patch,
> LUCENE-7583.fork-FastOutputStream.patch, LUCENE-7583.patch,
> LUCENE-7583.patch, LUCENE-7583.private-IndexOutput.patch
>
>
> When BKD writes its leaf blocks, it's essentially a lot of tiny writes (vint,
> int, short, etc.), and I've seen deep thread stacks through our IndexOutput
> impl ({{OutputStreamIndexOutput}}) when pulling hot threads while BKD is
> writing.
> So I tried a small change, to have BKDWriter do its own buffering, by first
> writing each leaf block into a {{RAMOutputStream}}, and then dumping that (in
> 1 KB byte[] chunks) to the actual IndexOutput.
> This gives a non-trivial reduction (~6%) in the total time for BKD writing +
> merging time on the 20M NYC taxis nightly benchmark (2 times each):
> Trunk, sparse:
> - total: 64.691 sec
> - total: 64.702 sec
> Patch, sparse:
> - total: 60.820 sec
> - total: 60.965 sec
> Trunk dense:
> - total: 62.730 sec
> - total: 62.383 sec
> Patch dense:
> - total: 58.805 sec
> - total: 58.742 sec
> The results seem to be consistent and reproducible. I'm using Java 1.8.0_101
> on a fast SSD on Ubuntu 16.04.
> It's sort of weird and annoying that this helps so much, because
> {{OutputStreamIndexOutput}} already uses java's {{BufferedOutputStream}}
> (default 8 KB buffer) to buffer writes.
> [~thetaphi] suggested maybe hotspot is failing to inline/optimize the
> {{writeByte}} / the call stack just has too many layers.
> We could commit this patch (it's trivial) but it'd be nice to understand and
> fix why buffering writes is somehow costly so any other Lucene codec
> components that write lots of little things can be improved too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6673) Maven build fails for target javadoc:jar on trunk/Java8
[ https://issues.apache.org/jira/browse/LUCENE-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15715106#comment-15715106 ] Daniel Collins commented on LUCENE-6673: We had patched this locally on our 4.8 branch (with the added complication that in Java 7 this flag isn't needed). Getting back to trunk, this still applies, any thoughts on this being applied? > Maven build fails for target javadoc:jar on trunk/Java8 > --- > > Key: LUCENE-6673 > URL: https://issues.apache.org/jira/browse/LUCENE-6673 > Project: Lucene - Core > Issue Type: Bug > Components: general/build >Reporter: Daniel Collins >Assignee: Ramkumar Aiyengar >Priority: Minor > Attachments: LUCENE-6673.patch > > > We currently disable missing checks for doclint, but the maven poms don't > have it, as a result javadoc:jar fails. > (thanks to [~dancollins] for spotting this) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7340) MemoryIndex.toString is broken if you enable payloads
[ https://issues.apache.org/jira/browse/LUCENE-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15353689#comment-15353689 ] Daniel Collins commented on LUCENE-7340: The only potential issue I see with the output as it stands with your patch, is that the bracketing suggests that the payload is part of the position information (at least that's how I would interpret it), when really its something separate? But payloads aren't an area I know well, we came upon this bug by accident, so I don't feel that strongly about it. Agreed, there is no real value in the number of payloads, I only added it as both terms and positions had counts, so it was purely for consistency with them. > MemoryIndex.toString is broken if you enable payloads > - > > Key: LUCENE-7340 > URL: https://issues.apache.org/jira/browse/LUCENE-7340 > Project: Lucene - Core > Issue Type: Bug > Components: modules/highlighter >Affects Versions: 5.4.1, 6.0.1, master (7.0) >Reporter: Daniel Collins >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE-7340.diff, LUCENE-7340.diff, LUCENE-7340.patch > > > Noticed this as we use Luwak which creates a MemoryIndex(true, true) storing > both offsets and payloads (though in reality we never put any payloads in it). > We used to use MemoryIndex.toString() for debugging and noticed it broke in > Lucene 5.x and beyond. I think LUCENE-6155 broke it when it added support > for payloads? > Creating default memoryindex (as all the tests currently do) works fine, as > does one with just offsets, it is just the payload version which is broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7340) MemoryIndex.toString is broken if you enable payloads
[ https://issues.apache.org/jira/browse/LUCENE-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15352794#comment-15352794 ] Daniel Collins commented on LUCENE-7340: [~romseygeek] and [~dsmiley], any more thoughts on this? > MemoryIndex.toString is broken if you enable payloads > - > > Key: LUCENE-7340 > URL: https://issues.apache.org/jira/browse/LUCENE-7340 > Project: Lucene - Core > Issue Type: Bug > Components: modules/highlighter >Affects Versions: 5.4.1, 6.0.1, master (7.0) >Reporter: Daniel Collins >Priority: Minor > Attachments: LUCENE-7340.diff, LUCENE-7340.diff > > > Noticed this as we use Luwak which creates a MemoryIndex(true, true) storing > both offsets and payloads (though in reality we never put any payloads in it). > We used to use MemoryIndex.toString() for debugging and noticed it broke in > Lucene 5.x and beyond. I think LUCENE-6155 broke it when it added support > for payloads? > Creating default memoryindex (as all the tests currently do) works fine, as > does one with just offsets, it is just the payload version which is broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7340) MemoryIndex.toString is broken if you enable payloads
[ https://issues.apache.org/jira/browse/LUCENE-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15335786#comment-15335786 ] Daniel Collins commented on LUCENE-7340: Thanks Alan, there was an existing test that did actually check the payload API, so I've put the toString() checks in that existing test > MemoryIndex.toString is broken if you enable payloads > - > > Key: LUCENE-7340 > URL: https://issues.apache.org/jira/browse/LUCENE-7340 > Project: Lucene - Core > Issue Type: Bug > Components: modules/highlighter >Affects Versions: 5.4.1, 6.0.1, master (7.0) >Reporter: Daniel Collins >Priority: Minor > Attachments: LUCENE-7340.diff, LUCENE-7340.diff > > > Noticed this as we use Luwak which creates a MemoryIndex(true, true) storing > both offsets and payloads (though in reality we never put any payloads in it). > We used to use MemoryIndex.toString() for debugging and noticed it broke in > Lucene 5.x and beyond. I think LUCENE-6155 broke it when it added support > for payloads? > Creating default memoryindex (as all the tests currently do) works fine, as > does one with just offsets, it is just the payload version which is broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7340) MemoryIndex.toString is broken if you enable payloads
[ https://issues.apache.org/jira/browse/LUCENE-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated LUCENE-7340: --- Attachment: LUCENE-7340.diff Updated patch, this extends an existing test instead of adding new ones > MemoryIndex.toString is broken if you enable payloads > - > > Key: LUCENE-7340 > URL: https://issues.apache.org/jira/browse/LUCENE-7340 > Project: Lucene - Core > Issue Type: Bug > Components: modules/highlighter >Affects Versions: 5.4.1, 6.0.1, master (7.0) >Reporter: Daniel Collins >Priority: Minor > Attachments: LUCENE-7340.diff, LUCENE-7340.diff > > > Noticed this as we use Luwak which creates a MemoryIndex(true, true) storing > both offsets and payloads (though in reality we never put any payloads in it). > We used to use MemoryIndex.toString() for debugging and noticed it broke in > Lucene 5.x and beyond. I think LUCENE-6155 broke it when it added support > for payloads? > Creating default memoryindex (as all the tests currently do) works fine, as > does one with just offsets, it is just the payload version which is broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7340) MemoryIndex.toString is broken if you enable payloads
[ https://issues.apache.org/jira/browse/LUCENE-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated LUCENE-7340: --- Attachment: LUCENE-7340.diff This patches toString() so that it works and adds some tests to verify that. What it doesn't do is actually add a field with payloads into the MI to validate the resulting format Still trying to work out how to do that. > MemoryIndex.toString is broken if you enable payloads > - > > Key: LUCENE-7340 > URL: https://issues.apache.org/jira/browse/LUCENE-7340 > Project: Lucene - Core > Issue Type: Bug > Components: modules/highlighter >Affects Versions: 5.4.1, 6.0.1, master (7.0) >Reporter: Daniel Collins >Priority: Minor > Attachments: LUCENE-7340.diff > > > Noticed this as we use Luwak which creates a MemoryIndex(true, true) storing > both offsets and payloads (though in reality we never put any payloads in it). > We used to use MemoryIndex.toString() for debugging and noticed it broke in > Lucene 5.x and beyond. I think LUCENE-6155 broke it when it added support > for payloads? > Creating default memoryindex (as all the tests currently do) works fine, as > does one with just offsets, it is just the payload version which is broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7340) MemoryIndex.toString is broken if you enable payloads
Daniel Collins created LUCENE-7340: -- Summary: MemoryIndex.toString is broken if you enable payloads Key: LUCENE-7340 URL: https://issues.apache.org/jira/browse/LUCENE-7340 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 6.0.1, 5.4.1, master (7.0) Reporter: Daniel Collins Priority: Minor Noticed this as we use Luwak which creates a MemoryIndex(true, true) storing both offsets and payloads (though in reality we never put any payloads in it). We used to use MemoryIndex.toString() for debugging and noticed it broke in Lucene 5.x and beyond. I think LUCENE-6155 broke it when it added support for payloads? Creating default memoryindex (as all the tests currently do) works fine, as does one with just offsets, it is just the payload version which is broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9109) Add support for custom ivysettings.xml
[ https://issues.apache.org/jira/browse/SOLR-9109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15284262#comment-15284262 ] Daniel Collins commented on SOLR-9109: -- +1 for this for a different reason. We build Solr in a corporate environment which means we are behind firewalls, and so can't use the public repos. Currently we have to patch Solr in order to build it, which is not ideal. If we had a custom extra file, that would be fine, but patching an existing Solr file doesn't feel right. > Add support for custom ivysettings.xml > -- > > Key: SOLR-9109 > URL: https://issues.apache.org/jira/browse/SOLR-9109 > Project: Solr > Issue Type: Improvement >Reporter: Misha Dmitriev > Attachments: 0001-Support-for-custom-ivysettings.xml.patch, > SOLR-9109.patch > > > Currently solr/lucene/common-build.xml hardcodes file ivy-settings.xml in the > ivy.configure task. It means that, unlike all other CDH components that use > Ant, Solr does not allow the user to provide a custom ivysettings.xml. > In the Cauldron CDH build, we need to make some adjustments in the build > process to satisfy CDH-internal build dependencies with artifacts generated > locally, rather than download them from repo1.maven.org etc. E.g. all > component should use locally-generated avro-snapshot jars instead of publicly > released ones, etc. For Ant, we achieve that by giving it a special > ivysettings.xml file, that limits artifact downloading to the local on-disk > maven repository and Cloudera artifactory server. > All CDH components except Solr allow the user to specify a custom > ivysettings.xml file by overriding -Divysettings.xml property. We need to add > the same feature to Solr. It can be easily achieved by changing several lines > in solr/lucene/common-build.xml. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7263) xmlparser: Allow SpanQueryBuilder to be used by derived classes
[ https://issues.apache.org/jira/browse/LUCENE-7263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15264216#comment-15264216 ] Daniel Collins commented on LUCENE-7263: Don't think there is anything controversial here, its just allowing derived classes access to the span builder, but if anyone sees any issues, let me know > xmlparser: Allow SpanQueryBuilder to be used by derived classes > --- > > Key: LUCENE-7263 > URL: https://issues.apache.org/jira/browse/LUCENE-7263 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/queryparser >Affects Versions: master >Reporter: Daniel Collins > Attachments: LUCENE-7263.patch > > > Following on from LUCENE-7210 (and others), the xml queryparser has different > factories, one for creating normal queries and one for creating span queries. > The former is a protected variable so can be used by derived classes, the > latter isn't. > This makes the spanFactory a variable that can be used more easily. No > functional changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7263) xmlparser: Allow SpanQueryBuilder to be used by derived classes
[ https://issues.apache.org/jira/browse/LUCENE-7263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated LUCENE-7263: --- Attachment: LUCENE-7263.patch > xmlparser: Allow SpanQueryBuilder to be used by derived classes > --- > > Key: LUCENE-7263 > URL: https://issues.apache.org/jira/browse/LUCENE-7263 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/queryparser >Affects Versions: master >Reporter: Daniel Collins > Attachments: LUCENE-7263.patch > > > Following on from LUCENE-7210 (and others), the xml queryparser has different > factories, one for creating normal queries and one for creating span queries. > The former is a protected variable so can be used by derived classes, the > latter isn't. > This makes the spanFactory a variable that can be used more easily. No > functional changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7263) xmlparser: Allow SpanQueryBuilder to be used by derived classes
Daniel Collins created LUCENE-7263: -- Summary: xmlparser: Allow SpanQueryBuilder to be used by derived classes Key: LUCENE-7263 URL: https://issues.apache.org/jira/browse/LUCENE-7263 Project: Lucene - Core Issue Type: Improvement Components: modules/queryparser Affects Versions: master Reporter: Daniel Collins Following on from LUCENE-7210 (and others), the xml queryparser has different factories, one for creating normal queries and one for creating span queries. The former is a protected variable so can be used by derived classes, the latter isn't. This makes the spanFactory a variable that can be used more easily. No functional changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-839) XML Query Parser support (deftype=xmlparser)
[
https://issues.apache.org/jira/browse/SOLR-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106641#comment-15106641
]
Daniel Collins commented on SOLR-839:
-
I think this broke the Maven build option within Solr, due to a new dependency.
The XML Parser test code is now dependent on Lucene test code, which the maven
pom.xml files don't allow for.
Will create a new JIRA and issue a patch to fix that.
> XML Query Parser support (deftype=xmlparser)
>
>
> Key: SOLR-839
> URL: https://issues.apache.org/jira/browse/SOLR-839
> Project: Solr
> Issue Type: New Feature
> Components: query parsers
>Affects Versions: 1.3, 5.4, Trunk
>Reporter: Erik Hatcher
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-839-object-parser.patch, SOLR-839.patch,
> SOLR-839.patch, SOLR-839.patch, lucene-xml-query-parser-2.4-dev.jar
>
>
> Lucene includes a query parser that is able to create the full-spectrum of
> Lucene queries, using an XML data structure.
> This patch adds "xml" query parser support to Solr.
> Example (from
> {{lucene/queryparser/src/test/org/apache/lucene/queryparser/xml/NestedBooleanQuery.xml}}):
> {code}
>
>
>
>
>
> doesNotExistButShouldBeOKBecauseOtherClauseExists
>
>
>
>
> bank
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-8567) SOLR-839 broke the Maven build
Daniel Collins created SOLR-8567: Summary: SOLR-839 broke the Maven build Key: SOLR-8567 URL: https://issues.apache.org/jira/browse/SOLR-8567 Project: Solr Issue Type: Bug Components: Build Affects Versions: 5.4, Trunk Reporter: Daniel Collins Priority: Minor SOLR-839 adds a new code dependency between the Solr test code and the Lucene test code. ant handles this with some updates to the common-build.xml (included in SOLR-839) but the maven build mechanism needs updates to the pom.xml.template with an equivalent change. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8567) SOLR-839 broke the Maven build
[ https://issues.apache.org/jira/browse/SOLR-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Collins updated SOLR-8567: - Attachment: SOLR-8567.patch This is a dump of a git patch, but should be good enough to let you apply it to trunk and 5.4. > SOLR-839 broke the Maven build > -- > > Key: SOLR-8567 > URL: https://issues.apache.org/jira/browse/SOLR-8567 > Project: Solr > Issue Type: Bug > Components: Build >Affects Versions: 5.4, Trunk >Reporter: Daniel Collins >Priority: Minor > Attachments: SOLR-8567.patch > > > SOLR-839 adds a new code dependency between the Solr test code and the Lucene > test code. ant handles this with some updates to the common-build.xml > (included in SOLR-839) but the maven build mechanism needs updates to the > pom.xml.template with an equivalent change. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-8567) SOLR-839 broke the Maven build (trunk, 5.5)
[ https://issues.apache.org/jira/browse/SOLR-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15107099#comment-15107099 ] Daniel Collins edited comment on SOLR-8567 at 1/19/16 6:06 PM: --- [~erickerickson] The references to 5.4 were my bad, I'm back-porting to our internal 5.4.x branch which was what confused me, so apologies for that. I've updated my comment now to correct that. The only versions that are broken are 5.5 and trunk, so only "unreleased" branches. I wonder if anyone (else) used the Maven build process, wasn't sure of its status, but I figured it wasn't really used much. For any projects which are dependent on Lucene (e.g. Luwak), maven seems to be a more convenient build mechanism, so we do make use of it, but I don't know who else does! was (Author: dancollins): [~erickerickson] The references to 5.4 was my bad, I'm back-porting to our internal 5.4.x branch which was what confused me, so apologies for that. I've updated my comment now to correct that. The only versions that are broken are 5.5 and trunk, so only "unreleased" branches. I wonder if anyone (else) used the Maven build process, wasn't sure of its status, but I figured it wasn't really used much. For any projects which are dependent on Lucene (e.g. Luwak), maven seems to be a more convenient build mechanism, so we do make use of it, but I don't know who else does! > SOLR-839 broke the Maven build (trunk, 5.5) > --- > > Key: SOLR-8567 > URL: https://issues.apache.org/jira/browse/SOLR-8567 > Project: Solr > Issue Type: Bug > Components: Build >Affects Versions: 5.5, Trunk >Reporter: Daniel Collins >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-8567.patch > > > SOLR-839 adds a new code dependency between the Solr test code and the Lucene > test code. ant handles this with some updates to the common-build.xml > (included in SOLR-839) but the maven build mechanism needs updates to the > pom.xml.template with an equivalent change. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8567) SOLR-839 broke the Maven build (trunk, 5.5)
[ https://issues.apache.org/jira/browse/SOLR-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15107099#comment-15107099 ] Daniel Collins commented on SOLR-8567: -- [~erickerickson] The references to 5.4 was my bad, I'm back-porting to our internal 5.4.x branch which was what confused me, so apologies for that. I've updated my comment now to correct that. The only versions that are broken are 5.5 and trunk, so only "unreleased" branches. I wonder if anyone (else) used the Maven build process, wasn't sure of its status, but I figured it wasn't really used much. For any projects which are dependent on Lucene (e.g. Luwak), maven seems to be a more convenient build mechanism, so we do make use of it, but I don't know who else does! > SOLR-839 broke the Maven build (trunk, 5.5) > --- > > Key: SOLR-8567 > URL: https://issues.apache.org/jira/browse/SOLR-8567 > Project: Solr > Issue Type: Bug > Components: Build >Affects Versions: 5.5, Trunk >Reporter: Daniel Collins >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-8567.patch > > > SOLR-839 adds a new code dependency between the Solr test code and the Lucene > test code. ant handles this with some updates to the common-build.xml > (included in SOLR-839) but the maven build mechanism needs updates to the > pom.xml.template with an equivalent change. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-8567) SOLR-839 broke the Maven build (trunk, 5.5)
[ https://issues.apache.org/jira/browse/SOLR-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106646#comment-15106646 ] Daniel Collins edited comment on SOLR-8567 at 1/19/16 6:01 PM: --- This is a dump of a git patch, but should be good enough to let you apply it to trunk and 5.5. was (Author: dancollins): This is a dump of a git patch, but should be good enough to let you apply it to trunk and 5.4. > SOLR-839 broke the Maven build (trunk, 5.5) > --- > > Key: SOLR-8567 > URL: https://issues.apache.org/jira/browse/SOLR-8567 > Project: Solr > Issue Type: Bug > Components: Build >Affects Versions: 5.5, Trunk >Reporter: Daniel Collins >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-8567.patch > > > SOLR-839 adds a new code dependency between the Solr test code and the Lucene > test code. ant handles this with some updates to the common-build.xml > (included in SOLR-839) but the maven build mechanism needs updates to the > pom.xml.template with an equivalent change. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7698) solr alternative logback contrib
[
https://issues.apache.org/jira/browse/SOLR-7698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14602548#comment-14602548
]
Daniel Collins commented on SOLR-7698:
--
I don't really follow why we need to change code in Solr (or add code) to make
use of Logback? All solr code should use SLF4J which is a framework, so
swapping log4j - logback should just be a matter of replacing the relevant Jar
files, and adding a logback.xml to configure logback itself...
We do that already (in Solr 4.x admittedly) as part of our deployment process,
but no code changes are needed.
Also Solr doesn't tend to use Pull Requests, since the gold copy host is SVN
(github is just a mirror for convenience), all changes would have to be
submitted as a patch instead of a PR.
solr alternative logback contrib
-
Key: SOLR-7698
URL: https://issues.apache.org/jira/browse/SOLR-7698
Project: Solr
Issue Type: New Feature
Affects Versions: 5.2.1
Reporter: Linbin Chen
Labels: logback
Fix For: 5.3
Attachments: SOLR-7698.patch
alternative use logback support
solr.xml like
{code:xml}
solr
!-- ... --
logging
str name=classorg.apache.solr.logging.logback.LogbackWatcher/str
bool name=enabledtrue/bool
watcher
int name=size50/int
str name=thresholdWARN/str
/watcher
/logging
!-- ... --
/solr
{code}
solr-X.X.X/server/lib/ext remove:
* log4j-1.2.X.jar
* slf4j-log4j12-1.7.X.jar
add :
* log4j-over-slf4j-1.7.7.jar
* logback-classic-1.1.3.jar
* logback-core-1.1.3.jar
example : https://github.com/chenlb/vootoo/wiki/Logback-for-solr-logging
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6584) Docs on StandardTokenizer don't mention the behaviour change in Version.LUCENE_4_7_0
[
https://issues.apache.org/jira/browse/LUCENE-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593306#comment-14593306
]
Daniel Collins commented on LUCENE-6584:
I think the point is that in Lucene 4.7, this update was made:
{quote}
LUCENE-5357: Upgrade StandardTokenizer and UAX29URLEmailTokenizer to Unicode
6.3; update UAX29URLEmailTokenizer's recognized top level domains in URLs and
Emails from the IANA Root Zone Database.
{quote}
but that never made it to the Javadoc page..
Docs on StandardTokenizer don't mention the behaviour change in
Version.LUCENE_4_7_0
Key: LUCENE-6584
URL: https://issues.apache.org/jira/browse/LUCENE-6584
Project: Lucene - Core
Issue Type: Bug
Components: modules/analysis
Affects Versions: 4.10.4
Reporter: Trejkaz
Priority: Minor
The following test shows that the behaviour of StandardTokenizer differs once
you start passing Version.LUCENE_4_7_0 or greater:
{code}
import java.io.StringReader;
import org.apache.lucene.analysis.TokenStream;
import org.apache.lucene.analysis.standard.StandardTokenizer;
import org.apache.lucene.util.Version;
import org.junit.Test;
import static org.hamcrest.Matchers.is;
import static org.junit.Assert.assertThat;
public class TestStandardTokenizerStandalone
{
@Test
public void testLucene4_6_1() throws Exception
{
doTest(Version.LUCENE_4_6_1);
}
@Test
public void testLucene4_7_0() throws Exception
{
doTest(Version.LUCENE_4_7_0);
}
public void doTest(Version version) throws Exception
{
try (TokenStream stream = new StandardTokenizer(version, new
StringReader(makeLongString(2550
{
stream.reset();
assertThat(stream.incrementToken(), is(false));
}
}
private String makeLongString(int length)
{
StringBuilder builder = new StringBuilder(length);
for (int i = 0; i length; i++)
{
builder.append('x');
}
return builder.toString();
}
}
{code}
However, the Javadoc only mentions the behaviour changes in versions 3.1 and
3.4.
The constructor for passing the version is deprecated, presumably under the
false impression that no changes occurred during Lucene 4. I know the Version
parameter was killed off entirely in version 5, which presumably means that
people who tokenised stuff in Lucene 4.6 or earlier have now been trapped and
have to copy the tokeniser from Lucene 4 to keep their queries working.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6693) Start script for windows fails with 32bit JRE
[
https://issues.apache.org/jira/browse/SOLR-6693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14197967#comment-14197967
]
Daniel Collins commented on SOLR-6693:
--
Yeah, I was half-joking and half-serious when I suggested JVM re-install.
Windows JVM installs always seem somewhat prone to needing a re-install from
time to time, The {{C:\Windows\System32\java.exe}} always seems to favour the
last JVM you installed as well, so if you have (for example) a Java 7 and
Java 8 JVM installed, and then you update your Java 7 JVM, that becomes the new
default. You have to re-update Java 8 to update that magic version of
{{java.exe}}.
It always makes me glad to get back to Linux every time I have to use Windows,
at least there applications get installed into directories, if they are on your
path (or I explicitly run them), they get used, if they aren't, they don't. It
makes so much more sense that way :-)
Start script for windows fails with 32bit JRE
-
Key: SOLR-6693
URL: https://issues.apache.org/jira/browse/SOLR-6693
Project: Solr
Issue Type: Bug
Components: scripts and tools
Affects Versions: 4.10.2
Environment: WINDOWS 8.1
Reporter: Jan Høydahl
Labels: bin\solr.cmd
Fix For: 5.0, Trunk
*Reproduce:*
# Install JRE8 from www.java.com (typically {{C:\Program Files
(x86)\Java\jre1.8.0_25}})
# Run the command {{bin\solr start -V}}
The result is:
{{\Java\jre1.8.0_25\bin\java was unexpected at this time.}}
*Reason*
This comes from bad quoting of the {{%SOLR%}} variable. I think it's because
of the parenthesis that it freaks out. I think the same would apply for a
32-bit JDK because of the (x86) in the path, but I have not tested.
Tip: You can remove the line {{@ECHO OFF}} at the top to see exactly which is
the offending line
*Solution*
Quoting the lines where %JAVA% is printed, e.g. instead of
{noformat}
@echo Using Java: %JAVA%
{noformat}
then use
{noformat}
@echo Using Java: %JAVA%
{noformat}
This is needed several places.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6693) Start script for windows fails with 32bit JRE
[
https://issues.apache.org/jira/browse/SOLR-6693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14195893#comment-14195893
]
Daniel Collins commented on SOLR-6693:
--
Jan, quoting issue aside, the {{-version}} syntax does seem to work in Windows
even for 32-bit JVMs?
{noformat}
C:\Users\dcollins53C:\Program Files (x86)\Java\jre1.8.0_20\bin\java
-version:1.8 -version
java version 1.8.0_20
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) Client VM (build 25.20-b23, mixed mode)
C:\Users\dcollins53C:\Program Files\Java\jre1.8.0_20\bin\java -version:1.8
-version
java version 1.8.0_20
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)
{noformat}
I confess I don't have any Java 7 JVMs any more, but Java 8 32-bit does seem to
be printing the right output. Whether the {{solr.cmd}} script is handling it
correctly, I haven't checked, but it should be possible to get that to work.
Start script for windows fails with 32bit JRE
-
Key: SOLR-6693
URL: https://issues.apache.org/jira/browse/SOLR-6693
Project: Solr
Issue Type: Bug
Components: scripts and tools
Affects Versions: 4.10.2
Environment: WINDOWS 8.1
Reporter: Jan Høydahl
Labels: bin\solr.cmd
Fix For: 5.0, Trunk
*Reproduce:*
# Install JRE8 from www.java.com (typically {{C:\Program Files
(x86)\Java\jre1.8.0_25}})
# Run the command {{bin\solr start -V}}
The result is:
{{\Java\jre1.8.0_25\bin\java was unexpected at this time.}}
*Reason*
This comes from bad quoting of the {{%SOLR%}} variable. I think it's because
of the parenthesis that it freaks out. I think the same would apply for a
32-bit JDK because of the (x86) in the path, but I have not tested.
Tip: You can remove the line {{@ECHO OFF}} at the top to see exactly which is
the offending line
*Solution*
Quoting the lines where %JAVA% is printed, e.g. instead of
{noformat}
@echo Using Java: %JAVA%
{noformat}
then use
{noformat}
@echo Using Java: %JAVA%
{noformat}
This is needed several places.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6693) Start script for windows fails with 32bit JRE
[
https://issues.apache.org/jira/browse/SOLR-6693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14196087#comment-14196087
]
Daniel Collins commented on SOLR-6693:
--
Strange, I'm on Windows 7, and with a slightly older Java8 VM, but I can't see
why any of those things would affect the results.
I confess my usual resolution to any oddities with Java VMs on Windows is to
uninstall and re-install the JVM (often twice!) which usually seems to deal
with it... Its not pretty or scientific but it seems to help.
:-)
Start script for windows fails with 32bit JRE
-
Key: SOLR-6693
URL: https://issues.apache.org/jira/browse/SOLR-6693
Project: Solr
Issue Type: Bug
Components: scripts and tools
Affects Versions: 4.10.2
Environment: WINDOWS 8.1
Reporter: Jan Høydahl
Labels: bin\solr.cmd
Fix For: 5.0, Trunk
*Reproduce:*
# Install JRE8 from www.java.com (typically {{C:\Program Files
(x86)\Java\jre1.8.0_25}})
# Run the command {{bin\solr start -V}}
The result is:
{{\Java\jre1.8.0_25\bin\java was unexpected at this time.}}
*Reason*
This comes from bad quoting of the {{%SOLR%}} variable. I think it's because
of the parenthesis that it freaks out. I think the same would apply for a
32-bit JDK because of the (x86) in the path, but I have not tested.
Tip: You can remove the line {{@ECHO OFF}} at the top to see exactly which is
the offending line
*Solution*
Quoting the lines where %JAVA% is printed, e.g. instead of
{noformat}
@echo Using Java: %JAVA%
{noformat}
then use
{noformat}
@echo Using Java: %JAVA%
{noformat}
This is needed several places.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6392) If run Solr having two collections configured but only one config delivered to Zookeeper causes that config is applied for all collections
[ https://issues.apache.org/jira/browse/SOLR-6392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103598#comment-14103598 ] Daniel Collins commented on SOLR-6392: -- By deliver config, I am assuming you mean upload that config to zk? Do you use the zkcli.sh script for that or do you do it via some other means? What I think you are saying is: # You have 2 collections which should be using independent configurations (both stored in ZK). # If you change config1 (and restart Solr), that takes effect (in collection1 or both?) # If you change config2 (and restart Solr), there is no apparent effect? First question is then, are you sure both collections are using different configs, or have they somehow both picked up the same config? How did you set them up, and how did you define which config each collection uses? There used to be a fall-back approach in Solr, if you started a core but didn't tell it to use any config from ZK AND there was only 1 possible config in ZK, the Solr guessed that was what you meant and set up the links. I would guess that might what's happened here, so both your collections are actually using config1. Check in ZK, under the /collections/collectionName node there should be an element called configName which maps to the configuration in ZK. If that is wrong, you need to correct that, which is the -linkconfig option in zkcli.sh But as Erick says, this would be better discussed on the list. If run Solr having two collections configured but only one config delivered to Zookeeper causes that config is applied for all collections -- Key: SOLR-6392 URL: https://issues.apache.org/jira/browse/SOLR-6392 Project: Solr Issue Type: Bug Affects Versions: 4.4 Reporter: Ilya Meleshkov I have simplest Solr cloud configured locally. Thus I have single Solr and Zookeeper nodes. Steps to reproduce an error: # have stopped Solr+ZK with two collections # run ZK # deliver config to one collection only # run Solr - Solr running without any complains or errors # deliver config to second collection - doesn't have an effect But if I deliver configs for both collections before start Solr - it work perfectly. So I would say that Solr should fail with meaningful error if there is no config for some collection. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5952) Recovery race/ error
[ https://issues.apache.org/jira/browse/SOLR-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958614#comment-13958614 ] Daniel Collins commented on SOLR-5952: -- I know there have been issues if the follower disconnected from ZK, then it will fail to take updates from the leader (since it can't confirm the source of the messages is the real leader), so the follower will get asked to recover, and will have to wait until it has a valid ZK connection in order to do that. But I believe there have been fixes around that area. In the example logs here though (I'm assuming host 1 was the leader) host1 says that its last published state was down? We might need to go further back in the trace history of that node, why did it publish itself as down but was still leader? Recovery race/ error Key: SOLR-5952 URL: https://issues.apache.org/jira/browse/SOLR-5952 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.7 Reporter: Jessica Cheng Assignee: Mark Miller Labels: leader, recovery, solrcloud, zookeeper Fix For: 4.8, 5.0 Attachments: recovery-failure-host1-log.txt, recovery-failure-host2-log.txt We're seeing some shard recovery errors in our cluster when a zookeeper error event happened. In this particular case, we had two replicas. The event from the logs look roughly like this: 18:40:36 follower (host2) disconnected from zk 18:40:38 original leader started recovery (there was no log about why it needed recovery though) and failed because cluster state still says it's the leader 18:40:39 follower successfully connected to zk after some trouble 19:03:35 follower register core/replica 19:16:36 follower registration fails due to no leader (NoNode for /collections/test-1/leaders/shard2) Essentially, I think the problem is that the isLeader property on the cluster state is never cleaned up, so neither replicas are able to recover/register in order to participate in leader election again. Looks like from the code that the only place that the isLeader property is cleared from the cluster state is from ElectionContext.runLeaderProcess, which assumes that the replica with the next election seqId will notice the leader's node disappearing and run the leader process. This assumption fails in this scenario because the follower experienced the same zookeeper error event and never handled the event of the leader going away. (Mark, this is where I was saying in SOLR-3582 that maybe the watcher in LeaderElector.checkIfIamLeader does need to handle Expired by somehow realizing that the leader is gone and clearing the isLeader state at least, but it currently ignores all EventType.None events.) -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5747) Update the config need manual restart the cluster server.
[ https://issues.apache.org/jira/browse/SOLR-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13906792#comment-13906792 ] Daniel Collins commented on SOLR-5747: -- I'd agree with Shawn/Mark, for a large production system, having it automatically pick up new configuration feels positively dangerous. Our production systems need more fine-grained control over when replicas are reloaded, so operationally, we upload new config, and then restart parts of the cloud piece by piece. This also reduces our load on ZK (we have 1024 cores, so it they all receive a watch at the same time, and start pulling config, its a non-trivial load on ZK, and the poor old Overseer gets swamped!) I can understand automatic deployment in a development system (definitely easier I grant you), or maybe small-scale production (depends what rollout/backout you have to handle) but seems more of a nice to have than important. But I guess it depends on your use case. Update the config need manual restart the cluster server. - Key: SOLR-5747 URL: https://issues.apache.org/jira/browse/SOLR-5747 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.5, 4.5.1, 4.6, 4.6.1 Environment: linux, solr cloud Reporter: Raintung Li Labels: collection, config Attachments: patch-5747 Many collections bundle one config. If I update the config, I need manual reload the collection one by one. Could monitor config for every collection. If update the config, the monitor will notify and automatic reload collection for every solr core. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5689) On reconnect, ZkController cancels election on first context rather than latest
[
https://issues.apache.org/jira/browse/SOLR-5689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889390#comment-13889390
]
Daniel Collins commented on SOLR-5689:
--
My understanding of what `LeaderElector.setup()` does is that it just creates
the `/overseer_elect/election` directory in ZK. This isn't ephemeral, so in
reality should only be a one-off job? Unless ZK has been wiped whilst the node
was disconnected from ZK, that directory should still be there. It shouldn't
hurt to add in the call to setup in reconnect, but I don't believe it is
necessary.
cancelElection() removes the `leaderSeqPath` which is the ephemeral node(s)
under that directory, e.g.
19127283862405127-xxx:y_solr-n_000368 in my case.
On reconnect, ZkController cancels election on first context rather than
latest
---
Key: SOLR-5689
URL: https://issues.apache.org/jira/browse/SOLR-5689
Project: Solr
Issue Type: Bug
Affects Versions: 4.6.1, 5.0, 4.7
Reporter: Gregory Chanan
I haven't tested this yet, so I could be wrong, but this is my reading of the
code:
During init:
{code}
ElectionContext context = new OverseerElectionContext(zkClient, overseer,
getNodeName());
overseerElector.setup(context);
overseerElector.joinElection(context, false);
{code}
On reconnect:
{code}
ElectionContext context = new OverseerElectionContext(zkClient,overseer,
getNodeName());
ElectionContext prevContext = overseerElector.getContext();
if (prevContext != null) {
prevContext.cancelElection();
}
overseerElector.joinElection(context, true);
{code}
setup doesn't appear to be called on reconnect, so the new context is never
set and the first context gets cancelled over and over.
A call to overseerElector.setup(context); before joinElection in the
reconnect case would address this.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5689) On reconnect, ZkController cancels election on first context rather than latest
[
https://issues.apache.org/jira/browse/SOLR-5689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889607#comment-13889607
]
Daniel Collins commented on SOLR-5689:
--
DOH, my bad, missed that line, too used to expecting whitespace line between
bracket and first code statement, must be a bug in my brain's Java parser.
On reconnect, ZkController cancels election on first context rather than
latest
---
Key: SOLR-5689
URL: https://issues.apache.org/jira/browse/SOLR-5689
Project: Solr
Issue Type: Bug
Affects Versions: 4.6.1, 5.0, 4.7
Reporter: Gregory Chanan
I haven't tested this yet, so I could be wrong, but this is my reading of the
code:
During init:
{code}
ElectionContext context = new OverseerElectionContext(zkClient, overseer,
getNodeName());
overseerElector.setup(context);
overseerElector.joinElection(context, false);
{code}
On reconnect:
{code}
ElectionContext context = new OverseerElectionContext(zkClient,overseer,
getNodeName());
ElectionContext prevContext = overseerElector.getContext();
if (prevContext != null) {
prevContext.cancelElection();
}
overseerElector.joinElection(context, true);
{code}
setup doesn't appear to be called on reconnect, so the new context is never
set and the first context gets cancelled over and over.
A call to overseerElector.setup(context); before joinElection in the
reconnect case would address this.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5658) commitWithin does not reflect the new documents added
[
https://issues.apache.org/jira/browse/SOLR-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13880114#comment-13880114
]
Daniel Collins commented on SOLR-5658:
--
Mark, what's the impact of this issue? Are you saying that soft commits were
never distributed (which seems quite a big deal!), or is it more subtle than
that?
commitWithin does not reflect the new documents added
-
Key: SOLR-5658
URL: https://issues.apache.org/jira/browse/SOLR-5658
Project: Solr
Issue Type: Bug
Affects Versions: 4.6, 5.0
Reporter: Varun Thacker
Assignee: Shalin Shekhar Mangar
Attachments: SOLR-5658.patch
I start 4 nodes using the setup mentioned on -
https://cwiki.apache.org/confluence/display/solr/Getting+Started+with+SolrCloud
I added a document using -
curl http://localhost:8983/solr/update?commitWithin=1 -H Content-Type:
text/xml --data-binary 'adddocfield
name=idtestdoc/field/doc/add'
In Solr 4.5.1 there is 1 soft commit with openSearcher=true and 1 hard commit
with openSearcher=false
In Solr 4.6.x there is there is only one commit hard commit with
openSearcher=false
So even after 10 seconds queries on none of the shards reflect the added
document.
This was also reported on the solr-user list (
http://lucene.472066.n3.nabble.com/Possible-regression-for-Solr-4-6-0-commitWithin-does-not-work-with-replicas-td4106102.html
)
Here are the relevant logs
Logs from Solr 4.5.1
Node 1:
{code}
420021 [qtp619011445-12] INFO
org.apache.solr.update.processor.LogUpdateProcessor – [collection1]
webapp=/solr path=/update params={commitWithin=1} {add=[testdoc]} 0 45
{code}
Node 2:
{code}
119896 [qtp1608701025-10] INFO
org.apache.solr.update.processor.LogUpdateProcessor – [collection1]
webapp=/solr path=/update
params={distrib.from=http://192.168.1.103:8983/solr/collection1/update.distrib=TOLEADERwt=javabinversion=2}
{add=[testdoc (1458003295513608192)]} 0 348
129648 [commitScheduler-8-thread-1] INFO
org.apache.solr.update.UpdateHandler – start
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
129679 [commitScheduler-8-thread-1] INFO
org.apache.solr.search.SolrIndexSearcher – Opening Searcher@e174f70 main
129680 [commitScheduler-8-thread-1] INFO
org.apache.solr.update.UpdateHandler – end_commit_flush
129681 [searcherExecutor-5-thread-1] INFO org.apache.solr.core.SolrCore –
QuerySenderListener sending requests to Searcher@e174f70
main{StandardDirectoryReader(segments_3:11:nrt _2(4.5.1):C1)}
129681 [searcherExecutor-5-thread-1] INFO org.apache.solr.core.SolrCore –
QuerySenderListener done.
129681 [searcherExecutor-5-thread-1] INFO org.apache.solr.core.SolrCore –
[collection1] Registered new searcher Searcher@e174f70
main{StandardDirectoryReader(segments_3:11:nrt _2(4.5.1):C1)}
134648 [commitScheduler-7-thread-1] INFO
org.apache.solr.update.UpdateHandler – start
commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
134658 [commitScheduler-7-thread-1] INFO org.apache.solr.core.SolrCore –
SolrDeletionPolicy.onCommit: commits: num=2
commit{dir=NRTCachingDirectory(org.apache.lucene.store.NIOFSDirectory@/Users/varun/solr-4.5.1/node2/solr/collection1/data/index
lockFactory=org.apache.lucene.store.NativeFSLockFactory@66a394a3;
maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_3,generation=3}
commit{dir=NRTCachingDirectory(org.apache.lucene.store.NIOFSDirectory@/Users/varun/solr-4.5.1/node2/solr/collection1/data/index
lockFactory=org.apache.lucene.store.NativeFSLockFactory@66a394a3;
maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_4,generation=4}
134658 [commitScheduler-7-thread-1] INFO org.apache.solr.core.SolrCore –
newest commit generation = 4
134660 [commitScheduler-7-thread-1] INFO
org.apache.solr.update.UpdateHandler – end_commit_flush
{code}
Node 3:
Node 4:
{code}
374545 [qtp1608701025-16] INFO
org.apache.solr.update.processor.LogUpdateProcessor – [collection1]
webapp=/solr path=/update
params={distrib.from=http://192.168.1.103:7574/solr/collection1/update.distrib=FROMLEADERwt=javabinversion=2}
{add=[testdoc (1458002133233172480)]} 0 20
384545 [commitScheduler-8-thread-1] INFO
org.apache.solr.update.UpdateHandler – start
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
384552 [commitScheduler-8-thread-1] INFO
org.apache.solr.search.SolrIndexSearcher – Opening Searcher@36137e08 main
384553 [commitScheduler-8-thread-1] INFO
org.apache.solr.update.UpdateHandler – end_commit_flush
384553 [searcherExecutor-5-thread-1] INFO
[jira] [Comment Edited] (SOLR-5658) commitWithin does not reflect the new documents added
[
https://issues.apache.org/jira/browse/SOLR-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13880114#comment-13880114
]
Daniel Collins edited comment on SOLR-5658 at 1/23/14 5:38 PM:
---
Mark, what's the impact of this issue? Are you saying that CommitWithin was
never distributed (which seems quite a big deal!), or is it more subtle than
that?
was (Author: dancollins):
Mark, what's the impact of this issue? Are you saying that soft commits were
never distributed (which seems quite a big deal!), or is it more subtle than
that?
commitWithin does not reflect the new documents added
-
Key: SOLR-5658
URL: https://issues.apache.org/jira/browse/SOLR-5658
Project: Solr
Issue Type: Bug
Affects Versions: 4.6, 5.0
Reporter: Varun Thacker
Assignee: Shalin Shekhar Mangar
Attachments: SOLR-5658.patch
I start 4 nodes using the setup mentioned on -
https://cwiki.apache.org/confluence/display/solr/Getting+Started+with+SolrCloud
I added a document using -
curl http://localhost:8983/solr/update?commitWithin=1 -H Content-Type:
text/xml --data-binary 'adddocfield
name=idtestdoc/field/doc/add'
In Solr 4.5.1 there is 1 soft commit with openSearcher=true and 1 hard commit
with openSearcher=false
In Solr 4.6.x there is there is only one commit hard commit with
openSearcher=false
So even after 10 seconds queries on none of the shards reflect the added
document.
This was also reported on the solr-user list (
http://lucene.472066.n3.nabble.com/Possible-regression-for-Solr-4-6-0-commitWithin-does-not-work-with-replicas-td4106102.html
)
Here are the relevant logs
Logs from Solr 4.5.1
Node 1:
{code}
420021 [qtp619011445-12] INFO
org.apache.solr.update.processor.LogUpdateProcessor – [collection1]
webapp=/solr path=/update params={commitWithin=1} {add=[testdoc]} 0 45
{code}
Node 2:
{code}
119896 [qtp1608701025-10] INFO
org.apache.solr.update.processor.LogUpdateProcessor – [collection1]
webapp=/solr path=/update
params={distrib.from=http://192.168.1.103:8983/solr/collection1/update.distrib=TOLEADERwt=javabinversion=2}
{add=[testdoc (1458003295513608192)]} 0 348
129648 [commitScheduler-8-thread-1] INFO
org.apache.solr.update.UpdateHandler – start
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
129679 [commitScheduler-8-thread-1] INFO
org.apache.solr.search.SolrIndexSearcher – Opening Searcher@e174f70 main
129680 [commitScheduler-8-thread-1] INFO
org.apache.solr.update.UpdateHandler – end_commit_flush
129681 [searcherExecutor-5-thread-1] INFO org.apache.solr.core.SolrCore –
QuerySenderListener sending requests to Searcher@e174f70
main{StandardDirectoryReader(segments_3:11:nrt _2(4.5.1):C1)}
129681 [searcherExecutor-5-thread-1] INFO org.apache.solr.core.SolrCore –
QuerySenderListener done.
129681 [searcherExecutor-5-thread-1] INFO org.apache.solr.core.SolrCore –
[collection1] Registered new searcher Searcher@e174f70
main{StandardDirectoryReader(segments_3:11:nrt _2(4.5.1):C1)}
134648 [commitScheduler-7-thread-1] INFO
org.apache.solr.update.UpdateHandler – start
commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
134658 [commitScheduler-7-thread-1] INFO org.apache.solr.core.SolrCore –
SolrDeletionPolicy.onCommit: commits: num=2
commit{dir=NRTCachingDirectory(org.apache.lucene.store.NIOFSDirectory@/Users/varun/solr-4.5.1/node2/solr/collection1/data/index
lockFactory=org.apache.lucene.store.NativeFSLockFactory@66a394a3;
maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_3,generation=3}
commit{dir=NRTCachingDirectory(org.apache.lucene.store.NIOFSDirectory@/Users/varun/solr-4.5.1/node2/solr/collection1/data/index
lockFactory=org.apache.lucene.store.NativeFSLockFactory@66a394a3;
maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_4,generation=4}
134658 [commitScheduler-7-thread-1] INFO org.apache.solr.core.SolrCore –
newest commit generation = 4
134660 [commitScheduler-7-thread-1] INFO
org.apache.solr.update.UpdateHandler – end_commit_flush
{code}
Node 3:
Node 4:
{code}
374545 [qtp1608701025-16] INFO
org.apache.solr.update.processor.LogUpdateProcessor – [collection1]
webapp=/solr path=/update
params={distrib.from=http://192.168.1.103:7574/solr/collection1/update.distrib=FROMLEADERwt=javabinversion=2}
{add=[testdoc (1458002133233172480)]} 0 20
384545 [commitScheduler-8-thread-1] INFO
org.apache.solr.update.UpdateHandler – start
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
384552
[jira] [Commented] (SOLR-5658) commitWithin does not reflect the new documents added
[
https://issues.apache.org/jira/browse/SOLR-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13880139#comment-13880139
]
Daniel Collins commented on SOLR-5658:
--
Ok, was just puzzled about how our system is working then (4.4.0), we
consistently see softCommits running on the replicas, maybe it is autoCommit
firing instead...
commitWithin does not reflect the new documents added
-
Key: SOLR-5658
URL: https://issues.apache.org/jira/browse/SOLR-5658
Project: Solr
Issue Type: Bug
Affects Versions: 4.6, 5.0
Reporter: Varun Thacker
Assignee: Shalin Shekhar Mangar
Attachments: SOLR-5658.patch
I start 4 nodes using the setup mentioned on -
https://cwiki.apache.org/confluence/display/solr/Getting+Started+with+SolrCloud
I added a document using -
curl http://localhost:8983/solr/update?commitWithin=1 -H Content-Type:
text/xml --data-binary 'adddocfield
name=idtestdoc/field/doc/add'
In Solr 4.5.1 there is 1 soft commit with openSearcher=true and 1 hard commit
with openSearcher=false
In Solr 4.6.x there is there is only one commit hard commit with
openSearcher=false
So even after 10 seconds queries on none of the shards reflect the added
document.
This was also reported on the solr-user list (
http://lucene.472066.n3.nabble.com/Possible-regression-for-Solr-4-6-0-commitWithin-does-not-work-with-replicas-td4106102.html
)
Here are the relevant logs
Logs from Solr 4.5.1
Node 1:
{code}
420021 [qtp619011445-12] INFO
org.apache.solr.update.processor.LogUpdateProcessor – [collection1]
webapp=/solr path=/update params={commitWithin=1} {add=[testdoc]} 0 45
{code}
Node 2:
{code}
119896 [qtp1608701025-10] INFO
org.apache.solr.update.processor.LogUpdateProcessor – [collection1]
webapp=/solr path=/update
params={distrib.from=http://192.168.1.103:8983/solr/collection1/update.distrib=TOLEADERwt=javabinversion=2}
{add=[testdoc (1458003295513608192)]} 0 348
129648 [commitScheduler-8-thread-1] INFO
org.apache.solr.update.UpdateHandler – start
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
129679 [commitScheduler-8-thread-1] INFO
org.apache.solr.search.SolrIndexSearcher – Opening Searcher@e174f70 main
129680 [commitScheduler-8-thread-1] INFO
org.apache.solr.update.UpdateHandler – end_commit_flush
129681 [searcherExecutor-5-thread-1] INFO org.apache.solr.core.SolrCore –
QuerySenderListener sending requests to Searcher@e174f70
main{StandardDirectoryReader(segments_3:11:nrt _2(4.5.1):C1)}
129681 [searcherExecutor-5-thread-1] INFO org.apache.solr.core.SolrCore –
QuerySenderListener done.
129681 [searcherExecutor-5-thread-1] INFO org.apache.solr.core.SolrCore –
[collection1] Registered new searcher Searcher@e174f70
main{StandardDirectoryReader(segments_3:11:nrt _2(4.5.1):C1)}
134648 [commitScheduler-7-thread-1] INFO
org.apache.solr.update.UpdateHandler – start
commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
134658 [commitScheduler-7-thread-1] INFO org.apache.solr.core.SolrCore –
SolrDeletionPolicy.onCommit: commits: num=2
commit{dir=NRTCachingDirectory(org.apache.lucene.store.NIOFSDirectory@/Users/varun/solr-4.5.1/node2/solr/collection1/data/index
lockFactory=org.apache.lucene.store.NativeFSLockFactory@66a394a3;
maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_3,generation=3}
commit{dir=NRTCachingDirectory(org.apache.lucene.store.NIOFSDirectory@/Users/varun/solr-4.5.1/node2/solr/collection1/data/index
lockFactory=org.apache.lucene.store.NativeFSLockFactory@66a394a3;
maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_4,generation=4}
134658 [commitScheduler-7-thread-1] INFO org.apache.solr.core.SolrCore –
newest commit generation = 4
134660 [commitScheduler-7-thread-1] INFO
org.apache.solr.update.UpdateHandler – end_commit_flush
{code}
Node 3:
Node 4:
{code}
374545 [qtp1608701025-16] INFO
org.apache.solr.update.processor.LogUpdateProcessor – [collection1]
webapp=/solr path=/update
params={distrib.from=http://192.168.1.103:7574/solr/collection1/update.distrib=FROMLEADERwt=javabinversion=2}
{add=[testdoc (1458002133233172480)]} 0 20
384545 [commitScheduler-8-thread-1] INFO
org.apache.solr.update.UpdateHandler – start
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
384552 [commitScheduler-8-thread-1] INFO
org.apache.solr.search.SolrIndexSearcher – Opening Searcher@36137e08 main
384553 [commitScheduler-8-thread-1] INFO
org.apache.solr.update.UpdateHandler – end_commit_flush
384553 [searcherExecutor-5-thread-1]
[jira] [Commented] (SOLR-5563) Tone down some SolrCloud logging
[ https://issues.apache.org/jira/browse/SOLR-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13853797#comment-13853797 ] Daniel Collins commented on SOLR-5563: -- Just a note, we are still in the process of trying to debug some cloud-related issues that we only see in production, and messages like the Watcher (from ConnectionManager.java) and A cluster state change (from ZKStateReader.java) are really useful to us, without those we would never have been able to debug our latest issue (which we should be logging later today). I know we could configure logging to enable some debug trace in specific components, but we then need to go through all the components and work out which ones we need to enable. but I would just urge some caution on this before committing IMHO. SolrCloud issues are still being reported issues on the list, so there still seem to be some issues related to the Overseer that haven't been caught yet. Just my tuppence worth :) Tone down some SolrCloud logging Key: SOLR-5563 URL: https://issues.apache.org/jira/browse/SOLR-5563 Project: Solr Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward Priority: Minor Attachments: SOLR-5563.patch We output a *lot* of logging data from various bits of SolrCloud, a lot of which is basically implementation detail that isn't particularly helpful. Here's a patch to move a bunch of stuff to #debug level, rather than #info. -- This message was sent by Atlassian JIRA (v6.1.4#6159) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5351) DirectoryReader#close can throw AlreadyClosedException if it's and NRT reader
[
https://issues.apache.org/jira/browse/LUCENE-5351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13835259#comment-13835259
]
Daniel Collins commented on LUCENE-5351:
Hmm, I have noticed this error when using RAMDirectoryFactory, I often get an
AlreadyClosedException when I shutdown my instance that uses that Will try
to see if this is the same issue.
DirectoryReader#close can throw AlreadyClosedException if it's and NRT reader
-
Key: LUCENE-5351
URL: https://issues.apache.org/jira/browse/LUCENE-5351
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Affects Versions: 4.6
Reporter: Simon Willnauer
Assignee: Simon Willnauer
Fix For: 5.0, 4.7
in StandartDirectoryReader#doClose we do this:
{noformat}
if (writer != null) {
// Since we just closed, writer may now be able to
// delete unused files:
writer.deletePendingFiles();
}
{noformat}
which can throw AlreadyClosedException from the directory if the Direcotory
has already closed. To me this looks like a bug and we should catch this
exception from the directory.
--
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-5277) Stamp core names on log entries for certain classes
[
https://issues.apache.org/jira/browse/SOLR-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831416#comment-13831416
]
Daniel Collins commented on SOLR-5277:
--
Seems to me that several approaches have merit.
1) At a basic level, we should be naming the Solr threads with core-name if it
is available. wherever we use {{DefaultSolrThreadFactory}} or anything derived
from that, we should try to include a core-name.
2) Something like MDC could help for those classes that don't have direct
access to the core, but presumably that is more work that option 1) but can be
done at a slower pace?
Stamp core names on log entries for certain classes
---
Key: SOLR-5277
URL: https://issues.apache.org/jira/browse/SOLR-5277
Project: Solr
Issue Type: Bug
Components: search, update
Affects Versions: 4.3.1, 4.4, 4.5
Reporter: Dmitry Kan
Attachments: SOLR-5277.patch, SOLR-5277.patch
It is handy that certain Java classes stamp a [coreName] on a log entry. It
would be useful for multicore setup if more classes would stamp this
information.
In particular we came accross a situaion with commits coming in a quick
succession to the same multicore shard and found it to be hard time figuring
out was it the same core or different cores.
The classes in question with log sample output:
o.a.s.c.SolrCore
06:57:53.577 [qtp1640764503-13617] INFO org.apache.solr.core.SolrCore -
SolrDeletionPolicy.onCommit: commits:num=2
11:53:19.056 [coreLoadExecutor-3-thread-1] INFO
org.apache.solr.core.SolrCore - Soft AutoCommit: if uncommited for 1000ms;
o.a.s.u.UpdateHandler
14:45:24.447 [commitScheduler-9-thread-1] INFO
org.apache.solr.update.UpdateHandler - start
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
06:57:53.591 [qtp1640764503-13617] INFO org.apache.solr.update.UpdateHandler
- end_commit_flush
o.a.s.s.SolrIndexSearcher
14:45:24.553 [commitScheduler-7-thread-1] INFO
org.apache.solr.search.SolrIndexSearcher - Opening Searcher@1067e5a9 main
The original question was posted on #solr and on SO:
http://stackoverflow.com/questions/19026577/how-to-output-solr-core-name-with-log4j
--
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-5499) Real-time /get handler is required when using Solr Cloud
Daniel Collins created SOLR-5499:
Summary: Real-time /get handler is required when using Solr Cloud
Key: SOLR-5499
URL: https://issues.apache.org/jira/browse/SOLR-5499
Project: Solr
Issue Type: Bug
Components: documentation
Affects Versions: 4.5.1, 4.5, 4.4
Reporter: Daniel Collins
Priority: Minor
Noticed during some leadership election when we shutdown Solr nodes.
Delving through the code it seems that PeerSync uses the /get handler (with
some very ugly code explicitly creating an HTTP request by hand). If that isn't
configured, then any election change will cause a full sync in ALL replicas for
the shard in question.
{noformat}
2013-11-25 06:35:39,766 INFO [main-EventThread] o.a.s.c.SyncStrategy
[SyncStrategy.java:94] Sync replicas to
http://x:xxx/solr/_shard74_replica1/
2013-11-25 06:35:39,766 INFO [main-EventThread] o.a.s.u.PeerSync
[PeerSync.java:186] PeerSync: core=xxx_shard74_replica1 u
rl=http://xxx:x/solr START
replicas=[http://xxx:/solr/xxx_shard74_replica2/, http://:xxx/sol
r/xxx_shard74_replica3/] nUpdates=100
2013-11-25 06:35:39,768 WARN [main-EventThread] o.a.s.u.PeerSync
[PeerSync.java:321] PeerSync: core=xxx_shard74_replica1 u
rl=http://xxx:xxx/solr got a 404 from
http://xxx:xxx/solr/xxx_shard74_replica2/, counting as success
2013-11-25 06:35:39,769 INFO [main-EventThread] o.a.s.u.PeerSync
[PeerSync.java:273] PeerSync: core=xxx_shard74_replica1 u
rl=http://nsrchnj2:10650/solr DONE. sync succeeded
2013-11-25 06:35:39,769 INFO [main-EventThread] o.a.s.c.SyncStrategy
[SyncStrategy.java:134] Sync Success - now sync replicas to me
2013-11-25 06:35:39,769 INFO [main-EventThread] o.a.s.c.SyncStrategy
[SyncStrategy.java:191] http://xxx:xxx/solr/xxx_shard74_replica1/: try and ask
http://xxx:xxx/solr/xxx_shard74_replica2/ to sync
2013-11-25 06:35:39,771 ERROR [main-EventThread] o.a.s.c.SyncStrategy
[SolrException.java:129] Sync request error: org.apache.solr.client.
solrj.impl.HttpSolrServer$RemoteSolrException: Server at
http://xxx:xxx/solr/xxx_shard74_replica3 returned non ok
status:404, message:Not Found
2013-11-25 06:35:39,771 INFO [main-EventThread] o.a.s.c.SyncStrategy
[SyncStrategy.java:211] http://xxx:xxx/solr/xxx_shard74_replica1/: Sync failed
- asking replica (http://xxx:xxx/solr/xxx_shard74_replica2/) to recover.
{noformat}
The triggers here (for me) were the 404 response codes, but we should just make
it clear in the docs that the /get handler is required and shouldn't be removed
(if using Solr Cloud)
--
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-5209) cores/action=UNLOAD of last replica removes shard from clusterstate
[
https://issues.apache.org/jira/browse/SOLR-5209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13756446#comment-13756446
]
Daniel Collins commented on SOLR-5209:
--
When I had a look at that code, I was confused why removeCore was even
attempting to remove all empty pre allocated slices? And it also tries to
clean up collections, given we have the collections API to do that, why is a
simple core unload going any further? I can see that its nice and saves the
user having to run the collections API to remove the collection, but isn't it
potentially dangerous (like in this case) if we are second guessing what the
user will do next?
Say they are just removing all the replicas, and re-assigning them to different
hosts? They may want to leave the collection/shard ranges empty and then
move the data to new hosts, and restart the cores to re-register them. Yes, we
could/should start the new ones before removing the old, but that's not
enforced?
cores/action=UNLOAD of last replica removes shard from clusterstate
---
Key: SOLR-5209
URL: https://issues.apache.org/jira/browse/SOLR-5209
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.4
Reporter: Christine Poerschke
Attachments: SOLR-5209.patch
The problem we saw was that unloading of an only replica of a shard deleted
that shard's info from the clusterstate. Once it was gone then there was no
easy way to re-create the shard (other than dropping and re-creating the
whole collection's state).
This seems like a bug?
Overseer.java around line 600 has a comment and commented out code:
// TODO TODO TODO!!! if there are no replicas left for the slice, and the
slice has no hash range, remove it
// if (newReplicas.size() == 0 slice.getRange() == null) {
// if there are no replicas left for the slice remove it
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5209) cores/action=UNLOAD of last replica removes shard from clusterstate
[
https://issues.apache.org/jira/browse/SOLR-5209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13756446#comment-13756446
]
Daniel Collins edited comment on SOLR-5209 at 9/3/13 8:25 AM:
--
When I had a look at that code, I was confused why {{removeCore}} was even
attempting to remove all empty pre allocated slices? And it also tries to
clean up collections, given we have the collections API to do that, why is a
simple core unload going any further? I can see that its nice and saves the
user having to run the collections API to remove the collection, but isn't it
potentially dangerous (like in this case) if we are second guessing what the
user will do next?
Say they are just removing all the replicas, and re-assigning them to different
hosts? They may want to leave the collection/shard ranges empty and then
move the data to new hosts, and restart the cores to re-register them. Yes, we
could/should start the new ones before removing the old, but that's not
enforced?
was (Author: dancollins):
When I had a look at that code, I was confused why removeCore was even
attempting to remove all empty pre allocated slices? And it also tries to
clean up collections, given we have the collections API to do that, why is a
simple core unload going any further? I can see that its nice and saves the
user having to run the collections API to remove the collection, but isn't it
potentially dangerous (like in this case) if we are second guessing what the
user will do next?
Say they are just removing all the replicas, and re-assigning them to different
hosts? They may want to leave the collection/shard ranges empty and then
move the data to new hosts, and restart the cores to re-register them. Yes, we
could/should start the new ones before removing the old, but that's not
enforced?
cores/action=UNLOAD of last replica removes shard from clusterstate
---
Key: SOLR-5209
URL: https://issues.apache.org/jira/browse/SOLR-5209
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.4
Reporter: Christine Poerschke
Attachments: SOLR-5209.patch
The problem we saw was that unloading of an only replica of a shard deleted
that shard's info from the clusterstate. Once it was gone then there was no
easy way to re-create the shard (other than dropping and re-creating the
whole collection's state).
This seems like a bug?
Overseer.java around line 600 has a comment and commented out code:
// TODO TODO TODO!!! if there are no replicas left for the slice, and the
slice has no hash range, remove it
// if (newReplicas.size() == 0 slice.getRange() == null) {
// if there are no replicas left for the slice remove it
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5209) cores/action=UNLOAD of last replica removes shard from clusterstate
[
https://issues.apache.org/jira/browse/SOLR-5209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13756827#comment-13756827
]
Daniel Collins commented on SOLR-5209:
--
Ok, my bad, I wasn't clear enough. At the user-level there is collections API
and core API, and yes one is just a wrapper around the other. But at the
Overseer level, we seem to have various different sub-commands (not sure what
the correct terminology for them is!): create_shard, removeshard,
createcollection, removecollection, deletecore, etc. I appreciate this is
probably historical code, but since we have these other methods, it felt like
deletecore was overstepping its bounds now :)
Could submit an extra patch, but wasn't sure of the historical nature of this
code, hence just a comment first to get an opinion/discussion.
cores/action=UNLOAD of last replica removes shard from clusterstate
---
Key: SOLR-5209
URL: https://issues.apache.org/jira/browse/SOLR-5209
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.4
Reporter: Christine Poerschke
Assignee: Mark Miller
Attachments: SOLR-5209.patch
The problem we saw was that unloading of an only replica of a shard deleted
that shard's info from the clusterstate. Once it was gone then there was no
easy way to re-create the shard (other than dropping and re-creating the
whole collection's state).
This seems like a bug?
Overseer.java around line 600 has a comment and commented out code:
// TODO TODO TODO!!! if there are no replicas left for the slice, and the
slice has no hash range, remove it
// if (newReplicas.size() == 0 slice.getRange() == null) {
// if there are no replicas left for the slice remove it
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5209) cores/action=UNLOAD of last replica removes shard from clusterstate
[
https://issues.apache.org/jira/browse/SOLR-5209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13756827#comment-13756827
]
Daniel Collins edited comment on SOLR-5209 at 9/3/13 5:46 PM:
--
Ok, my bad, I wasn't clear enough. At the user-level there is collections API
and core API, and yes one is just a wrapper around the other. But at the
Overseer level, we seem to have various different sub-commands (not sure what
the correct terminology for them is!): {{create_shard}}, {{removeshard}},
{{createcollection}}, {{removecollection}}, {{deletecore}}, etc. I appreciate
this is probably historical code, but since we have these other methods, it
felt like deletecore was overstepping its bounds now :)
Could submit an extra patch, but wasn't sure of the historical nature of this
code, hence just a comment first to get an opinion/discussion.
was (Author: dancollins):
Ok, my bad, I wasn't clear enough. At the user-level there is collections
API and core API, and yes one is just a wrapper around the other. But at the
Overseer level, we seem to have various different sub-commands (not sure what
the correct terminology for them is!): create_shard, removeshard,
createcollection, removecollection, deletecore, etc. I appreciate this is
probably historical code, but since we have these other methods, it felt like
deletecore was overstepping its bounds now :)
Could submit an extra patch, but wasn't sure of the historical nature of this
code, hence just a comment first to get an opinion/discussion.
cores/action=UNLOAD of last replica removes shard from clusterstate
---
Key: SOLR-5209
URL: https://issues.apache.org/jira/browse/SOLR-5209
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.4
Reporter: Christine Poerschke
Assignee: Mark Miller
Attachments: SOLR-5209.patch
The problem we saw was that unloading of an only replica of a shard deleted
that shard's info from the clusterstate. Once it was gone then there was no
easy way to re-create the shard (other than dropping and re-creating the
whole collection's state).
This seems like a bug?
Overseer.java around line 600 has a comment and commented out code:
// TODO TODO TODO!!! if there are no replicas left for the slice, and the
slice has no hash range, remove it
// if (newReplicas.size() == 0 slice.getRange() == null) {
// if there are no replicas left for the slice remove it
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5121) zkcli usage for makepath doesn't match actual command.
Daniel Collins created SOLR-5121: Summary: zkcli usage for makepath doesn't match actual command. Key: SOLR-5121 URL: https://issues.apache.org/jira/browse/SOLR-5121 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.4 Reporter: Daniel Collins Priority: Minor After the patch for SOLR-4972 was introduced, the usage for zkcli.sh -cmd makepath changed to zkcli.sh -zkhost localhost:9983 -cmd makepath /apache/solr/data.txt 'config data' Yet that is not what the command expects, it expects just a single path to create, no data can be supplied. put is the new way to create an actual file in ZK. Am assuming makepath should have stayed as it was (so command is correct, but usage is wrong), alternatively usage might be right and makepath could be a superset of PUT (but that seems unlikely) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5121) zkcli usage for makepath doesn't match actual command.
[
https://issues.apache.org/jira/browse/SOLR-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Collins updated SOLR-5121:
-
Description:
After the patch for SOLR-4972 was introduced, the usage for zkcli.sh -cmd
makepath changed to
{{zkcli.sh -zkhost localhost:9983 -cmd makepath /apache/solr/data.txt 'config
data'}}
Yet that is not what the command expects, it expects just a single path to
create, no data can be supplied.
put is the new way to create an actual file in ZK.
Am assuming makepath should have stayed as it was (so command is correct, but
usage is wrong), alternatively usage might be right and makepath could be a
superset of PUT (but that seems unlikely)
was:
After the patch for SOLR-4972 was introduced, the usage for zkcli.sh -cmd
makepath changed to
zkcli.sh -zkhost localhost:9983 -cmd makepath /apache/solr/data.txt 'config
data'
Yet that is not what the command expects, it expects just a single path to
create, no data can be supplied.
put is the new way to create an actual file in ZK.
Am assuming makepath should have stayed as it was (so command is correct, but
usage is wrong), alternatively usage might be right and makepath could be a
superset of PUT (but that seems unlikely)
zkcli usage for makepath doesn't match actual command.
--
Key: SOLR-5121
URL: https://issues.apache.org/jira/browse/SOLR-5121
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.4
Reporter: Daniel Collins
Priority: Minor
After the patch for SOLR-4972 was introduced, the usage for zkcli.sh -cmd
makepath changed to
{{zkcli.sh -zkhost localhost:9983 -cmd makepath /apache/solr/data.txt 'config
data'}}
Yet that is not what the command expects, it expects just a single path to
create, no data can be supplied.
put is the new way to create an actual file in ZK.
Am assuming makepath should have stayed as it was (so command is correct, but
usage is wrong), alternatively usage might be right and makepath could be a
superset of PUT (but that seems unlikely)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5121) zkcli usage for makepath doesn't match actual command.
[
https://issues.apache.org/jira/browse/SOLR-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13732055#comment-13732055
]
Daniel Collins commented on SOLR-5121:
--
Trivial patch attached to correct the usage to what I think it should be.
zkcli usage for makepath doesn't match actual command.
--
Key: SOLR-5121
URL: https://issues.apache.org/jira/browse/SOLR-5121
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.4
Reporter: Daniel Collins
Priority: Minor
Attachments: SOLR-5121.patch
After the patch for SOLR-4972 was introduced, the usage for zkcli.sh -cmd
makepath changed to
{{zkcli.sh -zkhost localhost:9983 -cmd makepath /apache/solr/data.txt 'config
data'}}
Yet that is not what the command expects, it expects just a single path to
create, no data can be supplied.
put is the new way to create an actual file in ZK.
Am assuming makepath should have stayed as it was (so command is correct, but
usage is wrong), alternatively usage might be right and makepath could be a
superset of PUT (but that seems unlikely)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5121) zkcli usage for makepath doesn't match actual command.
[
https://issues.apache.org/jira/browse/SOLR-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Collins updated SOLR-5121:
-
Attachment: SOLR-5121.patch
zkcli usage for makepath doesn't match actual command.
--
Key: SOLR-5121
URL: https://issues.apache.org/jira/browse/SOLR-5121
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.4
Reporter: Daniel Collins
Priority: Minor
Attachments: SOLR-5121.patch
After the patch for SOLR-4972 was introduced, the usage for zkcli.sh -cmd
makepath changed to
{{zkcli.sh -zkhost localhost:9983 -cmd makepath /apache/solr/data.txt 'config
data'}}
Yet that is not what the command expects, it expects just a single path to
create, no data can be supplied.
put is the new way to create an actual file in ZK.
Am assuming makepath should have stayed as it was (so command is correct, but
usage is wrong), alternatively usage might be right and makepath could be a
superset of PUT (but that seems unlikely)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5102) Simplify Solr Home
[ https://issues.apache.org/jira/browse/SOLR-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13729424#comment-13729424 ] Daniel Collins commented on SOLR-5102: -- Maybe the more important question is what does solr.home mean and what should it contain? If using Solr Cloud, then solr.home is just solr.xml, zoo.cfg, and directories containing core.properties files. That is purely data and configuration, so I'd agree with Noble Paul, I wouldn't want that to live alongside JARs or code. I know the distinctions as a web-app are not as clear, but treating Solr like an application (which we do), we like to keep a nice distinction between code and data and I think I would object to something that forced it all to live in one area. For upgrades (assuming we migrate away from web-apps at some point), again it would be nice to keep the custom stuff, i.e. solr.xml, zoo.cfg and all my core configuration/data away from solr code, so I could migrate between Solr versions for an upgrade path more cleanly. Simplify Solr Home -- Key: SOLR-5102 URL: https://issues.apache.org/jira/browse/SOLR-5102 Project: Solr Issue Type: Bug Reporter: Grant Ingersoll Assignee: Grant Ingersoll Fix For: 5.0 I think for 5.0, we should re-think some of the variations we support around things like Solr Home, etc. We have a fair bit of code, I suspect that could just go away if make it easier by assuming there is a single solr home where everything lives. The notion of making that stuff configurable has outlived its usefulness -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5071) Solrcloud change core to another shard issue
[ https://issues.apache.org/jira/browse/SOLR-5071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13718187#comment-13718187 ] Daniel Collins commented on SOLR-5071: -- I suspect the response to this will be you are doing something unsupported. To do this properly, you should UNLOAD the old core, and (re-)CREATE it as a new core, that would keep ZK in sync. ZK has no knowledge of what you've done in the solr.xml file, so it can't possibly know what's going on. In addition, this syntax of solr.xml is deprecated as of Solr 4.4 so the whole issue would only affect versions up to Solr 4.3.1. From Solr 4.4 onwards, solr.xml won't have any of this information, it will be in the core.properties file for each core. I'm not sure what happens if you change that file by hand, but I suspect that may to be an unsupported action. Solrcloud change core to another shard issue Key: SOLR-5071 URL: https://issues.apache.org/jira/browse/SOLR-5071 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Illu Y Ying Attachments: 2013-7-24 11-55-45.png I have a solrcloud cluster with one collection and two shards. One core is a replica for shard1, I stop it and change its solr.xml like this: core name=collection1 instanceDir=collection1 shard=shard2/ So this core should be a shard2 replica, Then I restart it, open cloud graph page(see attachment), you can see this core as a down replica still in shard1 and also as a active replica in shard2. There is doubt about one core status in two shards. In this one core has two status scenario I suggest that if we could remove the down replica information of other shard in clusterStatus.json. I remember when core is changing to active status, it will send overseer an active status message, so add this logic to overseer change core to active status part. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5015) shards.info should return the shard ID
[
https://issues.apache.org/jira/browse/SOLR-5015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13705610#comment-13705610
]
Daniel Collins commented on SOLR-5015:
--
If we are suggesting alternative formats, could I vote for something with a
little more detail?
{code:javascript}
shards.info:[
{
shardName: shard2,
servers:[
207.237.114.232:8984/solr/collection1/,
207.237.114.232:8986/solr/collection1/
],
numFound:2,
maxScore:1.0,
time:224
},
{
shardName: shard1,
servers:[
207.237.114.232:8983/solr/collection1/,
207.237.114.232:8985/solr/collection1/
],
numFound:8,
maxScore:1.0,
time:898
}
]
{code}
The 2 important differences (for us) are that shards.info becomes an array
instead of an object with (non-obvious) keys, this seems a better fit
conceptually. And also, the list of servers becomes an array instead of a
string with some internal parsing required (separated by |).
Lastly, (though this could be a separate issue), it would be nice if
shards.info indicated *which* server out of the list it actually went to?
Currently the response indicates the results come from shard1 and shard2 and
which possible servers could have generated those responses. It would be nice
(for monitoring load and checking timings) to see which of these 2 servers
actually supplied the results for this query. We could use that to check
timing issues/load spikes on a particular replica of a shard.
I appreciate that shards.info pre-dates SolrCloud, and in that (Solr 3.x) world
the client dictated which servers to to go, but in the Cloud world, Solr can
load-balance itself, so it would be nice to see where it is sending requests
for monitoring purposes. Maybe we need a new cloud-aware parameter (e.g.
replicas.info), that wouldn't suffer any backward compatibility issues?
shards.info should return the shard ID
--
Key: SOLR-5015
URL: https://issues.apache.org/jira/browse/SOLR-5015
Project: Solr
Issue Type: Improvement
Components: SolrCloud
Reporter: Jack Krupansky
Currently, the shards.info section of a SolrCloud query response uses the |
delimited list of equivalent servers of the available servers for the shard
keys in the response, rather than the shard IDs (names?.)
My first preference would be for the shard IDs to be used for the shards.info
keys, and then the list of servers could be a servers key value at the next
level down in the response. But if compatibility is important, continue to
use the server list as the keys for shards.info, and then add shardID or
shardName as a key at the next level down in the response.
For example, instead of:
{code}
shards.info:{
207.237.114.232:8984/solr/collection1/|207.237.114.232:8986/solr/collection1/:{
numFound:2,
maxScore:1.0,
time:224},
207.237.114.232:8983/solr/collection1/|207.237.114.232:8985/solr/collection1/:{
numFound:8,
maxScore:1.0,
time:898}},
{code}
My first choice would be:
{code}
shards.info:{
shard2: {
servers:
207.237.114.232:8984/solr/collection1/|207.237.114.232:8986/solr/collection1/,
numFound:2,
maxScore:1.0,
time:224},
shard1: {
servers:
207.237.114.232:8983/solr/collection1/|207.237.114.232:8985/solr/collection1/,
numFound:8,
maxScore:1.0,
time:898}},
{code}
And my second choice would be:
{code}
shards.info:{
207.237.114.232:8984/solr/collection1/|207.237.114.232:8986/solr/collection1/:{
shardName: shard2,
numFound:2,
maxScore:1.0,
time:224},
207.237.114.232:8983/solr/collection1/|207.237.114.232:8985/solr/collection1/:{
shardName: shard1,
numFound:8,
maxScore:1.0,
time:898}},
{code}
(We don't have shard name, but I presume that at some point we will. For
now, it would just be the shard ID.)
I suppose the second choice might be better for non-cloud traditional
distributed Solr - where there is no shard ID/name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4992) Solr queries don't propagate Java OutOfMemoryError back to the JVM
Daniel Collins created SOLR-4992:
Summary: Solr queries don't propagate Java OutOfMemoryError back
to the JVM
Key: SOLR-4992
URL: https://issues.apache.org/jira/browse/SOLR-4992
Project: Solr
Issue Type: Bug
Components: search, SolrCloud, update
Affects Versions: 4.3.1
Reporter: Daniel Collins
Solr (specifically SolrDispatchFilter.doFilter() but there might be other
places) handle generic java.lang.Throwable errors but that hides
OutOfMemoryError scenarios.
IndexWriter does this too but that has a specific exclusion for OOM scenarios
and handles them explicitly (stops committing and just logs to the transaction
log).
{noformat}
Example Stack trace:
2013-06-26 19:31:33,801 [qtp632640515-62] ERROR
solr.servlet.SolrDispatchFilter Q:22 -
null:java.lang.RuntimeException: java.lang.OutOfMemoryError: Java heap
space
at
org.apache.solr.servlet.SolrDispatchFilter.sendError(SolrDispatchFilter.java:670)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:380)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:155)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1423)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:450)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:138)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:564)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:213)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1083)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:379)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:175)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1017)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:136)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:258)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:445)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:260)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:225)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:596)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:527)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.OutOfMemoryError: Java heap space
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2587) SolrCloud should allow for partial results should a shard be unavailable
[ https://issues.apache.org/jira/browse/SOLR-2587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13696925#comment-13696925 ] Daniel Collins commented on SOLR-2587: -- Actually we have this, with the shards.tolerant=true and shards.info=true parameters, right? It would take some parsing of the response (in essence, if you get a shards.info with an error section in it, you have a partial response set). I agree it could be made more user-friendly, but the functionality is there if callers want to use it. SolrCloud should allow for partial results should a shard be unavailable Key: SOLR-2587 URL: https://issues.apache.org/jira/browse/SOLR-2587 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Jamie Johnson Fix For: 4.4 When executing a query against a SolrCloud there are instances where it would be beneficial to allow the results to still be returned should some shards be unreachable. Additionally, the response should somehow indicate to the caller that this is a partial result set. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4650) copyField doesn't work with patterns that don't match dynamic fields
Daniel Collins created SOLR-4650: Summary: copyField doesn't work with patterns that don't match dynamic fields Key: SOLR-4650 URL: https://issues.apache.org/jira/browse/SOLR-4650 Project: Solr Issue Type: Bug Components: Schema and Analysis Affects Versions: 4.2 Reporter: Daniel Collins We have a schema that is currently on Solr 4.0 and supports language-specific stemming for content by use of dynamic fields and copyFields. Sample of schema: field name=headline type=text_general indexed=true stored=true required=false omitNorms=true/ field name=body type=text_general indexed=true stored=false required=false omitNorms=true/ dynamicField name=*_en type=text_en indexed=true stored=false multiValued=true omitNorms=true/ dynamicField name=*_ja type=text_ja indexed=true stored=false multiValued=true omitNorms=true/ dynamicField name=*_fr type=text_fr indexed=true stored=false multiValued=true omitNorms=true/ dynamicField name=*_de type=text_de indexed=true stored=false multiValued=true omitNorms=true/ dynamicField name=*_es type=text_es indexed=true stored=false multiValued=true omitNorms=true/ dynamicField name=*_pt type=text_pt indexed=true stored=false multiValued=true omitNorms=true/ ... copyField source=headline_* dest=headline/ copyField source=body_* dest=body/ The aim is to store language-specific (stemmed) text in the headline_en, body_en, ... fields and then generic versions (no stemming) in headline body. This works fine in 4.0 and 4.1, but now fails to start in 4.2, SEVERE: Unable to create core: collection1 org.apache.solr.common.SolrException: copyField source :'headline_*' is not an explicit field and doesn't match a dynamicField. at org.apache.solr.schema.IndexSchema.registerCopyField(IndexSchema.java:688) Shouldn't this still work? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4650) copyField doesn't work with patterns that don't match dynamic fields
[
https://issues.apache.org/jira/browse/SOLR-4650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Collins updated SOLR-4650:
-
Description:
We have a schema that is currently on Solr 4.0 and supports language-specific
stemming for content by use of dynamic fields and copyFields.
Sample of schema:
{code:xml}
field name=headline type=text_general indexed=true stored=true
required=false omitNorms=true/
field name=body type=text_general indexed=true stored=false
required=false omitNorms=true/
dynamicField name=*_en type=text_en indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_ja type=text_ja indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_fr type=text_fr indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_de type=text_de indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_es type=text_es indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_pt type=text_pt indexed=true stored=false
multiValued=true omitNorms=true/
...
copyField source=headline_* dest=headline/
copyField source=body_* dest=body/
{code}
The aim is to store language-specific (stemmed) text in the headline_en,
body_en, ... fields and then generic versions (no stemming) in headline body.
This works fine in 4.0 and 4.1, but now fails to start in 4.2,
{noformat}
SEVERE: Unable to create core: collection1
org.apache.solr.common.SolrException: copyField source :'headline_*' is not an
explicit field and doesn't match a dynamicField.
at
org.apache.solr.schema.IndexSchema.registerCopyField(IndexSchema.java:688)
{noformat}
Shouldn't this still work?
was:
We have a schema that is currently on Solr 4.0 and supports language-specific
stemming for content by use of dynamic fields and copyFields.
Sample of schema:
field name=headline type=text_general indexed=true stored=true
required=false omitNorms=true/
field name=body type=text_general indexed=true stored=false
required=false omitNorms=true/
dynamicField name=*_en type=text_en indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_ja type=text_ja indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_fr type=text_fr indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_de type=text_de indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_es type=text_es indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_pt type=text_pt indexed=true stored=false
multiValued=true omitNorms=true/
...
copyField source=headline_* dest=headline/
copyField source=body_* dest=body/
The aim is to store language-specific (stemmed) text in the headline_en,
body_en, ... fields and then generic versions (no stemming) in headline body.
This works fine in 4.0 and 4.1, but now fails to start in 4.2,
SEVERE: Unable to create core: collection1
org.apache.solr.common.SolrException: copyField source :'headline_*' is not an
explicit field and doesn't match a dynamicField.
at
org.apache.solr.schema.IndexSchema.registerCopyField(IndexSchema.java:688)
Shouldn't this still work?
copyField doesn't work with patterns that don't match dynamic fields
Key: SOLR-4650
URL: https://issues.apache.org/jira/browse/SOLR-4650
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Affects Versions: 4.2
Reporter: Daniel Collins
We have a schema that is currently on Solr 4.0 and supports language-specific
stemming for content by use of dynamic fields and copyFields.
Sample of schema:
{code:xml}
field name=headline type=text_general indexed=true stored=true
required=false omitNorms=true/
field name=body type=text_general indexed=true stored=false
required=false omitNorms=true/
dynamicField name=*_en type=text_en indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_ja type=text_ja indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_fr type=text_fr indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_de type=text_de indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_es type=text_es indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_pt type=text_pt indexed=true stored=false
multiValued=true omitNorms=true/
...
copyField source=headline_* dest=headline/
copyField source=body_* dest=body/
{code}
The aim is to store language-specific (stemmed) text in the headline_en,
body_en, ... fields and then generic versions (no stemming) in
[jira] [Commented] (SOLR-4650) copyField doesn't work with patterns that don't match dynamic fields
[
https://issues.apache.org/jira/browse/SOLR-4650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13616295#comment-13616295
]
Daniel Collins commented on SOLR-4650:
--
Seems to be related to the comment
[branch_4x commit] Steven Rowe
http://svn.apache.org/viewvc?view=revisionrevision=1453162
Might be do to with the fix for SOLR-3798?
copyField doesn't work with patterns that don't match dynamic fields
Key: SOLR-4650
URL: https://issues.apache.org/jira/browse/SOLR-4650
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Affects Versions: 4.2
Reporter: Daniel Collins
Assignee: Steve Rowe
Fix For: 4.2.1
We have a schema that is currently on Solr 4.0 and supports language-specific
stemming for content by use of dynamic fields and copyFields.
Sample of schema:
{code:xml}
field name=headline type=text_general indexed=true stored=true
required=false omitNorms=true/
field name=body type=text_general indexed=true stored=false
required=false omitNorms=true/
dynamicField name=*_en type=text_en indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_ja type=text_ja indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_fr type=text_fr indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_de type=text_de indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_es type=text_es indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_pt type=text_pt indexed=true stored=false
multiValued=true omitNorms=true/
...
copyField source=headline_* dest=headline/
copyField source=body_* dest=body/
{code}
The aim is to store language-specific (stemmed) text in the headline_en,
body_en, ... fields and then generic versions (no stemming) in headline
body. This works fine in 4.0 and 4.1, but now fails to start in 4.2,
{noformat}
SEVERE: Unable to create core: collection1
org.apache.solr.common.SolrException: copyField source :'headline_*' is not
an explicit field and doesn't match a dynamicField.
at
org.apache.solr.schema.IndexSchema.registerCopyField(IndexSchema.java:688)
{noformat}
Shouldn't this still work?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4650) copyField doesn't work with patterns that don't match dynamic fields
[
https://issues.apache.org/jira/browse/SOLR-4650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13616306#comment-13616306
]
Daniel Collins commented on SOLR-4650:
--
Yes, I hadn't seen SOLR-4567, but not sure if your fix for that will be good
enough here.
It depends how the pattern matching is done, but as it stands headline_* won't
match any static field but it *could* generate a match with the dynamic field
*_en (and in our case it does)? But is is non-trivial to work that out, since
the wildcards don't make for easy comparison (one at the start, one at the end).
I think this is more than the subset pattern as defined in SOLR-4567, but I
can't see any other way to do what we want (and it used to work!)
copyField doesn't work with patterns that don't match dynamic fields
Key: SOLR-4650
URL: https://issues.apache.org/jira/browse/SOLR-4650
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Affects Versions: 4.2
Reporter: Daniel Collins
Assignee: Steve Rowe
Fix For: 4.2.1
We have a schema that is currently on Solr 4.0 and supports language-specific
stemming for content by use of dynamic fields and copyFields.
Sample of schema:
{code:xml}
field name=headline type=text_general indexed=true stored=true
required=false omitNorms=true/
field name=body type=text_general indexed=true stored=false
required=false omitNorms=true/
dynamicField name=*_en type=text_en indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_ja type=text_ja indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_fr type=text_fr indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_de type=text_de indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_es type=text_es indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_pt type=text_pt indexed=true stored=false
multiValued=true omitNorms=true/
...
copyField source=headline_* dest=headline/
copyField source=body_* dest=body/
{code}
The aim is to store language-specific (stemmed) text in the headline_en,
body_en, ... fields and then generic versions (no stemming) in headline
body. This works fine in 4.0 and 4.1, but now fails to start in 4.2,
{noformat}
SEVERE: Unable to create core: collection1
org.apache.solr.common.SolrException: copyField source :'headline_*' is not
an explicit field and doesn't match a dynamicField.
at
org.apache.solr.schema.IndexSchema.registerCopyField(IndexSchema.java:688)
{noformat}
Shouldn't this still work?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4650) copyField doesn't work with patterns that don't match dynamic fields
[
https://issues.apache.org/jira/browse/SOLR-4650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13616372#comment-13616372
]
Daniel Collins commented on SOLR-4650:
--
Cool, workaround is fine for now, at least we can see what's new in 4.2 now.
copyField doesn't work with patterns that don't match dynamic fields
Key: SOLR-4650
URL: https://issues.apache.org/jira/browse/SOLR-4650
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Affects Versions: 4.2
Reporter: Daniel Collins
Assignee: Steve Rowe
We have a schema that is currently on Solr 4.0 and supports language-specific
stemming for content by use of dynamic fields and copyFields.
Sample of schema:
{code:xml}
field name=headline type=text_general indexed=true stored=true
required=false omitNorms=true/
field name=body type=text_general indexed=true stored=false
required=false omitNorms=true/
dynamicField name=*_en type=text_en indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_ja type=text_ja indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_fr type=text_fr indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_de type=text_de indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_es type=text_es indexed=true stored=false
multiValued=true omitNorms=true/
dynamicField name=*_pt type=text_pt indexed=true stored=false
multiValued=true omitNorms=true/
...
copyField source=headline_* dest=headline/
copyField source=body_* dest=body/
{code}
The aim is to store language-specific (stemmed) text in the headline_en,
body_en, ... fields and then generic versions (no stemming) in headline
body. This works fine in 4.0 and 4.1, but now fails to start in 4.2,
{noformat}
SEVERE: Unable to create core: collection1
org.apache.solr.common.SolrException: copyField source :'headline_*' is not
an explicit field and doesn't match a dynamicField.
at
org.apache.solr.schema.IndexSchema.registerCopyField(IndexSchema.java:688)
{noformat}
Shouldn't this still work?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4223) jetty8 with solr4.0: In jetty.xml maxFormContentSize configuration needs Fixing
[
https://issues.apache.org/jira/browse/SOLR-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13537765#comment-13537765
]
Daniel Collins commented on SOLR-4223:
--
As nathan says we are seeing errors in Solr, such as:
{code}
05:53:44 newssolr:ERROR o.a.solr.servlet.SolrDispatchFilter -
null:java.lang.IllegalStateException: Form too large34859420
05:53:44 newssolr:~at
org.eclipse.jetty.server.Request.extractParameters(Request.java:285)
05:53:44 newssolr:~at
org.eclipse.jetty.server.Request.getParameterMap(Request.java:711)
05:53:44 newssolr:~at
org.apache.solr.request.ServletSolrParams.init(ServletSolrParams.java:29)
05:53:44 newssolr:~at
org.apache.solr.servlet.StandardRequestParser.parseParamsAndFillStreams(SolrRequestParsers.java:394)
05:53:44 newssolr:~at
org.apache.solr.servlet.SolrRequestParsers.parse(SolrRequestParsers.java:115)
05:53:44 newssolr:~at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:260)
05:53:44 newssolr:~at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1307)
05:53:44 newssolr:~at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:453)
05:53:44 newssolr:~at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
05:53:44 newssolr:~at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:559)
05:53:44 newssolr:~at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
05:53:44 newssolr:~at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1072)
05:53:44 newssolr:~at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:382)
05:53:44 newssolr:~at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
05:53:44 newssolr:~at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1006)
05:53:44 newssolr:~at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
05:53:44 newssolr:~at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
05:53:44 newssolr:~at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
05:53:44 newssolr:~at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
05:53:44 newssolr:~at org.eclipse.jetty.server.Server.handle(Server.java:365)
05:53:44 newssolr:~at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:485)
05:53:44 newssolr:~at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
05:53:44 newssolr:~at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:926)
05:53:44 newssolr:~at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:988)
05:53:44 newssolr:~at
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:642)
05:53:44 newssolr:~at
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
05:53:44 newssolr:~at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
05:53:44 newssolr:~at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
05:53:44 newssolr:~at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
05:53:44 newssolr:~at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
05:53:44 newssolr:~at java.lang.Thread.run(Thread.java:619)
{code}
We have very long queries (we are testing the XML parser) so we POST data
instead of GET.
jetty8 with solr4.0: In jetty.xml maxFormContentSize configuration needs
Fixing
---
Key: SOLR-4223
URL: https://issues.apache.org/jira/browse/SOLR-4223
Project: Solr
Issue Type: Bug
Components: search, Tests
Affects Versions: 4.0
Reporter: Nathan Visagan
Assignee: Shalin Shekhar Mangar
Priority: Minor
Labels: configuration
Fix For: 4.1
In jetty.xml, the cofiguration to set the maximum form content size does not
work, because jetty contextHandler reads System property
org.eclipse.jetty.server.Request.maxFormContentSize.
In CotextHandler.java line 137, the method call
Integer.getInteger(org.eclipse.jetty.server.Request.maxFormContentSize,20).intValue();
returns always the default value 20 regardless what is set below.
So instead of:
Call name=setAttribute
Argorg.eclipse.jetty.server.Request.maxFormContentSize/Arg
Arg40/Arg
/Call
Replace with:
Call class=java.lang.System name=setProperty
Argorg.eclipse.jetty.server.Request.maxFormContentSize/Arg
[jira] [Commented] (SOLR-839) XML Query Parser support
[
https://issues.apache.org/jira/browse/SOLR-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13537767#comment-13537767
]
Daniel Collins commented on SOLR-839:
-
We have a version of this we have built with Solr 4.0, it is still WIP, but
this is what we have.
{code}
import org.apache.solr.common.params.CommonParams;
import org.apache.solr.common.params.SolrParams;
import org.apache.solr.common.util.NamedList;
import org.apache.solr.request.SolrQueryRequest;
import org.apache.solr.search.*;
import org.apache.lucene.search.Query;
import org.apache.lucene.queryparser.classic.ParseException;
import org.apache.lucene.queryparser.xml.*;
import java.io.ByteArrayInputStream;
import java.io.UnsupportedEncodingException;
public class XmlQParserPlugin extends QParserPlugin {
private String contentEncoding = UTF8;
public void init(NamedList args) {
}
public QParser createParser(String qstr, SolrParams localParams,
SolrParams params, SolrQueryRequest req) {
return new XmlQParser(qstr, localParams, params, req);
}
class XmlQParser extends QParser {
public XmlQParser(String qstr, SolrParams localParams,
SolrParams params, SolrQueryRequest req) {
super(qstr, localParams, params, req);
}
public Query parse() throws ParseException {
SolrQueryParser lparser;
String qstr = getString();
if (qstr == null || qstr.length() == 0)
return null;
String defaultField = getParam(CommonParams.DF);
if (defaultField == null) {
defaultField = getReq().getSchema().getDefaultSearchFieldName();
}
lparser = new SolrQueryParser(this, defaultField);
lparser.setDefaultOperator(QueryParsing
.getQueryParserDefaultOperator(getReq().getSchema(),
getParam(QueryParsing.OP)));
CoreParser parser = new
CoreParser(getReq().getSchema().getQueryAnalyzer(), lparser);
// CorePlusExtensions parser requires lucene sandbox, which isn't
bundled with Solr (yet).
//CorePlusExtensionsParser parser = new CorePlusExtensionsParser(
//getReq().getSchema().getQueryAnalyzer(), lparser);
try {
return parser.parse(new ByteArrayInputStream(getString()
.getBytes(contentEncoding)));
} catch (UnsupportedEncodingException e) {
throw new ParseException(e.getMessage());
} catch (ParserException e) {
throw new ParseException(e.getMessage());
}
}
}
}
{code}
As the comment mentions, we can't use the CorePlusExtensionsParser as it
requires the lucene-sandbox.jar which is currently bundled with Solr 4.0?
XML Query Parser support
Key: SOLR-839
URL: https://issues.apache.org/jira/browse/SOLR-839
Project: Solr
Issue Type: New Feature
Components: query parsers
Affects Versions: 1.3
Reporter: Erik Hatcher
Assignee: Erik Hatcher
Fix For: 4.1, 5.0
Attachments: lucene-xml-query-parser-2.4-dev.jar, SOLR-839.patch
Lucene contrib includes a query parser that is able to create the
full-spectrum of Lucene queries, using an XML data structure.
This patch adds xml query parser support to Solr.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-839) XML Query Parser support
[ https://issues.apache.org/jira/browse/SOLR-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13537769#comment-13537769 ] Daniel Collins commented on SOLR-839: - Other issues we are considering: should things like BoostingQuery really be in the extensions, why are they not part of core? Additionally, we've noticed that CoreParser is missing some queries: 1) PhraseQuery 2) PayloadTermQuery (it has it under the old name of BoostingTermQuery, should there be an alias?) 3) FunctionQuery (not sure if this is even possible, presumably would require a lot of configuration about the function to call) Might look at some of those if I get bored of relatives over Xmas :) XML Query Parser support Key: SOLR-839 URL: https://issues.apache.org/jira/browse/SOLR-839 Project: Solr Issue Type: New Feature Components: query parsers Affects Versions: 1.3 Reporter: Erik Hatcher Assignee: Erik Hatcher Fix For: 4.1, 5.0 Attachments: lucene-xml-query-parser-2.4-dev.jar, SOLR-839.patch Lucene contrib includes a query parser that is able to create the full-spectrum of Lucene queries, using an XML data structure. This patch adds xml query parser support to Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-839) XML Query Parser support
[
https://issues.apache.org/jira/browse/SOLR-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13537767#comment-13537767
]
Daniel Collins edited comment on SOLR-839 at 12/21/12 9:21 AM:
---
We have a version of this we have built with Solr 4.0, it is still WIP, but
this is what we have.
{code}
import org.apache.solr.common.params.CommonParams;
import org.apache.solr.common.params.SolrParams;
import org.apache.solr.common.util.NamedList;
import org.apache.solr.request.SolrQueryRequest;
import org.apache.solr.search.*;
import org.apache.lucene.search.Query;
import org.apache.lucene.queryparser.classic.ParseException;
import org.apache.lucene.queryparser.xml.*;
import java.io.ByteArrayInputStream;
import java.io.UnsupportedEncodingException;
public class XmlQParserPlugin extends QParserPlugin {
private String contentEncoding = UTF8;
public void init(NamedList args) {
}
public QParser createParser(String qstr, SolrParams localParams,
SolrParams params, SolrQueryRequest req) {
return new XmlQParser(qstr, localParams, params, req);
}
class XmlQParser extends QParser {
public XmlQParser(String qstr, SolrParams localParams,
SolrParams params, SolrQueryRequest req) {
super(qstr, localParams, params, req);
}
public Query parse() throws ParseException {
SolrQueryParser lparser;
String qstr = getString();
if (qstr == null || qstr.length() == 0)
return null;
String defaultField = getParam(CommonParams.DF);
if (defaultField == null) {
defaultField = getReq().getSchema().getDefaultSearchFieldName();
}
lparser = new SolrQueryParser(this, defaultField);
lparser.setDefaultOperator(QueryParsing
.getQueryParserDefaultOperator(getReq().getSchema(),
getParam(QueryParsing.OP)));
CoreParser parser = new
CoreParser(getReq().getSchema().getQueryAnalyzer(), lparser);
// CorePlusExtensions parser requires lucene sandbox, which isn't
bundled with Solr (yet).
//CorePlusExtensionsParser parser = new CorePlusExtensionsParser(
//getReq().getSchema().getQueryAnalyzer(), lparser);
try {
return parser.parse(new ByteArrayInputStream(getString()
.getBytes(contentEncoding)));
} catch (UnsupportedEncodingException e) {
throw new ParseException(e.getMessage());
} catch (ParserException e) {
throw new ParseException(e.getMessage());
}
}
}
}
{code}
As the comment mentions, we can't use the CorePlusExtensionsParser as it
requires the lucene-sandbox.jar which isn't currently bundled with Solr 4.0?
was (Author: dancollins):
We have a version of this we have built with Solr 4.0, it is still WIP, but
this is what we have.
{code}
import org.apache.solr.common.params.CommonParams;
import org.apache.solr.common.params.SolrParams;
import org.apache.solr.common.util.NamedList;
import org.apache.solr.request.SolrQueryRequest;
import org.apache.solr.search.*;
import org.apache.lucene.search.Query;
import org.apache.lucene.queryparser.classic.ParseException;
import org.apache.lucene.queryparser.xml.*;
import java.io.ByteArrayInputStream;
import java.io.UnsupportedEncodingException;
public class XmlQParserPlugin extends QParserPlugin {
private String contentEncoding = UTF8;
public void init(NamedList args) {
}
public QParser createParser(String qstr, SolrParams localParams,
SolrParams params, SolrQueryRequest req) {
return new XmlQParser(qstr, localParams, params, req);
}
class XmlQParser extends QParser {
public XmlQParser(String qstr, SolrParams localParams,
SolrParams params, SolrQueryRequest req) {
super(qstr, localParams, params, req);
}
public Query parse() throws ParseException {
SolrQueryParser lparser;
String qstr = getString();
if (qstr == null || qstr.length() == 0)
return null;
String defaultField = getParam(CommonParams.DF);
if (defaultField == null) {
defaultField = getReq().getSchema().getDefaultSearchFieldName();
}
lparser = new SolrQueryParser(this, defaultField);
lparser.setDefaultOperator(QueryParsing
.getQueryParserDefaultOperator(getReq().getSchema(),
getParam(QueryParsing.OP)));
CoreParser parser = new
CoreParser(getReq().getSchema().getQueryAnalyzer(), lparser);
// CorePlusExtensions parser requires lucene sandbox, which isn't
