[jira] [Commented] (SOLR-13413) jetty IdleTimeout bugs with Http2SolrClient, cause sprious timeouts on intranode requests
[ https://issues.apache.org/jira/browse/SOLR-13413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872946#comment-16872946 ] ASF subversion and git services commented on SOLR-13413: Commit af487d9205a18a2bcbf95e0b750fe7286f875767 in lucene-solr's branch refs/heads/branch_8_1 from Cao Manh Dat [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=af487d9 ] SOLR-13413: Add missing sha files > jetty IdleTimeout bugs with Http2SolrClient, cause sprious timeouts on > intranode requests > - > > Key: SOLR-13413 > URL: https://issues.apache.org/jira/browse/SOLR-13413 > Project: Solr > Issue Type: Bug >Affects Versions: 8.0 >Reporter: Hoss Man >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2, 8.1.2 > > Attachments: SOLR-13413.patch, > nocommit_TestDistributedStatsComponentCardinality_trivial-no-http2.patch > > > There is evidence in some recent jenkins failures that we may have some manor > of bug in our http2 client/server code that can cause intra-node query > requests to stall / timeout non-reproducibly. > In at least one known case, forcing the jetty & SolrClients used in the test > to use http1.1, seems to prevent these test failures. -- 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: 8.1.2 bug fix release
Thanks, it's done. On Tue, Jun 25, 2019 at 9:48 PM Đạt Cao Mạnh wrote: > Sure Ignacio! > > On Tue, Jun 25, 2019 at 4:02 PM Ignacio Vera wrote: > >> Hi, >> >> I would like to backport bug fix LUCENE-8775 that fixes some failures in >> the polygon Tessellator when a polygon contain a hole sharing a vertex with >> the polygon. Is that ok? >> >> Thanks, >> >> Ignacio >> >> On Tue, Jun 25, 2019 at 1:39 AM Steve Rowe wrote: >> >>> Hi Đạt, I re-enabled the ASF Jenkins 8.1 jobs. - Steve >>> >>> On Jun 24, 2019, at 8:09 AM, Đạt Cao Mạnh >>> wrote: >>> >>> Hi Uwe, Steve. >>> >>> Can Jenkins on branch_8_1 be resumed for 8.1.2 release? I am not sure >>> how to enable them on https://builds.apache.org/view/L/view/Lucene/ >>> >>> Thanks. >>> >>> On Thu, Jun 13, 2019 at 10:51 AM Ishan Chattopadhyaya < >>> ichattopadhy...@gmail.com> wrote: >>> Sure Dat, sounds good. On Thu, Jun 13, 2019 at 2:11 PM Đạt Cao Mạnh wrote: > > Hi Ishan, > > If upgrade Jetty seems too much for a bug fix release, I will try to upgrade only part that affect SOLR-13413 (one module). Then see how tests will behave then. Does that sound good? > > On Thu, Jun 13, 2019 at 4:51 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: >> >> Have we vetted all other changes to Jetty? Are we sure that they don't introduce a different regression? >> >> On Thu, 13 Jun, 2019, 4:16 AM Kevin Risden, wrote: >>> >>> +1 to 8.1.2 and the Jetty upgrade. FYI Erick created https://issues.apache.org/jira/browse/SOLR-13541 specifically for the Jetty upgrade. >>> >>> Kevin Risden >>> >>> >>> On Wed, Jun 12, 2019 at 4:47 PM Đạt Cao Mạnh < caomanhdat...@gmail.com> wrote: Hi David, yeah sure, that bug fix seems important. I also want to do the upgrade Jetty 9.4.19 for 8.1.2 (fix: SOLR-13413). Do you guys have any objections? On Wed, Jun 12, 2019 at 3:40 PM David Smiley < david.w.smi...@gmail.com> wrote: > > Yes thanks for volunteering. Also, lets get this serious bug fix in: https://issues.apache.org/jira/browse/SOLR-13523 > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Wed, Jun 12, 2019 at 9:27 AM Đạt Cao Mạnh < caomanhdat...@gmail.com> wrote: >> >> Hi, >> >> Just right after the 8.1.1 release has been published we’ve discovered a serious bug in BasicAuthentication which affect all released versions of Solr including 8.0, 8.1, 8.1.1. Details of the bug can be found in SOLR-13510. >> >> I’m volunteering to do this release, if there are no objections, and I’d like to create a RC early next week. >> >> -- >> Best regards, >> Cao Mạnh Đạt >> E-mail: caomanhdat...@gmail.com -- Best regards, Cao Mạnh Đạt E-mail: caomanhdat...@gmail.com > > > > -- > Best regards, > Cao Mạnh Đạt > E-mail: caomanhdat...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> -- >>> *Best regards,* >>> *Cao Mạnh Đạt* >>> *E-mail: caomanhdat...@gmail.com * >>> >>> >>> > > -- > *Best regards,* > *Cao Mạnh Đạt* > *E-mail: caomanhdat...@gmail.com * >
[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=16872920#comment-16872920 ] ASF subversion and git services commented on LUCENE-8775: - Commit d398838f6c909f0e9d52c815500ba6227fca7533 in lucene-solr's branch refs/heads/branch_8_1 from Ignacio Vera [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d398838 ] LUCENE-8775: Compute properly the bridge between a polygon and a hole when sharing a vertex. > 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 >Assignee: Ignacio Vera >Priority: Major > Fix For: master (9.0), 8.2 > > Time Spent: 2.5h > 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
[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=16872919#comment-16872919 ] ASF subversion and git services commented on LUCENE-8775: - Commit 336eff705a98c92e8f8a0478fcf927d0e438fe48 in lucene-solr's branch refs/heads/branch_8_1 from Ignacio Vera [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=336eff7 ] 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 >Assignee: Ignacio Vera >Priority: Major > Fix For: master (9.0), 8.2 > > Time Spent: 2.5h > 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
[jira] [Commented] (SOLR-12638) Support atomic updates of nested/child documents for nested-enabled schema
[ https://issues.apache.org/jira/browse/SOLR-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872898#comment-16872898 ] David Smiley commented on SOLR-12638: - What gnaws at me is that this "UpdateLog.openRealtimeSearcher" is being called optimistically on a new doc because _mbeee_ some future atomic update will need to see it. And not just any type of atomic update; one that is directly to a nested child doc. It's as if we're optimizing for making that future atomic update faster by doing work in advance that will, I think, very rarely actually be used. It's a tragedy, if I'm understanding this right. If I do... then perhaps instead we somehow flag the UpdateLog to tell it that it's realtime searcher is "dirty" so it needs a new one _if_ it's asked for one. Just an idea off the top of my head. > Support atomic updates of nested/child documents for nested-enabled schema > -- > > Key: SOLR-12638 > URL: https://issues.apache.org/jira/browse/SOLR-12638 > Project: Solr > Issue Type: Sub-task >Reporter: mosh >Assignee: David Smiley >Priority: Major > Fix For: 8.1 > > Attachments: SOLR-12638-delete-old-block-no-commit.patch, > SOLR-12638-nocommit.patch, SOLR-12638.patch, SOLR-12638.patch > > Time Spent: 17h 10m > Remaining Estimate: 0h > > I have been toying with the thought of using this transformer in conjunction > with NestedUpdateProcessor and AtomicUpdate to allow SOLR to completely > re-index the entire nested structure. This is just a thought, I am still > thinking about implementation details. Hopefully I will be able to post a > more concrete proposal soon. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12638) Support atomic updates of nested/child documents for nested-enabled schema
[ https://issues.apache.org/jira/browse/SOLR-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872898#comment-16872898 ] David Smiley edited comment on SOLR-12638 at 6/26/19 4:02 AM: -- What gnaws at me is that this "UpdateLog.openRealtimeSearcher" is being called optimistically on a new doc because _mbeee_ some future atomic update will need to see it. And not just any type of atomic update; one that is directly to a nested child doc (something I consider highly experimental). It's as if we're optimizing for making that future atomic update faster by doing work in advance that will, I think, very rarely actually be used. It's a tragedy, if I'm understanding this right. If I do... then perhaps instead we somehow flag the UpdateLog to tell it that it's realtime searcher is "dirty" so it needs a new one _if_ it's asked for one. Just an idea off the top of my head. was (Author: dsmiley): What gnaws at me is that this "UpdateLog.openRealtimeSearcher" is being called optimistically on a new doc because _mbeee_ some future atomic update will need to see it. And not just any type of atomic update; one that is directly to a nested child doc. It's as if we're optimizing for making that future atomic update faster by doing work in advance that will, I think, very rarely actually be used. It's a tragedy, if I'm understanding this right. If I do... then perhaps instead we somehow flag the UpdateLog to tell it that it's realtime searcher is "dirty" so it needs a new one _if_ it's asked for one. Just an idea off the top of my head. > Support atomic updates of nested/child documents for nested-enabled schema > -- > > Key: SOLR-12638 > URL: https://issues.apache.org/jira/browse/SOLR-12638 > Project: Solr > Issue Type: Sub-task >Reporter: mosh >Assignee: David Smiley >Priority: Major > Fix For: 8.1 > > Attachments: SOLR-12638-delete-old-block-no-commit.patch, > SOLR-12638-nocommit.patch, SOLR-12638.patch, SOLR-12638.patch > > Time Spent: 17h 10m > Remaining Estimate: 0h > > I have been toying with the thought of using this transformer in conjunction > with NestedUpdateProcessor and AtomicUpdate to allow SOLR to completely > re-index the entire nested structure. This is just a thought, I am still > thinking about implementation details. Hopefully I will be able to post a > more concrete proposal soon. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8883) CHANGES.txt: Auto add issue categories on new releases
David Smiley created LUCENE-8883: Summary: CHANGES.txt: Auto add issue categories on new releases Key: LUCENE-8883 URL: https://issues.apache.org/jira/browse/LUCENE-8883 Project: Lucene - Core Issue Type: Task Components: general/build Reporter: David Smiley Assignee: David Smiley As I write this, looking at Solr's CHANGES.txt for 8.2 I see we have some sections: "Upgrade Notes", "New Features", "Bug Fixes", and "Other Changes". There is no "Improvements" so no surprise here, the New Features category has issues that ought to be listed as such. I think the order vary as well. I propose that on new releases, the initial state of the next release in CHANGES.txt have these sections. They can easily be removed at the upcoming release if there are no such sections, or they could stay as empty. It seems addVersion.py is the code that sets this up and it could be enhanced. -- 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-8.1 - Build # 63 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.1/63/ 1 tests failed. FAILED: org.apache.solr.client.solrj.io.stream.MathExpressionTest.testGeometricDistribution Error Message: expected:<0.4793> but was:<0.5> Stack Trace: java.lang.AssertionError: expected:<0.4793> but was:<0.5> at __randomizedtesting.SeedInfo.seed([EDB88B72517D6D8C:59198E953AD3B478]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:553) at org.junit.Assert.assertEquals(Assert.java:683) at org.apache.solr.client.solrj.io.stream.MathExpressionTest.testGeometricDistribution(MathExpressionTest.java:3142) 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) Build Log: [...truncated 16663 lines...] [junit4] Suite: org.apache.solr.client.solrj.io.stream.MathExpressionTest [junit4] 2> 216755 INFO
[jira] [Commented] (SOLR-13576) factor out a TopGroupsShardResponseProcessor.fillResultIds method
[
https://issues.apache.org/jira/browse/SOLR-13576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872809#comment-16872809
]
Lucene/Solr QA commented on SOLR-13576:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
3s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 55s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 50m
10s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 57m 1s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13576 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12972851/SOLR-13576.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 / 4d1058d |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/461/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/461/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> factor out a TopGroupsShardResponseProcessor.fillResultIds method
> -
>
> Key: SOLR-13576
> URL: https://issues.apache.org/jira/browse/SOLR-13576
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13576.patch
>
>
> The {{TopGroupsShardResponseProcessor.process}} method e.g.
> [#L54-L215|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L54-L215]
> does quite a few things and factoring out a {{fillResultIds}} (or similarly
> named) method for the logically distinct
> [#L192-L214|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L192-L214]
> portion could help with code comprehension.
--
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-13580) java 13-ea NumberFormat.parse bugs in some Locales, affects ParseNumeric UpdateProcessors when using the 'locale' config option
[
https://issues.apache.org/jira/browse/SOLR-13580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872801#comment-16872801
]
ASF subversion and git services commented on SOLR-13580:
Commit eeed1827d8cc9d934ce1be479a52dfc9e744cc54 in lucene-solr's branch
refs/heads/branch_8x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=eeed182 ]
SOLR-13580: add assumeThat calls to ParsingFieldUpdateProcessorsTest to skip
test methods impacted by java 13-ea bug in NumberFormat.parse()
(cherry picked from commit 583c219183b2bca85936a095727d287c5c28526b)
> java 13-ea NumberFormat.parse bugs in some Locales, affects ParseNumeric
> UpdateProcessors when using the 'locale' config option
> ---
>
> Key: SOLR-13580
> URL: https://issues.apache.org/jira/browse/SOLR-13580
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Labels: Java13
> Attachments: SOLR-13580.patch
>
>
> ParsingFieldUpdateProcessorsTest has uncovered a JDK 13-ea+26 bug when
> dealing with the fr_FR Locale (which may affect other locales as well) which
> causes the grouping seperator ( U+00A0 in fr_FR ) to be ignored when parsing,
> treating them as a termination character -- example: "10 898" is parsed as
> "10" instead of "10898", leaving the " 898" portion of the string unparsed.
> The way the ParseNumeric UpdateProcessors are implemented, the fact that the
> NumbertFormat instance does not recognize the entire string as a Number
> results in the String value being left "as is" in the input documents.
> In ParsingFieldUpdateProcessorsTest this has manifested as jenkins failures
> like this...
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=ParsingFieldUpdateProcessorsTest
> -Dtests.method=testParseFloatNonRootLocale -Dtests.seed=AE6C840917DD963B
> -Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=us -Dtests.timezone=GMT -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.03s |
> ParsingFieldUpdateProcessorsTest.testParseFloatNonRootLocale <<<
>[junit4]> Throwable #1: java.lang.AssertionError
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([AE6C840917DD963B:B5B079D8B7786A26]:0)
>[junit4]> at
> org.apache.solr.update.processor.ParsingFieldUpdateProcessorsTest.testParseFloatNonRootLocale(ParsingFieldUpdateProcessorsTest.java:471)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:567)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:830)
> {noformat}
--
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-13580) java 13-ea NumberFormat.parse bugs in some Locales, affects ParseNumeric UpdateProcessors when using the 'locale' config option
[
https://issues.apache.org/jira/browse/SOLR-13580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872794#comment-16872794
]
ASF subversion and git services commented on SOLR-13580:
Commit 583c219183b2bca85936a095727d287c5c28526b in lucene-solr's branch
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=583c219 ]
SOLR-13580: add assumeThat calls to ParsingFieldUpdateProcessorsTest to skip
test methods impacted by java 13-ea bug in NumberFormat.parse()
> java 13-ea NumberFormat.parse bugs in some Locales, affects ParseNumeric
> UpdateProcessors when using the 'locale' config option
> ---
>
> Key: SOLR-13580
> URL: https://issues.apache.org/jira/browse/SOLR-13580
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Labels: Java13
> Attachments: SOLR-13580.patch
>
>
> ParsingFieldUpdateProcessorsTest has uncovered a JDK 13-ea+26 bug when
> dealing with the fr_FR Locale (which may affect other locales as well) which
> causes the grouping seperator ( U+00A0 in fr_FR ) to be ignored when parsing,
> treating them as a termination character -- example: "10 898" is parsed as
> "10" instead of "10898", leaving the " 898" portion of the string unparsed.
> The way the ParseNumeric UpdateProcessors are implemented, the fact that the
> NumbertFormat instance does not recognize the entire string as a Number
> results in the String value being left "as is" in the input documents.
> In ParsingFieldUpdateProcessorsTest this has manifested as jenkins failures
> like this...
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=ParsingFieldUpdateProcessorsTest
> -Dtests.method=testParseFloatNonRootLocale -Dtests.seed=AE6C840917DD963B
> -Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=us -Dtests.timezone=GMT -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.03s |
> ParsingFieldUpdateProcessorsTest.testParseFloatNonRootLocale <<<
>[junit4]> Throwable #1: java.lang.AssertionError
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([AE6C840917DD963B:B5B079D8B7786A26]:0)
>[junit4]> at
> org.apache.solr.update.processor.ParsingFieldUpdateProcessorsTest.testParseFloatNonRootLocale(ParsingFieldUpdateProcessorsTest.java:471)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:567)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:830)
> {noformat}
--
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-Windows (64bit/jdk1.8.0_201) - Build # 331 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/331/ Java: 64bit/jdk1.8.0_201 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestNRTOpen Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_654869B79ADADC6B-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_654869B79ADADC6B-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_654869B79ADADC6B-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_654869B79ADADC6B-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_654869B79ADADC6B-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_654869B79ADADC6B-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_654869B79ADADC6B-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_654869B79ADADC6B-001 at __randomizedtesting.SeedInfo.seed([654869B79ADADC6B]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:319) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) 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) Build Log: [...truncated 13520 lines...] [junit4] Suite: org.apache.solr.core.TestNRTOpen [junit4] 2> 412087 INFO (SUITE-TestNRTOpen-seed#[654869B79ADADC6B]-worker) [ ] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom [junit4] 2> Creating dataDir: C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_654869B79ADADC6B-001\init-core-data-001 [junit4] 2> 412098 WARN (SUITE-TestNRTOpen-seed#[654869B79ADADC6B]-worker) [ ] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=3 numCloses=3 [junit4] 2> 412098 INFO (SUITE-TestNRTOpen-seed#[654869B79ADADC6B]-worker) [ ] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) w/NUMERIC_DOCVALUES_SYSPROP=false [junit4] 2> 412108 INFO (SUITE-TestNRTOpen-seed#[654869B79ADADC6B]-worker) [ ] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: @org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN) [junit4] 2> 412125 INFO (SUITE-TestNRTOpen-seed#[654869B79ADADC6B]-worker) [ ] o.a.s.SolrTestCaseJ4 initCore [junit4] 2> 412127 INFO (SUITE-TestNRTOpen-seed#[654869B79ADADC6B]-worker) [ ] o.a.s.c.SolrResourceLoader [null] Added 2 libs to classloader, from paths: [/C:/Users/jenkins/workspace/Lucene-Solr-8.x-Windows/solr/core/src/test-files/solr/collection1/lib, /C:/Users/jenkins/workspace/Lucene-Solr-8.x-Windows/solr/core/src/test-files/solr/collection1/lib/classes] [junit4] 2> 41 INFO (SUITE-TestNRTOpen-seed#[654869B79ADADC6B]-worker) [ ] o.a.s.c.SolrConfig Using Lucene MatchVersion: 8.2.0 [junit4] 2> 412241 INFO (SUITE-TestNRTOpen-seed#[654869B79ADADC6B]-worker) [ ] o.a.s.s.IndexSchema [null] Schema name=minimal [junit4] 2> 412248 WARN (SUITE-TestNRTOpen-seed#[654869B79ADADC6B]-worker) [ ] o.a.s.s.IndexSchema no uniqueKey specified in schema. [junit4] 2> 412248
[jira] [Updated] (SOLR-13580) java 13-ea NumberFormat.parse bugs in some Locales, affects ParseNumeric UpdateProcessors when using the 'locale' config option
[
https://issues.apache.org/jira/browse/SOLR-13580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-13580:
Attachment: SOLR-13580.patch
Status: Open (was: Open)
i've already submitted an openjdk ticket, will update this jira once public.
I'm attaching a patch for ParsingFieldUpdateProcessorsTest that:
* improves the test overall by changing all the {{assertTrue(v instanceOf X)}}
patterns to use {{org.hamcrest.core.IsInstanceOf}} so we get decent failure
messages in this type of situation
* adds an {{assumeThat}} to the affected test methods validating that
{{NumberFormat.getInstance(new Locale("fr","FR"));}} behaves as expected when
parsing a number with the french grouping seperator.
..i'll go ahead and commit ASAP to fix the 13-ea jenkins builds once precommit
passes.
> java 13-ea NumberFormat.parse bugs in some Locales, affects ParseNumeric
> UpdateProcessors when using the 'locale' config option
> ---
>
> Key: SOLR-13580
> URL: https://issues.apache.org/jira/browse/SOLR-13580
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Labels: Java13
> Attachments: SOLR-13580.patch
>
>
> ParsingFieldUpdateProcessorsTest has uncovered a JDK 13-ea+26 bug when
> dealing with the fr_FR Locale (which may affect other locales as well) which
> causes the grouping seperator ( U+00A0 in fr_FR ) to be ignored when parsing,
> treating them as a termination character -- example: "10 898" is parsed as
> "10" instead of "10898", leaving the " 898" portion of the string unparsed.
> The way the ParseNumeric UpdateProcessors are implemented, the fact that the
> NumbertFormat instance does not recognize the entire string as a Number
> results in the String value being left "as is" in the input documents.
> In ParsingFieldUpdateProcessorsTest this has manifested as jenkins failures
> like this...
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=ParsingFieldUpdateProcessorsTest
> -Dtests.method=testParseFloatNonRootLocale -Dtests.seed=AE6C840917DD963B
> -Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=us -Dtests.timezone=GMT -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.03s |
> ParsingFieldUpdateProcessorsTest.testParseFloatNonRootLocale <<<
>[junit4]> Throwable #1: java.lang.AssertionError
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([AE6C840917DD963B:B5B079D8B7786A26]:0)
>[junit4]> at
> org.apache.solr.update.processor.ParsingFieldUpdateProcessorsTest.testParseFloatNonRootLocale(ParsingFieldUpdateProcessorsTest.java:471)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:567)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:830)
> {noformat}
--
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-13580) java 13-ea NumberFormat.parse bugs in some Locales, affects ParseNumeric UpdateProcessors when using the 'locale' config option
Hoss Man created SOLR-13580:
---
Summary: java 13-ea NumberFormat.parse bugs in some Locales,
affects ParseNumeric UpdateProcessors when using the 'locale' config option
Key: SOLR-13580
URL: https://issues.apache.org/jira/browse/SOLR-13580
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man
ParsingFieldUpdateProcessorsTest has uncovered a JDK 13-ea+26 bug when dealing
with the fr_FR Locale (which may affect other locales as well) which causes the
grouping seperator ( U+00A0 in fr_FR ) to be ignored when parsing, treating
them as a termination character -- example: "10 898" is parsed as "10" instead
of "10898", leaving the " 898" portion of the string unparsed.
The way the ParseNumeric UpdateProcessors are implemented, the fact that the
NumbertFormat instance does not recognize the entire string as a Number results
in the String value being left "as is" in the input documents.
In ParsingFieldUpdateProcessorsTest this has manifested as jenkins failures
like this...
{noformat}
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=ParsingFieldUpdateProcessorsTest
-Dtests.method=testParseFloatNonRootLocale -Dtests.seed=AE6C840917DD963B
-Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=us
-Dtests.timezone=GMT -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 0.03s |
ParsingFieldUpdateProcessorsTest.testParseFloatNonRootLocale <<<
[junit4]> Throwable #1: java.lang.AssertionError
[junit4]>at
__randomizedtesting.SeedInfo.seed([AE6C840917DD963B:B5B079D8B7786A26]:0)
[junit4]>at
org.apache.solr.update.processor.ParsingFieldUpdateProcessorsTest.testParseFloatNonRootLocale(ParsingFieldUpdateProcessorsTest.java:471)
[junit4]>at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit4]>at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit4]>at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit4]>at
java.base/java.lang.reflect.Method.invoke(Method.java:567)
[junit4]>at java.base/java.lang.Thread.run(Thread.java:830)
{noformat}
--
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-8871) Move Kuromoji DictionaryBuilder tool from src/tools to src/
[
https://issues.apache.org/jira/browse/LUCENE-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872790#comment-16872790
]
Mike Sokolov commented on LUCENE-8871:
--
Thanks for reviewing. FYI I will be delayed a bit in pushing since my primary
laptop died, and I'm traveling, but will get back to this soon.
> Move Kuromoji DictionaryBuilder tool from src/tools to src/
>
>
> Key: LUCENE-8871
> URL: https://issues.apache.org/jira/browse/LUCENE-8871
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Mike Sokolov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently tests in tools directories are not run as part of the normal
> testing done by {{ant test}} - you have to explicitly run {{test-tools}},
> which it seems people don't do (and it might not survivie translation to
> gradle, who knows), so [~rcmuir] suggested we just move the tools into the
> main source tree (under src/java and src/test)
--
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=16872785#comment-16872785
]
ASF subversion and git services commented on SOLR-13105:
Commit 36787032e754b9313f838c567a73736944217b06 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3678703 ]
SOLR-13105: Start add cartogram
> 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
>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-8871) Move Kuromoji DictionaryBuilder tool from src/tools to src/
[
https://issues.apache.org/jira/browse/LUCENE-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872781#comment-16872781
]
Robert Muir commented on LUCENE-8871:
-
+1 from me. I looked thru the PR, it is just as described. Because the code
moved from src/tools it suddenly requires higher standard for the build, and
now tests are executed in every build. I think this is exactly what we want.
Thanks Mike!
> Move Kuromoji DictionaryBuilder tool from src/tools to src/
>
>
> Key: LUCENE-8871
> URL: https://issues.apache.org/jira/browse/LUCENE-8871
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Mike Sokolov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently tests in tools directories are not run as part of the normal
> testing done by {{ant test}} - you have to explicitly run {{test-tools}},
> which it seems people don't do (and it might not survivie translation to
> gradle, who knows), so [~rcmuir] suggested we just move the tools into the
> main source tree (under src/java and src/test)
--
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-NightlyTests-master - Build # 1881 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1881/ 2 tests failed. FAILED: org.apache.lucene.search.TestSimpleSearchEquivalence.testBooleanBoostPropagation Error Message: expected:<5459> but was:<5413> Stack Trace: java.lang.AssertionError: expected:<5459> but was:<5413> at __randomizedtesting.SeedInfo.seed([8F3FBBCBB0E639B8:A3727CBC51027F63]: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.lucene.search.SearchEquivalenceTestBase.assertSameScores(SearchEquivalenceTestBase.java:255) at org.apache.lucene.search.SearchEquivalenceTestBase.assertSameScores(SearchEquivalenceTestBase.java:228) at org.apache.lucene.search.TestSimpleSearchEquivalence.testBooleanBoostPropagation(TestSimpleSearchEquivalence.java:235) 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) 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 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:834) FAILED: org.apache.lucene.search.TestSimpleSearchEquivalence.testBoostQuerySimplification Error Message: expected:<5585> but was:<5568> Stack Trace: java.lang.AssertionError: expected:<5585> but was:<5568> at __randomizedtesting.SeedInfo.seed([8F3FBBCBB0E639B8:7A41280FEB747C7C]:0) at
[jira] [Commented] (SOLR-6853) solr.ManagedSynonymFilterFactory/ManagedStopwordFilterFactory: URLEncoding - Not able to delete Synonyms/Stopwords with special characters
[
https://issues.apache.org/jira/browse/SOLR-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872773#comment-16872773
]
Dzmitry Pisarevich commented on SOLR-6853:
--
Which new platform do you mean ?
> solr.ManagedSynonymFilterFactory/ManagedStopwordFilterFactory: URLEncoding -
> Not able to delete Synonyms/Stopwords with special characters
> --
>
> Key: SOLR-6853
> URL: https://issues.apache.org/jira/browse/SOLR-6853
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
>Affects Versions: 4.10.2
> Environment: Solr 4.10.2 running @ Win7
>Reporter: Tomasz Sulkowski
>Priority: Major
> Labels: ManagedStopwordFilterFactory,
> ManagedSynonymFilterFactory, REST, SOLR
> Attachments: SOLR-6853.patch
>
>
> Hi Guys,
> We're using the SOLR Rest API in order to manage synonyms and stopwords with
> solr.Managed*FilterFactory.
> {_emphasis_}The same applies to stopwords. I am going to explain the synonym
> case only from this point on.{_emphasis_}
> Let us consider the following _schema_analysis_synonyms_en.json managedMap: {
> "xxx#xxx":["xxx#xxx"],
> "xxx%xxx":["xxx%xxx"],
> "xxx/xxx":["xxx/xxx"],
> "xxx:xxx":["xxx:xxx"],
> "xxx;xxx":["xxx;xxx"],
> "xx ":["xx "]
> }
> I can add such synonym to keyword relations using REST API. The problem is
> that I cannot remove/list them as
> http://localhost:8983/solr/collection1/schema/analysis/synonyms/en/
> where is one of the map's key throws 404, or 500 (in case of
> xxx%25xxx):
> java.lang.NullPointerException at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:367)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455) at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:368) at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
> at
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640) at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
> at
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
> at java.lang.Thread.run(Unknown Source)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8882) Add State To QueryVisitor
Atri Sharma created LUCENE-8882: --- Summary: Add State To QueryVisitor Key: LUCENE-8882 URL: https://issues.apache.org/jira/browse/LUCENE-8882 Project: Lucene - Core Issue Type: Improvement Reporter: Atri Sharma QueryVisitor has no state passed in either up or down recursion. This limits the width of decisions that can be taken by visitation of QueryVisitor. For eg, for LUCENE-8881, we need a way to specify is the visitor is a rewriter visitor. This Jira proposes adding a property bag model to QueryVisitor, which can then be referred to by the Query instance being visited by QueryVisitor. -- 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-8878) Provide alternative sorting utility from SortField other than FieldComparator
[
https://issues.apache.org/jira/browse/LUCENE-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872734#comment-16872734
]
Tony Xu commented on LUCENE-8878:
-
> As long as we can keep comparing strings using their ordinals instead of
>their actual values, it should be good.
Is it the case today? I wonder whether the ordinals are comparable across
segments (likely not...); To support this I think the the {{ValueAccessor}} for
{{SortField.Type.String}} needs to return a 3-tuple (segmentId, ord, byteRef)
so the compare logic has enough context to compare ord if possible.
> I was hoping we could soon replace FunctionValues with the new
>oal.search.LongValues/DoubleValues.
+1. I'm still exploring the whole code base but I'm already overwhelmed by the
number of classes for valueSource and values representations which are
descendants of org.apache.lucene.queries.function.ValueSource... Any suggestion
on which class/interface to extend/implement for non-numeric {{ValueAccessor}}?
> Provide alternative sorting utility from SortField other than FieldComparator
> -
>
> Key: LUCENE-8878
> URL: https://issues.apache.org/jira/browse/LUCENE-8878
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: 8.1.1
>Reporter: Tony Xu
>Priority: Major
>
> The `FieldComparator` has many responsibilities and users get all of them at
> once. At high level the main functionalities of `FieldComparator` are
> * Provide LeafFieldComparator
> * Allocate storage for requested number of hits
> * Read the values from DocValues/Custom source etc.
> * Compare two values
> There are two major areas for improvement
> # The logic of reading values and storing them are coupled.
> # User need to specify the size in order to create a `FieldComparator` but
> sometimes the size is unknown upfront.
> # From `FieldComparator`'s API, one can't reason about thread-safety so it
> is not suitable for concurrent search.
> E.g. Can two concurrent thread use the same `FieldComparator` to call
> `getLeafComparator` for two different segments they are working on? In fact,
> almost all existing implementations of `FieldComparator` are not thread-safe.
> The proposal is to enhance `SortField` with two APIs
> # {color:#14892c}int compare(Object v1, Object v2){color} – this is to
> compare two values from different docs for this field
> # {color:#14892c}ValueAccessor newValueAccessor(LeafReaderContext
> leaf){color} – This encapsulate the logic for obtaining the right
> implementation in order to read the field values.
> `ValueAccessor` should be accessed in a similar way as `DocValues` to
> provide the sort value for a document in an advance & read fashion.
> With this API, hopefully we can reduce the memory usage when using
> `FieldComparator` because the users either store the sort values or at least
> the slot number besides the storage allocated by `FieldComparator` itself.
> Ideally, only once copy of the values should be stored.
> The proposed API is also more friendly to concurrent search since it provides
> the `ValueAccessor` per leaf. Although same `ValueAccessor` can't be shared
> if there are more than one thread working on the same leaf, at least they can
> initialize their own `ValueAccessor`.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8881) Query.rewrite Should Move To QueryVisitor
Atri Sharma created LUCENE-8881: --- Summary: Query.rewrite Should Move To QueryVisitor Key: LUCENE-8881 URL: https://issues.apache.org/jira/browse/LUCENE-8881 Project: Lucene - Core Issue Type: Improvement Reporter: Atri Sharma Now that we have QueryVisitor, the rewrite functionality should belong there, since rewrite is essentially a recursive visitation of underlying queries, which sounds exactly as what QueryVisitor is designed to be. -- 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=16872707#comment-16872707
]
ASF subversion and git services commented on SOLR-13105:
Commit bb1d7ff27b95476f14f61d0f212ffdade5659b2f in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=bb1d7ff ]
SOLR-13105: Start statistics vis 5
> 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
>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
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-12.0.1) - Build # 8017 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/8017/
Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseSerialGC
5 tests failed.
FAILED: org.apache.solr.cloud.ReplicationFactorTest.test
Error Message:
Expected rf=2 because batch should have succeeded on 2 replicas (only one
replica should be down) but got 1; clusterState: { "control_collection":{
"pullReplicas":"0", "replicationFactor":"1", "shards":{"shard1":{
"range":"8000-7fff", "state":"active",
"replicas":{"core_node2":{
"core":"control_collection_shard1_replica_n1",
"base_url":"http://127.0.0.1:50799;,
"node_name":"127.0.0.1:50799_", "state":"active",
"type":"NRT", "leader":"true",
"router":{"name":"compositeId"}, "maxShardsPerNode":"1",
"autoAddReplicas":"false", "nrtReplicas":"1", "tlogReplicas":"0"},
"repfacttest_c8n_1x3":{ "pullReplicas":"0", "replicationFactor":"3",
"shards":{"shard1":{ "range":"8000-7fff",
"state":"active", "replicas":{ "core_node4":{
"core":"repfacttest_c8n_1x3_shard1_replica_n1",
"base_url":"http://127.0.0.1:50902;,
"node_name":"127.0.0.1:50902_", "state":"active",
"type":"NRT"}, "core_node5":{
"core":"repfacttest_c8n_1x3_shard1_replica_n3",
"base_url":"http://127.0.0.1:50799;,
"node_name":"127.0.0.1:50799_", "state":"active",
"type":"NRT"}, "core_node6":{
"core":"repfacttest_c8n_1x3_shard1_replica_n2",
"base_url":"http://127.0.0.1:50946;,
"node_name":"127.0.0.1:50946_", "state":"active",
"type":"NRT", "leader":"true",
"router":{"name":"compositeId"}, "maxShardsPerNode":"1",
"autoAddReplicas":"false", "nrtReplicas":"3", "tlogReplicas":"0"},
"collection1":{ "pullReplicas":"0", "replicationFactor":"1",
"shards":{ "shard1":{ "range":"8000-d554",
"state":"active", "replicas":{"core_node5":{
"core":"collection1_shard1_replica_n3",
"base_url":"http://127.0.0.1:50946;,
"node_name":"127.0.0.1:50946_", "state":"active",
"type":"NRT", "leader":"true"}}}, "shard2":{
"range":"d555-2aa9", "state":"active",
"replicas":{"core_node4":{ "core":"collection1_shard2_replica_n1",
"base_url":"http://127.0.0.1:50862;,
"node_name":"127.0.0.1:50862_", "state":"active",
"type":"NRT", "leader":"true"}}}, "shard3":{
"range":"2aaa-7fff", "state":"active",
"replicas":{"core_node6":{ "core":"collection1_shard3_replica_n2",
"base_url":"http://127.0.0.1:50902;,
"node_name":"127.0.0.1:50902_", "state":"active",
"type":"NRT", "leader":"true",
"router":{"name":"compositeId"}, "maxShardsPerNode":"1",
"autoAddReplicas":"false", "nrtReplicas":"1", "tlogReplicas":"0"}}
Stack Trace:
java.lang.AssertionError: Expected rf=2 because batch should have succeeded on
2 replicas (only one replica should be down) but got 1; clusterState: {
"control_collection":{
"pullReplicas":"0",
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node2":{
"core":"control_collection_shard1_replica_n1",
"base_url":"http://127.0.0.1:50799;,
"node_name":"127.0.0.1:50799_",
"state":"active",
"type":"NRT",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"1",
"tlogReplicas":"0"},
"repfacttest_c8n_1x3":{
"pullReplicas":"0",
"replicationFactor":"3",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
"core_node4":{
"core":"repfacttest_c8n_1x3_shard1_replica_n1",
"base_url":"http://127.0.0.1:50902;,
"node_name":"127.0.0.1:50902_",
"state":"active",
"type":"NRT"},
"core_node5":{
"core":"repfacttest_c8n_1x3_shard1_replica_n3",
"base_url":"http://127.0.0.1:50799;,
"node_name":"127.0.0.1:50799_",
"state":"active",
"type":"NRT"},
"core_node6":{
"core":"repfacttest_c8n_1x3_shard1_replica_n2",
"base_url":"http://127.0.0.1:50946;,
"node_name":"127.0.0.1:50946_",
"state":"active",
"type":"NRT",
[jira] [Updated] (SOLR-13577) TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
[
https://issues.apache.org/jira/browse/SOLR-13577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13577:
Attachment: SOLR-13577.patch
> TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
> ---
>
> Key: SOLR-13577
> URL: https://issues.apache.org/jira/browse/SOLR-13577
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: 8016-consoleText.zip, SOLR-13577.patch,
> SOLR-13577.patch, SOLR-13577.patch, screenshot-1.png
>
>
> It's seems like clear test failures. Failed 6 times in a row at lines 682, 684
> {quote}
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 1 build (Since Failed#8011 )
> Took 6 sec.
> Error Message
> null
> Stacktrace
> java.lang.NumberFormatException: null
> at
> __randomizedtesting.SeedInfo.seed([6AB4ECC957E5CCA2:B243282DFC3E0EFE]:0)
> at java.base/java.lang.Integer.parseInt(Integer.java:614)
> at java.base/java.lang.Integer.parseInt(Integer.java:770)
> at
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:682)
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 3 builds (Since Failed#8011 )
> Took 7.5 sec.
> Stacktrace
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([E88092B4017D2D3D:30775650AAA6EF61]: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.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:684)
> {quote}
> !screenshot-1.png!
--
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] [Assigned] (SOLR-13577) TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
[
https://issues.apache.org/jira/browse/SOLR-13577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev reassigned SOLR-13577:
---
Assignee: Mikhail Khludnev
> TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
> ---
>
> Key: SOLR-13577
> URL: https://issues.apache.org/jira/browse/SOLR-13577
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: 8016-consoleText.zip, SOLR-13577.patch,
> SOLR-13577.patch, SOLR-13577.patch, screenshot-1.png
>
>
> It's seems like clear test failures. Failed 6 times in a row at lines 682, 684
> {quote}
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 1 build (Since Failed#8011 )
> Took 6 sec.
> Error Message
> null
> Stacktrace
> java.lang.NumberFormatException: null
> at
> __randomizedtesting.SeedInfo.seed([6AB4ECC957E5CCA2:B243282DFC3E0EFE]:0)
> at java.base/java.lang.Integer.parseInt(Integer.java:614)
> at java.base/java.lang.Integer.parseInt(Integer.java:770)
> at
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:682)
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 3 builds (Since Failed#8011 )
> Took 7.5 sec.
> Stacktrace
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([E88092B4017D2D3D:30775650AAA6EF61]: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.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:684)
> {quote}
> !screenshot-1.png!
--
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-8865) Use incoming thread for execution if IndexSearcher has an executor
[ https://issues.apache.org/jira/browse/LUCENE-8865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872690#comment-16872690 ] Simon Willnauer commented on LUCENE-8865: - [~hypothesisx86] I didn't run any benchmarks. maybe [~mikemccand] can provide infos if there are improvements. > Use incoming thread for execution if IndexSearcher has an executor > --- > > Key: LUCENE-8865 > URL: https://issues.apache.org/jira/browse/LUCENE-8865 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Simon Willnauer >Priority: Major > Fix For: master (9.0), 8.2 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Today we don't utilize the incoming thread for a search when IndexSearcher > has an executor. This thread is only idleing but can be used to execute a > search > once all other collectors are dispatched. -- 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-12866) Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore failures
[
https://issues.apache.org/jira/browse/SOLR-12866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-12866:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore
> failures
> -
>
> Key: SOLR-12866
> URL: https://issues.apache.org/jira/browse/SOLR-12866
> Project: Solr
> Issue Type: Task
>Reporter: Steve Rowe
>Assignee: Varun Thacker
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-12866.patch, SOLR-12866.patch, SOLR-12866.patch,
> SOLR-12866.patch, screenshot-1.png
>
>
> From [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/185/],
> both tests failed 10/10 iterations for me on branch_7x with the seed:
> {noformat}
> Checking out Revision 37fdcb02d87ec44293ec4942c75a3cb709c45418
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestLocalFSCloudBackupRestore -Dtests.method=test
> -Dtests.seed=3CD4284489C09DB4 -Dtests.multiplier=2 -Dtests.slow=true
> -Dtests.badapples=true -Dtests.locale=mk-MK
> -Dtests.timezone=Pacific/Kiritimati -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 10.8s J2 | TestLocalFSCloudBackupRestore.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Node
> 127.0.0.1:43864_solr has 3 replicas. Expected num replicas : 2. state:
>[junit4]>
> DocCollection(backuprestore_restored//collections/backuprestore_restored/state.json/9)={
>[junit4]> "pullReplicas":0,
>[junit4]> "replicationFactor":1,
>[junit4]> "shards":{
>[junit4]> "shard2":{
>[junit4]> "range":"0-7fff",
>[junit4]> "state":"active",
>[junit4]> "replicas":{"core_node62":{
>[junit4]> "core":"backuprestore_restored_shard2_replica_n61",
>[junit4]> "base_url":"https://127.0.0.1:43864/solr;,
>[junit4]> "node_name":"127.0.0.1:43864_solr",
>[junit4]> "state":"active",
>[junit4]> "type":"NRT",
>[junit4]> "force_set_state":"false",
>[junit4]> "leader":"true"}},
>[junit4]> "stateTimestamp":"1539459703266853250"},
>[junit4]> "shard1_1":{
>[junit4]> "range":"c000-",
>[junit4]> "state":"active",
>[junit4]> "replicas":{"core_node64":{
>[junit4]>
> "core":"backuprestore_restored_shard1_1_replica_n63",
>[junit4]> "base_url":"https://127.0.0.1:43864/solr;,
>[junit4]> "node_name":"127.0.0.1:43864_solr",
>[junit4]> "state":"active",
>[junit4]> "type":"NRT",
>[junit4]> "force_set_state":"false",
>[junit4]> "leader":"true"}},
>[junit4]> "stateTimestamp":"1539459703266887720"},
>[junit4]> "shard1_0":{
>[junit4]> "range":"8000-bfff",
>[junit4]> "state":"active",
>[junit4]> "replicas":{"core_node66":{
>[junit4]>
> "core":"backuprestore_restored_shard1_0_replica_n65",
>[junit4]> "base_url":"https://127.0.0.1:43864/solr;,
>[junit4]> "node_name":"127.0.0.1:43864_solr",
>[junit4]> "state":"active",
>[junit4]> "type":"NRT",
>[junit4]> "force_set_state":"false",
>[junit4]> "leader":"true"}},
>[junit4]> "stateTimestamp":"1539459703266910800"}},
>[junit4]> "router":{
>[junit4]> "name":"compositeId",
>[junit4]> "field":"shard_s"},
>[junit4]> "maxShardsPerNode":"-1",
>[junit4]> "autoAddReplicas":"false",
>[junit4]> "nrtReplicas":1,
>[junit4]> "tlogReplicas":0}
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([3CD4284489C09DB4:B480179E273CF04C]:0)
>[junit4]> at
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.lambda$testBackupAndRestore$1(AbstractCloudBackupRestoreTestCase.java:339)
>[junit4]> at java.util.HashMap.forEach(HashMap.java:1289)
>[junit4]> at
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.testBackupAndRestore(AbstractCloudBackupRestoreTestCase.java:338)
>[junit4]> at
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.test(AbstractCloudBackupRestoreTestCase.java:144)
>[junit4]> at
> org.apache.solr.cloud.api.collections.TestLocalFSCloudBackupRestore.test(TestLocalFSCloudBackupRestore.java:64)
>
[jira] [Updated] (SOLR-12866) Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore failures
[
https://issues.apache.org/jira/browse/SOLR-12866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-12866:
Fix Version/s: 8.2
> Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore
> failures
> -
>
> Key: SOLR-12866
> URL: https://issues.apache.org/jira/browse/SOLR-12866
> Project: Solr
> Issue Type: Task
>Reporter: Steve Rowe
>Assignee: Varun Thacker
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-12866.patch, SOLR-12866.patch, SOLR-12866.patch,
> SOLR-12866.patch, screenshot-1.png
>
>
> From [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/185/],
> both tests failed 10/10 iterations for me on branch_7x with the seed:
> {noformat}
> Checking out Revision 37fdcb02d87ec44293ec4942c75a3cb709c45418
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestLocalFSCloudBackupRestore -Dtests.method=test
> -Dtests.seed=3CD4284489C09DB4 -Dtests.multiplier=2 -Dtests.slow=true
> -Dtests.badapples=true -Dtests.locale=mk-MK
> -Dtests.timezone=Pacific/Kiritimati -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 10.8s J2 | TestLocalFSCloudBackupRestore.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Node
> 127.0.0.1:43864_solr has 3 replicas. Expected num replicas : 2. state:
>[junit4]>
> DocCollection(backuprestore_restored//collections/backuprestore_restored/state.json/9)={
>[junit4]> "pullReplicas":0,
>[junit4]> "replicationFactor":1,
>[junit4]> "shards":{
>[junit4]> "shard2":{
>[junit4]> "range":"0-7fff",
>[junit4]> "state":"active",
>[junit4]> "replicas":{"core_node62":{
>[junit4]> "core":"backuprestore_restored_shard2_replica_n61",
>[junit4]> "base_url":"https://127.0.0.1:43864/solr;,
>[junit4]> "node_name":"127.0.0.1:43864_solr",
>[junit4]> "state":"active",
>[junit4]> "type":"NRT",
>[junit4]> "force_set_state":"false",
>[junit4]> "leader":"true"}},
>[junit4]> "stateTimestamp":"1539459703266853250"},
>[junit4]> "shard1_1":{
>[junit4]> "range":"c000-",
>[junit4]> "state":"active",
>[junit4]> "replicas":{"core_node64":{
>[junit4]>
> "core":"backuprestore_restored_shard1_1_replica_n63",
>[junit4]> "base_url":"https://127.0.0.1:43864/solr;,
>[junit4]> "node_name":"127.0.0.1:43864_solr",
>[junit4]> "state":"active",
>[junit4]> "type":"NRT",
>[junit4]> "force_set_state":"false",
>[junit4]> "leader":"true"}},
>[junit4]> "stateTimestamp":"1539459703266887720"},
>[junit4]> "shard1_0":{
>[junit4]> "range":"8000-bfff",
>[junit4]> "state":"active",
>[junit4]> "replicas":{"core_node66":{
>[junit4]>
> "core":"backuprestore_restored_shard1_0_replica_n65",
>[junit4]> "base_url":"https://127.0.0.1:43864/solr;,
>[junit4]> "node_name":"127.0.0.1:43864_solr",
>[junit4]> "state":"active",
>[junit4]> "type":"NRT",
>[junit4]> "force_set_state":"false",
>[junit4]> "leader":"true"}},
>[junit4]> "stateTimestamp":"1539459703266910800"}},
>[junit4]> "router":{
>[junit4]> "name":"compositeId",
>[junit4]> "field":"shard_s"},
>[junit4]> "maxShardsPerNode":"-1",
>[junit4]> "autoAddReplicas":"false",
>[junit4]> "nrtReplicas":1,
>[junit4]> "tlogReplicas":0}
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([3CD4284489C09DB4:B480179E273CF04C]:0)
>[junit4]> at
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.lambda$testBackupAndRestore$1(AbstractCloudBackupRestoreTestCase.java:339)
>[junit4]> at java.util.HashMap.forEach(HashMap.java:1289)
>[junit4]> at
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.testBackupAndRestore(AbstractCloudBackupRestoreTestCase.java:338)
>[junit4]> at
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.test(AbstractCloudBackupRestoreTestCase.java:144)
>[junit4]> at
> org.apache.solr.cloud.api.collections.TestLocalFSCloudBackupRestore.test(TestLocalFSCloudBackupRestore.java:64)
>[junit4]> at
[jira] [Commented] (SOLR-12866) Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore failures
[
https://issues.apache.org/jira/browse/SOLR-12866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872683#comment-16872683
]
Mikhail Khludnev commented on SOLR-12866:
-
passed
https://builds.apache.org/job/Lucene-Solr-Tests-master/lastSuccessfulBuild/testReport/org.apache.solr.cloud.api.collections/TestHdfsCloudBackupRestore/
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24287/testReport/org.apache.solr.cloud.api.collections/TestHdfsCloudBackupRestore/
> Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore
> failures
> -
>
> Key: SOLR-12866
> URL: https://issues.apache.org/jira/browse/SOLR-12866
> Project: Solr
> Issue Type: Task
>Reporter: Steve Rowe
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12866.patch, SOLR-12866.patch, SOLR-12866.patch,
> SOLR-12866.patch, screenshot-1.png
>
>
> From [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/185/],
> both tests failed 10/10 iterations for me on branch_7x with the seed:
> {noformat}
> Checking out Revision 37fdcb02d87ec44293ec4942c75a3cb709c45418
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestLocalFSCloudBackupRestore -Dtests.method=test
> -Dtests.seed=3CD4284489C09DB4 -Dtests.multiplier=2 -Dtests.slow=true
> -Dtests.badapples=true -Dtests.locale=mk-MK
> -Dtests.timezone=Pacific/Kiritimati -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 10.8s J2 | TestLocalFSCloudBackupRestore.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Node
> 127.0.0.1:43864_solr has 3 replicas. Expected num replicas : 2. state:
>[junit4]>
> DocCollection(backuprestore_restored//collections/backuprestore_restored/state.json/9)={
>[junit4]> "pullReplicas":0,
>[junit4]> "replicationFactor":1,
>[junit4]> "shards":{
>[junit4]> "shard2":{
>[junit4]> "range":"0-7fff",
>[junit4]> "state":"active",
>[junit4]> "replicas":{"core_node62":{
>[junit4]> "core":"backuprestore_restored_shard2_replica_n61",
>[junit4]> "base_url":"https://127.0.0.1:43864/solr;,
>[junit4]> "node_name":"127.0.0.1:43864_solr",
>[junit4]> "state":"active",
>[junit4]> "type":"NRT",
>[junit4]> "force_set_state":"false",
>[junit4]> "leader":"true"}},
>[junit4]> "stateTimestamp":"1539459703266853250"},
>[junit4]> "shard1_1":{
>[junit4]> "range":"c000-",
>[junit4]> "state":"active",
>[junit4]> "replicas":{"core_node64":{
>[junit4]>
> "core":"backuprestore_restored_shard1_1_replica_n63",
>[junit4]> "base_url":"https://127.0.0.1:43864/solr;,
>[junit4]> "node_name":"127.0.0.1:43864_solr",
>[junit4]> "state":"active",
>[junit4]> "type":"NRT",
>[junit4]> "force_set_state":"false",
>[junit4]> "leader":"true"}},
>[junit4]> "stateTimestamp":"1539459703266887720"},
>[junit4]> "shard1_0":{
>[junit4]> "range":"8000-bfff",
>[junit4]> "state":"active",
>[junit4]> "replicas":{"core_node66":{
>[junit4]>
> "core":"backuprestore_restored_shard1_0_replica_n65",
>[junit4]> "base_url":"https://127.0.0.1:43864/solr;,
>[junit4]> "node_name":"127.0.0.1:43864_solr",
>[junit4]> "state":"active",
>[junit4]> "type":"NRT",
>[junit4]> "force_set_state":"false",
>[junit4]> "leader":"true"}},
>[junit4]> "stateTimestamp":"1539459703266910800"}},
>[junit4]> "router":{
>[junit4]> "name":"compositeId",
>[junit4]> "field":"shard_s"},
>[junit4]> "maxShardsPerNode":"-1",
>[junit4]> "autoAddReplicas":"false",
>[junit4]> "nrtReplicas":1,
>[junit4]> "tlogReplicas":0}
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([3CD4284489C09DB4:B480179E273CF04C]:0)
>[junit4]> at
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.lambda$testBackupAndRestore$1(AbstractCloudBackupRestoreTestCase.java:339)
>[junit4]> at java.util.HashMap.forEach(HashMap.java:1289)
>[junit4]> at
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.testBackupAndRestore(AbstractCloudBackupRestoreTestCase.java:338)
>[junit4]> at
>
[jira] [Assigned] (SOLR-12866) Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore failures
[
https://issues.apache.org/jira/browse/SOLR-12866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev reassigned SOLR-12866:
---
Assignee: Mikhail Khludnev (was: Varun Thacker)
> Reproducing TestLocalFSCloudBackupRestore and TestHdfsCloudBackupRestore
> failures
> -
>
> Key: SOLR-12866
> URL: https://issues.apache.org/jira/browse/SOLR-12866
> Project: Solr
> Issue Type: Task
>Reporter: Steve Rowe
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-12866.patch, SOLR-12866.patch, SOLR-12866.patch,
> SOLR-12866.patch, screenshot-1.png
>
>
> From [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/185/],
> both tests failed 10/10 iterations for me on branch_7x with the seed:
> {noformat}
> Checking out Revision 37fdcb02d87ec44293ec4942c75a3cb709c45418
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestLocalFSCloudBackupRestore -Dtests.method=test
> -Dtests.seed=3CD4284489C09DB4 -Dtests.multiplier=2 -Dtests.slow=true
> -Dtests.badapples=true -Dtests.locale=mk-MK
> -Dtests.timezone=Pacific/Kiritimati -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 10.8s J2 | TestLocalFSCloudBackupRestore.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Node
> 127.0.0.1:43864_solr has 3 replicas. Expected num replicas : 2. state:
>[junit4]>
> DocCollection(backuprestore_restored//collections/backuprestore_restored/state.json/9)={
>[junit4]> "pullReplicas":0,
>[junit4]> "replicationFactor":1,
>[junit4]> "shards":{
>[junit4]> "shard2":{
>[junit4]> "range":"0-7fff",
>[junit4]> "state":"active",
>[junit4]> "replicas":{"core_node62":{
>[junit4]> "core":"backuprestore_restored_shard2_replica_n61",
>[junit4]> "base_url":"https://127.0.0.1:43864/solr;,
>[junit4]> "node_name":"127.0.0.1:43864_solr",
>[junit4]> "state":"active",
>[junit4]> "type":"NRT",
>[junit4]> "force_set_state":"false",
>[junit4]> "leader":"true"}},
>[junit4]> "stateTimestamp":"1539459703266853250"},
>[junit4]> "shard1_1":{
>[junit4]> "range":"c000-",
>[junit4]> "state":"active",
>[junit4]> "replicas":{"core_node64":{
>[junit4]>
> "core":"backuprestore_restored_shard1_1_replica_n63",
>[junit4]> "base_url":"https://127.0.0.1:43864/solr;,
>[junit4]> "node_name":"127.0.0.1:43864_solr",
>[junit4]> "state":"active",
>[junit4]> "type":"NRT",
>[junit4]> "force_set_state":"false",
>[junit4]> "leader":"true"}},
>[junit4]> "stateTimestamp":"1539459703266887720"},
>[junit4]> "shard1_0":{
>[junit4]> "range":"8000-bfff",
>[junit4]> "state":"active",
>[junit4]> "replicas":{"core_node66":{
>[junit4]>
> "core":"backuprestore_restored_shard1_0_replica_n65",
>[junit4]> "base_url":"https://127.0.0.1:43864/solr;,
>[junit4]> "node_name":"127.0.0.1:43864_solr",
>[junit4]> "state":"active",
>[junit4]> "type":"NRT",
>[junit4]> "force_set_state":"false",
>[junit4]> "leader":"true"}},
>[junit4]> "stateTimestamp":"1539459703266910800"}},
>[junit4]> "router":{
>[junit4]> "name":"compositeId",
>[junit4]> "field":"shard_s"},
>[junit4]> "maxShardsPerNode":"-1",
>[junit4]> "autoAddReplicas":"false",
>[junit4]> "nrtReplicas":1,
>[junit4]> "tlogReplicas":0}
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([3CD4284489C09DB4:B480179E273CF04C]:0)
>[junit4]> at
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.lambda$testBackupAndRestore$1(AbstractCloudBackupRestoreTestCase.java:339)
>[junit4]> at java.util.HashMap.forEach(HashMap.java:1289)
>[junit4]> at
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.testBackupAndRestore(AbstractCloudBackupRestoreTestCase.java:338)
>[junit4]> at
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.test(AbstractCloudBackupRestoreTestCase.java:144)
>[junit4]> at
> org.apache.solr.cloud.api.collections.TestLocalFSCloudBackupRestore.test(TestLocalFSCloudBackupRestore.java:64)
>
[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=16872664#comment-16872664
]
ASF subversion and git services commented on SOLR-13105:
Commit 65e68d3cda877b3ff31feeb1ff15be4d66da461d in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=65e68d3 ]
SOLR-13105: Start statistics vis 4
> 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
>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
Re: 8.1.2 bug fix release
Sure Ignacio! On Tue, Jun 25, 2019 at 4:02 PM Ignacio Vera wrote: > Hi, > > I would like to backport bug fix LUCENE-8775 that fixes some failures in > the polygon Tessellator when a polygon contain a hole sharing a vertex with > the polygon. Is that ok? > > Thanks, > > Ignacio > > On Tue, Jun 25, 2019 at 1:39 AM Steve Rowe wrote: > >> Hi Đạt, I re-enabled the ASF Jenkins 8.1 jobs. - Steve >> >> On Jun 24, 2019, at 8:09 AM, Đạt Cao Mạnh >> wrote: >> >> Hi Uwe, Steve. >> >> Can Jenkins on branch_8_1 be resumed for 8.1.2 release? I am not sure how >> to enable them on https://builds.apache.org/view/L/view/Lucene/ >> >> Thanks. >> >> On Thu, Jun 13, 2019 at 10:51 AM Ishan Chattopadhyaya < >> ichattopadhy...@gmail.com> wrote: >> >>> Sure Dat, sounds good. >>> >>> On Thu, Jun 13, 2019 at 2:11 PM Đạt Cao Mạnh >>> wrote: >>> > >>> > Hi Ishan, >>> > >>> > If upgrade Jetty seems too much for a bug fix release, I will try to >>> upgrade only part that affect SOLR-13413 (one module). Then see how tests >>> will behave then. Does that sound good? >>> > >>> > On Thu, Jun 13, 2019 at 4:51 AM Ishan Chattopadhyaya < >>> ichattopadhy...@gmail.com> wrote: >>> >> >>> >> Have we vetted all other changes to Jetty? Are we sure that they >>> don't introduce a different regression? >>> >> >>> >> On Thu, 13 Jun, 2019, 4:16 AM Kevin Risden, >>> wrote: >>> >>> >>> >>> +1 to 8.1.2 and the Jetty upgrade. FYI Erick created >>> https://issues.apache.org/jira/browse/SOLR-13541 specifically for the >>> Jetty upgrade. >>> >>> >>> >>> Kevin Risden >>> >>> >>> >>> >>> >>> On Wed, Jun 12, 2019 at 4:47 PM Đạt Cao Mạnh < >>> caomanhdat...@gmail.com> wrote: >>> >>> Hi David, yeah sure, that bug fix seems important. >>> I also want to do the upgrade Jetty 9.4.19 for 8.1.2 (fix: >>> SOLR-13413). Do you guys have any objections? >>> >>> On Wed, Jun 12, 2019 at 3:40 PM David Smiley < >>> david.w.smi...@gmail.com> wrote: >>> > >>> > Yes thanks for volunteering. Also, lets get this serious bug fix >>> in: https://issues.apache.org/jira/browse/SOLR-13523 >>> > >>> > ~ David Smiley >>> > Apache Lucene/Solr Search Developer >>> > http://www.linkedin.com/in/davidwsmiley >>> > >>> > >>> > On Wed, Jun 12, 2019 at 9:27 AM Đạt Cao Mạnh < >>> caomanhdat...@gmail.com> wrote: >>> >> >>> >> Hi, >>> >> >>> >> Just right after the 8.1.1 release has been published we’ve >>> discovered a serious bug in BasicAuthentication which affect all released >>> versions of Solr including 8.0, 8.1, 8.1.1. Details of the bug can be found >>> in SOLR-13510. >>> >> >>> >> I’m volunteering to do this release, if there are no objections, >>> and I’d like to create a RC early next week. >>> >> >>> >> -- >>> >> Best regards, >>> >> Cao Mạnh Đạt >>> >> E-mail: caomanhdat...@gmail.com >>> >>> >>> >>> -- >>> Best regards, >>> Cao Mạnh Đạt >>> E-mail: caomanhdat...@gmail.com >>> > >>> > >>> > >>> > -- >>> > Best regards, >>> > Cao Mạnh Đạt >>> > E-mail: caomanhdat...@gmail.com >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >> >> -- >> *Best regards,* >> *Cao Mạnh Đạt* >> *E-mail: caomanhdat...@gmail.com * >> >> >> -- *Best regards,* *Cao Mạnh Đạt* *E-mail: caomanhdat...@gmail.com *
[GitHub] [lucene-solr] nknize commented on issue #726: LUCENE-8632: New XYShape Field and Queries for indexing and searching general cartesian geometries
nknize commented on issue #726: LUCENE-8632: New XYShape Field and Queries for indexing and searching general cartesian geometries URL: https://github.com/apache/lucene-solr/pull/726#issuecomment-505593978 @iverase +1 for renaming `Polygon` and `Line` to `LatLonPolygon` and `LatLonLine` . It's cleaner that way. 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] (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=16872633#comment-16872633
]
ASF subversion and git services commented on SOLR-13105:
Commit df63e75b6e31c6719dbd73489965922dce721a61 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=df63e75 ]
SOLR-13105: Start statistics vis 3
> 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
>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-8870) Support numeric value in Field class
[
https://issues.apache.org/jira/browse/LUCENE-8870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872601#comment-16872601
]
Namgyu Kim commented on LUCENE-8870:
Thank you for your reply! [~jpountz] :D
When I wrote a patch, the biggest advantage that I think is the FieldType
conversion for Numeric types.
Of course, it is not recommended way(it is already mentioned Expert in
Javadoc), but it can give users FieldType customization.
ex)
Currently NumericDocValuesField does not support the option for stored.
So users need to add a separate StoredField.
If we provide this patch, the user can get the characteristics of
NumericDocValuesField and StoredField in a single field.
{code:java}
FieldType type = new FieldType();
type.setStored(true);
type.setDocValuesType(DocValuesType.NUMERIC);
type.freeze();
Document doc = new Document();
Field field = new Field("number", 1234, type);
doc.add(field);
indexWriter.addDocument(doc);
{code}
After that, we can use methods such as
{code:java}
Sort sort = new Sort();
sort.setSort(new SortField("number", SortField.Type.INT));
{code}
and
{code:java}
doc.get("number");
{code}
in the "number" field.
> Support numeric value in Field class
>
>
> Key: LUCENE-8870
> URL: https://issues.apache.org/jira/browse/LUCENE-8870
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Namgyu Kim
>Priority: Major
> Attachments: LUCENE-8870.patch
>
>
> I checked the following comment in Field class.
> {code:java}
> // TODO: allow direct construction of int, long, float, double value too..?
> {code}
> We already have some fields like IntPoint and StoredField, but I think it's
> okay.
> The test cases are set in the TestField class.
--
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-8855) Add Accountable to Query implementations
[
https://issues.apache.org/jira/browse/LUCENE-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872575#comment-16872575
]
Andrzej Bialecki commented on LUCENE-8855:
---
Updated patch:
* removed left-over code from BytesRefHash
* use UNKNOWN_DEFAULT_RAM_BYTES_USED = 256 for estimating unknown Objects.
> Add Accountable to Query implementations
>
>
> Key: LUCENE-8855
> URL: https://issues.apache.org/jira/browse/LUCENE-8855
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: LUCENE-8855.patch, LUCENE-8855.patch, LUCENE-8855.patch,
> LUCENE-8855.patch, LUCENE-8855.patch
>
>
> Query implementations should also support {{Accountable}} API in order to
> monitor the memory consumption e.g. in caches where either keys or values are
> {{Query}} instances.
--
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-8855) Add Accountable to Query implementations
[
https://issues.apache.org/jira/browse/LUCENE-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki updated LUCENE-8855:
--
Attachment: LUCENE-8855.patch
> Add Accountable to Query implementations
>
>
> Key: LUCENE-8855
> URL: https://issues.apache.org/jira/browse/LUCENE-8855
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: LUCENE-8855.patch, LUCENE-8855.patch, LUCENE-8855.patch,
> LUCENE-8855.patch, LUCENE-8855.patch
>
>
> Query implementations should also support {{Accountable}} API in order to
> monitor the memory consumption e.g. in caches where either keys or values are
> {{Query}} instances.
--
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-8855) Add Accountable to Query implementations
[
https://issues.apache.org/jira/browse/LUCENE-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872558#comment-16872558
]
Andrzej Bialecki commented on LUCENE-8855:
---
{quote}Could we make it fail if it encounters an unknown object
{quote}
It's not a strict calculation anyway so I don't think we should fail, esp.
since some queries (LTR) may legitimately contain arbitrary parameters - we
could simply assume a larger default value for unknown objects, equivalent eg.
to a class with a few primitive and a few moderately-sized String fields (256
bytes? 384 bytes?).
> Add Accountable to Query implementations
>
>
> Key: LUCENE-8855
> URL: https://issues.apache.org/jira/browse/LUCENE-8855
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: LUCENE-8855.patch, LUCENE-8855.patch, LUCENE-8855.patch,
> LUCENE-8855.patch
>
>
> Query implementations should also support {{Accountable}} API in order to
> monitor the memory consumption e.g. in caches where either keys or values are
> {{Query}} instances.
--
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=16872551#comment-16872551
]
ASF subversion and git services commented on SOLR-13105:
Commit 601cb1518622b4488039471b2c95582e7e488f1a in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=601cb15 ]
SOLR-13105: Start statistics vis 2
> 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
>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-8811) Add maximum clause count check to IndexSearcher rather than BooleanQuery
[ https://issues.apache.org/jira/browse/LUCENE-8811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872550#comment-16872550 ] Atri Sharma commented on LUCENE-8811: - Any chance we could push this one? Happy to make any changes > Add maximum clause count check to IndexSearcher rather than BooleanQuery > > > Key: LUCENE-8811 > URL: https://issues.apache.org/jira/browse/LUCENE-8811 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Attachments: LUCENE-8811.patch, LUCENE-8811.patch, LUCENE-8811.patch, > LUCENE-8811.patch, LUCENE-8811.patch, LUCENE-8811.patch > > > Currently we only check whether boolean queries have too many clauses. > However there are other ways that queries may have too many clauses, for > instance if you have boolean queries that have themselves inner boolean > queries. > Could we use the new Query visitor API to move this check from BooleanQuery > to IndexSearcher in order to make this check more consistent across queries? > See for instance LUCENE-8810 where a rewrite rule caused the maximum clause > count to be hit even though the total number of leaf queries remained the > same. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8880) Add a TopDocsCollector which does not sort by score
Atri Sharma created LUCENE-8880: --- Summary: Add a TopDocsCollector which does not sort by score Key: LUCENE-8880 URL: https://issues.apache.org/jira/browse/LUCENE-8880 Project: Lucene - Core Issue Type: Improvement Reporter: Atri Sharma We assume that the user cares about the underlying hits being ordered by score. This Jira explores adding a collector which does not make this guarantee, thus not using priority queue as the collection data structure. This should help with large hits case, where the heap’s rebalancing can become a bottleneck -- 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-8877) TopDocsCollector Should Not Depend on Priority Queue
[ https://issues.apache.org/jira/browse/LUCENE-8877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872544#comment-16872544 ] Atri Sharma commented on LUCENE-8877: - Any thoughts on this? I am envisioning eventually getting to a state where the underlying data structure used is opaque to IndexSearcher API. This should allow an abstraction with high degree of flexibility > TopDocsCollector Should Not Depend on Priority Queue > > > Key: LUCENE-8877 > URL: https://issues.apache.org/jira/browse/LUCENE-8877 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Atri Sharma >Priority: Major > > TopDocsCollector is tightly coupled to the notion of priority queue, which is > not necessarily a good abstraction to have since the collector really just > needs an interface to iterate on and hold docID and score, with possibly > shard indexes. > > We should rewrite this to a more simplistic interface with priority queue > being the default implementation -- 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-13528) Rate limiting in Solr
[ https://issues.apache.org/jira/browse/SOLR-13528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872543#comment-16872543 ] David Smiley commented on SOLR-13528: - Note that there is important open-source discussion in SOLR-7344 over years that should be considered. I linked to it from that issue to help keep the watchers there be aware of this issue. The main take-away I got was that a QOS filter of some sort would be useful, be it one Jetty has or one [~hgadre] has. > Rate limiting in Solr > - > > Key: SOLR-13528 > URL: https://issues.apache.org/jira/browse/SOLR-13528 > Project: Solr > Issue Type: New Feature >Reporter: Anshum Gupta >Priority: Major > > In relation to SOLR-13527, Solr also needs a way to throttle update and > search requests based on usage metrics. This is the umbrella JIRA for both > update and search rate limiting. -- 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-13574) harden tests that fail (usually NPE) during After/AfterClas methods if there is an assumption violation in Before/BeforeClass methods
[
https://issues.apache.org/jira/browse/SOLR-13574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-13574:
Attachment: SOLR-13574.patch
Status: Open (was: Open)
Ok, here's what i've got ... i's a big patch, but it's mainly lots of little
stuff like this in After/AfterClass metods...
{noformat}
-solrClient.close();
+if (null != solrClient) {
+ solrClient.close();
+ solrClient = null;
+}
{noformat}
To "test the tests" I also added this to {{SolrTestCase}} ...
{code}
/**
* Special hook for sanity checking if any tests trigger failures when an
* Assumption failure occures in a {@link BeforeClass} method
* @lucene.internal
*/
@BeforeClass
public static void checkSyspropForceBeforeClassAssumptionFailure() {
// ant test -Dargs="-Dtests.force.assumption.failure.beforeclass=true"
final String PROP = "tests.force.assumption.failure.beforeclass";
assumeFalse(PROP + " == true",
systemPropertyAsBoolean(PROP, false));
}
/**
* Special hook for sanity checking if any tests trigger failures when an
* Assumption failure occures in a {@link Before} method
* @lucene.internal
*/
@Before
public void checkSyspropForceBeforeAssumptionFailure() {
// ant test -Dargs="-Dtests.force.assumption.failure.before=true"
final String PROP = "tests.force.assumption.failure.before";
assumeFalse(PROP + " == true",
systemPropertyAsBoolean(PROP, false));
}
{code}
...but it currently requires manual testing -- adding a hook for this to the
build.xml seems like something that might be worth considering later? not sure.
(Ideally it would be something the Runner could implement directly w/o these
hooks in SolrTestCase? ... need to think about it)
I should point out: even w/this in place, and when using either of those sys
props, some tests still run (so evidently we still don't have all tests
extending SolrTestCase) but this should be a good enough starting point to make
the changes in SOLR-12988 possible.
I'll plan to commit this soon unless anyone sees any problems?
> harden tests that fail (usually NPE) during After/AfterClas methods if there
> is an assumption violation in Before/BeforeClass methods
> -
>
> Key: SOLR-13574
> URL: https://issues.apache.org/jira/browse/SOLR-13574
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13574.patch
>
>
> We have a bunch of tests that blindly try to call cleanup methods on objects
> w/o sanity checking if the object exists and the cleanup is actually
> neccessary -- which may not be true, particularly there was an Assumption
> failure during a Before/BeforeClass 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] [Updated] (SOLR-13558) Allow dynamic resizing of SolrCache-s
[ https://issues.apache.org/jira/browse/SOLR-13558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-13558: - Issue Type: Sub-task (was: Improvement) Parent: SOLR-13578 > Allow dynamic resizing of SolrCache-s > - > > Key: SOLR-13558 > URL: https://issues.apache.org/jira/browse/SOLR-13558 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > > Currently SolrCache limits are configured statically and can't be > reconfigured without cache re-initialization (core reload), which is costly. > In some situations it would help to be able to dynamically re-size the cache > based on the resource contention (such as the total heap size used for > caching across all cores in a node). > Each cache implementation already knows how to evict its entries when it runs > into configured limits - what is missing is to expose this mechanism using a > uniform API. -- 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-13579) Create resource management API
Andrzej Bialecki created SOLR-13579: Summary: Create resource management API Key: SOLR-13579 URL: https://issues.apache.org/jira/browse/SOLR-13579 Project: Solr Issue Type: Sub-task Security Level: Public (Default Security Level. Issues are Public) Reporter: Andrzej Bialecki Assignee: Andrzej Bialecki -- 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-13578) Implement a generic Resource Manager for monitoring and controlling limited resources
Andrzej Bialecki created SOLR-13578: Summary: Implement a generic Resource Manager for monitoring and controlling limited resources Key: SOLR-13578 URL: https://issues.apache.org/jira/browse/SOLR-13578 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Andrzej Bialecki Assignee: Andrzej Bialecki Many common resources such as CPUs, threads, file descriptors, heap, etc. are shared between multiple SolrCore-s within a CoreContainer. Most of these resources can already be monitored for usage using metrics. However, in most cases Solr doesn't have any control mechanism to actually do something about excessive use (or extreme under-utilization) of a resource by any particular SolrCore or CoreContainer. Furthermore, even when a control mechanism exists it's usually available only as a static configuration parameter (eg. max cache size) and changing it requires at least a core reload, or restarting the JVM. This issue is especially important for multi-tenant applications where the admin cannot assume voluntary co-operation of users and needs more fine-grained tools to prevent DOS attacks, either accidental or purposeful. This is an umbrella issue that proposes the following: * adding a generic ResourceManager component to Solr, which would run at a CoreContainer level and would be able to monitor and enforce both global limits and a "fair" division of resources among competing SolrCore-s. * extending key existing components so that their resource consumption aspects can be dynamically controlled. * adding a number of management plugins that implement specific strategies for managing eg. the cache sizes according to the specified "fairness" and global limits. * the API should allow for implementation of this control loop both in Solr and as an outside mechanism. -- 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-8878) Provide alternative sorting utility from SortField other than FieldComparator
[
https://issues.apache.org/jira/browse/LUCENE-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872534#comment-16872534
]
Adrien Grand commented on LUCENE-8878:
--
+1 to simplify, even at the cost of some performance. As long as we can keep
comparing strings using their ordinals instead of their actual values, it
should be good.
bq. To access the values can we somehow use the existing FunctionValues classes?
I was hoping we could soon replace FunctionValues with the new
oal.search.LongValues/DoubleValues. :)
> Provide alternative sorting utility from SortField other than FieldComparator
> -
>
> Key: LUCENE-8878
> URL: https://issues.apache.org/jira/browse/LUCENE-8878
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: 8.1.1
>Reporter: Tony Xu
>Priority: Major
>
> The `FieldComparator` has many responsibilities and users get all of them at
> once. At high level the main functionalities of `FieldComparator` are
> * Provide LeafFieldComparator
> * Allocate storage for requested number of hits
> * Read the values from DocValues/Custom source etc.
> * Compare two values
> There are two major areas for improvement
> # The logic of reading values and storing them are coupled.
> # User need to specify the size in order to create a `FieldComparator` but
> sometimes the size is unknown upfront.
> # From `FieldComparator`'s API, one can't reason about thread-safety so it
> is not suitable for concurrent search.
> E.g. Can two concurrent thread use the same `FieldComparator` to call
> `getLeafComparator` for two different segments they are working on? In fact,
> almost all existing implementations of `FieldComparator` are not thread-safe.
> The proposal is to enhance `SortField` with two APIs
> # {color:#14892c}int compare(Object v1, Object v2){color} – this is to
> compare two values from different docs for this field
> # {color:#14892c}ValueAccessor newValueAccessor(LeafReaderContext
> leaf){color} – This encapsulate the logic for obtaining the right
> implementation in order to read the field values.
> `ValueAccessor` should be accessed in a similar way as `DocValues` to
> provide the sort value for a document in an advance & read fashion.
> With this API, hopefully we can reduce the memory usage when using
> `FieldComparator` because the users either store the sort values or at least
> the slot number besides the storage allocated by `FieldComparator` itself.
> Ideally, only once copy of the values should be stored.
> The proposed API is also more friendly to concurrent search since it provides
> the `ValueAccessor` per leaf. Although same `ValueAccessor` can't be shared
> if there are more than one thread working on the same leaf, at least they can
> initialize their own `ValueAccessor`.
--
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-13413) jetty IdleTimeout bugs with Http2SolrClient, cause sprious timeouts on intranode requests
[ https://issues.apache.org/jira/browse/SOLR-13413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872533#comment-16872533 ] Ignacio Vera commented on SOLR-13413: - [~caomanhdat] yes currently the branch 8.1 is broken due to a missing sha1. > jetty IdleTimeout bugs with Http2SolrClient, cause sprious timeouts on > intranode requests > - > > Key: SOLR-13413 > URL: https://issues.apache.org/jira/browse/SOLR-13413 > Project: Solr > Issue Type: Bug >Affects Versions: 8.0 >Reporter: Hoss Man >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2, 8.1.2 > > Attachments: SOLR-13413.patch, > nocommit_TestDistributedStatsComponentCardinality_trivial-no-http2.patch > > > There is evidence in some recent jenkins failures that we may have some manor > of bug in our http2 client/server code that can cause intra-node query > requests to stall / timeout non-reproducibly. > In at least one known case, forcing the jetty & SolrClients used in the test > to use http1.1, seems to prevent these test failures. -- 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-8855) Add Accountable to Query implementations
[
https://issues.apache.org/jira/browse/LUCENE-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872532#comment-16872532
]
Adrien Grand commented on LUCENE-8855:
--
BytesRefHash has some code commented out that looks like a left over? One minor
last concern I have is that sizeOf without a default size feels a bit trappy
since lots of objects are larger than their shallow size. Could we make it fail
if it encounters an unknown object instead of assuming shallow size?
> Add Accountable to Query implementations
>
>
> Key: LUCENE-8855
> URL: https://issues.apache.org/jira/browse/LUCENE-8855
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: LUCENE-8855.patch, LUCENE-8855.patch, LUCENE-8855.patch,
> LUCENE-8855.patch
>
>
> Query implementations should also support {{Accountable}} API in order to
> monitor the memory consumption e.g. in caches where either keys or values are
> {{Query}} instances.
--
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=16872515#comment-16872515
]
ASF subversion and git services commented on SOLR-13105:
Commit c9cf9c43217317014bbe586d163363305a4dcf78 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c9cf9c4 ]
SOLR-13105: Start statistics vis 1
> 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
>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-8855) Add Accountable to Query implementations
[
https://issues.apache.org/jira/browse/LUCENE-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872513#comment-16872513
]
Andrzej Bialecki commented on LUCENE-8855:
---
[~jpountz] if the latest patch addresses all your comments I'd like to commit
it shortly.
> Add Accountable to Query implementations
>
>
> Key: LUCENE-8855
> URL: https://issues.apache.org/jira/browse/LUCENE-8855
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: LUCENE-8855.patch, LUCENE-8855.patch, LUCENE-8855.patch,
> LUCENE-8855.patch
>
>
> Query implementations should also support {{Accountable}} API in order to
> monitor the memory consumption e.g. in caches where either keys or values are
> {{Query}} instances.
--
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] [Assigned] (SOLR-13003) Query Result Cache does not honour maxRamBytes parameter
[ https://issues.apache.org/jira/browse/SOLR-13003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki reassigned SOLR-13003: Assignee: Andrzej Bialecki > Query Result Cache does not honour maxRamBytes parameter > > > Key: SOLR-13003 > URL: https://issues.apache.org/jira/browse/SOLR-13003 > Project: Solr > Issue Type: Bug >Affects Versions: 7.3.1 >Reporter: Cetra Free >Assignee: Andrzej Bialecki >Priority: Major > Attachments: CLRU-logging.patch, lrucacheexpanded.png, > lrucachemaxmb.png, solr-core-7.3.1-SNAPSHOT.jar, solrconfig.xml > > > When using the maxRamBytes parameter with the queryResultCache directive, we > have seen the retained size of the cache orders of magnitude larger than what > is configured. > Please see attached VisualVM output which shows the retained size is about > 1.5gb, but the maxRamBytes is set to 64mb. -- 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-Java11 - Build # 180 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro-Java11/180/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/395/consoleText [repro] Revision: 6d6f14d39123512b8734d63c584bceb9d7bd832f [repro] Repro line: ant test -Dtestcase=HttpPartitionTest -Dtests.method=test -Dtests.seed=F8E5AD77FEBC431E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=th-TH-u-nu-thai-x-lvariant-TH -Dtests.timezone=Asia/Novosibirsk -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TestRandomFlRTGCloud -Dtests.seed=F8E5AD77FEBC431E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ru-KG -Dtests.timezone=America/Juneau -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TestDistributedMap -Dtests.seed=F8E5AD77FEBC431E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-NI -Dtests.timezone=America/Port_of_Spain -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=MetricsHandlerTest -Dtests.seed=F8E5AD77FEBC431E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=dje -Dtests.timezone=EST5EDT -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TestCloudDeleteByQuery -Dtests.seed=F8E5AD77FEBC431E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ff-SN -Dtests.timezone=CET -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=ResponseHeaderTest -Dtests.seed=F8E5AD77FEBC431E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=sr-Latn-ME -Dtests.timezone=GB -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TestTolerantSearch -Dtests.seed=F8E5AD77FEBC431E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=fr-BJ -Dtests.timezone=America/Cayenne -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TestEmbeddedSolrServerSchemaAPI -Dtests.seed=F8E5AD77FEBC431E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=kea-CV -Dtests.timezone=Pacific/Tarawa -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TestCloudPhrasesIdentificationComponent -Dtests.seed=F8E5AD77FEBC431E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=mas-TZ -Dtests.timezone=Pacific/Honolulu -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TestSizeLimitedDistributedMap -Dtests.seed=F8E5AD77FEBC431E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=hsb-DE -Dtests.timezone=America/Resolute -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TestSolrCloudWithDelegationTokens -Dtests.seed=F8E5AD77FEBC431E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=sv-AX -Dtests.timezone=Europe/Uzhgorod -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=ZkFailoverTest -Dtests.seed=F8E5AD77FEBC431E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=dyo -Dtests.timezone=Asia/Kuala_Lumpur -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TestManagedSchemaThreadSafety -Dtests.seed=F8E5AD77FEBC431E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-PR -Dtests.timezone=Pacific/Pohnpei -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TestCloudJSONFacetJoinDomain -Dtests.seed=F8E5AD77FEBC431E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=yue -Dtests.timezone=Etc/GMT-10 -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TestCloudJSONFacetSKG -Dtests.seed=F8E5AD77FEBC431E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-IC -Dtests.timezone=GB-Eire -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=AddBlockUpdateTest -Dtests.seed=F8E5AD77FEBC431E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=en-TZ -Dtests.timezone=Asia/Kolkata -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=HttpSolrClientConPoolTest -Dtests.seed=23945577D1F072F8 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=gv-IM -Dtests.timezone=Zulu -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=HttpSolrClientSSLAuthConPoolTest -Dtests.seed=23945577D1F072F8 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true
[jira] [Updated] (SOLR-13003) Query Result Cache does not honour maxRamBytes parameter
[ https://issues.apache.org/jira/browse/SOLR-13003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-13003: - Fix Version/s: 8.1.2 > Query Result Cache does not honour maxRamBytes parameter > > > Key: SOLR-13003 > URL: https://issues.apache.org/jira/browse/SOLR-13003 > Project: Solr > Issue Type: Bug >Affects Versions: 7.3.1 >Reporter: Cetra Free >Assignee: Andrzej Bialecki >Priority: Major > Fix For: 8.1.2 > > Attachments: CLRU-logging.patch, lrucacheexpanded.png, > lrucachemaxmb.png, solr-core-7.3.1-SNAPSHOT.jar, solrconfig.xml > > > When using the maxRamBytes parameter with the queryResultCache directive, we > have seen the retained size of the cache orders of magnitude larger than what > is configured. > Please see attached VisualVM output which shows the retained size is about > 1.5gb, but the maxRamBytes is set to 64mb. -- 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=16872500#comment-16872500
]
ASF subversion and git services commented on SOLR-13105:
Commit 4d0e648c91325813c2c900c13d782944ffe5e7ee in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4d0e648 ]
SOLR-13105: Start statistics vis
> 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
>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] [Updated] (SOLR-13566) REINDEXCOLLECTION does not work with (basic) authentication
[
https://issues.apache.org/jira/browse/SOLR-13566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki updated SOLR-13566:
-
Resolution: Fixed
Status: Resolved (was: Patch Available)
Thanks Colvin for the analysis and the patch! The other part of the problem
(overall thread pool limits for daemons) is tracked separately in SOLR-13575.
> REINDEXCOLLECTION does not work with (basic) authentication
> ---
>
> Key: SOLR-13566
> URL: https://issues.apache.org/jira/browse/SOLR-13566
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.1.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.1.2
>
> Attachments: SOLR-13566.patch, SOLR-13566.patch, SOLR-13566.patch,
> responses.txt, security.json, solr.log
>
>
> I'm on the Solr 8.1 branch off commit
> f26388d034fe5eadca7416aa63b509b8db2c7688 so I have the authentication fixes
> from SOLR-13510 (intermittent 401s for internode requests)
>
> When trying to use the new REINDEXCOLLECTION command introduced in
> SOLR-11127 with basic auth enabled, the daemon stream fails with repeated
> 401s when trying to access the target collection.
>
> This might be the same problem as SOLR-13472, except it applies even with a
> single node, and this doesn't require role based configuration.
>
> Repro: I added a reindex request in BasicAuthIntegrationTest and it is
> reproducible in there... I don't know what effect it should have on the auth
> metrics, if it were working correctly, so I don't know how to update the test
> properly. But you can add the request towards the end of
> org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth()
>
> _CollectionAdminRequest.ReindexCollection reindexReq =
> CollectionAdminRequest.reindexCollection(COLLECTION);_
> _reindexReq.setBasicAuthCredentials("harry", "HarryIsUberCool");_
> _cluster.getSolrClient().request(reindexReq, COLLECTION);_
>
> Manual Repro:
> run bin/solr -e cloud
> Choose 1 node / 1 shard / 1 replica
> In browser GET
> [http://localhost:8983/solr/admin/collections?action=REINDEXCOLLECTION=gettingstarted]
> will succeed
> Enable security: server\scripts\cloud-scripts\zkcli -zkhost localhost:9983
> -cmd putfile /security.json
>
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials":
> { "solradmin": "fskh17INKrOTSRCJ8HkamA0L6Uiq1dSMgn4OVy8htME=
> /Q4VgOkwVlP6AMVY+ML+IuodbfV81WEfZ3lFb390bws=" }
> }
> }
>
>
> In browser authenticate (as solradmin : solradmin) and GET
> [http://localhost:8983/solr/admin/collections?action=REINDEXCOLLECTION=gettingstarted]
> will time out after 180 seconds
>
> The solr log will show repeated 401s
>
> Setting "forwardCredentials" : true in the security.json does not appear to
> change the outcome.
>
>
> The daemon stream should probably be using PKI auth for the internal request.
>
--
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-13566) REINDEXCOLLECTION does not work with (basic) authentication
[
https://issues.apache.org/jira/browse/SOLR-13566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872483#comment-16872483
]
ASF subversion and git services commented on SOLR-13566:
Commit 3fa1997ede83ebb251a3de6e58d4f8613624bf4f in lucene-solr's branch
refs/heads/branch_8_1 from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3fa1997 ]
SOLR-13566: REINDEXCOLLECTION does not work with (basic) authentication.
> REINDEXCOLLECTION does not work with (basic) authentication
> ---
>
> Key: SOLR-13566
> URL: https://issues.apache.org/jira/browse/SOLR-13566
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.1.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.1.2
>
> Attachments: SOLR-13566.patch, SOLR-13566.patch, SOLR-13566.patch,
> responses.txt, security.json, solr.log
>
>
> I'm on the Solr 8.1 branch off commit
> f26388d034fe5eadca7416aa63b509b8db2c7688 so I have the authentication fixes
> from SOLR-13510 (intermittent 401s for internode requests)
>
> When trying to use the new REINDEXCOLLECTION command introduced in
> SOLR-11127 with basic auth enabled, the daemon stream fails with repeated
> 401s when trying to access the target collection.
>
> This might be the same problem as SOLR-13472, except it applies even with a
> single node, and this doesn't require role based configuration.
>
> Repro: I added a reindex request in BasicAuthIntegrationTest and it is
> reproducible in there... I don't know what effect it should have on the auth
> metrics, if it were working correctly, so I don't know how to update the test
> properly. But you can add the request towards the end of
> org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth()
>
> _CollectionAdminRequest.ReindexCollection reindexReq =
> CollectionAdminRequest.reindexCollection(COLLECTION);_
> _reindexReq.setBasicAuthCredentials("harry", "HarryIsUberCool");_
> _cluster.getSolrClient().request(reindexReq, COLLECTION);_
>
> Manual Repro:
> run bin/solr -e cloud
> Choose 1 node / 1 shard / 1 replica
> In browser GET
> [http://localhost:8983/solr/admin/collections?action=REINDEXCOLLECTION=gettingstarted]
> will succeed
> Enable security: server\scripts\cloud-scripts\zkcli -zkhost localhost:9983
> -cmd putfile /security.json
>
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials":
> { "solradmin": "fskh17INKrOTSRCJ8HkamA0L6Uiq1dSMgn4OVy8htME=
> /Q4VgOkwVlP6AMVY+ML+IuodbfV81WEfZ3lFb390bws=" }
> }
> }
>
>
> In browser authenticate (as solradmin : solradmin) and GET
> [http://localhost:8983/solr/admin/collections?action=REINDEXCOLLECTION=gettingstarted]
> will time out after 180 seconds
>
> The solr log will show repeated 401s
>
> Setting "forwardCredentials" : true in the security.json does not appear to
> change the outcome.
>
>
> The daemon stream should probably be using PKI auth for the internal request.
>
--
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-8848) UnifiedHighlighter should highlight all Query types that implement Weight.matches
[ https://issues.apache.org/jira/browse/LUCENE-8848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872449#comment-16872449 ] David Smiley commented on LUCENE-8848: -- Bleh! Thanks for the fix [~jim.ferenczi]! > UnifiedHighlighter should highlight all Query types that implement > Weight.matches > - > > Key: LUCENE-8848 > URL: https://issues.apache.org/jira/browse/LUCENE-8848 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/highlighter >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Fix For: 8.2 > > Attachments: LUCENE-8848.patch > > > The UnifiedHighlighter internally extracts terms and automata from the query. > Usually this works perfectly but it's possible a Query might be of a type it > doesn't know -- a leaf query that is perhaps in effect similar to a > MultiTermQuery yet it might not even be a subclass of this or it does but the > UH doesn't know how to extract an automata from it. The UH is oblivious to > this and probably won't highlight this query. If re-analysis of the text is > necessary, the UH will pre-filter all terms to only those it _thinks_ are > pertinent. Or if offsets are in the postings then the UH could perform very > poorly by unleashing this query on the index for each highlighted document > without recognizing re-analysis is a more appropriate path. > I think to solve this, the UnifiedHighlighter.getFieldHighlighter needs to > inspect the query (using a QueryVisitor) to see if it can find a leaf query > that is not one it knows how to pull automata from, and is otherwise not in a > special list (like MatchAllDocsQuery). If we find one, we avoid choosing > OffsetSource.POSTINGS or OffsetSource.NONE_NEEDED since we might in effect > have an MTQ like query. If a MemoryIndex is needed then we don't pre-filter > the terms since we can't assume we know precisely which terms are pertinent. > We needn't bother extracting terms & automata in this case either; it's > wasted effort which can involve building a CharacterRunAutomaton (see > MultiTermHighlighting.binaryToCharRunAutomaton). Speaking of which, it'd be > nice to avoid that in other cases as well, like for WEIGHT_MATCHES when we > aren't using MemoryIndex (thus no term pre-filtering). -- 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-13577) TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
[
https://issues.apache.org/jira/browse/SOLR-13577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13577:
Attachment: SOLR-13577.patch
> TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
> ---
>
> Key: SOLR-13577
> URL: https://issues.apache.org/jira/browse/SOLR-13577
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: 8016-consoleText.zip, SOLR-13577.patch,
> SOLR-13577.patch, screenshot-1.png
>
>
> It's seems like clear test failures. Failed 6 times in a row at lines 682, 684
> {quote}
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 1 build (Since Failed#8011 )
> Took 6 sec.
> Error Message
> null
> Stacktrace
> java.lang.NumberFormatException: null
> at
> __randomizedtesting.SeedInfo.seed([6AB4ECC957E5CCA2:B243282DFC3E0EFE]:0)
> at java.base/java.lang.Integer.parseInt(Integer.java:614)
> at java.base/java.lang.Integer.parseInt(Integer.java:770)
> at
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:682)
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 3 builds (Since Failed#8011 )
> Took 7.5 sec.
> Stacktrace
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([E88092B4017D2D3D:30775650AAA6EF61]: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.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:684)
> {quote}
> !screenshot-1.png!
--
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-13566) REINDEXCOLLECTION does not work with (basic) authentication
[
https://issues.apache.org/jira/browse/SOLR-13566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872447#comment-16872447
]
ASF subversion and git services commented on SOLR-13566:
Commit da6e6fd559488287b495d2a526014e27240b77cb in lucene-solr's branch
refs/heads/branch_8x from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=da6e6fd ]
SOLR-13566: REINDEXCOLLECTION does not work with (basic) authentication.
> REINDEXCOLLECTION does not work with (basic) authentication
> ---
>
> Key: SOLR-13566
> URL: https://issues.apache.org/jira/browse/SOLR-13566
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.1.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.1.2
>
> Attachments: SOLR-13566.patch, SOLR-13566.patch, SOLR-13566.patch,
> responses.txt, security.json, solr.log
>
>
> I'm on the Solr 8.1 branch off commit
> f26388d034fe5eadca7416aa63b509b8db2c7688 so I have the authentication fixes
> from SOLR-13510 (intermittent 401s for internode requests)
>
> When trying to use the new REINDEXCOLLECTION command introduced in
> SOLR-11127 with basic auth enabled, the daemon stream fails with repeated
> 401s when trying to access the target collection.
>
> This might be the same problem as SOLR-13472, except it applies even with a
> single node, and this doesn't require role based configuration.
>
> Repro: I added a reindex request in BasicAuthIntegrationTest and it is
> reproducible in there... I don't know what effect it should have on the auth
> metrics, if it were working correctly, so I don't know how to update the test
> properly. But you can add the request towards the end of
> org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth()
>
> _CollectionAdminRequest.ReindexCollection reindexReq =
> CollectionAdminRequest.reindexCollection(COLLECTION);_
> _reindexReq.setBasicAuthCredentials("harry", "HarryIsUberCool");_
> _cluster.getSolrClient().request(reindexReq, COLLECTION);_
>
> Manual Repro:
> run bin/solr -e cloud
> Choose 1 node / 1 shard / 1 replica
> In browser GET
> [http://localhost:8983/solr/admin/collections?action=REINDEXCOLLECTION=gettingstarted]
> will succeed
> Enable security: server\scripts\cloud-scripts\zkcli -zkhost localhost:9983
> -cmd putfile /security.json
>
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials":
> { "solradmin": "fskh17INKrOTSRCJ8HkamA0L6Uiq1dSMgn4OVy8htME=
> /Q4VgOkwVlP6AMVY+ML+IuodbfV81WEfZ3lFb390bws=" }
> }
> }
>
>
> In browser authenticate (as solradmin : solradmin) and GET
> [http://localhost:8983/solr/admin/collections?action=REINDEXCOLLECTION=gettingstarted]
> will time out after 180 seconds
>
> The solr log will show repeated 401s
>
> Setting "forwardCredentials" : true in the security.json does not appear to
> change the outcome.
>
>
> The daemon stream should probably be using PKI auth for the internal request.
>
--
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] iverase commented on issue #726: LUCENE-8632: New XYShape Field and Queries for indexing and searching general cartesian geometries
iverase commented on issue #726: LUCENE-8632: New XYShape Field and Queries for indexing and searching general cartesian geometries URL: https://github.com/apache/lucene-solr/pull/726#issuecomment-505487115 Thanks Nick! I am having problems with Polygon and XYPolygon and Line and XYLine and so on. Are we keeping Polygon for backwards compatibility? It looks like it should be called LatLonPolygon for consistency. 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
Re: 8.1.2 bug fix release
Hi, I would like to backport bug fix LUCENE-8775 that fixes some failures in the polygon Tessellator when a polygon contain a hole sharing a vertex with the polygon. Is that ok? Thanks, Ignacio On Tue, Jun 25, 2019 at 1:39 AM Steve Rowe wrote: > Hi Đạt, I re-enabled the ASF Jenkins 8.1 jobs. - Steve > > On Jun 24, 2019, at 8:09 AM, Đạt Cao Mạnh wrote: > > Hi Uwe, Steve. > > Can Jenkins on branch_8_1 be resumed for 8.1.2 release? I am not sure how > to enable them on https://builds.apache.org/view/L/view/Lucene/ > > Thanks. > > On Thu, Jun 13, 2019 at 10:51 AM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > >> Sure Dat, sounds good. >> >> On Thu, Jun 13, 2019 at 2:11 PM Đạt Cao Mạnh >> wrote: >> > >> > Hi Ishan, >> > >> > If upgrade Jetty seems too much for a bug fix release, I will try to >> upgrade only part that affect SOLR-13413 (one module). Then see how tests >> will behave then. Does that sound good? >> > >> > On Thu, Jun 13, 2019 at 4:51 AM Ishan Chattopadhyaya < >> ichattopadhy...@gmail.com> wrote: >> >> >> >> Have we vetted all other changes to Jetty? Are we sure that they don't >> introduce a different regression? >> >> >> >> On Thu, 13 Jun, 2019, 4:16 AM Kevin Risden, >> wrote: >> >>> >> >>> +1 to 8.1.2 and the Jetty upgrade. FYI Erick created >> https://issues.apache.org/jira/browse/SOLR-13541 specifically for the >> Jetty upgrade. >> >>> >> >>> Kevin Risden >> >>> >> >>> >> >>> On Wed, Jun 12, 2019 at 4:47 PM Đạt Cao Mạnh >> wrote: >> >> Hi David, yeah sure, that bug fix seems important. >> I also want to do the upgrade Jetty 9.4.19 for 8.1.2 (fix: >> SOLR-13413). Do you guys have any objections? >> >> On Wed, Jun 12, 2019 at 3:40 PM David Smiley < >> david.w.smi...@gmail.com> wrote: >> > >> > Yes thanks for volunteering. Also, lets get this serious bug fix >> in: https://issues.apache.org/jira/browse/SOLR-13523 >> > >> > ~ David Smiley >> > Apache Lucene/Solr Search Developer >> > http://www.linkedin.com/in/davidwsmiley >> > >> > >> > On Wed, Jun 12, 2019 at 9:27 AM Đạt Cao Mạnh < >> caomanhdat...@gmail.com> wrote: >> >> >> >> Hi, >> >> >> >> Just right after the 8.1.1 release has been published we’ve >> discovered a serious bug in BasicAuthentication which affect all released >> versions of Solr including 8.0, 8.1, 8.1.1. Details of the bug can be found >> in SOLR-13510. >> >> >> >> I’m volunteering to do this release, if there are no objections, >> and I’d like to create a RC early next week. >> >> >> >> -- >> >> Best regards, >> >> Cao Mạnh Đạt >> >> E-mail: caomanhdat...@gmail.com >> >> >> >> -- >> Best regards, >> Cao Mạnh Đạt >> E-mail: caomanhdat...@gmail.com >> > >> > >> > >> > -- >> > Best regards, >> > Cao Mạnh Đạt >> > E-mail: caomanhdat...@gmail.com >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > > -- > *Best regards,* > *Cao Mạnh Đạt* > *E-mail: caomanhdat...@gmail.com * > > >
[jira] [Commented] (SOLR-13566) REINDEXCOLLECTION does not work with (basic) authentication
[
https://issues.apache.org/jira/browse/SOLR-13566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872416#comment-16872416
]
ASF subversion and git services commented on SOLR-13566:
Commit 4d1058db6e51cc1869c0d0fcc32f6356f9e61e45 in lucene-solr's branch
refs/heads/master from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4d1058d ]
SOLR-13566: REINDEXCOLLECTION does not work with (basic) authentication.
> REINDEXCOLLECTION does not work with (basic) authentication
> ---
>
> Key: SOLR-13566
> URL: https://issues.apache.org/jira/browse/SOLR-13566
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.1.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.1.2
>
> Attachments: SOLR-13566.patch, SOLR-13566.patch, SOLR-13566.patch,
> responses.txt, security.json, solr.log
>
>
> I'm on the Solr 8.1 branch off commit
> f26388d034fe5eadca7416aa63b509b8db2c7688 so I have the authentication fixes
> from SOLR-13510 (intermittent 401s for internode requests)
>
> When trying to use the new REINDEXCOLLECTION command introduced in
> SOLR-11127 with basic auth enabled, the daemon stream fails with repeated
> 401s when trying to access the target collection.
>
> This might be the same problem as SOLR-13472, except it applies even with a
> single node, and this doesn't require role based configuration.
>
> Repro: I added a reindex request in BasicAuthIntegrationTest and it is
> reproducible in there... I don't know what effect it should have on the auth
> metrics, if it were working correctly, so I don't know how to update the test
> properly. But you can add the request towards the end of
> org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth()
>
> _CollectionAdminRequest.ReindexCollection reindexReq =
> CollectionAdminRequest.reindexCollection(COLLECTION);_
> _reindexReq.setBasicAuthCredentials("harry", "HarryIsUberCool");_
> _cluster.getSolrClient().request(reindexReq, COLLECTION);_
>
> Manual Repro:
> run bin/solr -e cloud
> Choose 1 node / 1 shard / 1 replica
> In browser GET
> [http://localhost:8983/solr/admin/collections?action=REINDEXCOLLECTION=gettingstarted]
> will succeed
> Enable security: server\scripts\cloud-scripts\zkcli -zkhost localhost:9983
> -cmd putfile /security.json
>
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials":
> { "solradmin": "fskh17INKrOTSRCJ8HkamA0L6Uiq1dSMgn4OVy8htME=
> /Q4VgOkwVlP6AMVY+ML+IuodbfV81WEfZ3lFb390bws=" }
> }
> }
>
>
> In browser authenticate (as solradmin : solradmin) and GET
> [http://localhost:8983/solr/admin/collections?action=REINDEXCOLLECTION=gettingstarted]
> will time out after 180 seconds
>
> The solr log will show repeated 401s
>
> Setting "forwardCredentials" : true in the security.json does not appear to
> change the outcome.
>
>
> The daemon stream should probably be using PKI auth for the internal request.
>
--
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-13577) TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
[
https://issues.apache.org/jira/browse/SOLR-13577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872401#comment-16872401
]
Mikhail Khludnev commented on SOLR-13577:
-
Just adding assumption, and more details in assert message.
I would like to spin until slave hit replication failure.
> TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
> ---
>
> Key: SOLR-13577
> URL: https://issues.apache.org/jira/browse/SOLR-13577
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: 8016-consoleText.zip, SOLR-13577.patch, screenshot-1.png
>
>
> It's seems like clear test failures. Failed 6 times in a row at lines 682, 684
> {quote}
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 1 build (Since Failed#8011 )
> Took 6 sec.
> Error Message
> null
> Stacktrace
> java.lang.NumberFormatException: null
> at
> __randomizedtesting.SeedInfo.seed([6AB4ECC957E5CCA2:B243282DFC3E0EFE]:0)
> at java.base/java.lang.Integer.parseInt(Integer.java:614)
> at java.base/java.lang.Integer.parseInt(Integer.java:770)
> at
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:682)
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 3 builds (Since Failed#8011 )
> Took 7.5 sec.
> Stacktrace
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([E88092B4017D2D3D:30775650AAA6EF61]: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.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:684)
> {quote}
> !screenshot-1.png!
--
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-13577) TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
[
https://issues.apache.org/jira/browse/SOLR-13577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13577:
Status: Patch Available (was: Open)
> TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
> ---
>
> Key: SOLR-13577
> URL: https://issues.apache.org/jira/browse/SOLR-13577
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: 8016-consoleText.zip, SOLR-13577.patch, screenshot-1.png
>
>
> It's seems like clear test failures. Failed 6 times in a row at lines 682, 684
> {quote}
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 1 build (Since Failed#8011 )
> Took 6 sec.
> Error Message
> null
> Stacktrace
> java.lang.NumberFormatException: null
> at
> __randomizedtesting.SeedInfo.seed([6AB4ECC957E5CCA2:B243282DFC3E0EFE]:0)
> at java.base/java.lang.Integer.parseInt(Integer.java:614)
> at java.base/java.lang.Integer.parseInt(Integer.java:770)
> at
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:682)
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 3 builds (Since Failed#8011 )
> Took 7.5 sec.
> Stacktrace
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([E88092B4017D2D3D:30775650AAA6EF61]: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.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:684)
> {quote}
> !screenshot-1.png!
--
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-13577) TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
[
https://issues.apache.org/jira/browse/SOLR-13577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13577:
Attachment: SOLR-13577.patch
> TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
> ---
>
> Key: SOLR-13577
> URL: https://issues.apache.org/jira/browse/SOLR-13577
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: 8016-consoleText.zip, SOLR-13577.patch, screenshot-1.png
>
>
> It's seems like clear test failures. Failed 6 times in a row at lines 682, 684
> {quote}
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 1 build (Since Failed#8011 )
> Took 6 sec.
> Error Message
> null
> Stacktrace
> java.lang.NumberFormatException: null
> at
> __randomizedtesting.SeedInfo.seed([6AB4ECC957E5CCA2:B243282DFC3E0EFE]:0)
> at java.base/java.lang.Integer.parseInt(Integer.java:614)
> at java.base/java.lang.Integer.parseInt(Integer.java:770)
> at
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:682)
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 3 builds (Since Failed#8011 )
> Took 7.5 sec.
> Stacktrace
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([E88092B4017D2D3D:30775650AAA6EF61]: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.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:684)
> {quote}
> !screenshot-1.png!
--
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-13577) TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
[
https://issues.apache.org/jira/browse/SOLR-13577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872393#comment-16872393
]
Mikhail Khludnev commented on SOLR-13577:
-
it seems like shutting down master for a few sec isn't enough, it's somehow
retried underneath networking
{quote}
[junit4] 2> 69070 INFO (indexFetcher-346-thread-1) [ ]
o.a.h.i.e.RetryExec I/O exception (java.net.SocketException) caught when
processing request to {}->http://127.0.0.1:55628: Software caused connection
abort: recv failed
[junit4] 2> 69070 INFO (indexFetcher-346-thread-1) [ ]
o.a.h.i.e.RetryExec Retrying request to {}->http://127.0.0.1:55628
{quote}
see test output attached.
> TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
> ---
>
> Key: SOLR-13577
> URL: https://issues.apache.org/jira/browse/SOLR-13577
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: 8016-consoleText.zip, screenshot-1.png
>
>
> It's seems like clear test failures. Failed 6 times in a row at lines 682, 684
> {quote}
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 1 build (Since Failed#8011 )
> Took 6 sec.
> Error Message
> null
> Stacktrace
> java.lang.NumberFormatException: null
> at
> __randomizedtesting.SeedInfo.seed([6AB4ECC957E5CCA2:B243282DFC3E0EFE]:0)
> at java.base/java.lang.Integer.parseInt(Integer.java:614)
> at java.base/java.lang.Integer.parseInt(Integer.java:770)
> at
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:682)
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 3 builds (Since Failed#8011 )
> Took 7.5 sec.
> Stacktrace
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([E88092B4017D2D3D:30775650AAA6EF61]: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.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:684)
> {quote}
> !screenshot-1.png!
--
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-13577) TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
[
https://issues.apache.org/jira/browse/SOLR-13577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13577:
Attachment: 8016-consoleText.zip
> TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
> ---
>
> Key: SOLR-13577
> URL: https://issues.apache.org/jira/browse/SOLR-13577
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: 8016-consoleText.zip, screenshot-1.png
>
>
> It's seems like clear test failures. Failed 6 times in a row at lines 682, 684
> {quote}
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 1 build (Since Failed#8011 )
> Took 6 sec.
> Error Message
> null
> Stacktrace
> java.lang.NumberFormatException: null
> at
> __randomizedtesting.SeedInfo.seed([6AB4ECC957E5CCA2:B243282DFC3E0EFE]:0)
> at java.base/java.lang.Integer.parseInt(Integer.java:614)
> at java.base/java.lang.Integer.parseInt(Integer.java:770)
> at
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:682)
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 3 builds (Since Failed#8011 )
> Took 7.5 sec.
> Stacktrace
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([E88092B4017D2D3D:30775650AAA6EF61]: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.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:684)
> {quote}
> !screenshot-1.png!
--
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-8.x - Build # 266 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/266/ 1 tests failed. FAILED: org.apache.solr.cloud.SystemCollectionCompatTest.testBackCompat Error Message: Error from server at https://127.0.0.1:36436/solr/.system: Error reading input String Can't find resource 'schema.xml' in classpath or '/configs/.system', cwd=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/build/solr-core/test/J1 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:36436/solr/.system: Error reading input String Can't find resource 'schema.xml' in classpath or '/configs/.system', cwd=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/build/solr-core/test/J1 at __randomizedtesting.SeedInfo.seed([48BE459448DD8D53:384BE63D28152425]: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:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.cloud.SystemCollectionCompatTest.setupSystemCollection(SystemCollectionCompatTest.java:104) 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$9.evaluate(RandomizedRunner.java:972) 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
[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=16872388#comment-16872388
]
ASF subversion and git services commented on SOLR-13105:
Commit a928b4c35f893fe7a2a3e4424169603856081265 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a928b4c ]
SOLR-13105: Add quantile plots
> 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
>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
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11.0.3) - Build # 24288 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24288/ Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 2027 lines...] [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/test/temp/junit4-J2-20190625_123131_99716972631816653492323.syserr [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J2: EOF [...truncated 3 lines...] [junit4] JVM J1: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/test/temp/junit4-J1-20190625_123131_9979098626527546276364.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 5 lines...] [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/test/temp/junit4-J0-20190625_123131_9944618424786924930939.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 304 lines...] [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/test-framework/test/temp/junit4-J2-20190625_124450_5845196885864413129047.syserr [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J2: EOF [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/test-framework/test/temp/junit4-J0-20190625_124450_5831285573068450463.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 3 lines...] [junit4] JVM J1: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/test-framework/test/temp/junit4-J1-20190625_124450_58415361790429310196683.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 1075 lines...] [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/analysis/common/test/temp/junit4-J2-20190625_124709_6147289507420539632540.syserr [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J2: EOF [...truncated 3 lines...] [junit4] JVM J1: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/analysis/common/test/temp/junit4-J1-20190625_124709_6141341161645547638191.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 3 lines...] [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/analysis/common/test/temp/junit4-J0-20190625_124709_61416371864529539155358.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 238 lines...] [junit4] JVM J1: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/analysis/icu/test/temp/junit4-J1-20190625_125037_19417900935109246381755.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 9 lines...] [junit4] JVM J2: stderr was not empty, see:
Re: Welcome Munendra S N as Lucene/Solr committer
Congrats and welcome Munendra! Kevin Risden On Tue, Jun 25, 2019 at 6:06 AM Christine Poerschke (BLOOMBERG/ LONDON) < cpoersc...@bloomberg.net> wrote: > Welcome Munendra! > > Christine > > From: dev@lucene.apache.org At: 06/21/19 14:50:57 > To: dev@lucene.apache.org > Subject: Re: Welcome Munendra S N as Lucene/Solr committer > > Thanks Ishan, and thank you everyone for this opportunity > I came across Lucene/Solr when I joined as Software Engineer at Unbxd. I > have been working with Lucene/Solr from past 3 years and started > contributing from past 2 years. > I'm delighted to be part of this great team. Looking forward to the > exciting times. > > Regards, > Munendra S N > > > On Fri, Jun 21, 2019 at 4:52 PM Jan Høydahl wrote: > >> Welcome Munendra! >> >> -- >> Jan Høydahl, search solution architect >> Cominvent AS - www.cominvent.com >> >> 21. jun. 2019 kl. 11:41 skrev Ishan Chattopadhyaya < >> ichattopadhy...@gmail.com>: >> >> Hi all, >> >> Please join me in welcoming Munendra as a Lucene/Solr committer! >> >> Munendra has been working on bug fixes and improvements in various >> parts of Solr. >> >> Congratulations and welcome! It is a tradition to introduce yourself >> with a brief bio, Munendra. >> >> Ishan >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> >> >
[jira] [Updated] (SOLR-13577) TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
[
https://issues.apache.org/jira/browse/SOLR-13577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13577:
Attachment: screenshot-1.png
> TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
> ---
>
> Key: SOLR-13577
> URL: https://issues.apache.org/jira/browse/SOLR-13577
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: screenshot-1.png
>
>
> It's seems like clear test failures. Failed 6 times in a row at lines 682, 684
> {quote}
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 1 build (Since Failed#8011 )
> Took 6 sec.
> Error Message
> null
> Stacktrace
> java.lang.NumberFormatException: null
> at
> __randomizedtesting.SeedInfo.seed([6AB4ECC957E5CCA2:B243282DFC3E0EFE]:0)
> at java.base/java.lang.Integer.parseInt(Integer.java:614)
> at java.base/java.lang.Integer.parseInt(Integer.java:770)
> at
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:682)
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 3 builds (Since Failed#8011 )
> Took 7.5 sec.
> Stacktrace
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([E88092B4017D2D3D:30775650AAA6EF61]: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.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:684)
> {quote}
--
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-13577) TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
[
https://issues.apache.org/jira/browse/SOLR-13577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13577:
Description:
It's seems like clear test failures. Failed 6 times in a row at lines 682, 684
{quote}
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
Failing for the past 1 build (Since Failed#8011 )
Took 6 sec.
Error Message
null
Stacktrace
java.lang.NumberFormatException: null
at
__randomizedtesting.SeedInfo.seed([6AB4ECC957E5CCA2:B243282DFC3E0EFE]:0)
at java.base/java.lang.Integer.parseInt(Integer.java:614)
at java.base/java.lang.Integer.parseInt(Integer.java:770)
at
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:682)
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
Failing for the past 3 builds (Since Failed#8011 )
Took 7.5 sec.
Stacktrace
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([E88092B4017D2D3D:30775650AAA6EF61]: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.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:684)
{quote}
!screenshot-1.png!
was:
It's seems like clear test failures. Failed 6 times in a row at lines 682, 684
{quote}
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
Failing for the past 1 build (Since Failed#8011 )
Took 6 sec.
Error Message
null
Stacktrace
java.lang.NumberFormatException: null
at
__randomizedtesting.SeedInfo.seed([6AB4ECC957E5CCA2:B243282DFC3E0EFE]:0)
at java.base/java.lang.Integer.parseInt(Integer.java:614)
at java.base/java.lang.Integer.parseInt(Integer.java:770)
at
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:682)
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
Failing for the past 3 builds (Since Failed#8011 )
Took 7.5 sec.
Stacktrace
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([E88092B4017D2D3D:30775650AAA6EF61]: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.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:684)
{quote}
> TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
> ---
>
> Key: SOLR-13577
> URL: https://issues.apache.org/jira/browse/SOLR-13577
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: screenshot-1.png
>
>
> It's seems like clear test failures. Failed 6 times in a row at lines 682, 684
> {quote}
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 1 build (Since Failed#8011 )
> Took 6 sec.
> Error Message
> null
> Stacktrace
> java.lang.NumberFormatException: null
> at
> __randomizedtesting.SeedInfo.seed([6AB4ECC957E5CCA2:B243282DFC3E0EFE]:0)
> at java.base/java.lang.Integer.parseInt(Integer.java:614)
> at java.base/java.lang.Integer.parseInt(Integer.java:770)
> at
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:682)
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
> Failing for the past 3 builds (Since Failed#8011 )
> Took 7.5 sec.
> Stacktrace
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([E88092B4017D2D3D:30775650AAA6EF61]: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.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:684)
> {quote}
> !screenshot-1.png!
--
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-13577) TestReplicationHandler.doTestIndexFetchOnMasterRestart failures
Mikhail Khludnev created SOLR-13577:
---
Summary: TestReplicationHandler.doTestIndexFetchOnMasterRestart
failures
Key: SOLR-13577
URL: https://issues.apache.org/jira/browse/SOLR-13577
Project: Solr
Issue Type: Test
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Mikhail Khludnev
It's seems like clear test failures. Failed 6 times in a row at lines 682, 684
{quote}
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
Failing for the past 1 build (Since Failed#8011 )
Took 6 sec.
Error Message
null
Stacktrace
java.lang.NumberFormatException: null
at
__randomizedtesting.SeedInfo.seed([6AB4ECC957E5CCA2:B243282DFC3E0EFE]:0)
at java.base/java.lang.Integer.parseInt(Integer.java:614)
at java.base/java.lang.Integer.parseInt(Integer.java:770)
at
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:682)
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart
Failing for the past 3 builds (Since Failed#8011 )
Took 7.5 sec.
Stacktrace
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([E88092B4017D2D3D:30775650AAA6EF61]: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.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:684)
{quote}
--
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-13568) Expand component should not cache group queries in the filter cache
[ https://issues.apache.org/jira/browse/SOLR-13568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872322#comment-16872322 ] Joel Bernstein commented on SOLR-13568: --- Ok, I'll take a look. > Expand component should not cache group queries in the filter cache > --- > > Key: SOLR-13568 > URL: https://issues.apache.org/jira/browse/SOLR-13568 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7.2, 8.1.1 >Reporter: Ludovic Boutros >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently the expand component is creating queries (bit sets) from the > current page document ids. > These queries are sadly put in the filter cache. > This behavior floods the filter cache and it becomes inefficient. > Therefore, the group query should be wrapped in a query with its cache flag > disabled. > This is a tiny little thing to do. The PR will follow very soon. -- 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-13375) Dimensional Routed Aliases
[ https://issues.apache.org/jira/browse/SOLR-13375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872310#comment-16872310 ] Gus Heck commented on SOLR-13375: - Actually looking again this morning I realize that the writeParams method is a bit of a red herring. It's really the conflict between the getParams() method api and the objects I want to express. The real problem is that the v2 API (as I am attempting to use it) wants to be able to handle more complex objects than SolrParams really was intended for. SolrParams *is* documented as being string to one or more strings, but that makes it hard to handle json that has properties that are lists of objects (lists of strings clearly work). Autoscaling seems to be using lists of object for set-trigger.actions but AFAICT they don't have a v1 api and I suspect they therefore dodge this SolrParams.toMap()/getParam() issue. One possible way around this might be to override toMap() in the wrapper to just return the map that backs the wrapper, but that has to still somehow do the conversions to v1 api keys before returning the map, and it widens the actual capabilities of SolrParams beyond it's documentation which could trip up other folks. > Dimensional Routed Aliases > -- > > Key: SOLR-13375 > URL: https://issues.apache.org/jira/browse/SOLR-13375 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Affects Versions: master (9.0) >Reporter: Gus Heck >Assignee: Gus Heck >Priority: Major > Attachments: SOLR-13375.patch > > > Current available routed aliases are restricted to a single field. This > feature will allow Solr to provide data driven collection access, creation > and management based on multiple fields in a document. The collections will > be queried and updated in a unified manner via an alias. Current routing is > restricted to the values of a single field. The particularly useful > combination at this time will be Category X Time routing but Category X > Category may also be useful. More importantly, if additional routing schemes > are created in the future (either as contributions or as custom code by > users) combination among these should be supported. > It is expected that not all combinations will be useful, and that > determination of usefulness I expect to leave up to the user. Some Routing > schemes may need to be limited to be the leaf/last routing scheme for > technical reasons, though I'm not entirely convinced of that yet. If so, a > flag will be added to the RoutedAlias interface. > Initial desire is to support two levels, though if arbitrary levels can be > supported easily that will be done. > This could also have been called CompositeRoutedAlias, but that creates a TLA > clash with CategoryRoutedAlias. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13375) Dimensional Routed Aliases
[ https://issues.apache.org/jira/browse/SOLR-13375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872310#comment-16872310 ] Gus Heck edited comment on SOLR-13375 at 6/25/19 12:31 PM: --- Actually looking again this morning I realize that the writeMap method is a bit of a red herring. It's really the conflict between the getParams() method api and the objects I want to express. The real problem is that the v2 API (as I am attempting to use it) wants to be able to handle more complex objects than SolrParams really was intended for. SolrParams *is* documented as being string to one or more strings, but that makes it hard to handle json that has properties that are lists of objects (lists of strings clearly work). Autoscaling seems to be using lists of object for set-trigger.actions but AFAICT they don't have a v1 api and I suspect they therefore dodge this SolrParams.toMap()/getParam() issue. One possible way around this might be to override toMap() in the wrapper to just return the map that backs the wrapper, but that has to still somehow do the conversions to v1 api keys before returning the map, and it widens the actual capabilities of SolrParams beyond it's documentation which could trip up other folks. was (Author: gus_heck): Actually looking again this morning I realize that the writeParams method is a bit of a red herring. It's really the conflict between the getParams() method api and the objects I want to express. The real problem is that the v2 API (as I am attempting to use it) wants to be able to handle more complex objects than SolrParams really was intended for. SolrParams *is* documented as being string to one or more strings, but that makes it hard to handle json that has properties that are lists of objects (lists of strings clearly work). Autoscaling seems to be using lists of object for set-trigger.actions but AFAICT they don't have a v1 api and I suspect they therefore dodge this SolrParams.toMap()/getParam() issue. One possible way around this might be to override toMap() in the wrapper to just return the map that backs the wrapper, but that has to still somehow do the conversions to v1 api keys before returning the map, and it widens the actual capabilities of SolrParams beyond it's documentation which could trip up other folks. > Dimensional Routed Aliases > -- > > Key: SOLR-13375 > URL: https://issues.apache.org/jira/browse/SOLR-13375 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Affects Versions: master (9.0) >Reporter: Gus Heck >Assignee: Gus Heck >Priority: Major > Attachments: SOLR-13375.patch > > > Current available routed aliases are restricted to a single field. This > feature will allow Solr to provide data driven collection access, creation > and management based on multiple fields in a document. The collections will > be queried and updated in a unified manner via an alias. Current routing is > restricted to the values of a single field. The particularly useful > combination at this time will be Category X Time routing but Category X > Category may also be useful. More importantly, if additional routing schemes > are created in the future (either as contributions or as custom code by > users) combination among these should be supported. > It is expected that not all combinations will be useful, and that > determination of usefulness I expect to leave up to the user. Some Routing > schemes may need to be limited to be the leaf/last routing scheme for > technical reasons, though I'm not entirely convinced of that yet. If so, a > flag will be added to the RoutedAlias interface. > Initial desire is to support two levels, though if arbitrary levels can be > supported easily that will be done. > This could also have been called CompositeRoutedAlias, but that creates a TLA > clash with CategoryRoutedAlias. -- 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-11.0.3) - Build # 8016 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/8016/ Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -XX:+UseG1GC 4 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart Error Message: null Stack Trace: java.lang.NumberFormatException: null at __randomizedtesting.SeedInfo.seed([FAF773A5415B4026:2200B741EA80827A]:0) at java.base/java.lang.Integer.parseInt(Integer.java:614) at java.base/java.lang.Integer.parseInt(Integer.java:770) at org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:682) 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) 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:834) FAILED: org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart Error Message: null Stack Trace: java.lang.NumberFormatException: null at __randomizedtesting.SeedInfo.seed([FAF773A5415B4026:2200B741EA80827A]:0) at
[jira] [Commented] (SOLR-13375) Dimensional Routed Aliases
[ https://issues.apache.org/jira/browse/SOLR-13375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872301#comment-16872301 ] Gus Heck commented on SOLR-13375: - org.apache.solr.handler.admin.BaseHandlerApiSupport#wrapParams > Dimensional Routed Aliases > -- > > Key: SOLR-13375 > URL: https://issues.apache.org/jira/browse/SOLR-13375 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Affects Versions: master (9.0) >Reporter: Gus Heck >Assignee: Gus Heck >Priority: Major > Attachments: SOLR-13375.patch > > > Current available routed aliases are restricted to a single field. This > feature will allow Solr to provide data driven collection access, creation > and management based on multiple fields in a document. The collections will > be queried and updated in a unified manner via an alias. Current routing is > restricted to the values of a single field. The particularly useful > combination at this time will be Category X Time routing but Category X > Category may also be useful. More importantly, if additional routing schemes > are created in the future (either as contributions or as custom code by > users) combination among these should be supported. > It is expected that not all combinations will be useful, and that > determination of usefulness I expect to leave up to the user. Some Routing > schemes may need to be limited to be the leaf/last routing scheme for > technical reasons, though I'm not entirely convinced of that yet. If so, a > flag will be added to the RoutedAlias interface. > Initial desire is to support two levels, though if arbitrary levels can be > supported easily that will be done. > This could also have been called CompositeRoutedAlias, but that creates a TLA > clash with CategoryRoutedAlias. -- 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-8.1 - Build # 62 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.1/62/ All tests passed Build Log: [...truncated 36848 lines...] check-licenses: [echo] License check under: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.1/solr [licenses] MISSING sha1 checksum file for: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.1/solr/solrj/lib/http2-http-client-transport-9.4.19.v20190610.jar [licenses] EXPECTED sha1 checksum file : /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.1/solr/licenses/http2-http-client-transport-9.4.19.v20190610.jar.sha1 [...truncated 1 lines...] BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.1/build.xml:634: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.1/build.xml:117: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.1/solr/build.xml:328: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.1/lucene/tools/custom-tasks.xml:62: License check failed. Check the logs. If you recently modified ivy-versions.properties or any module's ivy.xml, make sure you run "ant clean-jars jar-checksums" before running precommit. Total time: 95 minutes 5 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] cpoerschke commented on a change in pull request #300: SOLR-11831: Skip second grouping step if group.limit is 1 (aka Las Vegas Patch)
cpoerschke commented on a change in pull request #300: SOLR-11831: Skip second
grouping step if group.limit is 1 (aka Las Vegas Patch)
URL: https://github.com/apache/lucene-solr/pull/300#discussion_r297135820
##
File path:
solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java
##
@@ -188,7 +188,11 @@ public void process(ResponseBuilder rb, ShardRequest
shardRequest) {
}
rb.mergedQueryCommandResults.put(query, new
QueryCommandResult(mergedTopDocs, mergedMatches, maxScore));
}
+fillResultIds(rb);
+ }
+
+ static void fillResultIds(ResponseBuilder rb){
Review comment:
https://issues.apache.org/jira/browse/SOLR-13576 opened for this fairly
independent refactoring here.
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] [Updated] (SOLR-13576) factor out a TopGroupsShardResponseProcessor.fillResultIds method
[
https://issues.apache.org/jira/browse/SOLR-13576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13576:
---
Status: Patch Available (was: Open)
> factor out a TopGroupsShardResponseProcessor.fillResultIds method
> -
>
> Key: SOLR-13576
> URL: https://issues.apache.org/jira/browse/SOLR-13576
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13576.patch
>
>
> The {{TopGroupsShardResponseProcessor.process}} method e.g.
> [#L54-L215|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L54-L215]
> does quite a few things and factoring out a {{fillResultIds}} (or similarly
> named) method for the logically distinct
> [#L192-L214|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L192-L214]
> portion could help with code comprehension.
--
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-13576) factor out a TopGroupsShardResponseProcessor.fillResultIds method
[
https://issues.apache.org/jira/browse/SOLR-13576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872273#comment-16872273
]
Christine Poerschke commented on SOLR-13576:
"factor out a TopGroupsShardResponseProcessor.fillResultIds method (Christine
Poerschke, Diego Ceccarelli)" patch attached. Will commit in a couple of days
if no questions or concerns.
> factor out a TopGroupsShardResponseProcessor.fillResultIds method
> -
>
> Key: SOLR-13576
> URL: https://issues.apache.org/jira/browse/SOLR-13576
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13576.patch
>
>
> The {{TopGroupsShardResponseProcessor.process}} method e.g.
> [#L54-L215|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L54-L215]
> does quite a few things and factoring out a {{fillResultIds}} (or similarly
> named) method for the logically distinct
> [#L192-L214|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L192-L214]
> portion could help with code comprehension.
--
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-13576) factor out a TopGroupsShardResponseProcessor.fillResultIds method
[
https://issues.apache.org/jira/browse/SOLR-13576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13576:
---
Attachment: SOLR-13576.patch
> factor out a TopGroupsShardResponseProcessor.fillResultIds method
> -
>
> Key: SOLR-13576
> URL: https://issues.apache.org/jira/browse/SOLR-13576
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13576.patch
>
>
> The {{TopGroupsShardResponseProcessor.process}} method e.g.
> [#L54-L215|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L54-L215]
> does quite a few things and factoring out a {{fillResultIds}} (or similarly
> named) method for the logically distinct
> [#L192-L214|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L192-L214]
> portion could help with code comprehension.
--
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-13576) factor out a TopGroupsShardResponseProcessor.fillResultIds method
[
https://issues.apache.org/jira/browse/SOLR-13576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872272#comment-16872272
]
Christine Poerschke commented on SOLR-13576:
In the context of SOLR-11831 the method (if it has package visibility) would
also help avoid code duplication:
* https://github.com/apache/lucene-solr/pull/300#discussion_r276714459
*
https://github.com/cpoerschke/lucene-solr/commit/1570f7c0ad0194681897403613e87cfad367d577
* https://github.com/apache/lucene-solr/pull/300#discussion_r290346022
*
https://github.com/apache/lucene-solr/commit/a7df0c0d8d9c292998df1e12848735eaa662ff38
> factor out a TopGroupsShardResponseProcessor.fillResultIds method
> -
>
> Key: SOLR-13576
> URL: https://issues.apache.org/jira/browse/SOLR-13576
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> The {{TopGroupsShardResponseProcessor.process}} method e.g.
> [#L54-L215|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L54-L215]
> does quite a few things and factoring out a {{fillResultIds}} (or similarly
> named) method for the logically distinct
> [#L192-L214|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L192-L214]
> portion could help with code comprehension.
--
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-13576) factor out a TopGroupsShardResponseProcessor.fillResultIds method
Christine Poerschke created SOLR-13576:
--
Summary: factor out a
TopGroupsShardResponseProcessor.fillResultIds method
Key: SOLR-13576
URL: https://issues.apache.org/jira/browse/SOLR-13576
Project: Solr
Issue Type: Task
Reporter: Christine Poerschke
Assignee: Christine Poerschke
The {{TopGroupsShardResponseProcessor.process}} method e.g.
[#L54-L215|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L54-L215]
does quite a few things and factoring out a {{fillResultIds}} (or similarly
named) method for the logically distinct
[#L192-L214|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L192-L214]
portion could help with code comprehension.
--
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-8878) Provide alternative sorting utility from SortField other than FieldComparator
[
https://issues.apache.org/jira/browse/LUCENE-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872270#comment-16872270
]
Michael McCandless commented on LUCENE-8878:
+1 to simplify Lucene's comparator APIs – they are crazy complicated because
they are "hiding" a priority queue underneath. They look nothing like you'd
expect a comparator to look like! They were designed this way to sometimes
enable int ordinal comparisons when sorting by string fields
({{DocValuesType.SORTED}}) but I'm not sure all that API complexity is really
worth the performance.
To access the values can we somehow use the existing {{FunctionValues}} classes?
> Provide alternative sorting utility from SortField other than FieldComparator
> -
>
> Key: LUCENE-8878
> URL: https://issues.apache.org/jira/browse/LUCENE-8878
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: 8.1.1
>Reporter: Tony Xu
>Priority: Major
>
> The `FieldComparator` has many responsibilities and users get all of them at
> once. At high level the main functionalities of `FieldComparator` are
> * Provide LeafFieldComparator
> * Allocate storage for requested number of hits
> * Read the values from DocValues/Custom source etc.
> * Compare two values
> There are two major areas for improvement
> # The logic of reading values and storing them are coupled.
> # User need to specify the size in order to create a `FieldComparator` but
> sometimes the size is unknown upfront.
> # From `FieldComparator`'s API, one can't reason about thread-safety so it
> is not suitable for concurrent search.
> E.g. Can two concurrent thread use the same `FieldComparator` to call
> `getLeafComparator` for two different segments they are working on? In fact,
> almost all existing implementations of `FieldComparator` are not thread-safe.
> The proposal is to enhance `SortField` with two APIs
> # {color:#14892c}int compare(Object v1, Object v2){color} – this is to
> compare two values from different docs for this field
> # {color:#14892c}ValueAccessor newValueAccessor(LeafReaderContext
> leaf){color} – This encapsulate the logic for obtaining the right
> implementation in order to read the field values.
> `ValueAccessor` should be accessed in a similar way as `DocValues` to
> provide the sort value for a document in an advance & read fashion.
> With this API, hopefully we can reduce the memory usage when using
> `FieldComparator` because the users either store the sort values or at least
> the slot number besides the storage allocated by `FieldComparator` itself.
> Ideally, only once copy of the values should be stored.
> The proposed API is also more friendly to concurrent search since it provides
> the `ValueAccessor` per leaf. Although same `ValueAccessor` can't be shared
> if there are more than one thread working on the same leaf, at least they can
> initialize their own `ValueAccessor`.
--
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-EA] Lucene-Solr-master-Linux (64bit/jdk-13-ea+shipilev-fastdebug) - Build # 24287 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24287/ Java: 64bit/jdk-13-ea+shipilev-fastdebug -XX:-UseCompressedOops -XX:+UseG1GC 8 tests failed. FAILED: org.apache.solr.update.processor.ParsingFieldUpdateProcessorsTest.testParseFloatNonRootLocale Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([917D4659E782D7C8:8AA1BB8847272BD5]: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.update.processor.ParsingFieldUpdateProcessorsTest.testParseFloatNonRootLocale(ParsingFieldUpdateProcessorsTest.java:471) 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:830) FAILED: org.apache.solr.update.processor.ParsingFieldUpdateProcessorsTest.testParseDoubleNonRootLocale Error Message: Stack Trace: java.lang.AssertionError at
[jira] [Commented] (SOLR-13573) Add getters to SolrRangeQuery for lower and upper values
[
https://issues.apache.org/jira/browse/SOLR-13573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872249#comment-16872249
]
Lucene/Solr QA commented on SOLR-13573:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
0s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 53s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 51m 39s{color}
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 58m 25s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.TestLockTree |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13573 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12972796/SOLR-13573.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 / b85840b |
| 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/460/artifact/out/patch-unit-solr_core.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/460/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/460/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Add getters to SolrRangeQuery for lower and upper values
>
>
> Key: SOLR-13573
> URL: https://issues.apache.org/jira/browse/SOLR-13573
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7, 8.1.1
>Reporter: Brian Rhees
>Priority: Minor
> Attachments: SOLR-13573.patch
>
>
> SolrRangeQuery has no getters for the lower/upper values once set (other than
> calling toString). Adding getters will help users extract those values after
> an object has been created.
--
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-13569) AdminUI visual indication of prod/test/dev environment
[
https://issues.apache.org/jira/browse/SOLR-13569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872238#comment-16872238
]
Christine Poerschke commented on SOLR-13569:
I like the idea of visually differentiating clusters.
A question about the
{{-Dsolr.environment=test;label=Functional_test;color=brown}} example in the
{{solr.in.sh}} file: does the choice of semi-colon as a delimiter give rise to
{code}
-Dsolr.environment=test
{code}
vs.
{code}
-Dsolr.environment=test;label=Functional_test;color=brown
{code}
vs.
{code}
-Dsolr.environment="test;label=Functional_test;color=brown"
{code}
or
{code}
-Dsolr.environment=test\;label=Functional_test\;color=brown
{code}
subtlety i.e. if only the environment is specified then that is that but if
label and/or color is specified too then quoting or escaping of the semi-colon
would be required, for the {{solr.in.sh}} file at least; not sure what
equivalent in the {{solr.in.cmd}} file would be?
> AdminUI visual indication of prod/test/dev environment
> --
>
> Key: SOLR-13569
> URL: https://issues.apache.org/jira/browse/SOLR-13569
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: Environment-hint.png, prod-example.png, test-example.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To guard against accidentally changing the wrong cluster, we should add a
> visual indication in the Admin UI of whether you currently work with a
> production environment or not, e.g. a red bar on top with an optional
> environment label, see sketch. The bar could by default be red for
> production, yellow for test and green for dev.
> !Environment-hint.png|width=700!
--
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 Munendra S N as Lucene/Solr committer
Welcome Munendra! Christine From: dev@lucene.apache.org At: 06/21/19 14:50:57To: dev@lucene.apache.org Subject: Re: Welcome Munendra S N as Lucene/Solr committer Thanks Ishan, and thank you everyone for this opportunity I came across Lucene/Solr when I joined as Software Engineer at Unbxd. I have been working with Lucene/Solr from past 3 years and started contributing from past 2 years. I'm delighted to be part of this great team. Looking forward to the exciting times. Regards, Munendra S N On Fri, Jun 21, 2019 at 4:52 PM Jan Høydahl wrote: Welcome Munendra! -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com 21. jun. 2019 kl. 11:41 skrev Ishan Chattopadhyaya : Hi all, Please join me in welcoming Munendra as a Lucene/Solr committer! Munendra has been working on bug fixes and improvements in various parts of Solr. Congratulations and welcome! It is a tradition to introduce yourself with a brief bio, Munendra. Ishan - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8806) WANDScorer should support two-phase iterator
[ https://issues.apache.org/jira/browse/LUCENE-8806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872213#comment-16872213 ] Jim Ferenczi commented on LUCENE-8806: -- I am testing with wikimediumall > WANDScorer should support two-phase iterator > > > Key: LUCENE-8806 > URL: https://issues.apache.org/jira/browse/LUCENE-8806 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jim Ferenczi >Priority: Major > Attachments: LUCENE-8806.patch, LUCENE-8806.patch > > > Following https://issues.apache.org/jira/browse/LUCENE-8770 the WANDScorer > should leverage two-phase iterators in order to be faster when used in > conjunctions. -- 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-8806) WANDScorer should support two-phase iterator
[ https://issues.apache.org/jira/browse/LUCENE-8806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872205#comment-16872205 ] Adrien Grand commented on LUCENE-8806: -- Oh, that is interesting. Are you testing on wikibigall or one of the wikimedium datasets that has truncated content? > WANDScorer should support two-phase iterator > > > Key: LUCENE-8806 > URL: https://issues.apache.org/jira/browse/LUCENE-8806 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jim Ferenczi >Priority: Major > Attachments: LUCENE-8806.patch, LUCENE-8806.patch > > > Following https://issues.apache.org/jira/browse/LUCENE-8770 the WANDScorer > should leverage two-phase iterators in order to be faster when used in > conjunctions. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13566) REINDEXCOLLECTION does not work with (basic) authentication
[
https://issues.apache.org/jira/browse/SOLR-13566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872172#comment-16872172
]
Andrzej Bialecki edited comment on SOLR-13566 at 6/25/19 9:14 AM:
---
{quote}But I was wondering if there should instead be a cached or fixed thread
pool for all DaemonStreams to limit the number of concurrent DaemonStreams? Or
are they limited elsewhere? Or are they intentionally unlimited?
{quote}
That's an excellent question. IMHO they should be limited (because everything
has its limits) but looking at the existing API it's not clear where the pool
should be created and injected (CoreContainer? SolrCore? StreamFactory?) and
what the default limits should be.
Since this specific issue is about a bug and not an optimization let's fix this
bug first and address the limits in another issue (SOLR-13575).
was (Author: ab):
{quote}But I was wondering if there should instead be a cached or fixed thread
pool for all DaemonStreams to limit the number of concurrent DaemonStreams? Or
are they limited elsewhere? Or are they intentionally unlimited?
{quote}
That's an excellent question. IMHO they should be limited (because everything
has its limits) but looking at the existing API it's not clear where the pool
should be created and injected (CoreContainer? SolrCore? StreamFactory?) and
what the default limits should be.
Since this specific issue is about a bug and not an optimization let's fix this
bug first and address the limits in another issue.
> REINDEXCOLLECTION does not work with (basic) authentication
> ---
>
> Key: SOLR-13566
> URL: https://issues.apache.org/jira/browse/SOLR-13566
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.1.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.1.2
>
> Attachments: SOLR-13566.patch, SOLR-13566.patch, SOLR-13566.patch,
> responses.txt, security.json, solr.log
>
>
> I'm on the Solr 8.1 branch off commit
> f26388d034fe5eadca7416aa63b509b8db2c7688 so I have the authentication fixes
> from SOLR-13510 (intermittent 401s for internode requests)
>
> When trying to use the new REINDEXCOLLECTION command introduced in
> SOLR-11127 with basic auth enabled, the daemon stream fails with repeated
> 401s when trying to access the target collection.
>
> This might be the same problem as SOLR-13472, except it applies even with a
> single node, and this doesn't require role based configuration.
>
> Repro: I added a reindex request in BasicAuthIntegrationTest and it is
> reproducible in there... I don't know what effect it should have on the auth
> metrics, if it were working correctly, so I don't know how to update the test
> properly. But you can add the request towards the end of
> org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth()
>
> _CollectionAdminRequest.ReindexCollection reindexReq =
> CollectionAdminRequest.reindexCollection(COLLECTION);_
> _reindexReq.setBasicAuthCredentials("harry", "HarryIsUberCool");_
> _cluster.getSolrClient().request(reindexReq, COLLECTION);_
>
> Manual Repro:
> run bin/solr -e cloud
> Choose 1 node / 1 shard / 1 replica
> In browser GET
> [http://localhost:8983/solr/admin/collections?action=REINDEXCOLLECTION=gettingstarted]
> will succeed
> Enable security: server\scripts\cloud-scripts\zkcli -zkhost localhost:9983
> -cmd putfile /security.json
>
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials":
> { "solradmin": "fskh17INKrOTSRCJ8HkamA0L6Uiq1dSMgn4OVy8htME=
> /Q4VgOkwVlP6AMVY+ML+IuodbfV81WEfZ3lFb390bws=" }
> }
> }
>
>
> In browser authenticate (as solradmin : solradmin) and GET
> [http://localhost:8983/solr/admin/collections?action=REINDEXCOLLECTION=gettingstarted]
> will time out after 180 seconds
>
> The solr log will show repeated 401s
>
> Setting "forwardCredentials" : true in the security.json does not appear to
> change the outcome.
>
>
> The daemon stream should probably be using PKI auth for the internal request.
>
--
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-13575) DaemonStream-s should use a pool of threads
Andrzej Bialecki created SOLR-13575:
Summary: DaemonStream-s should use a pool of threads
Key: SOLR-13575
URL: https://issues.apache.org/jira/browse/SOLR-13575
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: streaming expressions
Reporter: Andrzej Bialecki
Spin-off from SOLR-13566: currently it's possible to create unlimited number of
DaemonStream-s, with each stream adding a single thread per core. This may
easily lead to resource exhaustion.
DaemonStream-s should use a thread pool with limited max number of threads,
managed by Solr (ie. created with {{ExecutorUtil}}). An open issue is where the
pool should be created and maintained in the existing API - possible candidates
are: CoreContainer, SolrCore, or StreamFactory.
--
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-13566) REINDEXCOLLECTION does not work with (basic) authentication
[
https://issues.apache.org/jira/browse/SOLR-13566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872172#comment-16872172
]
Andrzej Bialecki commented on SOLR-13566:
--
{quote}But I was wondering if there should instead be a cached or fixed thread
pool for all DaemonStreams to limit the number of concurrent DaemonStreams? Or
are they limited elsewhere? Or are they intentionally unlimited?
{quote}
That's an excellent question. IMHO they should be limited (because everything
has its limits) but looking at the existing API it's not clear where the pool
should be created and injected (CoreContainer? SolrCore? StreamFactory?) and
what the default limits should be.
Since this specific issue is about a bug and not an optimization let's fix this
bug first and address the limits in another issue.
> REINDEXCOLLECTION does not work with (basic) authentication
> ---
>
> Key: SOLR-13566
> URL: https://issues.apache.org/jira/browse/SOLR-13566
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.1.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.1.2
>
> Attachments: SOLR-13566.patch, SOLR-13566.patch, SOLR-13566.patch,
> responses.txt, security.json, solr.log
>
>
> I'm on the Solr 8.1 branch off commit
> f26388d034fe5eadca7416aa63b509b8db2c7688 so I have the authentication fixes
> from SOLR-13510 (intermittent 401s for internode requests)
>
> When trying to use the new REINDEXCOLLECTION command introduced in
> SOLR-11127 with basic auth enabled, the daemon stream fails with repeated
> 401s when trying to access the target collection.
>
> This might be the same problem as SOLR-13472, except it applies even with a
> single node, and this doesn't require role based configuration.
>
> Repro: I added a reindex request in BasicAuthIntegrationTest and it is
> reproducible in there... I don't know what effect it should have on the auth
> metrics, if it were working correctly, so I don't know how to update the test
> properly. But you can add the request towards the end of
> org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth()
>
> _CollectionAdminRequest.ReindexCollection reindexReq =
> CollectionAdminRequest.reindexCollection(COLLECTION);_
> _reindexReq.setBasicAuthCredentials("harry", "HarryIsUberCool");_
> _cluster.getSolrClient().request(reindexReq, COLLECTION);_
>
> Manual Repro:
> run bin/solr -e cloud
> Choose 1 node / 1 shard / 1 replica
> In browser GET
> [http://localhost:8983/solr/admin/collections?action=REINDEXCOLLECTION=gettingstarted]
> will succeed
> Enable security: server\scripts\cloud-scripts\zkcli -zkhost localhost:9983
> -cmd putfile /security.json
>
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials":
> { "solradmin": "fskh17INKrOTSRCJ8HkamA0L6Uiq1dSMgn4OVy8htME=
> /Q4VgOkwVlP6AMVY+ML+IuodbfV81WEfZ3lFb390bws=" }
> }
> }
>
>
> In browser authenticate (as solradmin : solradmin) and GET
> [http://localhost:8983/solr/admin/collections?action=REINDEXCOLLECTION=gettingstarted]
> will time out after 180 seconds
>
> The solr log will show repeated 401s
>
> Setting "forwardCredentials" : true in the security.json does not appear to
> change the outcome.
>
>
> The daemon stream should probably be using PKI auth for the internal request.
>
--
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-8806) WANDScorer should support two-phase iterator
[
https://issues.apache.org/jira/browse/LUCENE-8806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872169#comment-16872169
]
Jim Ferenczi commented on LUCENE-8806:
--
{quote}
FYI we have an issue for phrases already LUCENE-8311.
{quote}
I forgot about this one, thanks!
{quote}
I was thinking this could only get faster than before since we would now
leverage two-phase iterators instead of using iterators naively.
{quote}
That was my assumption too but not checking the two-phase iterator when looking
for candidates forces the second clause (the one with the lowest score) to
advance even when the first clause is a false positive. So It might be related
to the fact that checking for a match on high frequency phrases is faster than
advancing the other clause.
> WANDScorer should support two-phase iterator
>
>
> Key: LUCENE-8806
> URL: https://issues.apache.org/jira/browse/LUCENE-8806
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8806.patch, LUCENE-8806.patch
>
>
> Following https://issues.apache.org/jira/browse/LUCENE-8770 the WANDScorer
> should leverage two-phase iterators in order to be faster when used in
> conjunctions.
--
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
