[jira] [Commented] (SOLR-13691) Add example field type configurations using "name" attributes to Ref Guide
[
https://issues.apache.org/jira/browse/SOLR-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919243#comment-16919243
]
Tomoko Uchida commented on SOLR-13691:
--
Here is the patch [^SOLR-13691.patch] including only changes for
{{analyzers.adoc}}. Other files - {{tokenizers.adoc}},
{{filter-descriptions.adoc}}, and so on - would need to be updated in a similar
way.
Is there any good methods to automatically convert them...
> Add example field type configurations using "name" attributes to Ref Guide
> --
>
> Key: SOLR-13691
> URL: https://issues.apache.org/jira/browse/SOLR-13691
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-13691.patch, Screenshot from 2019-08-30
> 14-19-01.png, Screenshot from 2019-08-30 14-19-09.png
>
>
> This is a follow-up task for SOLR-13593.
> To encourage users to use the "name" attribute in field type configurations,
> we should add examples that includes "name" instead of "class" (and mark
> "Legacy" to the old examples).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13691) Add example field type configurations using "name" attributes to Ref Guide
[ https://issues.apache.org/jira/browse/SOLR-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated SOLR-13691: - Attachment: SOLR-13691.patch > Add example field type configurations using "name" attributes to Ref Guide > -- > > Key: SOLR-13691 > URL: https://issues.apache.org/jira/browse/SOLR-13691 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-13691.patch, Screenshot from 2019-08-30 > 14-19-01.png, Screenshot from 2019-08-30 14-19-09.png > > > This is a follow-up task for SOLR-13593. > To encourage users to use the "name" attribute in field type configurations, > we should add examples that includes "name" instead of "class" (and mark > "Legacy" to the old examples). -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13691) Add example field type configurations using "name" attributes to Ref Guide
[ https://issues.apache.org/jira/browse/SOLR-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated SOLR-13691: - Fix Version/s: master (9.0) > Add example field type configurations using "name" attributes to Ref Guide > -- > > Key: SOLR-13691 > URL: https://issues.apache.org/jira/browse/SOLR-13691 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Attachments: Screenshot from 2019-08-30 14-19-01.png, Screenshot from > 2019-08-30 14-19-09.png > > > This is a follow-up task for SOLR-13593. > To encourage users to use the "name" attribute in field type configurations, > we should add examples that includes "name" instead of "class" (and mark > "Legacy" to the old examples). -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13593) Allow to look-up analyzer components by their SPI names in field type configuration
[
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919212#comment-16919212
]
Tomoko Uchida commented on SOLR-13593:
--
I have started to work for Ref Guide (SOLR-13691). Though I'm not an expert on
AsciiDoc/asciidoctor, it seems we can place "name=" examples for all analyzer
documentation while keeping "class=" examples as is, with dynamic tabs (please
see the screenshots on the issue).
> Allow to look-up analyzer components by their SPI names in field type
> configuration
> ---
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-13593-add-spi-ReversedWildcardFilterFactory.patch,
> SOLR-13593.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Now each analysis factory has explicitely documented SPI name which is stored
> in the static "NAME" field (LUCENE-8778).
> Solr uses factories' simple class name in schema definition (like
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
>
>
>
> />
>
>
>
> {code}
> would be
> {code:xml}
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13691) Add example field type configurations using "name" attributes to Ref Guide
[ https://issues.apache.org/jira/browse/SOLR-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919202#comment-16919202 ] Tomoko Uchida commented on SOLR-13691: -- We can add "name" examples along with "class" examples to the Ref Guide's Analyzer section, with dynamic tabs like this: *"name=" example* !Screenshot from 2019-08-30 14-19-01.png! *"class=" example* !Screenshot from 2019-08-30 14-19-09.png! > Add example field type configurations using "name" attributes to Ref Guide > -- > > Key: SOLR-13691 > URL: https://issues.apache.org/jira/browse/SOLR-13691 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Tomoko Uchida >Priority: Major > Attachments: Screenshot from 2019-08-30 14-19-01.png, Screenshot from > 2019-08-30 14-19-09.png > > > This is a follow-up task for SOLR-13593. > To encourage users to use the "name" attribute in field type configurations, > we should add examples that includes "name" instead of "class" (and mark > "Legacy" to the old examples). -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13691) Add example field type configurations using "name" attributes to Ref Guide
[ https://issues.apache.org/jira/browse/SOLR-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated SOLR-13691: - Attachment: Screenshot from 2019-08-30 14-19-01.png > Add example field type configurations using "name" attributes to Ref Guide > -- > > Key: SOLR-13691 > URL: https://issues.apache.org/jira/browse/SOLR-13691 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Tomoko Uchida >Priority: Major > Attachments: Screenshot from 2019-08-30 14-19-01.png, Screenshot from > 2019-08-30 14-19-09.png > > > This is a follow-up task for SOLR-13593. > To encourage users to use the "name" attribute in field type configurations, > we should add examples that includes "name" instead of "class" (and mark > "Legacy" to the old examples). -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13691) Add example field type configurations using "name" attributes to Ref Guide
[ https://issues.apache.org/jira/browse/SOLR-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated SOLR-13691: - Attachment: Screenshot from 2019-08-30 14-19-09.png > Add example field type configurations using "name" attributes to Ref Guide > -- > > Key: SOLR-13691 > URL: https://issues.apache.org/jira/browse/SOLR-13691 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Tomoko Uchida >Priority: Major > Attachments: Screenshot from 2019-08-30 14-19-01.png, Screenshot from > 2019-08-30 14-19-09.png > > > This is a follow-up task for SOLR-13593. > To encourage users to use the "name" attribute in field type configurations, > we should add examples that includes "name" instead of "class" (and mark > "Legacy" to the old examples). -- This message was sent by Atlassian Jira (v8.3.2#803003) - 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&focusedCommentId=16919200#comment-16919200 ] David Smiley commented on SOLR-12638: - Thanks Moshe; you are right. Still, I think there is probably more we can do to have Solr be friendlier in this regard. If the user forgets about the specific/unusual settings of the root field in the schema, and nonetheless tries to do a partial-update, then it's a bad/confusing user experience. To help I think we can throw an error in this case: SOLR-13728. > 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 (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13728) Fail partial updates if it would inadvertently remove nested docs
[ https://issues.apache.org/jira/browse/SOLR-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-13728: Attachment: SOLR-13728.patch Status: Patch Available (was: Patch Available) > Fail partial updates if it would inadvertently remove nested docs > - > > Key: SOLR-13728 > URL: https://issues.apache.org/jira/browse/SOLR-13728 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Attachments: SOLR-13728.patch > > > In SOLR-12638 Solr gained the ability to do partial updates (aka atomic > updates) to nested documents. However this feature only works if the schema > meets certain circumstances. We can know we don't support it and fail the > request – what I propose here. This is much friendlier than wiping out > existing documents. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13728) Fail partial updates if it would inadvertently remove nested docs
[ https://issues.apache.org/jira/browse/SOLR-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-13728: Status: Patch Available (was: Open) > Fail partial updates if it would inadvertently remove nested docs > - > > Key: SOLR-13728 > URL: https://issues.apache.org/jira/browse/SOLR-13728 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > > In SOLR-12638 Solr gained the ability to do partial updates (aka atomic > updates) to nested documents. However this feature only works if the schema > meets certain circumstances. We can know we don't support it and fail the > request – what I propose here. This is much friendlier than wiping out > existing documents. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13728) Fail partial updates if it would inadvertently remove nested docs
David Smiley created SOLR-13728: --- Summary: Fail partial updates if it would inadvertently remove nested docs Key: SOLR-13728 URL: https://issues.apache.org/jira/browse/SOLR-13728 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: David Smiley Assignee: David Smiley In SOLR-12638 Solr gained the ability to do partial updates (aka atomic updates) to nested documents. However this feature only works if the schema meets certain circumstances. We can know we don't support it and fail the request – what I propose here. This is much friendlier than wiping out existing documents. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13593) Allow to look-up analyzer components by their SPI names in field type configuration
[
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919126#comment-16919126
]
Tomoko Uchida commented on SOLR-13593:
--
FYI, there is another follow-up task SOLR-13691 to add examples using the
"name=...". It would be another way to find the "name"s. In another words, the
way to find the each factory's identifier (whether "name" or "class") would be
the same as before - the Ref Guide or bundled schema examples.
> Allow to look-up analyzer components by their SPI names in field type
> configuration
> ---
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-13593-add-spi-ReversedWildcardFilterFactory.patch,
> SOLR-13593.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Now each analysis factory has explicitely documented SPI name which is stored
> in the static "NAME" field (LUCENE-8778).
> Solr uses factories' simple class name in schema definition (like
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
>
>
>
> />
>
>
>
> {code}
> would be
> {code:xml}
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 3648 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3648/ 1 tests failed. FAILED: org.apache.solr.schema.TestCloudSchemaless.test Error Message: Error from server at http://127.0.0.1:36841/d/collection1: 3 Async exceptions during distributed update: java.util.concurrent.TimeoutException: idle_timeout java.util.concurrent.TimeoutException: idle_timeout java.util.concurrent.TimeoutException: idle_timeout Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:36841/d/collection1: 3 Async exceptions during distributed update: java.util.concurrent.TimeoutException: idle_timeout java.util.concurrent.TimeoutException: idle_timeout java.util.concurrent.TimeoutException: idle_timeout at __randomizedtesting.SeedInfo.seed([F4BBC4C798DC9271:7CEFFB1D3620FF89]: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.SolrRequest.process(SolrRequest.java:207) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85) at org.apache.solr.schema.TestCloudSchemaless.test(TestCloudSchemaless.java:115) 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.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.
[jira] [Commented] (SOLR-13593) Allow to look-up analyzer components by their SPI names in field type configuration
[
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919094#comment-16919094
]
Tomoko Uchida commented on SOLR-13593:
--
The (SPI) names for all factories were already documented in the Javadocs (it
was the motivation for LUCENE-8778). I think we can add some notes to the Ref
Guide that where one can find the "name"s.
> Allow to look-up analyzer components by their SPI names in field type
> configuration
> ---
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-13593-add-spi-ReversedWildcardFilterFactory.patch,
> SOLR-13593.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Now each analysis factory has explicitely documented SPI name which is stored
> in the static "NAME" field (LUCENE-8778).
> Solr uses factories' simple class name in schema definition (like
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
>
>
>
> />
>
>
>
> {code}
> would be
> {code:xml}
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13105) A visual guide to Solr Math Expressions and Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919088#comment-16919088
]
ASF subversion and git services commented on SOLR-13105:
Commit 1746a08f5b1123b0633451faf7a46d4b5a5c7af9 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1746a08 ]
SOLR-13105: Update search/sample/agg viz5
> 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
(v8.3.2#803003)
-
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 # 1945 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1945/ No tests ran. Build Log: [...truncated 25 lines...] ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the server svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ... 4 more java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
[jira] [Commented] (SOLR-13105) A visual guide to Solr Math Expressions and Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919075#comment-16919075
]
ASF subversion and git services commented on SOLR-13105:
Commit 9502db30853fadc9af61caeb7c255fac97a4f9fb in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9502db3 ]
SOLR-13105: Update search/sample/agg viz4
> 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
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13105) A visual guide to Solr Math Expressions and Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919065#comment-16919065
]
ASF subversion and git services commented on SOLR-13105:
Commit 8b6a45520eae17a25077e16ff68e76a778dd84c5 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8b6a455 ]
SOLR-13105: Update search/sample/agg viz3
> 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
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 3647 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3647/
All tests passed
Build Log:
[...truncated 63887 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj24631864
[ecj-lint] Compiling 1289 source files to /tmp/ecj24631864
[ecj-lint] Processing annotations
[ecj-lint] Annotations processed
[ecj-lint] Processing annotations
[ecj-lint] No elements to process
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
[ecj-lint] --
[ecj-lint] 1. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
(at line 219)
[ecj-lint] return (NamedList) new
JavaBinCodec(resolver).unmarshal(in);
[ecj-lint]^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 2. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java
(at line 232)
[ecj-lint] ReplicationHandler replicationHandler = (ReplicationHandler)
handler;
[ecj-lint]^^
[ecj-lint] Resource leak: 'replicationHandler' is never closed
[ecj-lint] --
[ecj-lint] 3. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java
(at line 628)
[ecj-lint] PeerSyncWithLeader peerSyncWithLeader = new
PeerSyncWithLeader(core,
[ecj-lint]^^
[ecj-lint] Resource leak: 'peerSyncWithLeader' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/SyncStrategy.java
(at line 186)
[ecj-lint] PeerSync peerSync = new PeerSync(core, syncWith,
core.getUpdateHandler().getUpdateLog().getNumRecordsToKeep(), true,
peerSyncOnlyWithActive, false);
[ecj-lint]
[ecj-lint] Resource leak: 'peerSync' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 5. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 788)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] 6. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 794)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 7. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/CoreContainer.java
(at line 726)
[ecj-lint] SolrFieldCacheBean fieldCacheBean = new SolrFieldCacheBean();
[ecj-lint]^^
[ecj-lint] Resource leak: 'fieldCacheBean' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 8. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 19)
[ecj-lint] import javax.naming.Context;
[ecj-lint]
[ecj-lint] The type javax.naming.Context is not accessible
[ecj-lint] --
[ecj-lint] 9. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 20)
[ecj-lint] import javax.naming.InitialContext;
[ecj-lint]^^^
[ecj-lint] The type javax.naming.InitialContext is not accessible
[ecj-lint] --
[ecj-lint] 10. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 21)
[ecj-lint] import javax.naming.NamingException;
[ecj-lint]
[ecj-lint] The type javax.naming.NamingException is not accessible
[ecj-lint] --
[ecj-lint] 11. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at
[jira] [Commented] (LUCENE-8758) Class Field levelN is not populated correctly in QuadPrefixTree
[
https://issues.apache.org/jira/browse/LUCENE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918958#comment-16918958
]
Lucene/Solr QA commented on LUCENE-8758:
| (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} 0m
42s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 0m 35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 0m 35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 0m 35s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m
18s{color} | {color:green} spatial-extras in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 5m 14s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8758 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12978887/LUCENE-8758.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24
10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 6dea678439 |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-LUCENE-Build/203/testReport/ |
| modules | C: lucene/spatial-extras U: lucene/spatial-extras |
| Console output |
https://builds.apache.org/job/PreCommit-LUCENE-Build/203/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Class Field levelN is not populated correctly in QuadPrefixTree
> ---
>
> Key: LUCENE-8758
> URL: https://issues.apache.org/jira/browse/LUCENE-8758
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial-extras
>Affects Versions: 4.0, 5.0, 6.0, 7.0, 8.0
>Reporter: Dominic Page
>Assignee: David Smiley
>Priority: Trivial
> Labels: beginner
> Fix For: 8.x
>
> Attachments: LUCENE-8758.patch
>
>
> QuadPrefixTree in Lucene prepopulates these arrays:
> {{levelW = new double[maxLevels];}}
> {{levelH = new double[maxLevels];}}
> {{*levelS = new int[maxLevels];*}}
> {{*levelN = new int[maxLevels];*}}
> Like this
> {{for (int i = 1; i < levelW.length; i++) {}}
> {{ levelW[i] = levelW[i - 1] / 2.0;}}
> {{ levelH[i] = levelH[i - 1] / 2.0;}}
> {{ *levelS[i] = levelS[i - 1] * 2;*}}
> {{ *levelN[i] = levelN[i - 1] * 4;*}}
> {{}}}
> The field
> {{levelN[]}}
> overflows after level 14 = 1073741824 where maxLevels is limited to
> {{MAX_LEVELS_POSSIBLE = 50;}}
> The field levelN appears not to be used anywhere. Likewise, the field
> {{levelS[] }}
> is only used in the
> {{printInfo}}
> method. I would propose either to remove both
> {{levelN[],}}{{levelS[]}}
> or to change the datatype
> {{levelN = new long[maxLevels];}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 196 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/196/ No tests ran. Build Log: [...truncated 25 lines...] ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the server svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ... 4 more java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
[JENKINS] Lucene-Solr-Tests-master - Build # 3646 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3646/ 1 tests failed. FAILED: org.apache.solr.search.facet.TestCloudJSONFacetJoinDomain.testRandom Error Message: Error from server at http://127.0.0.1:37373/solr/org.apache.solr.search.facet.TestCloudJSONFacetJoinDomain_collection: Expected mime type application/octet-stream but got text/html. Error 500 Server Error HTTP ERROR 500 Problem accessing /solr/org.apache.solr.search.facet.TestCloudJSONFacetJoinDomain_collection/select. Reason: Server ErrorCaused by:java.lang.AssertionError at java.base/java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1896) at java.base/java.util.HashMap$TreeNode.putTreeVal(HashMap.java:2061) at java.base/java.util.HashMap.putVal(HashMap.java:633) at java.base/java.util.HashMap.put(HashMap.java:607) at org.apache.solr.search.LRUCache.put(LRUCache.java:197) at org.apache.solr.search.SolrCacheHolder.put(SolrCacheHolder.java:88) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1449) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:568) at org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1484) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:398) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:305) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:200) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2598) at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:780) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:424) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:167) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335) at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:753) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.Server.handle(Server.java:505) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:781) at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:917) at java.base/java.lang.Thread.run(Thread.java:834) http://eclipse.org/jetty";>Powered by Jetty:// 9.4.19.v20190610 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:37373/solr/org.apache.solr.search.facet.TestCloudJSONFacetJoinDomain_collection: Expected mime type application/octet-stream but got text/html. Error 500 Server Error HTTP ERROR 500 Problem accessing /solr/org.apache.solr.search.facet.TestCloudJSONFacetJoinDomain_collection/select. Reason: Server ErrorCaused by:java.lang.AssertionError at java.base/java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1896) at java.base/java.util.HashMap$TreeNode.putTreeVal(HashMap.java:2061) at java.base/java.util.HashMap.putVal(HashMap.java:633) at java.base/java.util.HashMap.put(HashMap.java:607)
[jira] [Updated] (LUCENE-8758) Class Field levelN is not populated correctly in QuadPrefixTree
[
https://issues.apache.org/jira/browse/LUCENE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated LUCENE-8758:
-
Status: Patch Available (was: Open)
> Class Field levelN is not populated correctly in QuadPrefixTree
> ---
>
> Key: LUCENE-8758
> URL: https://issues.apache.org/jira/browse/LUCENE-8758
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial-extras
>Affects Versions: 4.0, 5.0, 6.0, 7.0, 8.0
>Reporter: Dominic Page
>Assignee: David Smiley
>Priority: Trivial
> Labels: beginner
> Fix For: 8.x
>
> Attachments: LUCENE-8758.patch
>
>
> QuadPrefixTree in Lucene prepopulates these arrays:
> {{levelW = new double[maxLevels];}}
> {{levelH = new double[maxLevels];}}
> {{*levelS = new int[maxLevels];*}}
> {{*levelN = new int[maxLevels];*}}
> Like this
> {{for (int i = 1; i < levelW.length; i++) {}}
> {{ levelW[i] = levelW[i - 1] / 2.0;}}
> {{ levelH[i] = levelH[i - 1] / 2.0;}}
> {{ *levelS[i] = levelS[i - 1] * 2;*}}
> {{ *levelN[i] = levelN[i - 1] * 4;*}}
> {{}}}
> The field
> {{levelN[]}}
> overflows after level 14 = 1073741824 where maxLevels is limited to
> {{MAX_LEVELS_POSSIBLE = 50;}}
> The field levelN appears not to be used anywhere. Likewise, the field
> {{levelS[] }}
> is only used in the
> {{printInfo}}
> method. I would propose either to remove both
> {{levelN[],}}{{levelS[]}}
> or to change the datatype
> {{levelN = new long[maxLevels];}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-8758) Class Field levelN is not populated correctly in QuadPrefixTree
[
https://issues.apache.org/jira/browse/LUCENE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley reassigned LUCENE-8758:
Assignee: David Smiley
> Class Field levelN is not populated correctly in QuadPrefixTree
> ---
>
> Key: LUCENE-8758
> URL: https://issues.apache.org/jira/browse/LUCENE-8758
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial-extras
>Affects Versions: 4.0, 5.0, 6.0, 7.0, 8.0
>Reporter: Dominic Page
>Assignee: David Smiley
>Priority: Trivial
> Labels: beginner
> Fix For: 8.x
>
> Attachments: LUCENE-8758.patch
>
>
> QuadPrefixTree in Lucene prepopulates these arrays:
> {{levelW = new double[maxLevels];}}
> {{levelH = new double[maxLevels];}}
> {{*levelS = new int[maxLevels];*}}
> {{*levelN = new int[maxLevels];*}}
> Like this
> {{for (int i = 1; i < levelW.length; i++) {}}
> {{ levelW[i] = levelW[i - 1] / 2.0;}}
> {{ levelH[i] = levelH[i - 1] / 2.0;}}
> {{ *levelS[i] = levelS[i - 1] * 2;*}}
> {{ *levelN[i] = levelN[i - 1] * 4;*}}
> {{}}}
> The field
> {{levelN[]}}
> overflows after level 14 = 1073741824 where maxLevels is limited to
> {{MAX_LEVELS_POSSIBLE = 50;}}
> The field levelN appears not to be used anywhere. Likewise, the field
> {{levelS[] }}
> is only used in the
> {{printInfo}}
> method. I would propose either to remove both
> {{levelN[],}}{{levelS[]}}
> or to change the datatype
> {{levelN = new long[maxLevels];}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8403) Support 'filtered' term vectors - don't require all terms to be present
[ https://issues.apache.org/jira/browse/LUCENE-8403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918913#comment-16918913 ] David Smiley commented on LUCENE-8403: -- RE a separate field: That's a valid approach, yes. I/Michael should have acknowledged that up front. However the trade-off is that it would mean analyzing the text all over again[1], and mucking with the higher level features to use a separate field for the term vector (e.g. in a highlighter). [1]: It'd be neat if somehow one IndexableField could _listen_ for analysis events processed from another field. It's probably possible to hack something up that works today assuming you know the order of fields. This might be used not only for populating term vectors but also for populating SortedSetDocValues sourced from analyzed terms. RE "There's no good technical reason to introduce a layering violation". It debatable if term vectors need to be seen as "layered". I understand that you do, and hence your strong opposition about the proposal here. > Support 'filtered' term vectors - don't require all terms to be present > --- > > Key: LUCENE-8403 > URL: https://issues.apache.org/jira/browse/LUCENE-8403 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Priority: Minor > Attachments: LUCENE-8403.patch > > > The genesis of this was a conversation and idea from [~dsmiley] several years > ago. > In order to optimize term vector storage, we may not actually need all tokens > to be present in the term vectors - and if so, ideally our codec could just > opt not to store them. > I attempted to fork the standard codec and override the TermVectorsFormat and > TermVectorsWriter to ignore storing certain Terms within a field. This > worked, however, CheckIndex checks that the terms present in the standard > postings are also present in the TVs, if TVs enabled. So this then doesn't > work as 'valid' according to CheckIndex. > Can the TermVectorsFormat be made in such a way to support configuration of > tokens that should not be stored (benefits: less storage, more optimal > retrieval per doc)? Is this valuable to the wider community? Is there a way > we can design this to not break CheckIndex's contract while at the same time > lessening storage for unneeded tokens? -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8403) Support 'filtered' term vectors - don't require all terms to be present
[ https://issues.apache.org/jira/browse/LUCENE-8403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918910#comment-16918910 ] Robert Muir commented on LUCENE-8403: - My opinion remains the same, it makes no sense to disable checkindex here. There's no good technical reason to introduce a layering violation, and "filter" terms out at the encoding level. It makes no sense at all. You can simply add a separate field with the subset of terms instead. I have the feeling features such as this are often pushed because users don't understand how indexes work, and assume that using a separate field will double-their space. That isn't a good argument for a stupid design, such users should be educated instead. > Support 'filtered' term vectors - don't require all terms to be present > --- > > Key: LUCENE-8403 > URL: https://issues.apache.org/jira/browse/LUCENE-8403 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Priority: Minor > Attachments: LUCENE-8403.patch > > > The genesis of this was a conversation and idea from [~dsmiley] several years > ago. > In order to optimize term vector storage, we may not actually need all tokens > to be present in the term vectors - and if so, ideally our codec could just > opt not to store them. > I attempted to fork the standard codec and override the TermVectorsFormat and > TermVectorsWriter to ignore storing certain Terms within a field. This > worked, however, CheckIndex checks that the terms present in the standard > postings are also present in the TVs, if TVs enabled. So this then doesn't > work as 'valid' according to CheckIndex. > Can the TermVectorsFormat be made in such a way to support configuration of > tokens that should not be stored (benefits: less storage, more optimal > retrieval per doc)? Is this valuable to the wider community? Is there a way > we can design this to not break CheckIndex's contract while at the same time > lessening storage for unneeded tokens? -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13720) Impossible to create effective ToParenBlockJoinQuery in custom QParser
[ https://issues.apache.org/jira/browse/SOLR-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev reassigned SOLR-13720: --- Assignee: Mikhail Khludnev > Impossible to create effective ToParenBlockJoinQuery in custom QParser > -- > > Key: SOLR-13720 > URL: https://issues.apache.org/jira/browse/SOLR-13720 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Affects Versions: 8.2 >Reporter: Stanislav Livotov >Assignee: Mikhail Khludnev >Priority: Minor > Labels: noob > Fix For: 8.3 > > Attachments: SOLR-13720.patch > > > According to Solr [ducumentation|#SolrPlugins-QParserPlugin] QParser is > treated as a legal plugin. > > However, it is impossible to create an effective ToParentBlockJoin query > without copy-pasting(BitDocIdSetFilterWrapper class and getCachedFilter > method from BlockJoinParentQParser) or dirty hacks(like creating > org.apache.solr.search.join package with some accessor method to > package-private methods in plugin code and adding it in WEB-INF/lib directory > in order to be loaded by the same ClassLoader). > I don't see a truly clean way how to fix it, but at least we can help custom > plugin developers to create it a little bit easier by making > BlockJoinParentQParser#getCachedFilter public and > BlockJoinParentQParser#BitDocIdSetFilterWrapper and providing getter for > BitDocIdSetFilterWrapper#filter. > > > In order to create -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13720) Impossible to create effective ToParenBlockJoinQuery in custom QParser
[ https://issues.apache.org/jira/browse/SOLR-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-13720: Description: According to Solr [documentation|#SolrPlugins-QParserPlugin] QParser is treated as a legal plugin. However, it is impossible to create an effective ToParentBlockJoin query without copy-pasting(BitDocIdSetFilterWrapper class and getCachedFilter method from BlockJoinParentQParser) or dirty hacks(like creating org.apache.solr.search.join package with some accessor method to package-private methods in plugin code and adding it in WEB-INF/lib directory in order to be loaded by the same ClassLoader). I don't see a truly clean way how to fix it, but at least we can help custom plugin developers to create it a little bit easier by making BlockJoinParentQParser#getCachedFilter public and BlockJoinParentQParser#BitDocIdSetFilterWrapper and providing getter for BitDocIdSetFilterWrapper#filter. In order to create was: According to Solr [ducumentation|#SolrPlugins-QParserPlugin] QParser is treated as a legal plugin. However, it is impossible to create an effective ToParentBlockJoin query without copy-pasting(BitDocIdSetFilterWrapper class and getCachedFilter method from BlockJoinParentQParser) or dirty hacks(like creating org.apache.solr.search.join package with some accessor method to package-private methods in plugin code and adding it in WEB-INF/lib directory in order to be loaded by the same ClassLoader). I don't see a truly clean way how to fix it, but at least we can help custom plugin developers to create it a little bit easier by making BlockJoinParentQParser#getCachedFilter public and BlockJoinParentQParser#BitDocIdSetFilterWrapper and providing getter for BitDocIdSetFilterWrapper#filter. In order to create > Impossible to create effective ToParenBlockJoinQuery in custom QParser > -- > > Key: SOLR-13720 > URL: https://issues.apache.org/jira/browse/SOLR-13720 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Affects Versions: 8.2 >Reporter: Stanislav Livotov >Assignee: Mikhail Khludnev >Priority: Minor > Labels: noob > Fix For: 8.3 > > Attachments: SOLR-13720.patch > > > According to Solr [documentation|#SolrPlugins-QParserPlugin] QParser is > treated as a legal plugin. > > However, it is impossible to create an effective ToParentBlockJoin query > without copy-pasting(BitDocIdSetFilterWrapper class and getCachedFilter > method from BlockJoinParentQParser) or dirty hacks(like creating > org.apache.solr.search.join package with some accessor method to > package-private methods in plugin code and adding it in WEB-INF/lib directory > in order to be loaded by the same ClassLoader). > I don't see a truly clean way how to fix it, but at least we can help custom > plugin developers to create it a little bit easier by making > BlockJoinParentQParser#getCachedFilter public and > BlockJoinParentQParser#BitDocIdSetFilterWrapper and providing getter for > BitDocIdSetFilterWrapper#filter. > > > In order to create -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13727) V2Requests: HttpSolrClient replaces first instance of "/solr" with "/api" instead of using regex pattern
Megan Carey created SOLR-13727: -- Summary: V2Requests: HttpSolrClient replaces first instance of "/solr" with "/api" instead of using regex pattern Key: SOLR-13727 URL: https://issues.apache.org/jira/browse/SOLR-13727 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: clients - java, v2 API Affects Versions: 8.2 Reporter: Megan Carey When the HttpSolrClient is formatting a V2Request, it needs to change the endpoint from the default "/solr/..." to "/api/...". It does so by simply calling String.replace, which replaces the first instance of "/solr" in the URL with "/api". In the case where the host's address starts with "solr" and the HTTP protocol is appended, this call changes the address for the request. Example: if baseUrl is "http://solr-host.com/8983/solr";, this call will change to "http:/api-host.com:8983/solr" We should use a regex pattern to ensure that we're replacing the correct portion of the URL. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13593) Allow to look-up analyzer components by their SPI names in field type configuration
[
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918841#comment-16918841
]
Alexandre Rafalovitch commented on SOLR-13593:
--
Do we have a list of all those *names* somewhere, accessible to a non-developer?
How would a user find additional documentation on properties for those names.
Or if they wanted to compose their own chain?
Previously, they searched/checked Javadoc by the class name. What would they do
now?
> Allow to look-up analyzer components by their SPI names in field type
> configuration
> ---
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-13593-add-spi-ReversedWildcardFilterFactory.patch,
> SOLR-13593.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Now each analysis factory has explicitely documented SPI name which is stored
> in the static "NAME" field (LUCENE-8778).
> Solr uses factories' simple class name in schema definition (like
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
>
>
>
> />
>
>
>
> {code}
> would be
> {code:xml}
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
[ https://issues.apache.org/jira/browse/SOLR-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918808#comment-16918808 ] Kevin Risden commented on SOLR-13726: - [~anshum] - curious if you have any opinions/thoughts here on not setting the useSubjectCredsOnly system property. I don't have a patch yet - since I think overall this needs a bit more thought about how we handle Kerberos in SolrJ. Ideally we wrap every SolrJ call internally with the explicit subject. This would avoid having to fall back to the JVM JAAS config unless explicitly required. The Hadoop UserGroupInformation class wraps a lot of the ugly internals of JVM JAAS configs, but it is a pretty heavy dependency to bring into SolrJ (its part of hadoop-common). But it might give some ideas on how to better handle this. > Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly > --- > > Key: SOLR-13726 > URL: https://issues.apache.org/jira/browse/SOLR-13726 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: Kevin Risden >Priority: Major > > Solr should avoid setting system properties that affect the entire JVM. > Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause > a bunch of issues if SolrJ is colocated with other Kerberos secured services. > Krb5HttpClientBuilder changes the JVM default to false if it is not set. It > is defaulting to true. This affects everything in the JVM. Since SolrJ is > meant to be client side, we should avoid doing this. > [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
[ https://issues.apache.org/jira/browse/SOLR-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918806#comment-16918806 ] Kevin Risden commented on SOLR-13726: - Some references about useSubjectCredsOnly: * Source where default is true - http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/security/jgss/GSSUtil.java#l259 * ugly issue where causes hung threads - https://risdenk.github.io/2018/03/15/hdf-apache-nifi-kerberos-errors-usesubjectcredsonly.html > Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly > --- > > Key: SOLR-13726 > URL: https://issues.apache.org/jira/browse/SOLR-13726 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Kevin Risden >Priority: Major > > Solr should avoid setting system properties that affect the entire JVM. > Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause > a bunch of issues if SolrJ is colocated with other Kerberos secured services. > Krb5HttpClientBuilder changes the JVM default to false if it is not set. It > is defaulting to true. This affects everything in the JVM. Since SolrJ is > meant to be client side, we should avoid doing this. > [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
[ https://issues.apache.org/jira/browse/SOLR-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-13726: Component/s: SolrJ > Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly > --- > > Key: SOLR-13726 > URL: https://issues.apache.org/jira/browse/SOLR-13726 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: Kevin Risden >Priority: Major > > Solr should avoid setting system properties that affect the entire JVM. > Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause > a bunch of issues if SolrJ is colocated with other Kerberos secured services. > Krb5HttpClientBuilder changes the JVM default to false if it is not set. It > is defaulting to true. This affects everything in the JVM. Since SolrJ is > meant to be client side, we should avoid doing this. > [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
[ https://issues.apache.org/jira/browse/SOLR-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918804#comment-16918804 ] Kevin Risden commented on SOLR-13726: - SOLR-7468 introduced this a long time ago. This came up recently while trying to debug an issue where the JVM hangs looking for Kerberos credentials. javax.security.auth.useSubjectCredsOnly=false causes this behavior. We should therefore definitely avoid setting the property. The warning should be enough to help correct this. In an ideal world, the SolrJ kerberos handling would automatically set the Java Subject and not have to worry about this setting being configured at all. > Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly > --- > > Key: SOLR-13726 > URL: https://issues.apache.org/jira/browse/SOLR-13726 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Kevin Risden >Priority: Major > > Solr should avoid setting system properties that affect the entire JVM. > Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause > a bunch of issues if SolrJ is colocated with other Kerberos secured services. > Krb5HttpClientBuilder changes the JVM default to false if it is not set. It > is defaulting to true. This affects everything in the JVM. Since SolrJ is > meant to be client side, we should avoid doing this. > [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
Kevin Risden created SOLR-13726: --- Summary: Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly Key: SOLR-13726 URL: https://issues.apache.org/jira/browse/SOLR-13726 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Kevin Risden Solr should avoid setting system properties that affect the entire JVM. Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause a bunch of issues if SolrJ is colocated with other Kerberos secured services. Krb5HttpClientBuilder changes the JVM default to false if it is not set. It is defaulting to true. This affects everything in the JVM. Since SolrJ is meant to be client side, we should avoid doing this. [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13690) Migrate field type configurations in default/example schema files to look up factories by "name"
[
https://issues.apache.org/jira/browse/SOLR-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918752#comment-16918752
]
Tomoko Uchida commented on SOLR-13690:
--
Solr users will notice the changes when they open Admin UI files menu. For
example:
!Screenshot from 2019-08-30 01-09-43.png!
> Migrate field type configurations in default/example schema files to look up
> factories by "name"
>
>
> Key: SOLR-13690
> URL: https://issues.apache.org/jira/browse/SOLR-13690
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-13690.patch, Screenshot from 2019-08-30 01-09-43.png
>
>
> This is a follow-up task for SOLR-13593.
> To encourage users to use the "name" attribute in field type configurations,
> we should migrate all managed-schema files bundled with Solr.
> There are 8 managed-schemas (except for test resources) in solr.
> {code}
> lucene-solr-mirror $ find solr -name "managed-schema" | grep -v test
> solr/server/solr/configsets/sample_techproducts_configs/conf/managed-schema
> solr/server/solr/configsets/_default/conf/managed-schema
> solr/example/files/conf/managed-schema
> solr/example/example-DIH/solr/solr/conf/managed-schema
> solr/example/example-DIH/solr/db/conf/managed-schema
> solr/example/example-DIH/solr/atom/conf/managed-schema
> solr/example/example-DIH/solr/mail/conf/managed-schema
> solr/example/example-DIH/solr/tika/conf/managed-schema
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13690) Migrate field type configurations in default/example schema files to look up factories by "name"
[
https://issues.apache.org/jira/browse/SOLR-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated SOLR-13690:
-
Attachment: Screenshot from 2019-08-30 01-09-43.png
> Migrate field type configurations in default/example schema files to look up
> factories by "name"
>
>
> Key: SOLR-13690
> URL: https://issues.apache.org/jira/browse/SOLR-13690
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-13690.patch, Screenshot from 2019-08-30 01-09-43.png
>
>
> This is a follow-up task for SOLR-13593.
> To encourage users to use the "name" attribute in field type configurations,
> we should migrate all managed-schema files bundled with Solr.
> There are 8 managed-schemas (except for test resources) in solr.
> {code}
> lucene-solr-mirror $ find solr -name "managed-schema" | grep -v test
> solr/server/solr/configsets/sample_techproducts_configs/conf/managed-schema
> solr/server/solr/configsets/_default/conf/managed-schema
> solr/example/files/conf/managed-schema
> solr/example/example-DIH/solr/solr/conf/managed-schema
> solr/example/example-DIH/solr/db/conf/managed-schema
> solr/example/example-DIH/solr/atom/conf/managed-schema
> solr/example/example-DIH/solr/mail/conf/managed-schema
> solr/example/example-DIH/solr/tika/conf/managed-schema
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
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 # 493 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/493/ 1 tests failed. FAILED: org.apache.solr.cloud.UnloadDistributedZkTest.test Error Message: Error from server at http://127.0.0.1:34774: ADDREPLICA failed to create replica Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:34774: ADDREPLICA failed to create replica at __randomizedtesting.SeedInfo.seed([49E4041409F004D7:C1B03BCEA70C692F]: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.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.UnloadDistributedZkTest.testCoreUnloadAndLeaders(UnloadDistributedZkTest.java:215) at org.apache.solr.cloud.UnloadDistributedZkTest.test(UnloadDistributedZkTest.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowi
[jira] [Commented] (SOLR-13593) Allow to look-up analyzer components by their SPI names in field type configuration
[
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918759#comment-16918759
]
Tomoko Uchida commented on SOLR-13593:
--
Hi all,
I attached a patch to SOLR-13690 to change all default/example schemas bundled
in Solr.
If there are no objections I will commit it to the master in shortly (so it
will be shipped with Solr 9.0, and users will notice the changes soon after the
first run).
> Allow to look-up analyzer components by their SPI names in field type
> configuration
> ---
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-13593-add-spi-ReversedWildcardFilterFactory.patch,
> SOLR-13593.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Now each analysis factory has explicitely documented SPI name which is stored
> in the static "NAME" field (LUCENE-8778).
> Solr uses factories' simple class name in schema definition (like
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
>
>
>
> />
>
>
>
> {code}
> would be
> {code:xml}
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13690) Migrate field type configurations in default/example schema files to look up factories by "name"
[
https://issues.apache.org/jira/browse/SOLR-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918742#comment-16918742
]
Tomoko Uchida commented on SOLR-13690:
--
This patch [^SOLR-13690.patch] changes all "class=" attributes to "name=" in
the bundled default/example schemas.
I tested the schemas by packaging Solr and manually creating fresh cores from
the configsets.
{code:java}
# techproducts example
./solr-9.0.0-SNAPSHOT/bin/solr -e techproducts
# _default schema
./solr-9.0.0-SNAPSHOT/bin/solr create -c newcore1
# example/files
./solr-9.0.0-SNAPSHOT/bin/solr create -c newcore2 -d
solr-9.0.0-SNAPSHOT/example/files/conf/
# example-DIH (solr)
./solr-9.0.0-SNAPSHOT/bin/solr create -c newcore3 -d
solr-9.0.0-SNAPSHOT/example/example-DIH/solr/solr/conf/
# example-DIH (db)
./solr-9.0.0-SNAPSHOT/bin/solr create -c newcore4 -d
solr-9.0.0-SNAPSHOT/example/example-DIH/solr/db/conf/
# example-DIH (atom)
./solr-9.0.0-SNAPSHOT/bin/solr create -c newcore5 -d
solr-9.0.0-SNAPSHOT/example/example-DIH/solr/atom/conf/
# example-DIH (mail)
./solr-9.0.0-SNAPSHOT/bin/solr create -c newcore6 -d
solr-9.0.0-SNAPSHOT/example/example-DIH/solr/mail/conf/
# example-DIH (tika)
./solr-9.0.0-SNAPSHOT/bin/solr create -c newcore7 -d
solr-9.0.0-SNAPSHOT/example/example-DIH/solr/tika/conf/
{code}
They all work fine for me.
> Migrate field type configurations in default/example schema files to look up
> factories by "name"
>
>
> Key: SOLR-13690
> URL: https://issues.apache.org/jira/browse/SOLR-13690
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-13690.patch
>
>
> This is a follow-up task for SOLR-13593.
> To encourage users to use the "name" attribute in field type configurations,
> we should migrate all managed-schema files bundled with Solr.
> There are 8 managed-schemas (except for test resources) in solr.
> {code}
> lucene-solr-mirror $ find solr -name "managed-schema" | grep -v test
> solr/server/solr/configsets/sample_techproducts_configs/conf/managed-schema
> solr/server/solr/configsets/_default/conf/managed-schema
> solr/example/files/conf/managed-schema
> solr/example/example-DIH/solr/solr/conf/managed-schema
> solr/example/example-DIH/solr/db/conf/managed-schema
> solr/example/example-DIH/solr/atom/conf/managed-schema
> solr/example/example-DIH/solr/mail/conf/managed-schema
> solr/example/example-DIH/solr/tika/conf/managed-schema
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13690) Migrate field type configurations in default/example schema files to look up factories by "name"
[
https://issues.apache.org/jira/browse/SOLR-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated SOLR-13690:
-
Attachment: SOLR-13690.patch
> Migrate field type configurations in default/example schema files to look up
> factories by "name"
>
>
> Key: SOLR-13690
> URL: https://issues.apache.org/jira/browse/SOLR-13690
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-13690.patch
>
>
> This is a follow-up task for SOLR-13593.
> To encourage users to use the "name" attribute in field type configurations,
> we should migrate all managed-schema files bundled with Solr.
> There are 8 managed-schemas (except for test resources) in solr.
> {code}
> lucene-solr-mirror $ find solr -name "managed-schema" | grep -v test
> solr/server/solr/configsets/sample_techproducts_configs/conf/managed-schema
> solr/server/solr/configsets/_default/conf/managed-schema
> solr/example/files/conf/managed-schema
> solr/example/example-DIH/solr/solr/conf/managed-schema
> solr/example/example-DIH/solr/db/conf/managed-schema
> solr/example/example-DIH/solr/atom/conf/managed-schema
> solr/example/example-DIH/solr/mail/conf/managed-schema
> solr/example/example-DIH/solr/tika/conf/managed-schema
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8403) Support 'filtered' term vectors - don't require all terms to be present
[
https://issues.apache.org/jira/browse/LUCENE-8403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918711#comment-16918711
]
David Smiley commented on LUCENE-8403:
--
{quote}I understand the approaches – your approach seems to be a longer term
solution (I am not sure of the complexity implications though).
{quote}
I don't think it's long term; I expect it's a simple flag to inform CheckIndex
that it shouldn't check something in this case. Perhaps if you want to explore
this you might see if it's this simple. The biggest part would be a test
including a custom format that exercises this flag to ensure check index
doesn't freak out.
> Support 'filtered' term vectors - don't require all terms to be present
> ---
>
> Key: LUCENE-8403
> URL: https://issues.apache.org/jira/browse/LUCENE-8403
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael Braun
>Priority: Minor
> Attachments: LUCENE-8403.patch
>
>
> The genesis of this was a conversation and idea from [~dsmiley] several years
> ago.
> In order to optimize term vector storage, we may not actually need all tokens
> to be present in the term vectors - and if so, ideally our codec could just
> opt not to store them.
> I attempted to fork the standard codec and override the TermVectorsFormat and
> TermVectorsWriter to ignore storing certain Terms within a field. This
> worked, however, CheckIndex checks that the terms present in the standard
> postings are also present in the TVs, if TVs enabled. So this then doesn't
> work as 'valid' according to CheckIndex.
> Can the TermVectorsFormat be made in such a way to support configuration of
> tokens that should not be stored (benefits: less storage, more optimal
> retrieval per doc)? Is this valuable to the wider community? Is there a way
> we can design this to not break CheckIndex's contract while at the same time
> lessening storage for unneeded tokens?
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13720) Impossible to create effective ToParenBlockJoinQuery in custom QParser
[ https://issues.apache.org/jira/browse/SOLR-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-13720: Component/s: query parsers > Impossible to create effective ToParenBlockJoinQuery in custom QParser > -- > > Key: SOLR-13720 > URL: https://issues.apache.org/jira/browse/SOLR-13720 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Affects Versions: 8.2 >Reporter: Stanislav Livotov >Priority: Minor > Fix For: 8.3 > > Attachments: SOLR-13720.patch > > > According to Solr [ducumentation|#SolrPlugins-QParserPlugin] QParser is > treated as a legal plugin. > > However, it is impossible to create an effective ToParentBlockJoin query > without copy-pasting(BitDocIdSetFilterWrapper class and getCachedFilter > method from BlockJoinParentQParser) or dirty hacks(like creating > org.apache.solr.search.join package with some accessor method to > package-private methods in plugin code and adding it in WEB-INF/lib directory > in order to be loaded by the same ClassLoader). > I don't see a truly clean way how to fix it, but at least we can help custom > plugin developers to create it a little bit easier by making > BlockJoinParentQParser#getCachedFilter public and > BlockJoinParentQParser#BitDocIdSetFilterWrapper and providing getter for > BitDocIdSetFilterWrapper#filter. > > > In order to create -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13720) Impossible to create effective ToParenBlockJoinQuery in custom QParser
[ https://issues.apache.org/jira/browse/SOLR-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-13720: Labels: noob (was: ) > Impossible to create effective ToParenBlockJoinQuery in custom QParser > -- > > Key: SOLR-13720 > URL: https://issues.apache.org/jira/browse/SOLR-13720 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Affects Versions: 8.2 >Reporter: Stanislav Livotov >Priority: Minor > Labels: noob > Fix For: 8.3 > > Attachments: SOLR-13720.patch > > > According to Solr [ducumentation|#SolrPlugins-QParserPlugin] QParser is > treated as a legal plugin. > > However, it is impossible to create an effective ToParentBlockJoin query > without copy-pasting(BitDocIdSetFilterWrapper class and getCachedFilter > method from BlockJoinParentQParser) or dirty hacks(like creating > org.apache.solr.search.join package with some accessor method to > package-private methods in plugin code and adding it in WEB-INF/lib directory > in order to be loaded by the same ClassLoader). > I don't see a truly clean way how to fix it, but at least we can help custom > plugin developers to create it a little bit easier by making > BlockJoinParentQParser#getCachedFilter public and > BlockJoinParentQParser#BitDocIdSetFilterWrapper and providing getter for > BitDocIdSetFilterWrapper#filter. > > > In order to create -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13720) Impossible to create effective ToParenBlockJoinQuery in custom QParser
[ https://issues.apache.org/jira/browse/SOLR-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-13720: Resolution: Fixed Status: Resolved (was: Patch Available) > Impossible to create effective ToParenBlockJoinQuery in custom QParser > -- > > Key: SOLR-13720 > URL: https://issues.apache.org/jira/browse/SOLR-13720 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Affects Versions: 8.2 >Reporter: Stanislav Livotov >Priority: Minor > Labels: noob > Fix For: 8.3 > > Attachments: SOLR-13720.patch > > > According to Solr [ducumentation|#SolrPlugins-QParserPlugin] QParser is > treated as a legal plugin. > > However, it is impossible to create an effective ToParentBlockJoin query > without copy-pasting(BitDocIdSetFilterWrapper class and getCachedFilter > method from BlockJoinParentQParser) or dirty hacks(like creating > org.apache.solr.search.join package with some accessor method to > package-private methods in plugin code and adding it in WEB-INF/lib directory > in order to be loaded by the same ClassLoader). > I don't see a truly clean way how to fix it, but at least we can help custom > plugin developers to create it a little bit easier by making > BlockJoinParentQParser#getCachedFilter public and > BlockJoinParentQParser#BitDocIdSetFilterWrapper and providing getter for > BitDocIdSetFilterWrapper#filter. > > > In order to create -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13720) Impossible to create effective ToParenBlockJoinQuery in custom QParser
[ https://issues.apache.org/jira/browse/SOLR-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-13720: Affects Version/s: (was: master (9.0)) 8.2 > Impossible to create effective ToParenBlockJoinQuery in custom QParser > -- > > Key: SOLR-13720 > URL: https://issues.apache.org/jira/browse/SOLR-13720 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.2 >Reporter: Stanislav Livotov >Priority: Minor > Fix For: 8.3 > > Attachments: SOLR-13720.patch > > > According to Solr [ducumentation|#SolrPlugins-QParserPlugin] QParser is > treated as a legal plugin. > > However, it is impossible to create an effective ToParentBlockJoin query > without copy-pasting(BitDocIdSetFilterWrapper class and getCachedFilter > method from BlockJoinParentQParser) or dirty hacks(like creating > org.apache.solr.search.join package with some accessor method to > package-private methods in plugin code and adding it in WEB-INF/lib directory > in order to be loaded by the same ClassLoader). > I don't see a truly clean way how to fix it, but at least we can help custom > plugin developers to create it a little bit easier by making > BlockJoinParentQParser#getCachedFilter public and > BlockJoinParentQParser#BitDocIdSetFilterWrapper and providing getter for > BitDocIdSetFilterWrapper#filter. > > > In order to create -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13720) Impossible to create effective ToParenBlockJoinQuery in custom QParser
[ https://issues.apache.org/jira/browse/SOLR-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-13720: Priority: Minor (was: Major) > Impossible to create effective ToParenBlockJoinQuery in custom QParser > -- > > Key: SOLR-13720 > URL: https://issues.apache.org/jira/browse/SOLR-13720 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Stanislav Livotov >Priority: Minor > Fix For: 8.3 > > Attachments: SOLR-13720.patch > > > According to Solr [ducumentation|#SolrPlugins-QParserPlugin] QParser is > treated as a legal plugin. > > However, it is impossible to create an effective ToParentBlockJoin query > without copy-pasting(BitDocIdSetFilterWrapper class and getCachedFilter > method from BlockJoinParentQParser) or dirty hacks(like creating > org.apache.solr.search.join package with some accessor method to > package-private methods in plugin code and adding it in WEB-INF/lib directory > in order to be loaded by the same ClassLoader). > I don't see a truly clean way how to fix it, but at least we can help custom > plugin developers to create it a little bit easier by making > BlockJoinParentQParser#getCachedFilter public and > BlockJoinParentQParser#BitDocIdSetFilterWrapper and providing getter for > BitDocIdSetFilterWrapper#filter. > > > In order to create -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13720) Impossible to create effective ToParenBlockJoinQuery in custom QParser
[ https://issues.apache.org/jira/browse/SOLR-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-13720: Fix Version/s: (was: master (9.0)) 8.3 > Impossible to create effective ToParenBlockJoinQuery in custom QParser > -- > > Key: SOLR-13720 > URL: https://issues.apache.org/jira/browse/SOLR-13720 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Stanislav Livotov >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13720.patch > > > According to Solr [ducumentation|#SolrPlugins-QParserPlugin] QParser is > treated as a legal plugin. > > However, it is impossible to create an effective ToParentBlockJoin query > without copy-pasting(BitDocIdSetFilterWrapper class and getCachedFilter > method from BlockJoinParentQParser) or dirty hacks(like creating > org.apache.solr.search.join package with some accessor method to > package-private methods in plugin code and adding it in WEB-INF/lib directory > in order to be loaded by the same ClassLoader). > I don't see a truly clean way how to fix it, but at least we can help custom > plugin developers to create it a little bit easier by making > BlockJoinParentQParser#getCachedFilter public and > BlockJoinParentQParser#BitDocIdSetFilterWrapper and providing getter for > BitDocIdSetFilterWrapper#filter. > > > In order to create -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13720) Impossible to create effective ToParenBlockJoinQuery in custom QParser
[ https://issues.apache.org/jira/browse/SOLR-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-13720: Issue Type: Improvement (was: Bug) > Impossible to create effective ToParenBlockJoinQuery in custom QParser > -- > > Key: SOLR-13720 > URL: https://issues.apache.org/jira/browse/SOLR-13720 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Stanislav Livotov >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13720.patch > > > According to Solr [ducumentation|#SolrPlugins-QParserPlugin] QParser is > treated as a legal plugin. > > However, it is impossible to create an effective ToParentBlockJoin query > without copy-pasting(BitDocIdSetFilterWrapper class and getCachedFilter > method from BlockJoinParentQParser) or dirty hacks(like creating > org.apache.solr.search.join package with some accessor method to > package-private methods in plugin code and adding it in WEB-INF/lib directory > in order to be loaded by the same ClassLoader). > I don't see a truly clean way how to fix it, but at least we can help custom > plugin developers to create it a little bit easier by making > BlockJoinParentQParser#getCachedFilter public and > BlockJoinParentQParser#BitDocIdSetFilterWrapper and providing getter for > BitDocIdSetFilterWrapper#filter. > > > In order to create -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] gerlowskija commented on a change in pull request #665: Fixes SOLR-13539
gerlowskija commented on a change in pull request #665: Fixes SOLR-13539
URL: https://github.com/apache/lucene-solr/pull/665#discussion_r319118987
##
File path: solr/core/src/java/org/apache/solr/handler/loader/XMLLoader.java
##
@@ -429,7 +434,18 @@ public SolrInputDocument readDoc(XMLStreamReader parser)
throws XMLStreamExcepti
break;
} else if ("field".equals(parser.getLocalName())) {
// should I warn in some text has been found too
-Object v = isNull ? null : text.toString();
+Object v;
Review comment:
Hey @thomaswoeckinger what's the purpose of this change here? I gather it's
allowing the XMLLoader to handle a binary base64 content-type, but was that
required to get a particular test passing? Is it something needed by
EmbeddedSolrServer? Something else?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] gerlowskija commented on a change in pull request #665: Fixes SOLR-13539
gerlowskija commented on a change in pull request #665: Fixes SOLR-13539
URL: https://github.com/apache/lucene-solr/pull/665#discussion_r319118987
##
File path: solr/core/src/java/org/apache/solr/handler/loader/XMLLoader.java
##
@@ -429,7 +434,18 @@ public SolrInputDocument readDoc(XMLStreamReader parser)
throws XMLStreamExcepti
break;
} else if ("field".equals(parser.getLocalName())) {
// should I warn in some text has been found too
-Object v = isNull ? null : text.toString();
+Object v;
Review comment:
Hey @thomaswoeckinger what's the purpose of this change here? I gather it's
allowing the XMLLoader to handle a binary base64 content-type, but was that
required for a particular test change? Is it something needed by
EmbeddedSolrServer? Something else?
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-13720) Impossible to create effective ToParenBlockJoinQuery in custom QParser
[ https://issues.apache.org/jira/browse/SOLR-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918674#comment-16918674 ] ASF subversion and git services commented on SOLR-13720: Commit c857c1da3d24e7db8f2b3b4c93e74758024efe25 in lucene-solr's branch refs/heads/branch_8x from Mikhail Khludnev [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c857c1d ] SOLR-13720: BlockJoinParentQParser.getCachedFilter made public > Impossible to create effective ToParenBlockJoinQuery in custom QParser > -- > > Key: SOLR-13720 > URL: https://issues.apache.org/jira/browse/SOLR-13720 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Stanislav Livotov >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-13720.patch > > > According to Solr [ducumentation|#SolrPlugins-QParserPlugin] QParser is > treated as a legal plugin. > > However, it is impossible to create an effective ToParentBlockJoin query > without copy-pasting(BitDocIdSetFilterWrapper class and getCachedFilter > method from BlockJoinParentQParser) or dirty hacks(like creating > org.apache.solr.search.join package with some accessor method to > package-private methods in plugin code and adding it in WEB-INF/lib directory > in order to be loaded by the same ClassLoader). > I don't see a truly clean way how to fix it, but at least we can help custom > plugin developers to create it a little bit easier by making > BlockJoinParentQParser#getCachedFilter public and > BlockJoinParentQParser#BitDocIdSetFilterWrapper and providing getter for > BitDocIdSetFilterWrapper#filter. > > > In order to create -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13720) Impossible to create effective ToParenBlockJoinQuery in custom QParser
[ https://issues.apache.org/jira/browse/SOLR-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918671#comment-16918671 ] ASF subversion and git services commented on SOLR-13720: Commit 6dea6784396ca3a91524671789da6a36fbf32b54 in lucene-solr's branch refs/heads/master from Mikhail Khludnev [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6dea678 ] SOLR-13720: BlockJoinParentQParser.getCachedFilter made public > Impossible to create effective ToParenBlockJoinQuery in custom QParser > -- > > Key: SOLR-13720 > URL: https://issues.apache.org/jira/browse/SOLR-13720 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Stanislav Livotov >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-13720.patch > > > According to Solr [ducumentation|#SolrPlugins-QParserPlugin] QParser is > treated as a legal plugin. > > However, it is impossible to create an effective ToParentBlockJoin query > without copy-pasting(BitDocIdSetFilterWrapper class and getCachedFilter > method from BlockJoinParentQParser) or dirty hacks(like creating > org.apache.solr.search.join package with some accessor method to > package-private methods in plugin code and adding it in WEB-INF/lib directory > in order to be loaded by the same ClassLoader). > I don't see a truly clean way how to fix it, but at least we can help custom > plugin developers to create it a little bit easier by making > BlockJoinParentQParser#getCachedFilter public and > BlockJoinParentQParser#BitDocIdSetFilterWrapper and providing getter for > BitDocIdSetFilterWrapper#filter. > > > In order to create -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13539) Atomic Update Multivalue remove does not work for field types UUID, Enums, Bool and Binary
[ https://issues.apache.org/jira/browse/SOLR-13539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918660#comment-16918660 ] ASF subversion and git services commented on SOLR-13539: Commit 319cb005d314e6f15dd73339e99657d8e39218a4 in lucene-solr's branch refs/heads/master from Jason Gerlowski [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=319cb00 ] SOLR-13539: Introduce EmbeddedSolrServerTestBase This groundwork commit allows tests to randomize request content-type more flexibly. This will be taken advantage of by subsequent commits. Co-Authored-By: Thomas Woeckinger Closes: #755 > Atomic Update Multivalue remove does not work for field types UUID, Enums, > Bool and Binary > --- > > Key: SOLR-13539 > URL: https://issues.apache.org/jira/browse/SOLR-13539 > Project: Solr > Issue Type: Bug > Components: UpdateRequestProcessors >Affects Versions: 7.7.2, 8.1, 8.1.1 >Reporter: Thomas Wöckinger >Priority: Critical > Attachments: SOLR-13539.patch > > Time Spent: 6h 50m > Remaining Estimate: 0h > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > This is related to following field types: UUID, Enums, Bool and Binary -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] asfgit closed pull request #755: SOLR-13592: Introduce EmbeddedSolrTestBase for better integration tests
asfgit closed pull request #755: SOLR-13592: Introduce EmbeddedSolrTestBase for better integration tests URL: https://github.com/apache/lucene-solr/pull/755 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918654#comment-16918654 ] Uwe Schindler commented on LUCENE-8951: --- Will do this later as most of them are sleeping. > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists > # Announce to dev@ list that the change will happen > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] gerlowskija commented on issue #755: SOLR-13592: Introduce EmbeddedSolrTestBase for better integration tests
gerlowskija commented on issue #755: SOLR-13592: Introduce EmbeddedSolrTestBase for better integration tests URL: https://github.com/apache/lucene-solr/pull/755#issuecomment-526194384 Is there any difference between LargeVolumeEmbeddedTest, LargeVolumeJettyTest, and LargeVolumeBinaryJettyTest? It looks like all three are exactly the same with this PR. They look suspiciously similar before this PR too, so I think the problem pre-exists this change. But it's still very odd. Just wondering if you dug into that at all as you were working? 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-12291) Async prematurely reports completed status that causes severe shard loss
[ https://issues.apache.org/jira/browse/SOLR-12291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-12291: Fix Version/s: 7.7.3 > Async prematurely reports completed status that causes severe shard loss > > > Key: SOLR-12291 > URL: https://issues.apache.org/jira/browse/SOLR-12291 > Project: Solr > Issue Type: Bug > Components: Backup/Restore, SolrCloud >Reporter: Varun Thacker >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.1, master (9.0), 7.7.3 > > Attachments: SOLR-12291.patch, SOLR-12291.patch, SOLR-12291.patch, > SOLR-12291.patch, SOLR-12291.patch, SOLR-12291.patch, SOLR-12291.patch, > SOLR-122911.patch > > > The OverseerCollectionMessageHandler sliceCmd assumes only one replica exists > on one node > When multiple replicas of a slice are on the same node we only track one > replica's async request. This happens because the async requestMap's key is > "node_name" > I discovered this when [~alabax] shared some logs of a restore issue, where > the second replica got added before the first replica had completed it's > restorecore action. > While looking at the logs I noticed that the overseer never called > REQUESTSTATUS for the restorecore action , almost as if it had missed > tracking that particular async request. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12291) Async prematurely reports completed status that causes severe shard loss
[ https://issues.apache.org/jira/browse/SOLR-12291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918638#comment-16918638 ] ASF subversion and git services commented on SOLR-12291: Commit 8b6ca690acee929ceadd3ea7a8a504499cbfa012 in lucene-solr's branch refs/heads/branch_7_7 from Mikhail Khludnev [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8b6ca69 ] SOLR-12291: fixing premature completion of async tasks * extract async tracking methods from OverseerCollectionMessageHandler into the separate class * replacing hashmap to named list to avoid entry loss > Async prematurely reports completed status that causes severe shard loss > > > Key: SOLR-12291 > URL: https://issues.apache.org/jira/browse/SOLR-12291 > Project: Solr > Issue Type: Bug > Components: Backup/Restore, SolrCloud >Reporter: Varun Thacker >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-12291.patch, SOLR-12291.patch, SOLR-12291.patch, > SOLR-12291.patch, SOLR-12291.patch, SOLR-12291.patch, SOLR-12291.patch, > SOLR-122911.patch > > > The OverseerCollectionMessageHandler sliceCmd assumes only one replica exists > on one node > When multiple replicas of a slice are on the same node we only track one > replica's async request. This happens because the async requestMap's key is > "node_name" > I discovered this when [~alabax] shared some logs of a restore issue, where > the second replica got added before the first replica had completed it's > restorecore action. > While looking at the logs I noticed that the overseer never called > REQUESTSTATUS for the restorecore action , almost as if it had missed > tracking that particular async request. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on a change in pull request #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
atris commented on a change in pull request #823: LUCENE-8939: Introduce Shared
Count Early Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#discussion_r319070775
##
File path:
lucene/core/src/java/org/apache/lucene/search/HitCountThresholdCheckerFactory.java
##
@@ -0,0 +1,116 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.lucene.search;
+
+import java.util.concurrent.atomic.AtomicInteger;
+
+/**
+ * Factory which generates instances of GlobalHitsThresholdChecker and
LocalHitsThresholdChecker
+ * with the threshold as the passed in limit
+ */
+public final class HitCountThresholdCheckerFactory {
Review comment:
> Since we return a `HitsThresholdChecker` we could also make it public and
add the private impl and the static functions creation there. We don't really
need this factory class ?
@jimczi I was hesitant to do that since `HitsThresholdChecker` should
really be agnostic of the underlying implementation. However, given the fact
that the hit count checker(s) is the default, it makes sense to move it to the
parent class. Updated, please take a look.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] jimczi commented on a change in pull request #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
jimczi commented on a change in pull request #823: LUCENE-8939: Introduce
Shared Count Early Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#discussion_r319066704
##
File path:
lucene/core/src/java/org/apache/lucene/search/HitCountThresholdCheckerFactory.java
##
@@ -0,0 +1,116 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.lucene.search;
+
+import java.util.concurrent.atomic.AtomicInteger;
+
+/**
+ * Factory which generates instances of GlobalHitsThresholdChecker and
LocalHitsThresholdChecker
+ * with the threshold as the passed in limit
+ */
+public final class HitCountThresholdCheckerFactory {
Review comment:
I agree for the interface but the static functions to help build simple
checker could be directly implemented in `HitsThresholdChecker` ?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on a change in pull request #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
atris commented on a change in pull request #823: LUCENE-8939: Introduce Shared
Count Early Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#discussion_r319065020
##
File path:
lucene/core/src/java/org/apache/lucene/search/HitCountThresholdCheckerFactory.java
##
@@ -0,0 +1,116 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.lucene.search;
+
+import java.util.concurrent.atomic.AtomicInteger;
+
+/**
+ * Factory which generates instances of GlobalHitsThresholdChecker and
LocalHitsThresholdChecker
+ * with the threshold as the passed in limit
+ */
+public final class HitCountThresholdCheckerFactory {
Review comment:
`HitsThresholdChecker` is currently an interface -- I am inclined to let it
remain the same to allow users to do fancy early termination algorithms, hence
introduced the factory. Thoughts?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] jimczi commented on a change in pull request #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
jimczi commented on a change in pull request #823: LUCENE-8939: Introduce
Shared Count Early Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#discussion_r319063786
##
File path:
lucene/core/src/java/org/apache/lucene/search/HitCountThresholdCheckerFactory.java
##
@@ -0,0 +1,116 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.lucene.search;
+
+import java.util.concurrent.atomic.AtomicInteger;
+
+/**
+ * Factory which generates instances of GlobalHitsThresholdChecker and
LocalHitsThresholdChecker
+ * with the threshold as the passed in limit
+ */
+public final class HitCountThresholdCheckerFactory {
Review comment:
Since we return a `HitsThresholdChecker` we could also make it public and
add the private impl and the static functions creation there. We don't really
need this factory class ?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-526179514 @jimczi Updated per our discussion. Although, a user can potentially implement `HitsThresholdChecker` and give his custom limits, but that would be an overkill for just a different value for a limit, so agree with your proposal. Please let me know your thoughts. 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-13035) Utilize solr.data.home / solrDataHome in solr.xml to set all writable files in single directory
[
https://issues.apache.org/jira/browse/SOLR-13035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918580#comment-16918580
]
Mikhail Khludnev commented on SOLR-13035:
-
attached patch to master with resolved conflicts
> Utilize solr.data.home / solrDataHome in solr.xml to set all writable files
> in single directory
> ---
>
> Key: SOLR-13035
> URL: https://issues.apache.org/jira/browse/SOLR-13035
> Project: Solr
> Issue Type: Improvement
>Reporter: Amrit Sarkar
>Assignee: Shalin Shekhar Mangar
>Priority: Major
> Attachments: SOLR-13035.patch, SOLR-13035.patch, SOLR-13035.patch,
> SOLR-13035.patch, SOLR-13035.patch, SOLR-13035.patch,
> image-2019-08-28-23-57-39-826.png
>
>
> {{solr.data.home}} system property or {{solrDataHome}} in _solr.xml_ is
> already available as per SOLR-6671.
> The writable content in Solr are index files, core properties, and ZK data if
> embedded zookeeper is started in SolrCloud mode. It would be great if all
> writable content can come under the same directory to have separate READ-ONLY
> and WRITE-ONLY directories.
> It can then also solve official docker Solr image issues:
> https://github.com/docker-solr/docker-solr/issues/74
> https://github.com/docker-solr/docker-solr/issues/133
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13035) Utilize solr.data.home / solrDataHome in solr.xml to set all writable files in single directory
[
https://issues.apache.org/jira/browse/SOLR-13035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-13035:
Attachment: SOLR-13035.patch
> Utilize solr.data.home / solrDataHome in solr.xml to set all writable files
> in single directory
> ---
>
> Key: SOLR-13035
> URL: https://issues.apache.org/jira/browse/SOLR-13035
> Project: Solr
> Issue Type: Improvement
>Reporter: Amrit Sarkar
>Assignee: Shalin Shekhar Mangar
>Priority: Major
> Attachments: SOLR-13035.patch, SOLR-13035.patch, SOLR-13035.patch,
> SOLR-13035.patch, SOLR-13035.patch, SOLR-13035.patch,
> image-2019-08-28-23-57-39-826.png
>
>
> {{solr.data.home}} system property or {{solrDataHome}} in _solr.xml_ is
> already available as per SOLR-6671.
> The writable content in Solr are index files, core properties, and ZK data if
> embedded zookeeper is started in SolrCloud mode. It would be great if all
> writable content can come under the same directory to have separate READ-ONLY
> and WRITE-ONLY directories.
> It can then also solve official docker Solr image issues:
> https://github.com/docker-solr/docker-solr/issues/74
> https://github.com/docker-solr/docker-solr/issues/133
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
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 # 492 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/492/
2 tests failed.
FAILED:
org.apache.solr.cloud.api.collections.TestHdfsCloudBackupRestore.testRestoreFailure
Error Message:
Failed collection is still in the clusterstate:
DocCollection(hdfsbackuprestore_testfailure_restored//collections/hdfsbackuprestore_testfailure_restored/state.json/2)={
"pullReplicas":0, "replicationFactor":2, "shards":{ "shard2":{
"range":"0-7fff", "state":"construction",
"replicas":{"core_node2":{
"core":"hdfsbackuprestore_testfailure_restored_shard2_replica_n1",
"base_url":"https://127.0.0.1:37581/solr";,
"node_name":"127.0.0.1:37581_solr", "state":"down",
"type":"NRT", "force_set_state":"false"}},
"stateTimestamp":"1567075412159408232"}, "shard1":{
"range":"8000-", "state":"construction", "replicas":{},
"stateTimestamp":"1567075412159421642"}},
"router":{"name":"compositeId"}, "maxShardsPerNode":"2",
"autoAddReplicas":"false", "nrtReplicas":2, "tlogReplicas":0} Expected: not
a collection containing "hdfsbackuprestore_testfailure_restored" but: was
<[hdfsbackuprestore_testok, hdfsbackuprestore_testfailure_restored,
hdfsbackuprestore_testfailure, hdfsbackuprestore_testok_restored]>
Stack Trace:
java.lang.AssertionError: Failed collection is still in the clusterstate:
DocCollection(hdfsbackuprestore_testfailure_restored//collections/hdfsbackuprestore_testfailure_restored/state.json/2)={
"pullReplicas":0,
"replicationFactor":2,
"shards":{
"shard2":{
"range":"0-7fff",
"state":"construction",
"replicas":{"core_node2":{
"core":"hdfsbackuprestore_testfailure_restored_shard2_replica_n1",
"base_url":"https://127.0.0.1:37581/solr";,
"node_name":"127.0.0.1:37581_solr",
"state":"down",
"type":"NRT",
"force_set_state":"false"}},
"stateTimestamp":"1567075412159408232"},
"shard1":{
"range":"8000-",
"state":"construction",
"replicas":{},
"stateTimestamp":"1567075412159421642"}},
"router":{"name":"compositeId"},
"maxShardsPerNode":"2",
"autoAddReplicas":"false",
"nrtReplicas":2,
"tlogReplicas":0}
Expected: not a collection containing "hdfsbackuprestore_testfailure_restored"
but: was <[hdfsbackuprestore_testok,
hdfsbackuprestore_testfailure_restored, hdfsbackuprestore_testfailure,
hdfsbackuprestore_testok_restored]>
at
__randomizedtesting.SeedInfo.seed([4E0D9701184A2A9E:67710924301329B3]:0)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.junit.Assert.assertThat(Assert.java:956)
at
org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.testRestoreFailure(AbstractCloudBackupRestoreTestCase.java:211)
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.Random
[GitHub] [lucene-solr] atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-526164337 > Package protected might not be a good idea after all, sorry, users that wants to set the `totalHitsThreshold` different than the default would need to access the `GlobalHitsThresholdChecker`. Maybe we can have a single class and expose two static functions that creates anonymous impl: `create(int)` and `createShared(int)` ? This way users can still modify totalHitsThreshold and share it if they use the managed search ? If I understood correctly, the class would be public and return instances of local checker or global checker with the threshold set as the parameter passed in to the static methods? 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-13677) All Metrics Gauges should be unregistered by the objects that registered them
[ https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918563#comment-16918563 ] Noble Paul commented on SOLR-13677: --- let's make the changes/reverts in [https://github.com/apache/lucene-solr/tree/jira/SOLR-13677_3]. > All Metrics Gauges should be unregistered by the objects that registered them > - > > Key: SOLR-13677 > URL: https://issues.apache.org/jira/browse/SOLR-13677 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 3h 20m > Remaining Estimate: 0h > > The life cycle of Metrics producers are managed by the core (mostly). So, if > the lifecycle of the object is different from that of the core itself, these > objects will never be unregistered from the metrics registry. This will lead > to memory leaks -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918557#comment-16918557 ] Jan Høydahl commented on LUCENE-8951: - I only see those two first test mails in PonyMail as well. Great if you follow up with Infra on this Uwe. > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists > # Announce to dev@ list that the change will happen > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13718) SPLITSHARD using async can cause data loss
[
https://issues.apache.org/jira/browse/SOLR-13718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya resolved SOLR-13718.
-
Resolution: Fixed
> SPLITSHARD using async can cause data loss
> --
>
> Key: SOLR-13718
> URL: https://issues.apache.org/jira/browse/SOLR-13718
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7.2, 8.1, 8.2
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 7.7.3, 8.3
>
> Attachments: SOLR-13718.patch, solr-13718-reproduce.sh, solr.zip
>
>
> When using SPLITSHARD with async, if there are underlying failures in the
> SPLIT core command or other sub-commands of SPLITSHARD, then SPLITSHARD
> succeeds and results in two empty sub-shards.
> There are various potential failures with SPLIT core command, here's a way to
> reproduce using a Solr 6x index in Solr 7x.
> -Steps to reproduce (in Solr 7x):-
> {code}
> 1. Import the attached configset, and create a collection.
> 2. Move in the attached data directory (index created in Solr6x) in place of
> the created collection's data directory. Do a collection RELOAD.
> 3. Issue a *:* query, we see 5 documents.
> 4. Issue a SPLITSHARD (async), and then issue *:*, we see 0 documents.
> {code}
> Check attached solr-13718-reproduce.sh script to do the same (without needing
> the zip file).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13718) SPLITSHARD using async can cause data loss
[
https://issues.apache.org/jira/browse/SOLR-13718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918555#comment-16918555
]
ASF subversion and git services commented on SOLR-13718:
Commit 9d68b0d00dd815210674262463b7908f72a1ef30 in lucene-solr's branch
refs/heads/branch_7_7 from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9d68b0d ]
SOLR-13718: A more targeted fix for SPLITSHARD, thereby avoiding Backup/Restore
test failures
> SPLITSHARD using async can cause data loss
> --
>
> Key: SOLR-13718
> URL: https://issues.apache.org/jira/browse/SOLR-13718
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7.2, 8.1, 8.2
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 7.7.3, 8.3
>
> Attachments: SOLR-13718.patch, solr-13718-reproduce.sh, solr.zip
>
>
> When using SPLITSHARD with async, if there are underlying failures in the
> SPLIT core command or other sub-commands of SPLITSHARD, then SPLITSHARD
> succeeds and results in two empty sub-shards.
> There are various potential failures with SPLIT core command, here's a way to
> reproduce using a Solr 6x index in Solr 7x.
> -Steps to reproduce (in Solr 7x):-
> {code}
> 1. Import the attached configset, and create a collection.
> 2. Move in the attached data directory (index created in Solr6x) in place of
> the created collection's data directory. Do a collection RELOAD.
> 3. Issue a *:* query, we see 5 documents.
> 4. Issue a SPLITSHARD (async), and then issue *:*, we see 0 documents.
> {code}
> Check attached solr-13718-reproduce.sh script to do the same (without needing
> the zip file).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8758) Class Field levelN is not populated correctly in QuadPrefixTree
[
https://issues.apache.org/jira/browse/LUCENE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918554#comment-16918554
]
Amish Shah commented on LUCENE-8758:
[^LUCENE-8758.patch] Here is the patch that removes the levelN and levelS
fields from QuadPrefixTree. Please review and let me know if I need to make any
changes. Thanks!
> Class Field levelN is not populated correctly in QuadPrefixTree
> ---
>
> Key: LUCENE-8758
> URL: https://issues.apache.org/jira/browse/LUCENE-8758
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial-extras
>Affects Versions: 4.0, 5.0, 6.0, 7.0, 8.0
>Reporter: Dominic Page
>Priority: Trivial
> Labels: beginner
> Fix For: 8.x
>
> Attachments: LUCENE-8758.patch
>
>
> QuadPrefixTree in Lucene prepopulates these arrays:
> {{levelW = new double[maxLevels];}}
> {{levelH = new double[maxLevels];}}
> {{*levelS = new int[maxLevels];*}}
> {{*levelN = new int[maxLevels];*}}
> Like this
> {{for (int i = 1; i < levelW.length; i++) {}}
> {{ levelW[i] = levelW[i - 1] / 2.0;}}
> {{ levelH[i] = levelH[i - 1] / 2.0;}}
> {{ *levelS[i] = levelS[i - 1] * 2;*}}
> {{ *levelN[i] = levelN[i - 1] * 4;*}}
> {{}}}
> The field
> {{levelN[]}}
> overflows after level 14 = 1073741824 where maxLevels is limited to
> {{MAX_LEVELS_POSSIBLE = 50;}}
> The field levelN appears not to be used anywhere. Likewise, the field
> {{levelS[] }}
> is only used in the
> {{printInfo}}
> method. I would propose either to remove both
> {{levelN[],}}{{levelS[]}}
> or to change the datatype
> {{levelN = new long[maxLevels];}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8758) Class Field levelN is not populated correctly in QuadPrefixTree
[
https://issues.apache.org/jira/browse/LUCENE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amish Shah updated LUCENE-8758:
---
Attachment: LUCENE-8758.patch
> Class Field levelN is not populated correctly in QuadPrefixTree
> ---
>
> Key: LUCENE-8758
> URL: https://issues.apache.org/jira/browse/LUCENE-8758
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial-extras
>Affects Versions: 4.0, 5.0, 6.0, 7.0, 8.0
>Reporter: Dominic Page
>Priority: Trivial
> Labels: beginner
> Fix For: 8.x
>
> Attachments: LUCENE-8758.patch
>
>
> QuadPrefixTree in Lucene prepopulates these arrays:
> {{levelW = new double[maxLevels];}}
> {{levelH = new double[maxLevels];}}
> {{*levelS = new int[maxLevels];*}}
> {{*levelN = new int[maxLevels];*}}
> Like this
> {{for (int i = 1; i < levelW.length; i++) {}}
> {{ levelW[i] = levelW[i - 1] / 2.0;}}
> {{ levelH[i] = levelH[i - 1] / 2.0;}}
> {{ *levelS[i] = levelS[i - 1] * 2;*}}
> {{ *levelN[i] = levelN[i - 1] * 4;*}}
> {{}}}
> The field
> {{levelN[]}}
> overflows after level 14 = 1073741824 where maxLevels is limited to
> {{MAX_LEVELS_POSSIBLE = 50;}}
> The field levelN appears not to be used anywhere. Likewise, the field
> {{levelS[] }}
> is only used in the
> {{printInfo}}
> method. I would propose either to remove both
> {{levelN[],}}{{levelS[]}}
> or to change the datatype
> {{levelN = new long[maxLevels];}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12291) Async prematurely reports completed status that causes severe shard loss
[ https://issues.apache.org/jira/browse/SOLR-12291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918551#comment-16918551 ] Ishan Chattopadhyaya commented on SOLR-12291: - Thanks for clarifying. I can take a stab at it (since I'm already on backporting SOLR-13718 there); shall seek your help if I'm stuck. > Async prematurely reports completed status that causes severe shard loss > > > Key: SOLR-12291 > URL: https://issues.apache.org/jira/browse/SOLR-12291 > Project: Solr > Issue Type: Bug > Components: Backup/Restore, SolrCloud >Reporter: Varun Thacker >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-12291.patch, SOLR-12291.patch, SOLR-12291.patch, > SOLR-12291.patch, SOLR-12291.patch, SOLR-12291.patch, SOLR-12291.patch, > SOLR-122911.patch > > > The OverseerCollectionMessageHandler sliceCmd assumes only one replica exists > on one node > When multiple replicas of a slice are on the same node we only track one > replica's async request. This happens because the async requestMap's key is > "node_name" > I discovered this when [~alabax] shared some logs of a restore issue, where > the second replica got added before the first replica had completed it's > restorecore action. > While looking at the logs I noticed that the overseer never called > REQUESTSTATUS for the restorecore action , almost as if it had missed > tracking that particular async request. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13035) Utilize solr.data.home / solrDataHome in solr.xml to set all writable files in single directory
[
https://issues.apache.org/jira/browse/SOLR-13035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918114#comment-16918114
]
Mikhail Khludnev edited comment on SOLR-13035 at 8/29/19 12:20 PM:
---
Hello [~sarkaramr...@gmail.com] , I resolved conflicts a little, and launched
windows script. Here's what I have
At first I added -v -V and examine output. This one make sense
GC_LOG_OPTS = "-Xlog:gc*:file=\"data\logs\solr_gc.log\":time,up
This one looks odd
SOLR_DATA_HOME = data\data\data
Here's what I have in Solr Admin. Shouldn't tmp folder moved to writable home
-Djava.io.tmpdir=lucene-solr\solr\server\tmp
That's odd
-Dsolr.data.home=data\data\data
These are ok
-Dsolr.log.dir=data\logs
-Dsolr.solr.home=\lucene-solr\solr\server\solr
-Xlog:gc*:file="data\logs\solr_gc.log":
!image-2019-08-28-23-57-39-826.png!
I'm not sure if this is expected behavior. Also, notice creating pid file at
solr/bin/solr-8983.port
Also usage prompt seems vague to me
-w dir Solr will create all writable directories and files relative to this.
solr.data.home if relative, will be set as SOLR_VAR_ROOT\{this}/solr.data.home
solr.log.dir if relative, will be set as SOLR_VAR_ROOT\{this}/solr.log.dir
These references SOLR_VAR_ROOT\{this} isn't obvious.
was (Author: mkhludnev):
Hello [~sarkaramr...@gmail.com] , I resolved conflicts a little, and launched
windows script. Here's what I have
At first I added -v -V and examine output. This one make sense
GC_LOG_OPTS = "-Xlog:gc*:file=\"data\logs\solr_gc.log\":time,up
This one looks odd
SOLR_DATA_HOME = data\data\data
Here's what I have in Solr Admin. Shouldn't tmp folder moved to writable home
-Djava.io.tmpdir=lucene-solr\solr\server\tmp
That's odd
-Dsolr.data.home=data\data\data
This is ok
-Dsolr.log.dir=data\logs
-Dsolr.solr.home=\lucene-solr\solr\server\solr
-Xlog:gc*:file="data\logs\solr_gc.log":
!image-2019-08-28-23-57-39-826.png!
I'm not sure if this is expected behavior.
Also usage prompt seems vague to me
-w dir Solr will create all writable directories and files relative to this.
solr.data.home if relative, will be set as SOLR_VAR_ROOT\{this}/solr.data.home
solr.log.dir if relative, will be set as SOLR_VAR_ROOT\{this}/solr.log.dir
These references SOLR_VAR_ROOT\{this} isn't obvious.
> Utilize solr.data.home / solrDataHome in solr.xml to set all writable files
> in single directory
> ---
>
> Key: SOLR-13035
> URL: https://issues.apache.org/jira/browse/SOLR-13035
> Project: Solr
> Issue Type: Improvement
>Reporter: Amrit Sarkar
>Assignee: Shalin Shekhar Mangar
>Priority: Major
> Attachments: SOLR-13035.patch, SOLR-13035.patch, SOLR-13035.patch,
> SOLR-13035.patch, SOLR-13035.patch, image-2019-08-28-23-57-39-826.png
>
>
> {{solr.data.home}} system property or {{solrDataHome}} in _solr.xml_ is
> already available as per SOLR-6671.
> The writable content in Solr are index files, core properties, and ZK data if
> embedded zookeeper is started in SolrCloud mode. It would be great if all
> writable content can come under the same directory to have separate READ-ONLY
> and WRITE-ONLY directories.
> It can then also solve official docker Solr image issues:
> https://github.com/docker-solr/docker-solr/issues/74
> https://github.com/docker-solr/docker-solr/issues/133
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-526157715 @jimczi Updated 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-13677) All Metrics Gauges should be unregistered by the objects that registered them
[ https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918546#comment-16918546 ] Andrzej Bialecki commented on SOLR-13677: -- [~noble.paul] - please revert these changes until the above problems are addressed. I'll be happy to help you fix them - let's create a branch. > All Metrics Gauges should be unregistered by the objects that registered them > - > > Key: SOLR-13677 > URL: https://issues.apache.org/jira/browse/SOLR-13677 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 3h 20m > Remaining Estimate: 0h > > The life cycle of Metrics producers are managed by the core (mostly). So, if > the lifecycle of the object is different from that of the core itself, these > objects will never be unregistered from the metrics registry. This will lead > to memory leaks -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] jimczi commented on a change in pull request #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
jimczi commented on a change in pull request #823: LUCENE-8939: Introduce
Shared Count Early Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#discussion_r319030989
##
File path: lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
##
@@ -469,7 +469,7 @@ public TopDocs searchAfter(ScoreDoc after, Query query,
int numHits) throws IOEx
@Override
public TopScoreDocCollector newCollector() throws IOException {
-return TopScoreDocCollector.create(cappedNumHits, after,
TOTAL_HITS_THRESHOLD);
+return TopScoreDocCollector.create(cappedNumHits, after, new
GlobalHitsThresholdChecker(TOTAL_HITS_THRESHOLD));
Review comment:
The `HitsThresholdChecker` should be created once and shared within the
collectors ? We also don't need to use the `GlobalHitsThresholdChecker` if the
executor is null or if there is a single slice.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] jimczi commented on a change in pull request #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
jimczi commented on a change in pull request #823: LUCENE-8939: Introduce
Shared Count Early Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#discussion_r319031039
##
File path: lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
##
@@ -598,7 +598,7 @@ private TopFieldDocs searchAfter(FieldDoc after, Query
query, int numHits, Sort
@Override
public TopFieldCollector newCollector() throws IOException {
// TODO: don't pay the price for accurate hit counts by default
-return TopFieldCollector.create(rewrittenSort, cappedNumHits, after,
TOTAL_HITS_THRESHOLD);
+return TopFieldCollector.create(rewrittenSort, cappedNumHits, after,
new GlobalHitsThresholdChecker(TOTAL_HITS_THRESHOLD));
Review comment:
same 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
[GitHub] [lucene-solr] jimczi commented on a change in pull request #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
jimczi commented on a change in pull request #823: LUCENE-8939: Introduce
Shared Count Early Termination In Parallel Search
URL: https://github.com/apache/lucene-solr/pull/823#discussion_r319030989
##
File path: lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
##
@@ -469,7 +469,7 @@ public TopDocs searchAfter(ScoreDoc after, Query query,
int numHits) throws IOEx
@Override
public TopScoreDocCollector newCollector() throws IOException {
-return TopScoreDocCollector.create(cappedNumHits, after,
TOTAL_HITS_THRESHOLD);
+return TopScoreDocCollector.create(cappedNumHits, after, new
GlobalHitsThresholdChecker(TOTAL_HITS_THRESHOLD));
Review comment:
It should be created once and shared within the collectors ? We also don't
need to use the `GlobalHitsThresholdChecker` if the executor is null or if
there is a single slice.
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] (LUCENE-8959) JapaneseNumberFilter does not take whitespaces into account when concatenating numbers
[ https://issues.apache.org/jira/browse/LUCENE-8959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Ferenczi updated LUCENE-8959: - Description: Today the JapaneseNumberFilter tries to concatenate numbers even if they are separated by whitespaces. So for instance "10 100" is rewritten into "10100" -even if the tokenizer doesn't discard punctuations-. In practice this is not an issue but this can lead to giant number of tokens if there are a lot of numbers separated by spaces. The number of concatenation should be configurable with a sane default limit in order to avoid creating giant tokens that slows down the analysis if the tokenizer is not correctly configured. (was: Today the JapaneseNumberFilter tries to concatenate numbers even if they are separated by whitespaces. So for instance "10 100" is rewritten into "10100" even if the tokenizer doesn't discard punctuations. In practice this is not an issue but this can lead to giant number of tokens if there are a lot of numbers separated by spaces. The number of concatenation should be configurable with a sane default limit in order to avoid creating big tokens that slows down the analysis.) > JapaneseNumberFilter does not take whitespaces into account when > concatenating numbers > -- > > Key: LUCENE-8959 > URL: https://issues.apache.org/jira/browse/LUCENE-8959 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jim Ferenczi >Priority: Minor > > Today the JapaneseNumberFilter tries to concatenate numbers even if they are > separated by whitespaces. So for instance "10 100" is rewritten into "10100" > -even if the tokenizer doesn't discard punctuations-. In practice this is not > an issue but this can lead to giant number of tokens if there are a lot of > numbers separated by spaces. The number of concatenation should be > configurable with a sane default limit in order to avoid creating giant > tokens that slows down the analysis if the tokenizer is not correctly > configured. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13718) SPLITSHARD using async can cause data loss
[
https://issues.apache.org/jira/browse/SOLR-13718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918540#comment-16918540
]
ASF subversion and git services commented on SOLR-13718:
Commit f27665198a87692311e7798e835933fc1e9ff986 in lucene-solr's branch
refs/heads/master from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f276651 ]
SOLR-13718: A more targeted fix for SPLITSHARD, thereby avoiding Backup/Restore
test failures
> SPLITSHARD using async can cause data loss
> --
>
> Key: SOLR-13718
> URL: https://issues.apache.org/jira/browse/SOLR-13718
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7.2, 8.1, 8.2
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 7.7.3, 8.3
>
> Attachments: SOLR-13718.patch, solr-13718-reproduce.sh, solr.zip
>
>
> When using SPLITSHARD with async, if there are underlying failures in the
> SPLIT core command or other sub-commands of SPLITSHARD, then SPLITSHARD
> succeeds and results in two empty sub-shards.
> There are various potential failures with SPLIT core command, here's a way to
> reproduce using a Solr 6x index in Solr 7x.
> -Steps to reproduce (in Solr 7x):-
> {code}
> 1. Import the attached configset, and create a collection.
> 2. Move in the attached data directory (index created in Solr6x) in place of
> the created collection's data directory. Do a collection RELOAD.
> 3. Issue a *:* query, we see 5 documents.
> 4. Issue a SPLITSHARD (async), and then issue *:*, we see 0 documents.
> {code}
> Check attached solr-13718-reproduce.sh script to do the same (without needing
> the zip file).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13718) SPLITSHARD using async can cause data loss
[
https://issues.apache.org/jira/browse/SOLR-13718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918541#comment-16918541
]
ASF subversion and git services commented on SOLR-13718:
Commit 12715da544379ad6bad2f13164cea2f4cfe2c78e in lucene-solr's branch
refs/heads/branch_8x from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=12715da ]
SOLR-13718: A more targeted fix for SPLITSHARD, thereby avoiding Backup/Restore
test failures
> SPLITSHARD using async can cause data loss
> --
>
> Key: SOLR-13718
> URL: https://issues.apache.org/jira/browse/SOLR-13718
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7.2, 8.1, 8.2
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 7.7.3, 8.3
>
> Attachments: SOLR-13718.patch, solr-13718-reproduce.sh, solr.zip
>
>
> When using SPLITSHARD with async, if there are underlying failures in the
> SPLIT core command or other sub-commands of SPLITSHARD, then SPLITSHARD
> succeeds and results in two empty sub-shards.
> There are various potential failures with SPLIT core command, here's a way to
> reproduce using a Solr 6x index in Solr 7x.
> -Steps to reproduce (in Solr 7x):-
> {code}
> 1. Import the attached configset, and create a collection.
> 2. Move in the attached data directory (index created in Solr6x) in place of
> the created collection's data directory. Do a collection RELOAD.
> 3. Issue a *:* query, we see 5 documents.
> 4. Issue a SPLITSHARD (async), and then issue *:*, we see 0 documents.
> {code}
> Check attached solr-13718-reproduce.sh script to do the same (without needing
> the zip file).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-526152703 Ran precommit on the latest iteration -- came in clean. @jimczi Looks good to be committed? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 3643 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3643/
1 tests failed.
FAILED:
org.apache.solr.cloud.api.collections.TestHdfsCloudBackupRestore.testRestoreFailure
Error Message:
Failed collection is still in the clusterstate:
DocCollection(hdfsbackuprestore_testfailure_restored//collections/hdfsbackuprestore_testfailure_restored/state.json/2)={
"pullReplicas":0, "replicationFactor":2, "shards":{ "shard2":{
"range":"0-7fff", "state":"construction",
"replicas":{"core_node2":{
"core":"hdfsbackuprestore_testfailure_restored_shard2_replica_n1",
"base_url":"http://127.0.0.1:39491/solr";,
"node_name":"127.0.0.1:39491_solr", "state":"down",
"type":"NRT", "force_set_state":"false"}},
"stateTimestamp":"1567077343098341196"}, "shard1":{
"range":"8000-", "state":"construction", "replicas":{},
"stateTimestamp":"1567077343098356703"}},
"router":{"name":"compositeId"}, "maxShardsPerNode":"2",
"autoAddReplicas":"false", "nrtReplicas":2, "tlogReplicas":0} Expected: not
a collection containing "hdfsbackuprestore_testfailure_restored" but: was
<[hdfsbackuprestore_testok, hdfsbackuprestore_testfailure_restored,
hdfsbackuprestore_testfailure, hdfsbackuprestore_testok_restored]>
Stack Trace:
java.lang.AssertionError: Failed collection is still in the clusterstate:
DocCollection(hdfsbackuprestore_testfailure_restored//collections/hdfsbackuprestore_testfailure_restored/state.json/2)={
"pullReplicas":0,
"replicationFactor":2,
"shards":{
"shard2":{
"range":"0-7fff",
"state":"construction",
"replicas":{"core_node2":{
"core":"hdfsbackuprestore_testfailure_restored_shard2_replica_n1",
"base_url":"http://127.0.0.1:39491/solr";,
"node_name":"127.0.0.1:39491_solr",
"state":"down",
"type":"NRT",
"force_set_state":"false"}},
"stateTimestamp":"1567077343098341196"},
"shard1":{
"range":"8000-",
"state":"construction",
"replicas":{},
"stateTimestamp":"1567077343098356703"}},
"router":{"name":"compositeId"},
"maxShardsPerNode":"2",
"autoAddReplicas":"false",
"nrtReplicas":2,
"tlogReplicas":0}
Expected: not a collection containing "hdfsbackuprestore_testfailure_restored"
but: was <[hdfsbackuprestore_testok,
hdfsbackuprestore_testfailure_restored, hdfsbackuprestore_testfailure,
hdfsbackuprestore_testok_restored]>
at
__randomizedtesting.SeedInfo.seed([67B07A2A706FB781:4ECCE40F5836B4AC]:0)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.junit.Assert.assertThat(Assert.java:956)
at
org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.testRestoreFailure(AbstractCloudBackupRestoreTestCase.java:211)
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(Randomized
[jira] [Commented] (LUCENE-8959) JapaneseNumberFilter does not take whitespaces into account when concatenating numbers
[ https://issues.apache.org/jira/browse/LUCENE-8959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918532#comment-16918532 ] Jim Ferenczi commented on LUCENE-8959: -- *Update:* Whitespaces were removed in my tests because I was using the default JapanesePartOfSpeechStopFilter before the JapaneseNumberFilter. The behavior is correct when discardPunctuations is correctly set and the JapanesePartOfSpeechStopFilter is the first filter in the chain. We could protect against the rabbit hole for users that forget to set discardPunctuations to false or remove the whitespaces in a preceding filter but the behavior is correct. Sorry for the false alarm. > JapaneseNumberFilter does not take whitespaces into account when > concatenating numbers > -- > > Key: LUCENE-8959 > URL: https://issues.apache.org/jira/browse/LUCENE-8959 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jim Ferenczi >Priority: Minor > > Today the JapaneseNumberFilter tries to concatenate numbers even if they are > separated by whitespaces. So for instance "10 100" is rewritten into "10100" > even if the tokenizer doesn't discard punctuations. In practice this is not > an issue but this can lead to giant number of tokens if there are a lot of > numbers separated by spaces. The number of concatenation should be > configurable with a sane default limit in order to avoid creating big tokens > that slows down the analysis. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13718) SPLITSHARD using async can cause data loss
[
https://issues.apache.org/jira/browse/SOLR-13718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918519#comment-16918519
]
Ishan Chattopadhyaya commented on SOLR-13718:
-
The above fix caused a test failure in TestLocalFSCloudBackupRestore. There is
something wrong with ShardRequestTracker (OCMH)'s processResponses(), whereby
the abortOnError is not respected in case of async requests. In this fix, I
tried aborting (on error) the async requests as well. However, due to
aforementioned wrong behaviour, the RestoreCmd was working around by adding
additional checks, and hence the test started failing after my fix.
Fixing this the right way will require handling these async responses across
all collection API commands uniformly, and will be a longer effort. For now,
I'm going to revert my fix and handle the SPLITSHARD failure the same way as
RestoreCmd is doing.
> SPLITSHARD using async can cause data loss
> --
>
> Key: SOLR-13718
> URL: https://issues.apache.org/jira/browse/SOLR-13718
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7.2, 8.1, 8.2
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 7.7.3, 8.3
>
> Attachments: SOLR-13718.patch, solr-13718-reproduce.sh, solr.zip
>
>
> When using SPLITSHARD with async, if there are underlying failures in the
> SPLIT core command or other sub-commands of SPLITSHARD, then SPLITSHARD
> succeeds and results in two empty sub-shards.
> There are various potential failures with SPLIT core command, here's a way to
> reproduce using a Solr 6x index in Solr 7x.
> -Steps to reproduce (in Solr 7x):-
> {code}
> 1. Import the attached configset, and create a collection.
> 2. Move in the attached data directory (index created in Solr6x) in place of
> the created collection's data directory. Do a collection RELOAD.
> 3. Issue a *:* query, we see 5 documents.
> 4. Issue a SPLITSHARD (async), and then issue *:*, we see 0 documents.
> {code}
> Check attached solr-13718-reproduce.sh script to do the same (without needing
> the zip file).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918492#comment-16918492 ] Uwe Schindler commented on LUCENE-8951: --- I also found no bounces on my company's incoming server. > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists > # Announce to dev@ list that the change will happen > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[
https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918488#comment-16918488
]
Uwe Schindler commented on LUCENE-8951:
---
The Jenkins server already sent several mails, but all got lost (not even
appearing in moderation). It looks like they are swallowed completely. Could it
be that there is some size limit configured on this mailing list (in contrast
to dev@)? Maybe the server drops them because jenkins mails are quite big
because of log files.
This is a failed build and I neither got a mail notification through mailing
list nor any moderation mail:
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24630/console
{noformat}
Aug 29 09:58:05 serv1 postfix/smtpd[8811]: connect from ip6-localhost[::1]
Aug 29 09:58:05 serv1 postfix/smtpd[8811]: 502FE10800C7:
client=ip6-localhost[::1]
Aug 29 09:58:05 serv1 postfix/cleanup[8814]: 502FE10800C7:
message-id=<1214521720.14.1567072685329.javamail.jenk...@serv1.sd-datasolutions.de>
Aug 29 09:58:05 serv1 postfix/qmgr[3889]: 502FE10800C7:
from=, size=105988, nrcpt=1 (queue active)
Aug 29 09:58:05 serv1 postfix/smtpd[8811]: disconnect from ip6-localhost[::1]
ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
Aug 29 09:58:06 serv1 postfix/smtp[8815]: 502FE10800C7:
to=,
relay=mx1-he-de.apache.org[2a01:4f8:c2c:2bf7::1]:25, delay=1.6,
delays=0.1/0/0.22/1.3, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as
E24BE7D722)
Aug 29 09:58:06 serv1 postfix/qmgr[3889]: 502FE10800C7: removed
{noformat}
Not sure what happend with that mail! I think we may ask infra on Slack, all
required information to identify that mail should be above.
> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
> # Create mailing lists as an announce only list (/)
> # Subscribe all emails that will be allowed to post (/)
> # Update websites with info about the new lists
> # Announce to dev@ list that the change will happen
> # Modify Jira and Github bots to post to issues@ list instead of dev@
> # Modify Jenkins (including Policeman and other) to post to builds@
> # Announce to dev@ list that the change is effective
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-Tests-8.x - Build # 491 - Unstable
I'm looking into this failure. I think I caused it; apologies.
On Thu, Aug 29, 2019 at 12:56 PM Apache Jenkins Server
wrote:
>
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/491/
>
> 2 tests failed.
> FAILED:
> org.apache.solr.cloud.api.collections.TestHdfsCloudBackupRestore.testRestoreFailure
>
> Error Message:
> Failed collection is still in the clusterstate:
> DocCollection(hdfsbackuprestore_testfailure_restored//collections/hdfsbackuprestore_testfailure_restored/state.json/2)={
>"pullReplicas":0, "replicationFactor":1, "shards":{ "shard2":{
> "range":"0-7fff", "state":"construction",
> "replicas":{"core_node2":{
> "core":"hdfsbackuprestore_testfailure_restored_shard2_replica_n1",
> "base_url":"https://127.0.0.1:36659/solr";,
> "node_name":"127.0.0.1:36659_solr", "state":"down",
> "type":"NRT", "force_set_state":"false"}},
> "stateTimestamp":"1567059232049688251"}, "shard1":{
> "range":"8000-", "state":"construction",
> "replicas":{}, "stateTimestamp":"1567059232049701653"}},
> "router":{"name":"compositeId"}, "maxShardsPerNode":"1",
> "autoAddReplicas":"false", "nrtReplicas":1, "tlogReplicas":0} Expected:
> not a collection containing "hdfsbackuprestore_testfailure_restored"
> but: was <[hdfsbackuprestore_testok, hdfsbackuprestore_testfailure_restored,
> hdfsbackuprestore_testfailure, hdfsbackuprestore_testok_restored]>
>
> Stack Trace:
> java.lang.AssertionError: Failed collection is still in the clusterstate:
> DocCollection(hdfsbackuprestore_testfailure_restored//collections/hdfsbackuprestore_testfailure_restored/state.json/2)={
> "pullReplicas":0,
> "replicationFactor":1,
> "shards":{
> "shard2":{
> "range":"0-7fff",
> "state":"construction",
> "replicas":{"core_node2":{
> "core":"hdfsbackuprestore_testfailure_restored_shard2_replica_n1",
> "base_url":"https://127.0.0.1:36659/solr";,
> "node_name":"127.0.0.1:36659_solr",
> "state":"down",
> "type":"NRT",
> "force_set_state":"false"}},
> "stateTimestamp":"1567059232049688251"},
> "shard1":{
> "range":"8000-",
> "state":"construction",
> "replicas":{},
> "stateTimestamp":"1567059232049701653"}},
> "router":{"name":"compositeId"},
> "maxShardsPerNode":"1",
> "autoAddReplicas":"false",
> "nrtReplicas":1,
> "tlogReplicas":0}
> Expected: not a collection containing "hdfsbackuprestore_testfailure_restored"
> but: was <[hdfsbackuprestore_testok,
> hdfsbackuprestore_testfailure_restored, hdfsbackuprestore_testfailure,
> hdfsbackuprestore_testok_restored]>
> at
> __randomizedtesting.SeedInfo.seed([E037D74065656872:C94B49654D3C6B5F]:0)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.junit.Assert.assertThat(Assert.java:956)
> at
> org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.testRestoreFailure(AbstractCloudBackupRestoreTestCase.java:211)
> 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
[GitHub] [lucene-solr] atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-526122213 > > Also, I believe having the abstraction will let future implementations customize the threshold logic without needing to make any core changes or introduce a new collector, hence we should let the threshold checker implementations be public. WDYT? > > What kind of customization you have in mind ? Since this is now a `BooleanSupplier`, collectors can choose when to early terminate (a hacky idea might be to just terminate after some time has elapsed? Not saying it is a good idea though). > IMO having all this classes and functions that require HitsThresholdChecker as package protected would be enough and would not add to the overall complexity of running a simple search using an executor or not ? Package protected is a good idea -- updated. Does it look fine now? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] jimczi commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
jimczi commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-526120397 > Also, I believe having the abstraction will let future implementations customize the threshold logic without needing to make any core changes or introduce a new collector, hence we should let the threshold checker implementations be public. WDYT? What kind of customization you have in mind ? The logic is simple and I wonder if this could not be misleading since the total hits response depends on it to build the relation. IMO having all this classes and functions that require `HitsThresholdChecker ` as package protected would be enough and would not add to the overall complexity of running a simple search using an executor or not ? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8959) JapaneseNumberFilter does not take whitespaces into account when concatenating numbers
[ https://issues.apache.org/jira/browse/LUCENE-8959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918464#comment-16918464 ] Christian Moen commented on LUCENE-8959: Sounds like a good idea. This is also rather big rabbit hole... Would it be useful to consider making the digit grouping separators configurable as part of a bigger scheme here? In Japanese, if you're processing text with SI numbers, I believe space is a valid digit grouping. > JapaneseNumberFilter does not take whitespaces into account when > concatenating numbers > -- > > Key: LUCENE-8959 > URL: https://issues.apache.org/jira/browse/LUCENE-8959 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jim Ferenczi >Priority: Minor > > Today the JapaneseNumberFilter tries to concatenate numbers even if they are > separated by whitespaces. So for instance "10 100" is rewritten into "10100" > even if the tokenizer doesn't discard punctuations. In practice this is not > an issue but this can lead to giant number of tokens if there are a lot of > numbers separated by spaces. The number of concatenation should be > configurable with a sane default limit in order to avoid creating big tokens > that slows down the analysis. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-526113533 > > So, essentially, we make implicit CollectorManager implementations owned by IndexSearcher instead of separate implementation classes? > > Yes I think it would be easier and we don't really need to expose `HitsThresholdChecker` in this case, it's just an impl detail that is used by the parallel and the normal top docs collector ? Not really, it would be shared across both `TopFieldCollector and `TopScoreDocCollector`. Also, I believe having the abstraction will let future implementations customize the threshold logic without needing to make any core changes or introduce a new collector, hence we should let the threshold checker implementations be public. WDYT? Updated per comments -- let me know if it looks fine 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-12291) Async prematurely reports completed status that causes severe shard loss
[ https://issues.apache.org/jira/browse/SOLR-12291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918455#comment-16918455 ] Mikhail Khludnev commented on SOLR-12291: - It does. I haven't thought about porting to 7.x. Would you like me to do so? > Async prematurely reports completed status that causes severe shard loss > > > Key: SOLR-12291 > URL: https://issues.apache.org/jira/browse/SOLR-12291 > Project: Solr > Issue Type: Bug > Components: Backup/Restore, SolrCloud >Reporter: Varun Thacker >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-12291.patch, SOLR-12291.patch, SOLR-12291.patch, > SOLR-12291.patch, SOLR-12291.patch, SOLR-12291.patch, SOLR-12291.patch, > SOLR-122911.patch > > > The OverseerCollectionMessageHandler sliceCmd assumes only one replica exists > on one node > When multiple replicas of a slice are on the same node we only track one > replica's async request. This happens because the async requestMap's key is > "node_name" > I discovered this when [~alabax] shared some logs of a restore issue, where > the second replica got added before the first replica had completed it's > restorecore action. > While looking at the logs I noticed that the overseer never called > REQUESTSTATUS for the restorecore action , almost as if it had missed > tracking that particular async request. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] jimczi commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
jimczi commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-526110754 > So, essentially, we make implicit CollectorManager implementations owned by IndexSearcher instead of separate implementation classes? Yes I think it would be easier and we don't really need to expose `HitsThresholdChecker` in this case, it's just an impl detail that is used by the parallel and the normal top docs collector ? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 3577 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/3577/ [...truncated 31 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/491/consoleText [repro] Revision: d606ffdea92513a29bd7d7a1af3cfdf556aae93c [repro] Repro line: ant test -Dtestcase=TestHdfsCloudBackupRestore -Dtests.method=testRestoreFailure -Dtests.seed=E037D74065656872 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ja-JP -Dtests.timezone=America/Guyana -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=TestLocalFSCloudBackupRestore -Dtests.method=testRestoreFailure -Dtests.seed=E037D74065656872 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=el-CY -Dtests.timezone=Europe/Isle_of_Man -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 43d489cb4a0d71cf8dace9e015b9de0bc44854b2 [repro] git fetch [repro] git checkout d606ffdea92513a29bd7d7a1af3cfdf556aae93c [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestHdfsCloudBackupRestore [repro] TestLocalFSCloudBackupRestore [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 -Dtests.class="*.TestHdfsCloudBackupRestore|*.TestLocalFSCloudBackupRestore" -Dtests.showOutput=onerror -Dtests.seed=E037D74065656872 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ja-JP -Dtests.timezone=America/Guyana -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 19642 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 5/5 failed: org.apache.solr.cloud.api.collections.TestHdfsCloudBackupRestore [repro] 5/5 failed: org.apache.solr.cloud.api.collections.TestLocalFSCloudBackupRestore [repro] Re-testing 100% failures at the tip of branch_8x [repro] git fetch [repro] git checkout branch_8x [...truncated 4 lines...] [repro] git merge --ff-only [...truncated 41 lines...] [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestHdfsCloudBackupRestore [repro] TestLocalFSCloudBackupRestore [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 -Dtests.class="*.TestHdfsCloudBackupRestore|*.TestLocalFSCloudBackupRestore" -Dtests.showOutput=onerror -Dtests.seed=E037D74065656872 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ja-JP -Dtests.timezone=America/Guyana -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 19382 lines...] [repro] Setting last failure code to 256 [repro] Failures at the tip of branch_8x: [repro] 5/5 failed: org.apache.solr.cloud.api.collections.TestHdfsCloudBackupRestore [repro] 5/5 failed: org.apache.solr.cloud.api.collections.TestLocalFSCloudBackupRestore [repro] Re-testing 100% failures at the tip of branch_8x without a seed [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestHdfsCloudBackupRestore [repro] TestLocalFSCloudBackupRestore [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 -Dtests.class="*.TestHdfsCloudBackupRestore|*.TestLocalFSCloudBackupRestore" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ja-JP -Dtests.timezone=America/Guyana -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 22059 lines...] [repro] Setting last failure code to 256 [repro] Failures at the tip of branch_8x without a seed: [repro] 5/5 failed: org.apache.solr.cloud.api.collections.TestHdfsCloudBackupRestore [repro] 5/5 failed: org.apache.solr.cloud.api.collections.TestLocalFSCloudBackupRestore [repro] git checkout 43d489cb4a0d71cf8dace9e015b9de0bc44854b2 [...truncated 8 lines...] [repro] Exiting with code 256 [...truncated 6 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8959) JapaneseNumberFilter does not take whitespaces into account when concatenating numbers
Jim Ferenczi created LUCENE-8959: Summary: JapaneseNumberFilter does not take whitespaces into account when concatenating numbers Key: LUCENE-8959 URL: https://issues.apache.org/jira/browse/LUCENE-8959 Project: Lucene - Core Issue Type: Improvement Reporter: Jim Ferenczi Today the JapaneseNumberFilter tries to concatenate numbers even if they are separated by whitespaces. So for instance "10 100" is rewritten into "10100" even if the tokenizer doesn't discard punctuations. In practice this is not an issue but this can lead to giant number of tokens if there are a lot of numbers separated by spaces. The number of concatenation should be configurable with a sane default limit in order to avoid creating big tokens that slows down the analysis. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-526102145 > > That would require a CollectorManager implementation > > Not necessarily, you could create a `GlobalSharedHitsThresholdChecker` and use it in the manager impl of `IndexSearcher#searchAfter` if the executor is not null and the number of slices is > 1 ? > In fact I wonder if the collector manager impls (`SharedHitCountFieldCollectorManager`, ...) are required, we could use the `GlobalSharedHitsThresholdChecker` internally in `IndexSearcher` without adding a dedicated manager impl ? So, essentially, we make implicit `CollectorManager` implementations owned by `IndexSearcher` instead of separate implementation classes? I am fine with this -- I do not really have a strong preference either 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
