[GitHub] [lucene-solr] iverase merged pull request #652: LUCENE-8775: Tessellator: Improve the election of diagonals when splitting the polygon
iverase merged pull request #652: LUCENE-8775: Tessellator: Improve the election of diagonals when splitting the polygon URL: https://github.com/apache/lucene-solr/pull/652 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8775) Tessellator: Improve the election of diagonals when splitting the polygon
[ https://issues.apache.org/jira/browse/LUCENE-8775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857355#comment-16857355 ] ASF subversion and git services commented on LUCENE-8775: - Commit 05ea0f2d54afd91b10b845c7b01e6738f0de4a78 in lucene-solr's branch refs/heads/master from Ignacio Vera [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=05ea0f2 ] LUCENE-8775: Improve tessellator to handle better cases where a hole share a vertex with the polygon > Tessellator: Improve the election of diagonals when splitting the polygon > - > > Key: LUCENE-8775 > URL: https://issues.apache.org/jira/browse/LUCENE-8775 > Project: Lucene - Core > Issue Type: Bug >Reporter: Ignacio Vera >Priority: Major > Time Spent: 2h > Remaining Estimate: 0h > > There are some cases when polygon tessellation fails and it seems it is due > to a bad election of the diagonal when splitting the polygon. Here I propose > a patch that make sure when splitting a polygon that the resulting polygons > are valid CW polygons. > In addition this patch adds few test to check the functionality of the > tessellator and throws an error if the polygon cannot be splitted instead of > just empty the current tessellation. -- 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
Re: [ANNOUNCE] Apache Solr 7.7.2 released
On 05/06/2019 16:26, Jan Høydahl wrote: > 4 June 2019, Apache Solr™ 7.7.2 available Thanks for making this happen, Jan, much appreciated! - Bram
Re: Welcome Namgyu Kim as Lucene/Solr committer
Welcome Namgyu On Thu, Jun 6, 2019 at 12:32 PM Christian Moen wrote: > > Congrats, Namgyu! > > On Thu, Jun 6, 2019 at 4:36 AM Christine Poerschke (BLOOMBERG/ LONDON) > wrote: >> >> Welcome! >> >> Christine >> >> From: dev@lucene.apache.org At: 06/03/19 18:52:38 >> To: dev@lucene.apache.org >> Subject: Welcome Namgyu Kim as Lucene/Solr committer >> >> Hi all, >> >> Please join me in welcoming Namgyu Kim as Lucene/ Solr committer! >> >> Kim has been helping address technical debt and fixing bugs in the >> last year, including a cleanup to our DutchAnalyzer[0] and >> improvements to the StoredFieldsVisitor API[1]. More recently he also >> started improving our korean analyzer[2]. >> >> [0] https://issues.apache.org/jira/browse/LUCENE-8582 >> [1] https://issues.apache.org/jira/browse/LUCENE-8805 >> [2] https://issues.apache.org/jira/browse/LUCENE-8784 >> >> Congratulations and welcome! It is a tradition to introduce yourself >> with a brief bio. >> >> -- >> Adrien >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-master-Linux (64bit/jdk-12) - Build # 215 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/215/
Java: 64bit/jdk-12 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
2 tests failed.
FAILED:
org.apache.solr.cloud.TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader
Error Message:
Doc with id=4 not found in
http://127.0.0.1:45839/solr/outOfSyncReplicasCannotBecomeLeader-false due to:
Path not found: /id; rsp={doc=null}
Stack Trace:
java.lang.AssertionError: Doc with id=4 not found in
http://127.0.0.1:45839/solr/outOfSyncReplicasCannotBecomeLeader-false due to:
Path not found: /id; rsp={doc=null}
at
__randomizedtesting.SeedInfo.seed([85D7D89CBB745A00:FB3CF88C7813553A]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.solr.cloud.TestCloudConsistency.assertDocExists(TestCloudConsistency.java:283)
at
org.apache.solr.cloud.TestCloudConsistency.assertDocsExistInAllReplicas(TestCloudConsistency.java:267)
at
org.apache.solr.cloud.TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader(TestCloudConsistency.java:138)
at
org.apache.solr.cloud.TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader(TestCloudConsistency.java:97)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRule
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857313#comment-16857313 ] ASF subversion and git services commented on SOLR-13452: Commit b74abe272d58378626596de077c1de5e1f39c662 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_3 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b74abe2 ] SOLR-13452: Some cleanup, add a new task to help find unused deps, clean up some deps. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- 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-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857312#comment-16857312 ] ASF subversion and git services commented on SOLR-13452: Commit 616e5d849ee1fbd469d8ac28be751c1251349511 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_3 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=616e5d8 ] SOLR-13452: Change JarChecksum to not copy all deps to a tmp folder. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- 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-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857310#comment-16857310 ] ASF subversion and git services commented on SOLR-13452: Commit 8dd00af9f8554ffddd78a6f825ca9de4875b5e7c in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_3 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8dd00af ] SOLR-13452: Fix solrj to solr-solrj. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- 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-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857311#comment-16857311 ] ASF subversion and git services commented on SOLR-13452: Commit be8cf53b280516f7654c3b37b600e57a9c23e78e in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_3 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=be8cf53 ] SOLR-13452: Push down publish-maven plugin to submodules. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- 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-8620) Add CONTAINS support for LatLonShape
[
https://issues.apache.org/jira/browse/LUCENE-8620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignacio Vera updated LUCENE-8620:
-
Fix Version/s: (was: 8.1)
(was: master (9.0))
> Add CONTAINS support for LatLonShape
>
>
> Key: LUCENE-8620
> URL: https://issues.apache.org/jira/browse/LUCENE-8620
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/sandbox
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8620.patch, LUCENE-8620.patch
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> Currently the only spatial operation that cannot be performed using
> {{LatLonShape}} is CONTAINS. This issue will add such capability by tracking
> if an edge of a generated triangle from the {{Tessellator}} is an edge of the
> polygon.
--
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
Re: RM question JIRA fixVersion transition
+1 to "Find and remove these" which seems perfect. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Jun 5, 2019 at 5:43 PM Jan Høydahl wrote: > Hi > > I am just completing the last steps in the ReleaseTODO as first-time RM > for the 7.7.2 bugfix release. > > In the "Update JIRA" section it says: > > • Do another JIRA search to find all issues with Unresolved Resolution and > fixVersion of the release you just made. Note that Jira can only > bulk-change fixVersion if you search only one project at a time. This URL > may work - but edit the fixVersion part, and change LUCENE to SOLR to get > to Solr's issues separately - > https://issues.apache.org/jira/issues/?jql=project+=+LUCENE+AND+resolution=Unresolved+AND+fixVersion=6.0.1, > and do a bulk change to the fixVersion to be both the master version and > the next version on the branch you just released from. Uncheck the box that > says "send an email for these changes". > > > It is the part "*bulk change to the fixVersion to be both the master > version and the next version on the branch you just released from*" that > I wonder. JIRA now has a dropdown where you can either > - Add to existing > - Clear field > - Replace all with > - Find and remove these > > I guess this option is new to a recent JIRA release and that you earlier > could only replace all fixVersions. But if you do that, you risk removing > some fix versions that are NOT next or master, so this operation is > destructive. > Also the TODO is not clear what to do here for bugfix releases. For the > 7.7.2 release it would be wrong to *REPLACE* the field with 7.7.3, > master(9.0), what if some issues also had 8.1.2 and 8.2 in them? > My proposal is to instead select "Find and remove these" and the released > version, and thus remove just that one version from the Unresolved JIRA > issue. > > Opinions? > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > >
[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 377 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/377/
All tests passed
Build Log:
[...truncated 64201 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj2079880859
[ecj-lint] Compiling 69 source files to /tmp/ecj2079880859
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
[ecj-lint] --
[ecj-lint] 1. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 28)
[ecj-lint] import javax.naming.InitialContext;
[ecj-lint]^^^
[ecj-lint] The type javax.naming.InitialContext is not accessible
[ecj-lint] --
[ecj-lint] 2. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 29)
[ecj-lint] import javax.naming.NamingException;
[ecj-lint]
[ecj-lint] The type javax.naming.NamingException is not accessible
[ecj-lint] --
[ecj-lint] 3. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 182)
[ecj-lint] c = getFromJndi(initProps, jndiName);
[ecj-lint] ^^^
[ecj-lint] The method getFromJndi(Properties, String) from the type new
Callable(){} refers to the missing type NamingException
[ecj-lint] --
[ecj-lint] 4. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 245)
[ecj-lint] private Connection getFromJndi(final Properties initProps,
final String jndiName) throws NamingException,
[ecj-lint]
^^^
[ecj-lint] NamingException cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 5. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 249)
[ecj-lint] InitialContext ctx = new InitialContext();
[ecj-lint] ^^
[ecj-lint] InitialContext cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 6. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 249)
[ecj-lint] InitialContext ctx = new InitialContext();
[ecj-lint] ^^
[ecj-lint] InitialContext cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 6 problems (6 errors)
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/build.xml:643:
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/build.xml:101:
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/build.xml:651:
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/common-build.xml:479:
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/common-build.xml:2009:
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/common-build.xml:2048:
Compile failed; see the compiler error output for details.
Total time: 244 minutes 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13515) deprecate-then-remove SolrPluginUtils.IdentityRegenerator
[
https://issues.apache.org/jira/browse/SOLR-13515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857258#comment-16857258
]
David Smiley commented on SOLR-13515:
-
No need to have a deprecation phase I think; this is internal with a clear
replacement that already existed.
Thanks for doing the cleanup Christine.
> deprecate-then-remove SolrPluginUtils.IdentityRegenerator
> -
>
> Key: SOLR-13515
> URL: https://issues.apache.org/jira/browse/SOLR-13515
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> {{SolrPluginUtils.IdentityRegenerator}} seems to be identical (no pun
> intended) to {{NoOpRegenerator}}. This ticket proposes to deprecate
> IdentityRegenerator on branch_8x and then remove it on master branch.
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/util/SolrPluginUtils.java#L977-L997
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/NoOpRegenerator.java
--
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&focusedCommentId=16857240#comment-16857240 ] David Smiley commented on SOLR-13434: - [~caomanhdat] why did you "fix" Java 8 builds on the master branch? Don't we want to take advantage of what Java 11 has to offer on the master branch? Master is Java 11 only. > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >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
[JENKINS] Lucene-Solr-repro - Build # 3332 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/3332/ [...truncated 29 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/112/consoleText [repro] Revision: b8f430a853739518faad6aa25194314b3d39b314 [repro] Ant options: -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt [repro] Repro line: ant test -Dtestcase=TestIndexWriterReader -Dtests.method=testDuringAddDelete -Dtests.seed=DD23603F6B6E011C -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.locale=ga -Dtests.timezone=NST -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=TestIndexWriterReader -Dtests.method=testReopenNRTReaderOnCommit -Dtests.seed=DD23603F6B6E011C -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.locale=ga -Dtests.timezone=NST -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: f3148fa9e08ecedfa97eb7f04b19e2fb5fa870ff [repro] git fetch [repro] git checkout b8f430a853739518faad6aa25194314b3d39b314 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]lucene/core [repro] TestIndexWriterReader [repro] ant compile-test [...truncated 210 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestIndexWriterReader" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.seed=DD23603F6B6E011C -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.locale=ga -Dtests.timezone=NST -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 1269 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 3/5 failed: org.apache.lucene.index.TestIndexWriterReader [repro] git checkout f3148fa9e08ecedfa97eb7f04b19e2fb5fa870ff [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 6 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.1-Linux (64bit/jdk1.8.0_201) - Build # 390 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Linux/390/
Java: 64bit/jdk1.8.0_201 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
9 tests failed.
FAILED: org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth
Error Message:
Expected metric minimums for prefix SECURITY./authentication.:
{failMissingCredentials=2, authenticated=19, passThrough=9,
failWrongCredentials=1, requests=31, errors=0}, but got:
{failMissingCredentials=2, authenticated=18, passThrough=10,
totalTime=13569883, failWrongCredentials=1, requestTimes=1759, requests=31,
errors=0}
Stack Trace:
java.lang.AssertionError: Expected metric minimums for prefix
SECURITY./authentication.: {failMissingCredentials=2, authenticated=19,
passThrough=9, failWrongCredentials=1, requests=31, errors=0}, but got:
{failMissingCredentials=2, authenticated=18, passThrough=10,
totalTime=13569883, failWrongCredentials=1, requestTimes=1759, requests=31,
errors=0}
at
__randomizedtesting.SeedInfo.seed([EAD86991B61F5907:56B61F83124CDA7D]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:129)
at
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:83)
at
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:306)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.uti
Re: Welcome Namgyu Kim as Lucene/Solr committer
Congrats, Namgyu! On Thu, Jun 6, 2019 at 4:36 AM Christine Poerschke (BLOOMBERG/ LONDON) < cpoersc...@bloomberg.net> wrote: > Welcome! > > Christine > > From: dev@lucene.apache.org At: 06/03/19 18:52:38 > To: dev@lucene.apache.org > Subject: Welcome Namgyu Kim as Lucene/Solr committer > > Hi all, > > Please join me in welcoming Namgyu Kim as Lucene/ Solr committer! > > Kim has been helping address technical debt and fixing bugs in the > last year, including a cleanup to our DutchAnalyzer[0] and > improvements to the StoredFieldsVisitor API[1]. More recently he also > started improving our korean analyzer[2]. > > [0] https://issues.apache.org/jira/browse/LUCENE-8582 > [1] https://issues.apache.org/jira/browse/LUCENE-8805 > [2] https://issues.apache.org/jira/browse/LUCENE-8784 > > Congratulations and welcome! It is a tradition to introduce yourself > with a brief bio. > > -- > Adrien > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > >
[jira] [Commented] (SOLR-13105) A visual guide to Solr Math Expressions and Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857223#comment-16857223
]
ASF subversion and git services commented on SOLR-13105:
Commit e3665d5356837d9ca24f7b2adce8af07007c9f6b in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e3665d5 ]
SOLR-13105: Add Table of Contents
> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png,
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and
> Math Expressions. This ticket will create a visual guide to Solr Math
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin*
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize*
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable
> functions. These functions provide a system for searching, transforming,
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>
> A few sample visualizations are attached to the ticket.
--
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-13105) A visual guide to Solr Math Expressions and Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857222#comment-16857222
]
ASF subversion and git services commented on SOLR-13105:
Commit 2b1ac4b9c13a55796d6b8a881f50b6359d476b04 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2b1ac4b ]
SOLR-13105: Add sampling distributions to the TOC
> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png,
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and
> Math Expressions. This ticket will create a visual guide to Solr Math
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin*
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize*
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable
> functions. These functions provide a system for searching, transforming,
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>
> A few sample visualizations are attached to the ticket.
--
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-13521) SchemaRequest.DynamicField and SchemaRequest.FieldTypes drop the input parameters
[
https://issues.apache.org/jira/browse/SOLR-13521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857215#comment-16857215
]
ASF subversion and git services commented on SOLR-13521:
Commit f3148fa9e08ecedfa97eb7f04b19e2fb5fa870ff in lucene-solr's branch
refs/heads/SOLR-13105-visual from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f3148fa ]
SOLR-13521: Fix input parameter handling for DynamicField and FieldTypes
(Schema API)
> SchemaRequest.DynamicField and SchemaRequest.FieldTypes drop the input
> parameters
> -
>
> Key: SOLR-13521
> URL: https://issues.apache.org/jira/browse/SOLR-13521
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Trivial
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13521.patch
>
>
> In their constructors, {{SchemaRequest.DynamicField}} and
> {{SchemaRequest.FieldTypes}} accept a {{SolrParams}} object, but they drop it
> instead of passing it to the super constructor like other {{SchemaRequest}}'s
> do.
--
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-13105) A visual guide to Solr Math Expressions and Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857216#comment-16857216
]
ASF subversion and git services commented on SOLR-13105:
Commit a1efdf2eb0f43b9ac5c474de94237436905f944e in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a1efdf2 ]
Merge branch 'master' into SOLR-13105-visual
> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png,
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and
> Math Expressions. This ticket will create a visual guide to Solr Math
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin*
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize*
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable
> functions. These functions provide a system for searching, transforming,
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>
> A few sample visualizations are attached to the ticket.
--
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-13105) A visual guide to Solr Math Expressions and Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857218#comment-16857218
]
ASF subversion and git services commented on SOLR-13105:
Commit 6c038229bc904c3bb127eb3e7030268e5cbfe0b1 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6c03822 ]
SOLR-13105: Update TOC
> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png,
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and
> Math Expressions. This ticket will create a visual guide to Solr Math
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin*
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize*
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable
> functions. These functions provide a system for searching, transforming,
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>
> A few sample visualizations are attached to the ticket.
--
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-13518) improve SolrInfoBeanTest.testCallMBeanInfo debuggability
[
https://issues.apache.org/jira/browse/SOLR-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857214#comment-16857214
]
ASF subversion and git services commented on SOLR-13518:
Commit 757e4548c7390d4900cb4fe433e17d14a7b4a2ee in lucene-solr's branch
refs/heads/SOLR-13105-visual from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=757e454 ]
SOLR-13518: extra assertNotNull info for SolrInfoBeanTest
> improve SolrInfoBeanTest.testCallMBeanInfo debuggability
>
>
> Key: SOLR-13518
> URL: https://issues.apache.org/jira/browse/SOLR-13518
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (9.0), 8.2
>
>
> Today
> https://builds.apache.org/job/PreCommit-SOLR-Build/407/testReport/org.apache.solr/SolrInfoBeanTest/testCallMBeanInfo/
> reported
> {code}
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([D2ED2D454B87B637:2D8BA07920FFCB29]:0)
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at
> org.apache.solr.SolrInfoBeanTest.testCallMBeanInfo(SolrInfoBeanTest.java:73)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> ...
> {code}
> and since the test runs logic for multiple classes it would be nice to
> include e.g. the class name info in the assert itself.
--
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-13105) A visual guide to Solr Math Expressions and Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857217#comment-16857217
]
ASF subversion and git services commented on SOLR-13105:
Commit 027a3a62861a6b8609c6849333026e1ebcaee76e in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=027a3a6 ]
SOLR-13105: Add visualization place holder
> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png,
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and
> Math Expressions. This ticket will create a visual guide to Solr Math
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin*
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize*
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable
> functions. These functions provide a system for searching, transforming,
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>
> A few sample visualizations are attached to the ticket.
--
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-8827) Speed up poll-mirrors.py
[
https://issues.apache.org/jira/browse/LUCENE-8827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857213#comment-16857213
]
ASF subversion and git services commented on LUCENE-8827:
-
Commit 6b70bdb3c0d7331bfe4dfe92b9eb1a71791ab1f4 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6b70bdb ]
LUCENE-8827: Speed up poll-mirrors.py
> Speed up poll-mirrors.py
>
>
> Key: LUCENE-8827
> URL: https://issues.apache.org/jira/browse/LUCENE-8827
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: master (9.0), 8.2, 8.1.2
>
> Attachments: LUCENE-8827.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Speed up {{dev-tools/scripts/poll-mirrors.py}} by parallelizing the URL checks
--
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-8827) Speed up poll-mirrors.py
[
https://issues.apache.org/jira/browse/LUCENE-8827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857212#comment-16857212
]
ASF subversion and git services commented on LUCENE-8827:
-
Commit f070b7c742dede34594e1cf4ee28d23d5af3a303 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f070b7c ]
LUCENE-8827: Speed up poll-mirrors.py and add -once argument. Python3 only
(#699)
Also skips Python2 support like the other scripts in the folder
> Speed up poll-mirrors.py
>
>
> Key: LUCENE-8827
> URL: https://issues.apache.org/jira/browse/LUCENE-8827
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: master (9.0), 8.2, 8.1.2
>
> Attachments: LUCENE-8827.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Speed up {{dev-tools/scripts/poll-mirrors.py}} by parallelizing the URL checks
--
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&focusedCommentId=16857211#comment-16857211 ] ASF subversion and git services commented on SOLR-13434: Commit da832d4f3aa2e87cf1947ef437398ea6d2e0 in lucene-solr's branch refs/heads/SOLR-13105-visual from Cao Manh Dat [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=da832d4 ] SOLR-13434: Fixes problem on Java 8 build > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >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] [Commented] (LUCENE-8831) LatLonShapeBoundingBoxQuery hashcode is wrong
[ https://issues.apache.org/jira/browse/LUCENE-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857210#comment-16857210 ] ASF subversion and git services commented on LUCENE-8831: - Commit c6390f80d13a82cc8de4d43ccc85616a3f439624 in lucene-solr's branch refs/heads/SOLR-13105-visual from Ignacio Vera [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c6390f8 ] LUCENE-8831: Fixed LatLonShapeBoundingBoxQuery .hashCode method > LatLonShapeBoundingBoxQuery hashcode is wrong > -- > > Key: LUCENE-8831 > URL: https://issues.apache.org/jira/browse/LUCENE-8831 > Project: Lucene - Core > Issue Type: Bug >Reporter: Ignacio Vera >Assignee: Ignacio Vera >Priority: Major > Fix For: master (9.0), 8.2 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently the hashcode implementation for LatLonShapeBoundingBoxQuery returns > always a different value. Therefore the query cannot be cached. -- 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
[JENKINS] Lucene-Solr-8.1-Windows (64bit/jdk-10.0.1) - Build # 131 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Windows/131/
Java: 64bit/jdk-10.0.1 -XX:+UseCompressedOops -XX:+UseG1GC
12 tests failed.
FAILED: org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth
Error Message:
Expected metric minimums for prefix SECURITY./authentication.:
{failMissingCredentials=2, authenticated=19, passThrough=9,
failWrongCredentials=1, requests=31, errors=0}, but got:
{failMissingCredentials=2, authenticated=16, passThrough=11, totalTime=5268600,
failWrongCredentials=1, requestTimes=1535, requests=30, errors=0}
Stack Trace:
java.lang.AssertionError: Expected metric minimums for prefix
SECURITY./authentication.: {failMissingCredentials=2, authenticated=19,
passThrough=9, failWrongCredentials=1, requests=31, errors=0}, but got:
{failMissingCredentials=2, authenticated=16, passThrough=11, totalTime=5268600,
failWrongCredentials=1, requestTimes=1535, requests=30, errors=0}
at
__randomizedtesting.SeedInfo.seed([B0811E17925BFD2B:CEF680536087E51]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:129)
at
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:83)
at
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:306)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure
[JENKINS-MAVEN] Lucene-Solr-Maven-8.x #118: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-8.x/118/ No tests ran. Build Log: [...truncated 33186 lines...] [mvn] [INFO] - [mvn] [INFO] - [mvn] [ERROR] COMPILATION ERROR : [mvn] [INFO] - [...truncated 876 lines...] BUILD FAILED /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/build.xml:680: The following error occurred while executing this line: : Java returned: 1 Total time: 29 minutes 44 seconds Build step 'Invoke Ant' marked build as failure Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-MAVEN] Lucene-Solr-Maven-master #2577: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-master/2577/ No tests ran. Build Log: [...truncated 34694 lines...] BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:680: The following error occurred while executing this line: : Java returned: 1 Total time: 20 minutes 52 seconds Build step 'Invoke Ant' marked build as failure Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13521) SchemaRequest.DynamicField and SchemaRequest.FieldTypes drop the input parameters
[
https://issues.apache.org/jira/browse/SOLR-13521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe resolved SOLR-13521.
--
Resolution: Fixed
Assignee: Tomás Fernández Löbbe
Fix Version/s: 8.2
master (9.0)
> SchemaRequest.DynamicField and SchemaRequest.FieldTypes drop the input
> parameters
> -
>
> Key: SOLR-13521
> URL: https://issues.apache.org/jira/browse/SOLR-13521
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Trivial
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13521.patch
>
>
> In their constructors, {{SchemaRequest.DynamicField}} and
> {{SchemaRequest.FieldTypes}} accept a {{SolrParams}} object, but they drop it
> instead of passing it to the super constructor like other {{SchemaRequest}}'s
> do.
--
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-13521) SchemaRequest.DynamicField and SchemaRequest.FieldTypes drop the input parameters
[
https://issues.apache.org/jira/browse/SOLR-13521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857136#comment-16857136
]
ASF subversion and git services commented on SOLR-13521:
Commit f3148fa9e08ecedfa97eb7f04b19e2fb5fa870ff in lucene-solr's branch
refs/heads/master from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f3148fa ]
SOLR-13521: Fix input parameter handling for DynamicField and FieldTypes
(Schema API)
> SchemaRequest.DynamicField and SchemaRequest.FieldTypes drop the input
> parameters
> -
>
> Key: SOLR-13521
> URL: https://issues.apache.org/jira/browse/SOLR-13521
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Reporter: Tomás Fernández Löbbe
>Priority: Trivial
> Attachments: SOLR-13521.patch
>
>
> In their constructors, {{SchemaRequest.DynamicField}} and
> {{SchemaRequest.FieldTypes}} accept a {{SolrParams}} object, but they drop it
> instead of passing it to the super constructor like other {{SchemaRequest}}'s
> do.
--
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-13521) SchemaRequest.DynamicField and SchemaRequest.FieldTypes drop the input parameters
[
https://issues.apache.org/jira/browse/SOLR-13521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857137#comment-16857137
]
ASF subversion and git services commented on SOLR-13521:
Commit 43a7ec87a2c4dbaaa521ec219d2a267ee823d9b8 in lucene-solr's branch
refs/heads/branch_8x from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=43a7ec8 ]
SOLR-13521: Fix input parameter handling for DynamicField and FieldTypes
(Schema API)
> SchemaRequest.DynamicField and SchemaRequest.FieldTypes drop the input
> parameters
> -
>
> Key: SOLR-13521
> URL: https://issues.apache.org/jira/browse/SOLR-13521
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Reporter: Tomás Fernández Löbbe
>Priority: Trivial
> Attachments: SOLR-13521.patch
>
>
> In their constructors, {{SchemaRequest.DynamicField}} and
> {{SchemaRequest.FieldTypes}} accept a {{SolrParams}} object, but they drop it
> instead of passing it to the super constructor like other {{SchemaRequest}}'s
> do.
--
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-13521) SchemaRequest.DynamicField and SchemaRequest.FieldTypes drop the input parameters
[
https://issues.apache.org/jira/browse/SOLR-13521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe updated SOLR-13521:
-
Attachment: SOLR-13521.patch
> SchemaRequest.DynamicField and SchemaRequest.FieldTypes drop the input
> parameters
> -
>
> Key: SOLR-13521
> URL: https://issues.apache.org/jira/browse/SOLR-13521
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Reporter: Tomás Fernández Löbbe
>Priority: Trivial
> Attachments: SOLR-13521.patch
>
>
> In their constructors, {{SchemaRequest.DynamicField}} and
> {{SchemaRequest.FieldTypes}} accept a {{SolrParams}} object, but they drop it
> instead of passing it to the super constructor like other {{SchemaRequest}}'s
> do.
--
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-13521) SchemaRequest.DynamicField and SchemaRequest.FieldTypes drop the input parameters
Tomás Fernández Löbbe created SOLR-13521:
Summary: SchemaRequest.DynamicField and SchemaRequest.FieldTypes
drop the input parameters
Key: SOLR-13521
URL: https://issues.apache.org/jira/browse/SOLR-13521
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrJ
Reporter: Tomás Fernández Löbbe
In their constructors, {{SchemaRequest.DynamicField}} and
{{SchemaRequest.FieldTypes}} accept a {{SolrParams}} object, but they drop it
instead of passing it to the super constructor like other {{SchemaRequest}}'s
do.
--
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
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-12) - Build # 7978 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7978/ Java: 64bit/jdk-12 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.cdcr.CdcrBootstrapTest.testConvertClusterToCdcrAndBootstrap Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([D098E1E7FE7498E4:74FCE904A2B00A3]:0) at org.junit.Assert.fail(Assert.java:86) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertTrue(Assert.java:52) at org.apache.solr.cloud.cdcr.CdcrBootstrapTest.testConvertClusterToCdcrAndBootstrap(CdcrBootstrapTest.java:126) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:835) Build Log: [...truncated 12538 lines...] [junit4] Suite: org.apache.solr.cloud.cdcr.CdcrBootstrapTest [junit4] 2> 95710 INFO (SUITE-CdcrBootstrapTest-seed#[D098E1E7FE7498E4]-worker) [ ] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null
[JENKINS] Lucene-Solr-SmokeRelease-8.x - Build # 112 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/112/ No tests ran. Build Log: [...truncated 24756 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2573 links (2104 relative) to 3380 anchors in 254 files [echo] Validated Links & Anchors via: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked [untar] Expanding: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/solr-8.2.0.tgz into /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:c
[jira] [Commented] (SOLR-13509) NullPointerException in JSON Facet if omitHeaders=true
[
https://issues.apache.org/jira/browse/SOLR-13509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857115#comment-16857115
]
Lucene/Solr QA commented on SOLR-13509:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
2s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 58s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 50m 47s{color}
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 57m 41s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.handler.component.DistributedDebugComponentTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13509 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12970723/SOLR-13509.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.4.0-137-generic #163~14.04.1-Ubuntu SMP Mon
Sep 24 17:14:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 757e454 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | LTS |
| unit |
https://builds.apache.org/job/PreCommit-SOLR-Build/408/artifact/out/patch-unit-solr_core.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/408/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/408/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> NullPointerException in JSON Facet if omitHeaders=true
> --
>
> Key: SOLR-13509
> URL: https://issues.apache.org/jira/browse/SOLR-13509
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
>Affects Versions: 8.1.1
> Environment: Solr 8.1.1 downloaded tar gz, started in cloud mode:
> {code:java}
> bin/solr start -e cloud -noprompt
> bin/solr create -c techproducts -s 2 -rf 2 -d
> server/solr/configsets/sample_techproducts_configs/conf -n
> sample_techproducts_configs
> bin/post -c techproducts example/exampledocs/*.xml{code}
>Reporter: Markus Kalkbrenner
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13509.patch, SOLR-13509.patch
>
>
> The error exists in Solr 8.1.1 and didn't occur in Solr 8.0 and 7.x.
> Running this simple JSON Facet against the techproducts example (in cloud
> mode) succeeds as expected:
> {code:java}
> curl http://localhost:8983/solr/techproducts/select -d '
> q=*:*&
> omitHeader=false&
> json.facet={
> "max_price" : "max(price)"
> }{code}
> But as soon you omit Headers it results in a NullPointerException (which
> didn't happen in earlier Solr versions):
> {code:java}
> curl http://localhost:8983/solr/techproducts/select -d '
> q=*:*&
> omitHeader=true&
> json.facet={
> "max_price" : "max(price)"
> }'
> {code}
> Exception:
> {noformat}
> 2019-06-03 12:40:11.446 ERROR (qtp67730604-361) [c:techproducts s:shard2
> r:core_node7 x:techproducts_shard2_replica_n4] o.a.s.h.RequestHandlerBase
> java.lang.NullPointerException
> at
> org.apache.solr.search.facet.FacetModule.handleResponses(FacetModule.java:284)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
> at
> org.apache.solr.han
[JENKINS] Lucene-Solr-8.1-Linux (64bit/jdk1.8.0_201) - Build # 389 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Linux/389/
Java: 64bit/jdk1.8.0_201 -XX:+UseCompressedOops -XX:+UseG1GC
9 tests failed.
FAILED: org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth
Error Message:
Expected metric minimums for prefix SECURITY./authentication.:
{failMissingCredentials=2, authenticated=19, passThrough=9,
failWrongCredentials=1, requests=31, errors=0}, but got:
{failMissingCredentials=2, authenticated=16, passThrough=10,
totalTime=16050065, failWrongCredentials=1, requestTimes=992, requests=29,
errors=0}
Stack Trace:
java.lang.AssertionError: Expected metric minimums for prefix
SECURITY./authentication.: {failMissingCredentials=2, authenticated=19,
passThrough=9, failWrongCredentials=1, requests=31, errors=0}, but got:
{failMissingCredentials=2, authenticated=16, passThrough=10,
totalTime=16050065, failWrongCredentials=1, requestTimes=992, requests=29,
errors=0}
at
__randomizedtesting.SeedInfo.seed([59DC2A5F44BE7123:E5B25C4DE0EDF259]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:129)
at
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:83)
at
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:306)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMar
RM question JIRA fixVersion transition
Hi I am just completing the last steps in the ReleaseTODO as first-time RM for the 7.7.2 bugfix release. In the "Update JIRA" section it says: > • Do another JIRA search to find all issues with Unresolved Resolution and > fixVersion of the release you just made. Note that Jira can only bulk-change > fixVersion if you search only one project at a time. This URL may work - but > edit the fixVersion part, and change LUCENE to SOLR to get to Solr's issues > separately - > https://issues.apache.org/jira/issues/?jql=project+=+LUCENE+AND+resolution=Unresolved+AND+fixVersion=6.0.1, > and do a bulk change to the fixVersion to be both the master version and the > next version on the branch you just released from. Uncheck the box that says > "send an email for these changes". It is the part "bulk change to the fixVersion to be both the master version and the next version on the branch you just released from" that I wonder. JIRA now has a dropdown where you can either - Add to existing - Clear field - Replace all with - Find and remove these I guess this option is new to a recent JIRA release and that you earlier could only replace all fixVersions. But if you do that, you risk removing some fix versions that are NOT next or master, so this operation is destructive. Also the TODO is not clear what to do here for bugfix releases. For the 7.7.2 release it would be wrong to REPLACE the field with 7.7.3, master(9.0), what if some issues also had 8.1.2 and 8.2 in them? My proposal is to instead select "Find and remove these" and the released version, and thus remove just that one version from the Unresolved JIRA issue. Opinions? -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com
[jira] [Updated] (LUCENE-8834) Cache the SortedNumericDocValues.docValueCount() value whenever it is used in a loop
[
https://issues.apache.org/jira/browse/LUCENE-8834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Underwood updated LUCENE-8834:
--
Description:
While troubleshooting some multi-valued facet performance problems in Solr I
noticed that caching the SortedNumericDocValues.docValueCount() value when used
as a loop condition provides a performance improvement.
Specifically, going from something like this:
{code:java}
for (int i = 1; i < longs.docValueCount(); i++) {
...
}
{code}
to this:
{code:java}
final int docValueCount = longs.docValueCount();
for (int i = 1; i < docValueCount; i++) {
...
}
{code}
or this:
{code:java}
for (int i = 1, count = longs.docValueCount(); i < count; i++) {
...
}
{code}
provides a faceting performance improvement when trying to facet using doc
values on a multi-valued field with more than a few values per document.
This patch modifies most of the places in Lucene/Solr that were not already
using this pattern.
h2. Unscientific Manual Benchmarks
I focused on the change to NumericFacets.java and
FacetFieldProcessorByHashDV.java since that is what I was specifically trying
to improve.
Details about my setup:
* Index was created using Lucene/Solr 7.6.0 (I'm in the process of upgrading to
8.1.1)
* Total Docs: 5,736,951
* I'm faceting on a single multi-valued field that has 63,070,176 total values
indexed (10.99 values on average per document.)
* OpenJDK 11
h3. Lucene/Solr 7.6.0:
||Facet Type||QTime Before Patch||QTime After Patch||
|Legacy Facets|1042ms|854ms|
|JSON Facets|823ms|783ms|
h3. Lucene/Solr 8.1.1 (using the 7.6.0 index):
||Facet Type||QTime Before Patch||QTime After Patch||
|Legacy Facets|1043ms|777ms|
|JSON Facets|827ms|792ms|
The reported QTime is simply the lowest QTime I was able to get after repeating
the query a few dozen times. So not very scientific but it was repeatable
(removing the patch increased the times, reapplying the patch decreased the
times).
The patch touches both Lucene and Solr code which is why I have filed this as
a LUCENE issue. I can re-organized and break it apart if needed.
was:
While troubleshooting some multi-valued facet performance problems in Solr I
noticed that caching the SortedNumericDocValues.docValueCount() value when used
as a loop condition provides a performance improvement.
Specifically, going from something like this:
{code:java}
for (int i = 1; i < longs.docValueCount(); i++) {
...
}
{code}
to this:
{code:java}
final int docValueCount = longs.docValueCount();
for (int i = 1; i < docValueCount; i++) {
...
}
{code}
provides a faceting performance improvement when trying to facet using doc
values on a multi-valued field with more than a few values per document.
This patch modifies most of the places in Lucene/Solr that were not already
using this pattern.
h2. Unscientific Manual Benchmarks
I focused on the change to NumericFacets.java and
FacetFieldProcessorByHashDV.java since that is what I was specifically trying
to improve.
Details about my setup:
* Index was created using Lucene/Solr 7.6.0 (I'm in the process of upgrading to
8.1.1)
* Total Docs: 5,736,951
* I'm faceting on a single multi-valued field that has 63,070,176 total values
indexed (10.99 values on average per document.)
* OpenJDK 11
h3. Lucene/Solr 7.6.0:
||Facet Type||QTime Before Patch||QTime After Patch||
|Legacy Facets|1042ms|854ms|
|JSON Facets|823ms|783ms|
h3. Lucene/Solr 8.1.1 (using the 7.6.0 index):
||Facet Type||QTime Before Patch||QTime After Patch||
|Legacy Facets|1043ms|777ms|
|JSON Facets|827ms|792ms|
The reported QTime is simply the lowest QTime I was able to get after repeating
the query a few dozen times. So not very scientific but it was repeatable
(removing the patch increased the times, reapplying the patch decreased the
times).
The patch touches both Lucene and Solr code which is why I have filed this as
a LUCENE issue. I can re-organized and break it apart if needed.
> Cache the SortedNumericDocValues.docValueCount() value whenever it is used in
> a loop
>
>
> Key: LUCENE-8834
> URL: https://issues.apache.org/jira/browse/LUCENE-8834
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Tim Underwood
>Priority: Minor
> Time Spent: 1h
> Remaining Estimate: 0h
>
> While troubleshooting some multi-valued facet performance problems in Solr I
> noticed that caching the SortedNumericDocValues.docValueCount() value when
> used as a loop condition provides a performance improvement.
> Specifically, going from something like this:
> {code:java}
> for (int i = 1; i < longs.docValueCount(); i++) {
> ...
> }
> {code}
> to this:
> {code:java}
> final int docValueCount = longs.docValueCount();
> for (int i = 1; i < docValueCount; i++) {
> ...
> }
>
[GitHub] [lucene-solr] tpunder commented on a change in pull request #698: LUCENE-8834: Cache the SortedNumericDocValues.docValueCount() value whenever it is used in a loop
tpunder commented on a change in pull request #698: LUCENE-8834: Cache the
SortedNumericDocValues.docValueCount() value whenever it is used in a loop
URL: https://github.com/apache/lucene-solr/pull/698#discussion_r290945820
##
File path:
lucene/backward-codecs/src/java/org/apache/lucene/codecs/lucene70/Lucene70DocValuesConsumer.java
##
@@ -158,7 +158,8 @@ void nextBlock() {
long gcd = 0;
Set uniqueValues = new HashSet<>();
for (int doc = values.nextDoc(); doc != DocIdSetIterator.NO_MORE_DOCS; doc
= values.nextDoc()) {
- for (int i = 0, count = values.docValueCount(); i < count; ++i) {
+ final int docValueCount = values.docValueCount();
+ for (int i = 0, count = docValueCount; i < count; ++i) {
Review comment:
Fine by me. I've updated the PR to use the inline style except in the 2
cases where the count is used outside of the loop.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-8.x - Build # 217 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/217/ All tests passed Build Log: [...truncated 55664 lines...] -ecj-javadoc-lint-src: [mkdir] Created dir: /tmp/ecj1187093534 [ecj-lint] Compiling 85 source files to /tmp/ecj1187093534 [ecj-lint] -- [ecj-lint] 1. ERROR in /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/sandbox/src/java/org/apache/lucene/geo/Rectangle2D.java (at line 20) [ecj-lint] import java.util.Arrays; [ecj-lint] [ecj-lint] The import java.util.Arrays is never used [ecj-lint] -- [ecj-lint] 1 problem (1 error) BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:634: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:101: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/build.xml:207: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:2270: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:2093: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:2132: Compile failed; see the compiler error output for details. Total time: 104 minutes 27 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] jpountz commented on a change in pull request #698: LUCENE-8834: Cache the SortedNumericDocValues.docValueCount() value whenever it is used in a loop
jpountz commented on a change in pull request #698: LUCENE-8834: Cache the
SortedNumericDocValues.docValueCount() value whenever it is used in a loop
URL: https://github.com/apache/lucene-solr/pull/698#discussion_r290940191
##
File path:
lucene/backward-codecs/src/java/org/apache/lucene/codecs/lucene70/Lucene70DocValuesConsumer.java
##
@@ -158,7 +158,8 @@ void nextBlock() {
long gcd = 0;
Set uniqueValues = new HashSet<>();
for (int doc = values.nextDoc(); doc != DocIdSetIterator.NO_MORE_DOCS; doc
= values.nextDoc()) {
- for (int i = 0, count = values.docValueCount(); i < count; ++i) {
+ final int docValueCount = values.docValueCount();
+ for (int i = 0, count = docValueCount; i < count; ++i) {
Review comment:
I'm fine with both. One thing that is nice with inlining it in the for loop
is that the variable gets a smaller scope.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857035#comment-16857035
]
Adrien Grand commented on LUCENE-8362:
--
This looks good in general, some minor comments:
- tests should use IndexSearcher#count instead of computing top docs just to
get the count?
- BinaryRangeDocValues doesn't need to be public?
- isCacheable could return {{DocValues.isCacheable(ctx, field);}} instead of
false
> Add DocValue support for RangeFields
> -
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch, LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
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
[GitHub] [lucene-solr] tpunder commented on a change in pull request #698: LUCENE-8834: Cache the SortedNumericDocValues.docValueCount() value whenever it is used in a loop
tpunder commented on a change in pull request #698: LUCENE-8834: Cache the
SortedNumericDocValues.docValueCount() value whenever it is used in a loop
URL: https://github.com/apache/lucene-solr/pull/698#discussion_r290933179
##
File path:
lucene/backward-codecs/src/java/org/apache/lucene/codecs/lucene70/Lucene70DocValuesConsumer.java
##
@@ -158,7 +158,8 @@ void nextBlock() {
long gcd = 0;
Set uniqueValues = new HashSet<>();
for (int doc = values.nextDoc(); doc != DocIdSetIterator.NO_MORE_DOCS; doc
= values.nextDoc()) {
- for (int i = 0, count = values.docValueCount(); i < count; ++i) {
+ final int docValueCount = values.docValueCount();
+ for (int i = 0, count = docValueCount; i < count; ++i) {
Review comment:
@jpountz I reverted my changes in the case where it was already cached. It
looks like that mostly scopes the changes to Solr with the exception of the
Lucene JoinUtil.
Do you have a caching style preference of doing it inline in the `for`
expression vs a separate variable before the loop?
I've seen both ways used in the codebase. For example in
LatLonPointDistanceComparator.java:
```java
if (doc == currentDocs.docID()) {
setValues();
int numValues = currentDocs.docValueCount();
for (int i = 0; i < numValues; i++) {
long encoded = currentValues[i];
double docLatitude = decodeLatitude((int)(encoded >> 32));
double docLongitude = decodeLongitude((int)(encoded & 0x));
minValue = Math.min(minValue, SloppyMath.haversinSortKey(latitude,
longitude, docLatitude, docLongitude));
}
}
```
Versus the example you pointed out of:
```java
for (int i = 0, count = values.docValueCount(); i < count; ++i) {
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] tpunder commented on a change in pull request #698: LUCENE-8834: Cache the SortedNumericDocValues.docValueCount() value whenever it is used in a loop
tpunder commented on a change in pull request #698: LUCENE-8834: Cache the
SortedNumericDocValues.docValueCount() value whenever it is used in a loop
URL: https://github.com/apache/lucene-solr/pull/698#discussion_r290929514
##
File path:
lucene/backward-codecs/src/java/org/apache/lucene/codecs/lucene70/Lucene70DocValuesConsumer.java
##
@@ -158,7 +158,8 @@ void nextBlock() {
long gcd = 0;
Set uniqueValues = new HashSet<>();
for (int doc = values.nextDoc(); doc != DocIdSetIterator.NO_MORE_DOCS; doc
= values.nextDoc()) {
- for (int i = 0, count = values.docValueCount(); i < count; ++i) {
+ final int docValueCount = values.docValueCount();
+ for (int i = 0, count = docValueCount; i < count; ++i) {
Review comment:
Whoops, you are right. I totally missed that in that case it was already
caching the value. I will revert and audit the other changes.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] jpountz commented on a change in pull request #698: LUCENE-8834: Cache the SortedNumericDocValues.docValueCount() value whenever it is used in a loop
jpountz commented on a change in pull request #698: LUCENE-8834: Cache the
SortedNumericDocValues.docValueCount() value whenever it is used in a loop
URL: https://github.com/apache/lucene-solr/pull/698#discussion_r290928309
##
File path:
lucene/backward-codecs/src/java/org/apache/lucene/codecs/lucene70/Lucene70DocValuesConsumer.java
##
@@ -158,7 +158,8 @@ void nextBlock() {
long gcd = 0;
Set uniqueValues = new HashSet<>();
for (int doc = values.nextDoc(); doc != DocIdSetIterator.NO_MORE_DOCS; doc
= values.nextDoc()) {
- for (int i = 0, count = values.docValueCount(); i < count; ++i) {
+ final int docValueCount = values.docValueCount();
+ for (int i = 0, count = docValueCount; i < count; ++i) {
Review comment:
could you leave it the way it was before, it already cached the
docValueCount? Maybe this way of caching the docValueCount is a bit better by
the way as it gives a smaller scope to the variable?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8150) Remove references to segments.gen.
[
https://issues.apache.org/jira/browse/LUCENE-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857019#comment-16857019
]
Adrien Grand commented on LUCENE-8150:
--
No they are not, I removed the fixVersion.
> Remove references to segments.gen.
> --
>
> Key: LUCENE-8150
> URL: https://issues.apache.org/jira/browse/LUCENE-8150
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (9.0)
>
> Attachments: LUCENE-8150.patch, LUCENE-8150.patch
>
>
> This was the way we wrote pending segment files before we switch to
> {{pending_segments_N}} in LUCENE-5925.
--
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-8150) Remove references to segments.gen.
[
https://issues.apache.org/jira/browse/LUCENE-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-8150:
-
Fix Version/s: (was: master (9.0))
> Remove references to segments.gen.
> --
>
> Key: LUCENE-8150
> URL: https://issues.apache.org/jira/browse/LUCENE-8150
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-8150.patch, LUCENE-8150.patch
>
>
> This was the way we wrote pending segment files before we switch to
> {{pending_segments_N}} in LUCENE-5925.
--
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-8150) Remove references to segments.gen.
[
https://issues.apache.org/jira/browse/LUCENE-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-8150:
-
Fix Version/s: (was: 8.1)
> Remove references to segments.gen.
> --
>
> Key: LUCENE-8150
> URL: https://issues.apache.org/jira/browse/LUCENE-8150
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (9.0)
>
> Attachments: LUCENE-8150.patch, LUCENE-8150.patch
>
>
> This was the way we wrote pending segment files before we switch to
> {{pending_segments_N}} in LUCENE-5925.
--
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-13520) Solr should try reloading core on index corruptions
[ https://issues.apache.org/jira/browse/SOLR-13520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-13520: -- Description: We are observing a lot of index corruptions in Google Cloud Platform . Index files are reported to be missing. Most of these corruptions are ephemeral. a restart actually solved most of these and the index recovered. Solr should try reloading a core if an index corruption is encountered (was: We are observing a lot of index corruptions in Google Cloud Platform . Index files are reported to be missing. Most of these corruptions are ephemeral. a restart actually solved most of these and the index recovered. Solr should try reloading a core if an index corruption is encoutered) > Solr should try reloading core on index corruptions > --- > > Key: SOLR-13520 > URL: https://issues.apache.org/jira/browse/SOLR-13520 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > > We are observing a lot of index corruptions in Google Cloud Platform . Index > files are reported to be missing. Most of these corruptions are ephemeral. a > restart actually solved most of these and the index recovered. Solr should > try reloading a core if an index corruption is encountered -- 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-13520) Solr should try reloading core on index corruptions
Noble Paul created SOLR-13520: - Summary: Solr should try reloading core on index corruptions Key: SOLR-13520 URL: https://issues.apache.org/jira/browse/SOLR-13520 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul We are observing a lot of index corruptions in Google Cloud Platform . Index files are reported to be missing. Most of these corruptions are ephemeral. a restart actually solved most of these and the index recovered. Solr should try reloading a core if an index corruption is encoutered -- 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-13519) Support removing/renaming unused fields at a collection level.
Erick Erickson created SOLR-13519: - Summary: Support removing/renaming unused fields at a collection level. Key: SOLR-13519 URL: https://issues.apache.org/jira/browse/SOLR-13519 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Erick Erickson LUCENE-8832 introduces the ability to remove metadata etc. from the Lucene indexes when they're no longer used. If/when that Jira gets committed, we should make it accessible from Solr. Probably will need a collection-level API that sends the sub-request to each replica of each shard. -- 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] (LUCENE-8832) Support for field removal and renaming
[ https://issues.apache.org/jira/browse/LUCENE-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857003#comment-16857003 ] Andrzej Bialecki edited comment on LUCENE-8832 at 6/5/19 8:14 PM: --- Sure. Currently I'm exploring ways to define and record the mappings as userData in a SegmentCommitInfo, and have the Codec use this information for re-mapping. Once this part is in place for all intents and purposes the segments will appear as if the fields were already renamed / deleted, so the forced singleton merges with do The Right Thing (ie. they will skip data that corresponds to deleted fields, and pull data from other source fields in case of renamed fields). was (Author: ab): Sure. Currently I'm exploring ways to define and record the mappings as userData in a SegmentCommitInfo, and have the Codec use this information for re-mapping. Once this part is in place for all intents and purposes the segments will appear as if the fields were already renamed / deleted, so the forced singleton merges with do The Right Thing. > Support for field removal and renaming > -- > > Key: LUCENE-8832 > URL: https://issues.apache.org/jira/browse/LUCENE-8832 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > > Currently it's not possible to rename existing Lucene fields or delete them > without creating a new index from scratch (FieldInfos are basically > append-only). > This issue proposes to investigate an approach that applies these changes at > a Codec level so that the unwanted data is skipped over (in case of field > delete) or accessed under a different name (in case of field rename). Since > the same Codec API is used for segment merging the deletion / removal > filtering could be applied only to the currently existing segments because > the resulting merged segments would not contain this data anymore. -- 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-8832) Support for field removal and renaming
[ https://issues.apache.org/jira/browse/LUCENE-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857003#comment-16857003 ] Andrzej Bialecki commented on LUCENE-8832: --- Sure. Currently I'm exploring ways to define and record the mappings as userData in a SegmentCommitInfo, and have the Codec use this information for re-mapping. Once this part is in place for all intents and purposes the segments will appear as if the fields were already renamed / deleted, so the forced singleton merges with do The Right Thing. > Support for field removal and renaming > -- > > Key: LUCENE-8832 > URL: https://issues.apache.org/jira/browse/LUCENE-8832 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > > Currently it's not possible to rename existing Lucene fields or delete them > without creating a new index from scratch (FieldInfos are basically > append-only). > This issue proposes to investigate an approach that applies these changes at > a Codec level so that the unwanted data is skipped over (in case of field > delete) or accessed under a different name (in case of field rename). Since > the same Codec API is used for segment merging the deletion / removal > filtering could be applied only to the currently existing segments because > the resulting merged segments would not contain this data anymore. -- 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-12589) metrics name should not contains "/" path seperator while using SolrGangliaReporter
[ https://issues.apache.org/jira/browse/SOLR-12589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-12589: --- Fix Version/s: (was: 8.1) > metrics name should not contains "/" path seperator while using > SolrGangliaReporter > --- > > Key: SOLR-12589 > URL: https://issues.apache.org/jira/browse/SOLR-12589 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.3.1, 7.4, 8.0 >Reporter: weizhenyuan >Priority: Minor > Fix For: master (9.0) > > Attachments: SOLR-12589-1.diff, SOLR-12589-2.diff, SOLR-12589-3.diff > > > As I was using SolrGangliaReporter, default metrics names will contains > "/", which is > offen used in FileSystem as an seperator, than it encounters ERROR cause > creating > metrics data file failed, bellow is the Exception in /var/log/messages: > Jul 25 15:01:37 hb-bp1tg6t003y04p201-001 gmetad: Unable to write meta data > for metric > solr.node.QUERY.httpShardHandler.http_//hb-bp1tg6t003y04p201-003.hbase.rds.aliyuncs.com_8983/solr/admin/cores.post.requests.p999 > to RRD > Jul 25 15:01:37 hb-bp1tg6t003y04p201-001 gmetad: RRD_create: creating > '/var/lib/ganglia/rrds/__SummaryInfo__/solr.node.ADMIN./admin/cores.requestTimes.p999.rrd': > No such file or directory > Jul 25 15:01:37 hb-bp1tg6t003y04p201-001 gmetad: Unable to write meta data > for metric solr.node.ADMIN./admin/cores.requestTimes.p999 to RRD > Jul 25 15:01:37 localhost gmetad: RRD_create: creating > '/var/lib/ganglia/rrds/__SummaryInfo__/solr.node.ADMIN./admin/collections.requestTimes.min.rrd': > No such file or directory > Jul 25 15:01:37 localhost gmetad: Unable to write meta data for metric > solr.node.ADMIN./admin/collections.requestTimes.min to RRD > Jul 25 15:01:37 localhost gmetad: RRD_create: creating > '/var/lib/ganglia/rrds/__SummaryInfo__/solr.node.ADMIN./admin/authorization.requestTimes.stddev.rrd': > No such file or directory > Jul 25 15:01:37 localhost gmetad: Unable to write meta data for metric > solr.node.ADMIN./admin/authorization.requestTimes.stddev to RRD > Jul 25 15:01:37 localhost gmetad: RRD_create: creating > '/var/lib/ganglia/rrds/__SummaryInfo__/solr.node.ADMIN./admin/autoscaling/history.requestTimes.p99.rrd': > No such file or directory > Jul 25 15:01:37 localhost gmetad: Unable to write meta data for metric > solr.node.ADMIN./admin/autoscaling/history.requestTimes.p99 to RRD > Jul 25 15:01:37 localhost gmetad: RRD_create: creating > '/var/lib/ganglia/rrds/__SummaryInfo__/solr.node.QUERY./admin/autoscaling.timeouts.m1_rate.rrd': > No such file or directory > I think the metrics name should be normalized for different reporter，such as > SolrGangliaReport. > Some times other normalization is used for other reason，but now，for > ganglia，It must > replace the "/" . -- 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-12573) Config and using SolrGangliaReporter, encounters an ClassNotDefException
[ https://issues.apache.org/jira/browse/SOLR-12573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-12573: --- Fix Version/s: (was: 8.1) > Config and using SolrGangliaReporter, encounters an ClassNotDefException > > > Key: SOLR-12573 > URL: https://issues.apache.org/jira/browse/SOLR-12573 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 7.3.1, 7.4, 8.0 >Reporter: weizhenyuan >Priority: Minor > Labels: build, patch > Fix For: master (9.0) > > Attachments: ExceptionDetail.log, SOLR-12573-1.patch > > > Config and using SolrGangliaReporter, then start solr service encounters the > ClassNotDefException bellow: > java.lang.NoClassDefFoundError: org/acplt/oncrpc/XdrEncodingStream > at info.ganglia.gmetric4j.gmetric.GMetric.(GMetric.java:82) > at info.ganglia.gmetric4j.gmetric.GMetric.(GMetric.java:58) > at info.ganglia.gmetric4j.gmetric.GMetric.(GMetric.java:40) > at > org.apache.solr.metrics.reporters.SolrGangliaReporter.lambda$start$0(SolrGangliaReporter.java:106) > at > org.apache.solr.metrics.reporters.ReporterClientCache.getOrCreate(ReporterClientCache.java:59) > at > org.apache.solr.metrics.reporters.SolrGangliaReporter.start(SolrGangliaReporter.java:106) > at > .. > Caused by: java.lang.ClassNotFoundException: > org.acplt.oncrpc.XdrEncodingStream > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:448) > at java.lang.ClassLoader.loadClass(ClassLoader.java:380) > It should be configurated an dependency in solr/server/ivy.xml as default. -- 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-12447) Allow SimplePostTool to POST hidden files.
[ https://issues.apache.org/jira/browse/SOLR-12447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-12447: --- Fix Version/s: (was: 8.1) > Allow SimplePostTool to POST hidden files. > -- > > Key: SOLR-12447 > URL: https://issues.apache.org/jira/browse/SOLR-12447 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.0 >Reporter: Ian Goldsmith-Rooney >Priority: Minor > Labels: newbie, patch > Fix For: master (9.0) > > Attachments: SOLR-12447.patch > > > Currently, the SimplePostTool ignores all hidden files without a toggle. This > feature will add a toggle to allow POSTing hidden files for indexing. -- 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-11718) Deprecate CDCR Buffer APIs and set Buffer to "false"
[ https://issues.apache.org/jira/browse/SOLR-11718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856998#comment-16856998 ] Christine Poerschke commented on SOLR-11718: Hello. Could we confirm here if changes are included in the (already released) 8.1 version which is (currently) tagged as fixVersion. It appears from ticket updates and cursory CHANGES.txt scan that nothing was committed here yet – if that is correct, may I suggest to un-tag the fixVersion 8.1 portion? Thanks! > Deprecate CDCR Buffer APIs and set Buffer to "false" > > > Key: SOLR-11718 > URL: https://issues.apache.org/jira/browse/SOLR-11718 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR >Reporter: Amrit Sarkar >Assignee: Varun Thacker >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-11718.patch, SOLR-11718.patch, SOLR-11718.patch > > > Kindly see the discussion on SOLR-11652. > Today, if we see the current CDCR documentation page, buffering is "disabled" > by default in both source and target. We don't see any purpose served by Cdcr > buffering and it is quite an overhead considering it can take a lot heap > space (tlogs ptr) and forever retention of tlogs on the disk when enabled. > Also today, even if we disable buffer from API on source , considering it was > enabled at startup, tlogs are never purged on leader node of shards of > source, refer jira: SOLR-11652 -- 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-11528) ltr unit tests failed when run as JUnit in Eclipse Oxygen
[ https://issues.apache.org/jira/browse/SOLR-11528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-11528: --- Fix Version/s: (was: 8.1) (was: master (9.0)) > ltr unit tests failed when run as JUnit in Eclipse Oxygen > -- > > Key: SOLR-11528 > URL: https://issues.apache.org/jira/browse/SOLR-11528 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - LTR >Affects Versions: 8.0 > Environment: eclipse oxygen >Reporter: jin jing >Priority: Major > Attachments: SOLR-11528.patch > > > If we build the lucene project first and then run the ltr unit test, it will > have the following error: > ERROR: [doc=1] unknown field 'description' > i found this is beacuse of the under the floader > solr\contrib\ltr\src\test-files we shoud modify solr\collection1\conf to > ltr\solr\collection1\conf. and we shoud Specify solrhome in TestRerankBase. > If you do not modify the path schema may be overwritten -- 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-8833) Allow subclasses of MMapDirecory to preload individual IndexInputs
[ https://issues.apache.org/jira/browse/LUCENE-8833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856997#comment-16856997 ] Robert Muir commented on LUCENE-8833: - what would the iocontext provide to base the preload decision on? just curious. > Allow subclasses of MMapDirecory to preload individual IndexInputs > -- > > Key: LUCENE-8833 > URL: https://issues.apache.org/jira/browse/LUCENE-8833 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Simon Willnauer >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > I think it's useful for subclasses to select the preload flag on a per index > input basis rather than all or nothing. Here is a patch that has an > overloaded protected openInput method. -- 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-8150) Remove references to segments.gen.
[
https://issues.apache.org/jira/browse/LUCENE-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856996#comment-16856996
]
Christine Poerschke commented on LUCENE-8150:
-
Hello. Could we confirm here if changes are included in the (already released)
8.1 version which is (currently) tagged as fixVersion. It appears from ticket
updates and cursory CHANGES.txt scan that nothing was committed here yet – if
that is correct, may I suggest to un-tag the fixVersion 8.1 portion? Thanks!
> Remove references to segments.gen.
> --
>
> Key: LUCENE-8150
> URL: https://issues.apache.org/jira/browse/LUCENE-8150
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8150.patch, LUCENE-8150.patch
>
>
> This was the way we wrote pending segment files before we switch to
> {{pending_segments_N}} in LUCENE-5925.
--
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-8620) Add CONTAINS support for LatLonShape
[
https://issues.apache.org/jira/browse/LUCENE-8620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856995#comment-16856995
]
Christine Poerschke commented on LUCENE-8620:
-
Hello. Could we confirm here if changes are included in the (already released)
8.1 version which is (currently) tagged as fixVersion. It appears from ticket
updates and cursory CHANGES.txt scan that nothing was committed here yet – if
that is correct, may I suggest to un-tag the fixVersion 8.1 portion? Thanks!
> Add CONTAINS support for LatLonShape
>
>
> Key: LUCENE-8620
> URL: https://issues.apache.org/jira/browse/LUCENE-8620
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/sandbox
>Reporter: Ignacio Vera
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8620.patch, LUCENE-8620.patch
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> Currently the only spatial operation that cannot be performed using
> {{LatLonShape}} is CONTAINS. This issue will add such capability by tracking
> if an edge of a generated triangle from the {{Tessellator}} is an edge of the
> polygon.
--
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-13518) improve SolrInfoBeanTest.testCallMBeanInfo debuggability
[
https://issues.apache.org/jira/browse/SOLR-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13518:
---
Fix Version/s: 8.2
master (9.0)
> improve SolrInfoBeanTest.testCallMBeanInfo debuggability
>
>
> Key: SOLR-13518
> URL: https://issues.apache.org/jira/browse/SOLR-13518
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (9.0), 8.2
>
>
> Today
> https://builds.apache.org/job/PreCommit-SOLR-Build/407/testReport/org.apache.solr/SolrInfoBeanTest/testCallMBeanInfo/
> reported
> {code}
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([D2ED2D454B87B637:2D8BA07920FFCB29]:0)
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at
> org.apache.solr.SolrInfoBeanTest.testCallMBeanInfo(SolrInfoBeanTest.java:73)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> ...
> {code}
> and since the test runs logic for multiple classes it would be nice to
> include e.g. the class name info in the assert itself.
--
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-13518) improve SolrInfoBeanTest.testCallMBeanInfo debuggability
[
https://issues.apache.org/jira/browse/SOLR-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856988#comment-16856988
]
Christine Poerschke commented on SOLR-13518:
Two commits above done, will leave this ticket open for a bit in case anyone
else (or myself) wants to use it for additional debug-related adjustments for
the test.
> improve SolrInfoBeanTest.testCallMBeanInfo debuggability
>
>
> Key: SOLR-13518
> URL: https://issues.apache.org/jira/browse/SOLR-13518
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> Today
> https://builds.apache.org/job/PreCommit-SOLR-Build/407/testReport/org.apache.solr/SolrInfoBeanTest/testCallMBeanInfo/
> reported
> {code}
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([D2ED2D454B87B637:2D8BA07920FFCB29]:0)
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at
> org.apache.solr.SolrInfoBeanTest.testCallMBeanInfo(SolrInfoBeanTest.java:73)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> ...
> {code}
> and since the test runs logic for multiple classes it would be nice to
> include e.g. the class name info in the assert itself.
--
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-13518) improve SolrInfoBeanTest.testCallMBeanInfo debuggability
[
https://issues.apache.org/jira/browse/SOLR-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856983#comment-16856983
]
ASF subversion and git services commented on SOLR-13518:
Commit 57c159e476c23b8d2e4d87baece4c807f8556502 in lucene-solr's branch
refs/heads/branch_8x from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=57c159e ]
SOLR-13518: extra assertNotNull info for SolrInfoBeanTest
> improve SolrInfoBeanTest.testCallMBeanInfo debuggability
>
>
> Key: SOLR-13518
> URL: https://issues.apache.org/jira/browse/SOLR-13518
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> Today
> https://builds.apache.org/job/PreCommit-SOLR-Build/407/testReport/org.apache.solr/SolrInfoBeanTest/testCallMBeanInfo/
> reported
> {code}
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([D2ED2D454B87B637:2D8BA07920FFCB29]:0)
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at
> org.apache.solr.SolrInfoBeanTest.testCallMBeanInfo(SolrInfoBeanTest.java:73)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> ...
> {code}
> and since the test runs logic for multiple classes it would be nice to
> include e.g. the class name info in the assert itself.
--
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-13518) improve SolrInfoBeanTest.testCallMBeanInfo debuggability
[
https://issues.apache.org/jira/browse/SOLR-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856981#comment-16856981
]
ASF subversion and git services commented on SOLR-13518:
Commit 757e4548c7390d4900cb4fe433e17d14a7b4a2ee in lucene-solr's branch
refs/heads/master from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=757e454 ]
SOLR-13518: extra assertNotNull info for SolrInfoBeanTest
> improve SolrInfoBeanTest.testCallMBeanInfo debuggability
>
>
> Key: SOLR-13518
> URL: https://issues.apache.org/jira/browse/SOLR-13518
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> Today
> https://builds.apache.org/job/PreCommit-SOLR-Build/407/testReport/org.apache.solr/SolrInfoBeanTest/testCallMBeanInfo/
> reported
> {code}
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([D2ED2D454B87B637:2D8BA07920FFCB29]:0)
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at
> org.apache.solr.SolrInfoBeanTest.testCallMBeanInfo(SolrInfoBeanTest.java:73)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> ...
> {code}
> and since the test runs logic for multiple classes it would be nice to
> include e.g. the class name info in the assert itself.
--
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
[JENKINS] Lucene-Solr-Tests-master - Build # 3357 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3357/
All tests passed
Build Log:
[...truncated 64190 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj2108581380
[ecj-lint] Compiling 69 source files to /tmp/ecj2108581380
[ecj-lint] invalid Class-Path header in manifest of jar file:
/x1/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
[ecj-lint] invalid Class-Path header in manifest of jar file:
/x1/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
[ecj-lint] --
[ecj-lint] 1. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 28)
[ecj-lint] import javax.naming.InitialContext;
[ecj-lint]^^^
[ecj-lint] The type javax.naming.InitialContext is not accessible
[ecj-lint] --
[ecj-lint] 2. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 29)
[ecj-lint] import javax.naming.NamingException;
[ecj-lint]
[ecj-lint] The type javax.naming.NamingException is not accessible
[ecj-lint] --
[ecj-lint] 3. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 182)
[ecj-lint] c = getFromJndi(initProps, jndiName);
[ecj-lint] ^^^
[ecj-lint] The method getFromJndi(Properties, String) from the type new
Callable(){} refers to the missing type NamingException
[ecj-lint] --
[ecj-lint] 4. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 245)
[ecj-lint] private Connection getFromJndi(final Properties initProps,
final String jndiName) throws NamingException,
[ecj-lint]
^^^
[ecj-lint] NamingException cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 5. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 249)
[ecj-lint] InitialContext ctx = new InitialContext();
[ecj-lint] ^^
[ecj-lint] InitialContext cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 6. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 249)
[ecj-lint] InitialContext ctx = new InitialContext();
[ecj-lint] ^^
[ecj-lint] InitialContext cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 6 problems (6 errors)
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:634: The
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:101: The
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/build.xml:651:
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/common-build.xml:479:
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:2009:
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:2048:
Compile failed; see the compiler error output for details.
Total time: 124 minutes 11 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re:Welcome Namgyu Kim as Lucene/Solr committer
Welcome! Christine From: dev@lucene.apache.org At: 06/03/19 18:52:38To: dev@lucene.apache.org Subject: Welcome Namgyu Kim as Lucene/Solr committer Hi all, Please join me in welcoming Namgyu Kim as Lucene/ Solr committer! Kim has been helping address technical debt and fixing bugs in the last year, including a cleanup to our DutchAnalyzer[0] and improvements to the StoredFieldsVisitor API[1]. More recently he also started improving our korean analyzer[2]. [0] https://issues.apache.org/jira/browse/LUCENE-8582 [1] https://issues.apache.org/jira/browse/LUCENE-8805 [2] https://issues.apache.org/jira/browse/LUCENE-8784 Congratulations and welcome! It is a tradition to introduce yourself with a brief bio. -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13515) deprecate-then-remove SolrPluginUtils.IdentityRegenerator
[
https://issues.apache.org/jira/browse/SOLR-13515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856978#comment-16856978
]
Christine Poerschke commented on SOLR-13515:
bq. ... not sure why /SOLR-7090 added {{NoOpRegenerator}} ...
{{NoOpRegenerator}} was added in SOLR-5182 actually.
bq. ... looks like smiley even pointed out ...
Thanks for pointing out that [~dsmiley] pointed out in SOLR-7090 the same thing
I independently uncovered here, I missed that since did not scan past the first
comment on that issue.
Will proceed with change here early next week hopefully assuming no objections.
> deprecate-then-remove SolrPluginUtils.IdentityRegenerator
> -
>
> Key: SOLR-13515
> URL: https://issues.apache.org/jira/browse/SOLR-13515
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> {{SolrPluginUtils.IdentityRegenerator}} seems to be identical (no pun
> intended) to {{NoOpRegenerator}}. This ticket proposes to deprecate
> IdentityRegenerator on branch_8x and then remove it on master branch.
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/util/SolrPluginUtils.java#L977-L997
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/NoOpRegenerator.java
--
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] [Resolved] (LUCENE-8827) Speed up poll-mirrors.py
[
https://issues.apache.org/jira/browse/LUCENE-8827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl resolved LUCENE-8827.
-
Resolution: Fixed
> Speed up poll-mirrors.py
>
>
> Key: LUCENE-8827
> URL: https://issues.apache.org/jira/browse/LUCENE-8827
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: master (9.0), 8.2, 8.1.2
>
> Attachments: LUCENE-8827.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Speed up {{dev-tools/scripts/poll-mirrors.py}} by parallelizing the URL checks
--
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-8827) Speed up poll-mirrors.py
[
https://issues.apache.org/jira/browse/LUCENE-8827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856973#comment-16856973
]
ASF subversion and git services commented on LUCENE-8827:
-
Commit 02a207edd3b858bfeb7c91f0584a278e8825394d in lucene-solr's branch
refs/heads/branch_8_1 from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=02a207e ]
LUCENE-8827: Speed up poll-mirrors.py and add -once argument. Python3 only
> Speed up poll-mirrors.py
>
>
> Key: LUCENE-8827
> URL: https://issues.apache.org/jira/browse/LUCENE-8827
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: master (9.0), 8.2, 8.1.2
>
> Attachments: LUCENE-8827.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Speed up {{dev-tools/scripts/poll-mirrors.py}} by parallelizing the URL checks
--
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-8827) Speed up poll-mirrors.py
[
https://issues.apache.org/jira/browse/LUCENE-8827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated LUCENE-8827:
Issue Type: Improvement (was: Bug)
> Speed up poll-mirrors.py
>
>
> Key: LUCENE-8827
> URL: https://issues.apache.org/jira/browse/LUCENE-8827
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: master (9.0), 8.2, 8.1.2
>
> Attachments: LUCENE-8827.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Speed up {{dev-tools/scripts/poll-mirrors.py}} by parallelizing the URL checks
--
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-13517) Store query and filter parameters on page change and page refresh
[ https://issues.apache.org/jira/browse/SOLR-13517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saurav Kumar Singh updated SOLR-13517: -- Priority: Trivial (was: Major) > Store query and filter parameters on page change and page refresh > - > > Key: SOLR-13517 > URL: https://issues.apache.org/jira/browse/SOLR-13517 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Saurav Kumar Singh >Priority: Trivial > Labels: admin-interface, query > Time Spent: 10m > Remaining Estimate: 0h > > Admin UI can be used to make queries. The pain point comes when you need to > *change the page* OR *refresh* the page. In both the scenarios you end up > loosing the query params, filter params etc. This also does *NOT* allow to > share the UI URL with query parameters intact. -- 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-13517) Store query and filter parameters on page change and page refresh
[ https://issues.apache.org/jira/browse/SOLR-13517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saurav Kumar Singh updated SOLR-13517: -- Priority: Major (was: Trivial) > Store query and filter parameters on page change and page refresh > - > > Key: SOLR-13517 > URL: https://issues.apache.org/jira/browse/SOLR-13517 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Saurav Kumar Singh >Priority: Major > Labels: admin-interface, query > Time Spent: 10m > Remaining Estimate: 0h > > Admin UI can be used to make queries. The pain point comes when you need to > *change the page* OR *refresh* the page. In both the scenarios you end up > loosing the query params, filter params etc. This also does *NOT* allow to > share the UI URL with query parameters intact. -- 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
[JENKINS] Lucene-Solr-8.x-Solaris (64bit/jdk1.8.0) - Build # 163 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Solaris/163/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.UnloadDistributedZkTest.test Error Message: Error from server at http://127.0.0.1:49908: ADDREPLICA failed to create replica Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:49908: ADDREPLICA failed to create replica at __randomizedtesting.SeedInfo.seed([1CC083359B0B5604:9494BCEF35F73BFC]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1068) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:837) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:769) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.UnloadDistributedZkTest.testCoreUnloadAndLeaders(UnloadDistributedZkTest.java:300) at org.apache.solr.cloud.UnloadDistributedZkTest.test(UnloadDistributedZkTest.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtes
[jira] [Commented] (LUCENE-8827) Speed up poll-mirrors.py
[
https://issues.apache.org/jira/browse/LUCENE-8827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856969#comment-16856969
]
ASF subversion and git services commented on LUCENE-8827:
-
Commit 6b70bdb3c0d7331bfe4dfe92b9eb1a71791ab1f4 in lucene-solr's branch
refs/heads/master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6b70bdb ]
LUCENE-8827: Speed up poll-mirrors.py
> Speed up poll-mirrors.py
>
>
> Key: LUCENE-8827
> URL: https://issues.apache.org/jira/browse/LUCENE-8827
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: master (9.0), 8.2, 8.1.2
>
> Attachments: LUCENE-8827.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Speed up {{dev-tools/scripts/poll-mirrors.py}} by parallelizing the URL checks
--
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-8827) Speed up poll-mirrors.py
[
https://issues.apache.org/jira/browse/LUCENE-8827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated LUCENE-8827:
Fix Version/s: 8.1.2
8.2
master (9.0)
> Speed up poll-mirrors.py
>
>
> Key: LUCENE-8827
> URL: https://issues.apache.org/jira/browse/LUCENE-8827
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: master (9.0), 8.2, 8.1.2
>
> Attachments: LUCENE-8827.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Speed up {{dev-tools/scripts/poll-mirrors.py}} by parallelizing the URL checks
--
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-13496) NullPointerException in JSONWriter.writeSolrDocument
[
https://issues.apache.org/jira/browse/SOLR-13496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856968#comment-16856968
]
Christine Poerschke commented on SOLR-13496:
{quote}... Failed junit tests solr.SolrInfoBeanTest ...
{quote}
I think that's unrelated to the change proposed here. SOLR-13518 just opened to
improve the debuggability of that test.
> NullPointerException in JSONWriter.writeSolrDocument
>
>
> Key: SOLR-13496
> URL: https://issues.apache.org/jira/browse/SOLR-13496
> Project: Solr
> Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13496.patch, SOLR-13496.patch
>
>
> For non-grouped searches
> [QueryComponent.regularFinishStage|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java#L647-L655]
> already considers the possibility of null {{SolrDocument}} values due to an
> index change.
> For grouped searches
> [GroupedEndResultTransformer.transform|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/endresulttransformer/GroupedEndResultTransformer.java#L94-L114]
> potentially adds a null element to a {{SolrDocumentList}}.
> The
> [TextResponseWriter.writeSolrDocumentList|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/response/TextResponseWriter.java#L170]
> method passes any null {{SolrDocument}} through to the
> [JSONWriter.writeSolrDocument|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/response/JSONWriter.java#L87]
> method leading to a {{NullPointerException}} at line 87.
--
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-8827) Speed up poll-mirrors.py
[
https://issues.apache.org/jira/browse/LUCENE-8827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856966#comment-16856966
]
ASF subversion and git services commented on LUCENE-8827:
-
Commit f070b7c742dede34594e1cf4ee28d23d5af3a303 in lucene-solr's branch
refs/heads/master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f070b7c ]
LUCENE-8827: Speed up poll-mirrors.py and add -once argument. Python3 only
(#699)
Also skips Python2 support like the other scripts in the folder
> Speed up poll-mirrors.py
>
>
> Key: LUCENE-8827
> URL: https://issues.apache.org/jira/browse/LUCENE-8827
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: LUCENE-8827.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Speed up {{dev-tools/scripts/poll-mirrors.py}} by parallelizing the URL checks
--
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
[GitHub] [lucene-solr] janhoy merged pull request #699: LUCENE-8827: Speed up poll-mirrors.py and add -once option
janhoy merged pull request #699: LUCENE-8827: Speed up poll-mirrors.py and add -once option URL: https://github.com/apache/lucene-solr/pull/699 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13518) improve SolrInfoBeanTest.testCallMBeanInfo debuggability
Christine Poerschke created SOLR-13518:
--
Summary: improve SolrInfoBeanTest.testCallMBeanInfo debuggability
Key: SOLR-13518
URL: https://issues.apache.org/jira/browse/SOLR-13518
Project: Solr
Issue Type: Task
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Today
https://builds.apache.org/job/PreCommit-SOLR-Build/407/testReport/org.apache.solr/SolrInfoBeanTest/testCallMBeanInfo/
reported
{code}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([D2ED2D454B87B637:2D8BA07920FFCB29]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertNotNull(Assert.java:712)
at org.junit.Assert.assertNotNull(Assert.java:722)
at
org.apache.solr.SolrInfoBeanTest.testCallMBeanInfo(SolrInfoBeanTest.java:73)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
...
{code}
and since the test runs logic for multiple classes it would be nice to include
e.g. the class name info in the assert itself.
--
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
[GitHub] [lucene-solr] janhoy opened a new pull request #699: LUCENE-8827: Speed up poll-mirrors.py and add -once option
janhoy opened a new pull request #699: LUCENE-8827: Speed up poll-mirrors.py and add -once option URL: https://github.com/apache/lucene-solr/pull/699 Runs polling in 5 parallell processes Adds -once option to exit after one poll This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8827) Speed up poll-mirrors.py
[
https://issues.apache.org/jira/browse/LUCENE-8827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856959#comment-16856959
]
ASF subversion and git services commented on LUCENE-8827:
-
Commit 974a92ea7325ff37e525c0602dee7c88c845c145 in lucene-solr's branch
refs/heads/LUCENE-8827-poll-mirrors from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=974a92e ]
LUCENE-8827: Speed up poll-mirrors.py and add -once argument. Python3 only
> Speed up poll-mirrors.py
>
>
> Key: LUCENE-8827
> URL: https://issues.apache.org/jira/browse/LUCENE-8827
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: LUCENE-8827.patch
>
>
> Speed up {{dev-tools/scripts/poll-mirrors.py}} by parallelizing the URL checks
--
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
[JENKINS] Lucene-Solr-BadApples-Tests-8.x - Build # 116 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-8.x/116/ 3 tests failed. FAILED: org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI Error Message: should be a routed alias Stack Trace: java.lang.AssertionError: should be a routed alias at __randomizedtesting.SeedInfo.seed([638ABE5BD91C8ADA:7C5D2277AA177391]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI(AliasIntegrationTest.java:305) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.OverseerTest.testOverseerFailure Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([638ABE5BD91C8ADA]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.O
[jira] [Commented] (SOLR-13507) Remove support for "addr" parameter from the "/solr/admin/zookeeper" endpoint.
[ https://issues.apache.org/jira/browse/SOLR-13507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856934#comment-16856934 ] Erick Erickson commented on SOLR-13507: --- Well, they sure _look_ similar ;). But I think you're right. > Remove support for "addr" parameter from the "/solr/admin/zookeeper" endpoint. > -- > > Key: SOLR-13507 > URL: https://issues.apache.org/jira/browse/SOLR-13507 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Attachments: SOLR-13507.patch > > > The addr parameter isn't needed and it should be removed from the code. -- 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
Re: Welcome Namgyu Kim as Lucene/Solr committer
Welcome Namgyu! -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 3. jun. 2019 kl. 19:52 skrev Adrien Grand : > > Hi all, > > Please join me in welcoming Namgyu Kim as Lucene/ Solr committer! > > Kim has been helping address technical debt and fixing bugs in the > last year, including a cleanup to our DutchAnalyzer[0] and > improvements to the StoredFieldsVisitor API[1]. More recently he also > started improving our korean analyzer[2]. > > [0] https://issues.apache.org/jira/browse/LUCENE-8582 > [1] https://issues.apache.org/jira/browse/LUCENE-8805 > [2] https://issues.apache.org/jira/browse/LUCENE-8784 > > Congratulations and welcome! It is a tradition to introduce yourself > with a brief bio. > > -- > Adrien > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org >
[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 112 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/112/ 2 tests failed. FAILED: org.apache.lucene.index.TestIndexWriterReader.testDuringAddDelete Error Message: this IndexWriter is closed Stack Trace: org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:681) at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:695) at org.apache.lucene.index.IndexWriter.nrtIsCurrent(IndexWriter.java:4945) at org.apache.lucene.index.StandardDirectoryReader.doOpenFromWriter(StandardDirectoryReader.java:293) at org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:272) at org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:262) at org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:165) at org.apache.lucene.index.TestIndexWriterReader.testDuringAddDelete(TestIndexWriterReader.java:861) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Caused by: java.nio.file.FileSystemException: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/checkout/lucene/build/core/test/J2/temp/lucene.index.TestIndexWriterReader_DD23603F6B6E011C-001/index-N
[GitHub] [lucene-solr] tpunder opened a new pull request #698: LUCENE-8834: Cache the SortedNumericDocValues.docValueCount() value whenever it is used in a loop
tpunder opened a new pull request #698: LUCENE-8834: Cache the SortedNumericDocValues.docValueCount() value whenever it is used in a loop URL: https://github.com/apache/lucene-solr/pull/698 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8834) Cache the SortedNumericDocValues.docValueCount() value whenever it is used in a loop
Tim Underwood created LUCENE-8834:
-
Summary: Cache the SortedNumericDocValues.docValueCount() value
whenever it is used in a loop
Key: LUCENE-8834
URL: https://issues.apache.org/jira/browse/LUCENE-8834
Project: Lucene - Core
Issue Type: Improvement
Reporter: Tim Underwood
While troubleshooting some multi-valued facet performance problems in Solr I
noticed that caching the SortedNumericDocValues.docValueCount() value when used
as a loop condition provides a performance improvement.
Specifically, going from something like this:
{code:java}
for (int i = 1; i < longs.docValueCount(); i++) {
...
}
{code}
to this:
{code:java}
final int docValueCount = longs.docValueCount();
for (int i = 1; i < docValueCount; i++) {
...
}
{code}
provides a faceting performance improvement when trying to facet using doc
values on a multi-valued field with more than a few values per document.
This patch modifies most of the places in Lucene/Solr that were not already
using this pattern.
h2. Unscientific Manual Benchmarks
I focused on the change to NumericFacets.java and
FacetFieldProcessorByHashDV.java since that is what I was specifically trying
to improve.
Details about my setup:
* Index was created using Lucene/Solr 7.6.0 (I'm in the process of upgrading to
8.1.1)
* Total Docs: 5,736,951
* I'm faceting on a single multi-valued field that has 63,070,176 total values
indexed (10.99 values on average per document.)
* OpenJDK 11
h3. Lucene/Solr 7.6.0:
||Facet Type||QTime Before Patch||QTime After Patch||
|Legacy Facets|1042ms|854ms|
|JSON Facets|823ms|783ms|
h3. Lucene/Solr 8.1.1 (using the 7.6.0 index):
||Facet Type||QTime Before Patch||QTime After Patch||
|Legacy Facets|1043ms|777ms|
|JSON Facets|827ms|792ms|
The reported QTime is simply the lowest QTime I was able to get after repeating
the query a few dozen times. So not very scientific but it was repeatable
(removing the patch increased the times, reapplying the patch decreased the
times).
The patch touches both Lucene and Solr code which is why I have filed this as
a LUCENE issue. I can re-organized and break it apart if needed.
--
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-13507) Remove support for "addr" parameter from the "/solr/admin/zookeeper" endpoint.
[ https://issues.apache.org/jira/browse/SOLR-13507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856871#comment-16856871 ] Jan Høydahl commented on SOLR-13507: Hi, I think you confuse this with another issue. In this issue we’ll remove the http parameter “addr” from the /solr/admin/zookeeper endpoint, nothing to do with 4lw > Remove support for "addr" parameter from the "/solr/admin/zookeeper" endpoint. > -- > > Key: SOLR-13507 > URL: https://issues.apache.org/jira/browse/SOLR-13507 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Attachments: SOLR-13507.patch > > > The addr parameter isn't needed and it should be removed from the code. -- 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-13510) Intermittent 401's for internode requests with basicauth enabled
[
https://issues.apache.org/jira/browse/SOLR-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856862#comment-16856862
]
Colvin Cowie commented on SOLR-13510:
-
I tested with the patch on the 8.1.x branch and it certainly appears to fix the
random 401s.
I've got some other issues to resolve for migrating our config+plugins from
6.6. to 8.1. before I can really test our usage on 8. So that won't be for a
while.
One thing I have just encountered with trying 8 after using 6, is that there's
some slightly nasty behaviour around the Admin UI pages being cached by the
browser (at it appears to be a caching issue). It's easily fixed by reloading
the page without the cache, but it's not great if you hit it. I'll send it to
the mailing list.
> Intermittent 401's for internode requests with basicauth enabled
>
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-13510.patch
>
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
> "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
> "q":"*:*",
> "_":"1559474550365"}},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
> require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well. Other auth issues (SOLR-13472) look
> like they're impacted by the topography of the collection and cluster. But
> this doesn't seem affected by that at all (401's occur on inter-node requests
> regardless of the recipient of the initial request, and even when all nodes
> have a shard replica).
--
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
[JENKINS] Lucene-Solr-8.1-Linux (64bit/jdk1.8.0_201) - Build # 388 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Linux/388/ Java: 64bit/jdk1.8.0_201 -XX:+UseCompressedOops -XX:+UseSerialGC 14 tests failed. FAILED: org.apache.solr.cloud.PeerSyncReplicationTest.test Error Message: expected:<154> but was:<152> Stack Trace: java.lang.AssertionError: expected:<154> but was:<152> at __randomizedtesting.SeedInfo.seed([E6A3BA122470F81D:6EF785C88A8C95E5]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.junit.Assert.assertEquals(Assert.java:631) at org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:154) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$
Re: Welcome Namgyu Kim as Lucene/Solr committer
Congratulations and welcome Namgyu! On Wed, Jun 5, 2019 at 9:06 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > Welcome Namgyu! > > On Wed, 5 Jun, 2019, 6:35 PM jim ferenczi, wrote: > >> Welcome Namgyu! >> >> Le mer. 5 juin 2019 à 13:54, Ignacio Vera a écrit : >> >>> Welcome! >>> >>> On Wed, Jun 5, 2019 at 1:53 PM Michael Sokolov >>> wrote: >>> Namgyu! Welcome Mike On Mon, Jun 3, 2019 at 1:52 PM Adrien Grand wrote: > > Hi all, > > Please join me in welcoming Namgyu Kim as Lucene/ Solr committer! > > Kim has been helping address technical debt and fixing bugs in the > last year, including a cleanup to our DutchAnalyzer[0] and > improvements to the StoredFieldsVisitor API[1]. More recently he also > started improving our korean analyzer[2]. > > [0] https://issues.apache.org/jira/browse/LUCENE-8582 > [1] https://issues.apache.org/jira/browse/LUCENE-8805 > [2] https://issues.apache.org/jira/browse/LUCENE-8784 > > Congratulations and welcome! It is a tradition to introduce yourself > with a brief bio. > > -- > Adrien > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Anshum Gupta
Re: Welcome Namgyu Kim as Lucene/Solr committer
Welcome and congratulations, Namgyu! I'm just wondering... does he subscribe this list? Tomoko 2019年6月6日(木) 1:06 Ishan Chattopadhyaya : > > Welcome Namgyu! > > On Wed, 5 Jun, 2019, 6:35 PM jim ferenczi, wrote: >> >> Welcome Namgyu! >> >> Le mer. 5 juin 2019 à 13:54, Ignacio Vera a écrit : >>> >>> Welcome! >>> >>> On Wed, Jun 5, 2019 at 1:53 PM Michael Sokolov wrote: Namgyu! Welcome Mike On Mon, Jun 3, 2019 at 1:52 PM Adrien Grand wrote: > > Hi all, > > Please join me in welcoming Namgyu Kim as Lucene/ Solr committer! > > Kim has been helping address technical debt and fixing bugs in the > last year, including a cleanup to our DutchAnalyzer[0] and > improvements to the StoredFieldsVisitor API[1]. More recently he also > started improving our korean analyzer[2]. > > [0] https://issues.apache.org/jira/browse/LUCENE-8582 > [1] https://issues.apache.org/jira/browse/LUCENE-8805 > [2] https://issues.apache.org/jira/browse/LUCENE-8784 > > Congratulations and welcome! It is a tradition to introduce yourself > with a brief bio. > > -- > Adrien > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13510) Intermittent 401's for internode requests with basicauth enabled
[
https://issues.apache.org/jira/browse/SOLR-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856829#comment-16856829
]
Jason Gerlowski commented on SOLR-13510:
I retested things this morning, and confirm that this seems to have fixed the
auth issues for queries. I also tried reproducing the problem with index
updates/deletions, but wasn't able to. (We've only gotten reports of this for
queries, but I figured it made sense to double check updates, since they can
also be routed between nodes.)
Curious to hear whether this fixes things for Colvin as well.
> Intermittent 401's for internode requests with basicauth enabled
>
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-13510.patch
>
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
> "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
> "q":"*:*",
> "_":"1559474550365"}},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
> require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well. Other auth issues (SOLR-13472) look
> like they're impacted by the topography of the collection and cluster. But
> this doesn't seem affected by that at all (401's occur on inter-node requests
> regardless of the recipient of the initial request, and even when all nodes
> have a shard replica).
--
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
[GitHub] [lucene-solr] thomaswoeckinger commented on issue #681: Fix SOLR-13347
thomaswoeckinger commented on issue #681: Fix SOLR-13347 URL: https://github.com/apache/lucene-solr/pull/681#issuecomment-499152403 So ready to merge? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13421) Intermittent error 401 with JSON Facet query to retrieve count all collections
[
https://issues.apache.org/jira/browse/SOLR-13421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski resolved SOLR-13421.
Resolution: Duplicate
> Intermittent error 401 with JSON Facet query to retrieve count all collections
> --
>
> Key: SOLR-13421
> URL: https://issues.apache.org/jira/browse/SOLR-13421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: 8.0
>Reporter: Edwin Yeo Zheng Lin
>Priority: Major
> Labels: BasicAuth
>
> I am using the below JSON Facet to retrieve the count of all the different
> collections in one query.
>
>
> [https://localhost:8983/solr/collection1/select?q=testing&shards=https://localhost:8983/solr/collection1,https://localhost:8983/solr/collection2,https://localhost:8983/solr/collection3,https://localhost:8983/solr/collection4,https://localhost:8983/solr/collection5,https://localhost:8983/solr/collection6&rows=0&json.facet={categories|https://localhost:8983/solr/collection1/select?q=testing&shards=https://localhost:8983/solr/collection1,https://localhost:8983/solr/collection2,https://localhost:8983/solr/collection3,https://localhost:8983/solr/collection4,https://localhost:8983/solr/collection5,https://localhost:8983/solr/collection6&rows=0&json.facet=%7Bcategories]
> : \{type : terms,field : content_type,limit : 100}}
>
>
> Previously, in Solr 7.6 and Solr 7.7, this query can work correctly and we
> are able to produce the correct output.
>
> {
> "responseHeader":
> { "zkConnected":true, "status":0, "QTime":24}
> ,
> "response":
> {"numFound":41200,"start":0,"maxScore":12.993215,"docs":[] }
> ,
> "facets":{
> "count":41200,
> "categories":{
> "buckets":[
> { "val":"collection1", "count":26213}
> ,
>
> { "val":"collection2", "count":12075}
> ,
>
> { "val":"collection3", "count":1947}
> ,
>
> { "val":"collection4", "count":850}
> ,
>
> { "val":"collection5", "count":111}
> ,
>
> { "val":"collection6", "count":4}
> ]}}}
>
>
> However, in the new Solr 8.0.0, this query can only work if we put only one
> collection in the shards (can be any collection). If we put 2 collections,
> there will not be error 90% of the time (only 10% of the time the issue will
> occur with the 'Error 401 require authentication').
> However, once we put 3 or more collections (can be any of the collections),
> this issue of 'Error 401 require authentication' will keep occurring.
>
> {
> "responseHeader":
> { "zkConnected":true, "status":401, "QTime":11}
> ,
> "error":{
> "metadata":[
>
> "error-class","org.apache.solr.client.solrj.impl.Http2SolrClient$RemoteSolrException",
>
> "root-error-class","org.apache.solr.client.solrj.impl.Http2SolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/collection6/select. Reason:\n require
> authentication\n\n\n",
> "code":401}}
>
> This issue does not occur in Solr 7.6 and Solr 7.7, even though I have set
> up the same authentication for all the versions.
>
>
> Below is the format of my security.json:
>
> {
> "authentication":
> { "blockUnknown": true, "class":"solr.BasicAuthPlugin",
> "credentials":
> {"user1":"hyHXXuJSqcZdNgdSTGUvrQZRpqrYFUQ2ffmlWQ4GUTk=
> E0w3/2FD+rlxulbPm2G7i9HZqT+2gMBzcyJCcGcMWwA="}
> },
> "authorization":
> { "class":"solr.RuleBasedAuthorizationPlugin", "user-role":
> {"user1":"admin"}
> ,
> "permissions":[
> {"name":"security-edit", "role":"admin"}
> ]
> }}
--
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
