[jira] [Commented] (SOLR-14404) CoreContainer level custom requesthandlers
[
https://issues.apache.org/jira/browse/SOLR-14404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149919#comment-17149919
]
ASF subversion and git services commented on SOLR-14404:
Commit 2e60e1fbbd3f72526b2975398f3943c398637c21 in lucene-solr's branch
refs/heads/master from noblepaul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2e60e1f ]
SOLR-14404: Unregister was not working for plugins with $path-prefix
> CoreContainer level custom requesthandlers
> --
>
> Key: SOLR-14404
> URL: https://issues.apache.org/jira/browse/SOLR-14404
> Project: Solr
> Issue Type: New Feature
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/plugin}}
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "full.ClassName"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> add a plugin from a package
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "pkgName:full.ClassName" ,
> "version: "1.0"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName" }
> }
> }
> {code}
> example plugin
> {code:java}
> public class MyPlugin {
> private final CoreContainer coreContainer;
> public MyPlugin(CoreContainer coreContainer) {
> this.coreContainer = coreContainer;
> }
> @EndPoint(path = "/myplugin/path1",
> method = METHOD.GET,
> permission = READ)
> public void call(SolrQueryRequest req, SolrQueryResponse rsp){
> rsp.add("myplugin.version", "2.0");
> }
> }
> {code}
> This plugin will be accessible on all nodes at {{/api/myplugin/path1}}. It's
> possible to add more methods at different paths. Ensure that all paths start
> with {{myplugin}} because that is the name in which the plugin is registered
> with. So {{/myplugin/path2}} , {{/myplugin/my/deeply/nested/path}} are all
> valid paths.
> It's possible that the user chooses to register the plugin with a different
> name. In that case , use a template variable as follows in paths
> {{$plugin-name/path1}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14404) CoreContainer level custom requesthandlers
[
https://issues.apache.org/jira/browse/SOLR-14404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149918#comment-17149918
]
ASF subversion and git services commented on SOLR-14404:
Commit 093c992fd208bbcd1cc3b7738b202c6737207a4f in lucene-solr's branch
refs/heads/branch_8x from noblepaul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=093c992 ]
SOLR-14404: Unregister was not working for plugins with $path-prefix
> CoreContainer level custom requesthandlers
> --
>
> Key: SOLR-14404
> URL: https://issues.apache.org/jira/browse/SOLR-14404
> Project: Solr
> Issue Type: New Feature
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/plugin}}
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "full.ClassName"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> add a plugin from a package
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "pkgName:full.ClassName" ,
> "version: "1.0"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName" }
> }
> }
> {code}
> example plugin
> {code:java}
> public class MyPlugin {
> private final CoreContainer coreContainer;
> public MyPlugin(CoreContainer coreContainer) {
> this.coreContainer = coreContainer;
> }
> @EndPoint(path = "/myplugin/path1",
> method = METHOD.GET,
> permission = READ)
> public void call(SolrQueryRequest req, SolrQueryResponse rsp){
> rsp.add("myplugin.version", "2.0");
> }
> }
> {code}
> This plugin will be accessible on all nodes at {{/api/myplugin/path1}}. It's
> possible to add more methods at different paths. Ensure that all paths start
> with {{myplugin}} because that is the name in which the plugin is registered
> with. So {{/myplugin/path2}} , {{/myplugin/my/deeply/nested/path}} are all
> valid paths.
> It's possible that the user chooses to register the plugin with a different
> name. In that case , use a template variable as follows in paths
> {{$plugin-name/path1}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14404) CoreContainer level custom requesthandlers
[
https://issues.apache.org/jira/browse/SOLR-14404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149908#comment-17149908
]
ASF subversion and git services commented on SOLR-14404:
Commit 39dfc1e4f9d3a672f4eddd162c6d016bc8eab845 in lucene-solr's branch
refs/heads/branch_8_6 from noblepaul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=39dfc1e ]
SOLR-14404: Unregister was not working for plugins with $path-prefix
> CoreContainer level custom requesthandlers
> --
>
> Key: SOLR-14404
> URL: https://issues.apache.org/jira/browse/SOLR-14404
> Project: Solr
> Issue Type: New Feature
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/plugin}}
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "full.ClassName"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> add a plugin from a package
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "pkgName:full.ClassName" ,
> "version: "1.0"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName" }
> }
> }
> {code}
> example plugin
> {code:java}
> public class MyPlugin {
> private final CoreContainer coreContainer;
> public MyPlugin(CoreContainer coreContainer) {
> this.coreContainer = coreContainer;
> }
> @EndPoint(path = "/myplugin/path1",
> method = METHOD.GET,
> permission = READ)
> public void call(SolrQueryRequest req, SolrQueryResponse rsp){
> rsp.add("myplugin.version", "2.0");
> }
> }
> {code}
> This plugin will be accessible on all nodes at {{/api/myplugin/path1}}. It's
> possible to add more methods at different paths. Ensure that all paths start
> with {{myplugin}} because that is the name in which the plugin is registered
> with. So {{/myplugin/path2}} , {{/myplugin/my/deeply/nested/path}} are all
> valid paths.
> It's possible that the user chooses to register the plugin with a different
> name. In that case , use a template variable as follows in paths
> {{$plugin-name/path1}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] atris closed pull request #1636: Remove Compound file formation
atris closed pull request #1636: URL: https://github.com/apache/lucene-solr/pull/1636 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14597) Advanced Query Parser
[ https://issues.apache.org/jira/browse/SOLR-14597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149787#comment-17149787 ] David Smiley commented on SOLR-14597: - With the advent of Solr's package management system, I wonder if this should be a "package", either 1st party (i.e. a contrib) or even elsewhere. "elsewhere" isn't a great option as there is no central place to find them yet. Also, I see this plugin introduces schema components and the plugin system is very close but doesn't _quite_ support that yet (I'm guilty on that front). But that'll be addressed soon. I don't have a strong opinion on this but wanted to bring it up. I suppose the package system wouldn't help much here: (A) no dependencies added (B) not a large body of code (C) _seems_ to have zero security risk (e.g. no escaping mechanism to use another query parser). Also, I could see this parser being very useful. > Advanced Query Parser > - > > Key: SOLR-14597 > URL: https://issues.apache.org/jira/browse/SOLR-14597 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Affects Versions: 8.6 >Reporter: Mike Nibeck >Assignee: Gus Heck >Priority: Major > > This JIRA ticket tracks the progress of SIP-9, the Advanced Query Parser that > is being donated by the Library of Congress. Full description of the feature > can be found on the SIP Page. > [https://cwiki.apache.org/confluence/display/SOLR/SIP-9+Advanced+Query+Parser] > Briefly, this parser provides a comprehensive syntax for users that use > search on a daily basis. It also reserves a smaller set of punctuators than > other parsers. This facilitates easier handling of acronyms and punctuated > patterns with meaning ( such as C++ or 401(k) ). The new syntax opens up some > advanced features while also preventing access to arbitrary features via > local parameters. This parser will be safe for accepting user queries > directly with minimal pre-parsing, but for use cases beyond it's established > features alternate query paths (using other parsers) will need to be supplied. > The code drop is being prepared and will be supplied as soon as we receive > guidance from the PMC regarding the proper process. Given that the Library > already has a signed CCLA we need to understand which of these (or other > processes) apply: > [http://incubator.apache.org/ip-clearance/ip-clearance-template.html] > and > [https://www.apache.org/licenses/contributor-agreements.html#grants] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] MarcusSorealheis closed pull request #1640: test
MarcusSorealheis closed pull request #1640: URL: https://github.com/apache/lucene-solr/pull/1640 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] MarcusSorealheis opened a new pull request #1640: test
MarcusSorealheis opened a new pull request #1640: URL: https://github.com/apache/lucene-solr/pull/1640 # Description Please provide a short description of the changes you're making with this pull request. # Solution Please provide a short description of the approach taken to implement your solution. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [ ] I have developed this patch against the `master` branch. - [ ] I have run `ant precommit` and the appropriate test suite. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14523) Enhance gradle logging calls validation: eliminate getMessage()
[
https://issues.apache.org/jira/browse/SOLR-14523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-14523:
--
Fix Version/s: 8.7
Resolution: Fixed
Status: Resolved (was: Patch Available)
Thanks Andras!
> Enhance gradle logging calls validation: eliminate getMessage()
> ---
>
> Key: SOLR-14523
> URL: https://issues.apache.org/jira/browse/SOLR-14523
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andras Salamon
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 8.7
>
> Attachments: SOLR-14523.patch, validation.patch
>
>
> SOLR-14280 fixed a logging problem in SolrConfig by removing a few
> getMessage() calls. We could enhance this solution by modifying gradle's
> logging calls validation and forbid getMessage() calls during logging. We
> should check the existing code and eliminate such calls.
> It is possible to suppress the warning using {{//logok}}.
> [~erickerickson] [~gerlowskija]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14523) Enhance gradle logging calls validation: eliminate getMessage()
[
https://issues.apache.org/jira/browse/SOLR-14523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149777#comment-17149777
]
ASF subversion and git services commented on SOLR-14523:
Commit 1e9cfe87da7ddd7cb7f3777ca8690a67440c98c8 in lucene-solr's branch
refs/heads/branch_8x from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1e9cfe8 ]
SOLR-14523: Enhance gradle logging calls validation: eliminate getMessage()
> Enhance gradle logging calls validation: eliminate getMessage()
> ---
>
> Key: SOLR-14523
> URL: https://issues.apache.org/jira/browse/SOLR-14523
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andras Salamon
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-14523.patch, validation.patch
>
>
> SOLR-14280 fixed a logging problem in SolrConfig by removing a few
> getMessage() calls. We could enhance this solution by modifying gradle's
> logging calls validation and forbid getMessage() calls during logging. We
> should check the existing code and eliminate such calls.
> It is possible to suppress the warning using {{//logok}}.
> [~erickerickson] [~gerlowskija]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14523) Enhance gradle logging calls validation: eliminate getMessage()
[
https://issues.apache.org/jira/browse/SOLR-14523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149776#comment-17149776
]
ASF subversion and git services commented on SOLR-14523:
Commit d0864a19c7c039d49be3c8635252c42cebb48dfb in lucene-solr's branch
refs/heads/master from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d0864a1 ]
SOLR-14523: Enhance gradle logging calls validation: eliminate getMessage()
> Enhance gradle logging calls validation: eliminate getMessage()
> ---
>
> Key: SOLR-14523
> URL: https://issues.apache.org/jira/browse/SOLR-14523
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andras Salamon
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-14523.patch, validation.patch
>
>
> SOLR-14280 fixed a logging problem in SolrConfig by removing a few
> getMessage() calls. We could enhance this solution by modifying gradle's
> logging calls validation and forbid getMessage() calls during logging. We
> should check the existing code and eliminate such calls.
> It is possible to suppress the warning using {{//logok}}.
> [~erickerickson] [~gerlowskija]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149773#comment-17149773 ] David Smiley commented on SOLR-14066: - I just want to point out that removing deprecated things for 9.0 has its own JIRA -- SOLR-13138 and I've contributed to that branch already. DIH removal could be its own JIRA (I have no opinion there) as a sub-task. > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-14066: Description: DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in 8.6, remove from 9.0. A community supported version of DIH (which can be used with Solr's package manager) can be found here https://github.com/rohitbemax/dataimporthandler. (was: DataImportHandler has outlived its utility. DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in 8.6, remove from 9.0. A community supported version of DIH (which can be used with Solr's package manager) can be found here https://github.com/rohitbemax/dataimporthandler.) > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13138) Remove deprecated code prior to 9.0
[ https://issues.apache.org/jira/browse/SOLR-13138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-13138: Fix Version/s: master (9.0) Priority: Blocker (was: Major) Summary: Remove deprecated code prior to 9.0 (was: Remove deprecated code in master) > Remove deprecated code prior to 9.0 > --- > > Key: SOLR-13138 > URL: https://issues.apache.org/jira/browse/SOLR-13138 > Project: Solr > Issue Type: Improvement >Affects Versions: master (9.0) >Reporter: Alan Woodward >Priority: Blocker > Fix For: master (9.0) > > > There are a number of deprecations in master that should be removed. This > issue is to keep track of deprecations as a whole, some individual > deprecations may require their own issues. > > Work on this issue should be pushed to the `master-deprecations` branch on > gitbox. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1574: SOLR-14566: Add request-ID to all distrib-search requests
dsmiley commented on a change in pull request #1574:
URL: https://github.com/apache/lucene-solr/pull/1574#discussion_r448702273
##
File path:
solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java
##
@@ -500,6 +508,31 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
}
}
+ private void tagRequestWithRequestId(ResponseBuilder rb) {
+final boolean ridTaggingDisabled =
rb.req.getParams().getBool(CommonParams.DISABLE_REQUEST_ID, false);
+if (! ridTaggingDisabled) {
+ String rid = getRequestId(rb.req);
+ if
(StringUtils.isBlank(rb.req.getParams().get(CommonParams.REQUEST_ID))) {
+ModifiableSolrParams params = new
ModifiableSolrParams(rb.req.getParams());
+params.add(CommonParams.REQUEST_ID, rid);//add rid to the request so
that shards see it
+rb.req.setParams(params);
+ }
+ if (rb.isDistrib) {
+rb.rsp.addToLog(CommonParams.REQUEST_ID, rid); //to see it in the logs
of the landing core
+ }
+}
+ }
+
+ public static String getRequestId(SolrQueryRequest req) {
Review comment:
The fact that this method could generate a RID each time it's called on
the same request seems problematic. Instead, either don't have it do any such
generation (I think my preference), or have it both generate one and save it
into the the params so that the same request ID is returned given the same
request.
Also; let's document our public methods on an important class like
SearchHandler.
##
File path:
solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java
##
@@ -500,6 +508,31 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
}
}
+ private void tagRequestWithRequestId(ResponseBuilder rb) {
+final boolean ridTaggingDisabled =
rb.req.getParams().getBool(CommonParams.DISABLE_REQUEST_ID, false);
+if (! ridTaggingDisabled) {
+ String rid = getRequestId(rb.req);
+ if
(StringUtils.isBlank(rb.req.getParams().get(CommonParams.REQUEST_ID))) {
+ModifiableSolrParams params = new
ModifiableSolrParams(rb.req.getParams());
Review comment:
Maybe we don't need a flag parameter to decide what to do with rid.
What if Solr sees rid=\* (or true?) then it knows to generate a rid, and if it
sees a blank/empty string (or false?) then it does nothing. If it's something
else than it *is* the rid (either from the client or generated). One parameter
to look at for this feature seems nicer than two. Also, relating to my concern
about wholesale disabling, it could be set in the solrconfig as a param default.
##
File path:
solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java
##
@@ -298,7 +305,8 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
final RTimerTree timer = rb.isDebug() ? req.getRequestTimer() : null;
final ShardHandler shardHandler1 = getAndPrepShardHandler(req, rb); //
creates a ShardHandler object only if it's needed
-
+
+tagRequestWithRequestId(rb);
Review comment:
super minor but please add a blank line after this because it's not
related to timer.
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1574: SOLR-14566: Add request-ID to all distrib-search requests
dsmiley commented on a change in pull request #1574:
URL: https://github.com/apache/lucene-solr/pull/1574#discussion_r448699301
##
File path:
solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java
##
@@ -510,14 +510,18 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
}
private void tagRequestWithRequestId(ResponseBuilder rb) {
-String rid = getRequestId(rb.req);
-if (StringUtils.isBlank(rb.req.getParams().get(CommonParams.REQUEST_ID))) {
- ModifiableSolrParams params = new
ModifiableSolrParams(rb.req.getParams());
- params.add(CommonParams.REQUEST_ID, rid);//add rid to the request so
that shards see it
- rb.req.setParams(params);
-}
-if (rb.isDistrib) {
- rb.rsp.addToLog(CommonParams.REQUEST_ID, rid); //to see it in the logs
of the landing core
+final String disableFlag =
rb.req.getParams().get(CommonParams.DISABLE_REQUEST_ID);
Review comment:
Having to disable one parameter showing up by adding another parameter
kinda defeats the point. To some people, this new parameter is needless noise.
To them, your solution is to tell them to add more noise (another param) to
make that one go away. I don't understand why users would toggle this on a
query-by-query basis. I suspect people holistically like this new ID on all
their requests, or they don't. But maybe you have something in mind? I
suppose it *could* be both -- you set the default as a cluster property but
allow an override for the request. Hmm; yeah I rather like that.
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14557) eDisMax parser unable to parse {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149761#comment-17149761
]
Lucene/Solr QA commented on SOLR-14557:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
7s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 3s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 45m
28s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 49m 33s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-14557 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/13006862/SOLR-14557.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.15.0-108-generic #109-Ubuntu SMP Fri Jun 19
11:33:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 76e1d901cb9 |
| 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-SOLR-Build/773/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/773/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> eDisMax parser unable to parse {!lucene}(gigabyte)
> --
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman opened a new pull request #1639: SOLR-14022: Deprecate CDCR
chatman opened a new pull request #1639: URL: https://github.com/apache/lucene-solr/pull/1639 See JIRA for more details. 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14022) Deprecate CDCR from Solr in 8.x
[ https://issues.apache.org/jira/browse/SOLR-14022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149757#comment-17149757 ] Ishan Chattopadhyaya commented on SOLR-14022: - Added a PR for this: https://github.com/apache/lucene-solr/pull/1639 > Deprecate CDCR from Solr in 8.x > --- > > Key: SOLR-14022 > URL: https://issues.apache.org/jira/browse/SOLR-14022 > Project: Solr > Issue Type: Improvement > Components: CDCR >Reporter: Joel Bernstein >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Time Spent: 10m > Remaining Estimate: 0h > > This ticket will deprecate CDCR in Solr 8x. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149752#comment-17149752 ] Ishan Chattopadhyaya commented on SOLR-14066: - bq. I'm a bit sceptical of leaving traces of DIH in solr-core, used by a 3rd party package. What happens when Rohit needs to modify the UI to support a new feature? We should remove all traces of DIH in 9.0. In [~rohitcse]'s version, we could build a DIH UI separately. > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DataImportHandler has outlived its utility. DIH doesn't need to remain inside > Solr anymore. Plan is to deprecate DIH in 8.6, remove from 9.0. A community > supported version of DIH (which can be used with Solr's package manager) can > be found here https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-14066: Description: DataImportHandler has outlived its utility. DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in 8.6, remove from 9.0. A community supported version of DIH (which can be used with Solr's package manager) can be found here https://github.com/rohitbemax/dataimporthandler. (was: DataImportHandler has outlived its utility. DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in 8.5, remove from 9.0. Also, work on handing it off to volunteers in the community (so far, [~rohitcse] has volunteered to maintain it). Update: A community supported version of DIH would be https://github.com/rohitbemax/dataimporthandler.) > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DataImportHandler has outlived its utility. DIH doesn't need to remain inside > Solr anymore. Plan is to deprecate DIH in 8.6, remove from 9.0. A community > supported version of DIH (which can be used with Solr's package manager) can > be found here https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-14066: Summary: Deprecate DIH and migrate to a community supported package (was: Deprecate DIH) > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DataImportHandler has outlived its utility. DIH doesn't need to remain inside > Solr anymore. Plan is to deprecate DIH in 8.5, remove from 9.0. Also, work on > handing it off to volunteers in the community (so far, [~rohitcse] has > volunteered to maintain it). > Update: A community supported version of DIH would be > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149751#comment-17149751 ] Ishan Chattopadhyaya commented on SOLR-14066: - Added a PR for this: https://github.com/apache/lucene-solr/pull/1638 [~ilan], thanks for fixing the test. [~ctargett], I'll update the title and description of this issue. I'll open an issue to remove DIH after this issue is fixed. > Deprecate DIH > - > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DataImportHandler has outlived its utility. DIH doesn't need to remain inside > Solr anymore. Plan is to deprecate DIH in 8.5, remove from 9.0. Also, work on > handing it off to volunteers in the community (so far, [~rohitcse] has > volunteered to maintain it). > Update: A community supported version of DIH would be > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14592) Upgrade Zookeeper to 3.6.1
[ https://issues.apache.org/jira/browse/SOLR-14592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-14592. --- Fix Version/s: 8.7 Resolution: Fixed > Upgrade Zookeeper to 3.6.1 > -- > > Key: SOLR-14592 > URL: https://issues.apache.org/jira/browse/SOLR-14592 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Fix For: 8.7 > > Time Spent: 40m > Remaining Estimate: 0h > > We're two releases behind, seems like A Good Thing to upgrade. I'm usually > reluctant to upgrade just before a release so I'll do this after the 8.6 > branch is cut. > Shouldn't be a big deal, from Zookeeper: > "This is the second release for 3.6 branch. > It is a bugfix release and it fixes a few compatibility issues with > applications built for ZooKeeper 3.5. The upgrade from 3.5.7 to 3.6.1 can be > executed as usual, no particular additional upgrade procedure is needed. > ZooKeeper 3.6.1 clients are compatible with 3.5 servers as long as you are > not using new APIs not present in 3.5." -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14606) Upgrade Netty to 4.1.50
[ https://issues.apache.org/jira/browse/SOLR-14606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-14606. --- Fix Version/s: 8.7 Resolution: Fixed See SOLR-14592 > Upgrade Netty to 4.1.50 > --- > > Key: SOLR-14606 > URL: https://issues.apache.org/jira/browse/SOLR-14606 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Fix For: 8.7 > > > Other than general principles about not falling too far behind, do any of the > issues listed here seem compelling? NOTE: I wouldn't upgrade this until after > 8.6 is cut. > We're currently on 4-1-47 > https://netty.io/news/2020/03/17/4-1-48-Final.html > https://netty.io/news/2020/04/22/4-1-49-Final.html > https://netty.io/news/2020/05/13/4-1-50-Final.html -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman opened a new pull request #1638: SOLR-14066: Deprecate DIH
chatman opened a new pull request #1638: URL: https://github.com/apache/lucene-solr/pull/1638 Deprecating DIH. See SOLR-14066 for details. This is based on @janhoy's previous PR, with minor changes here and there. 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman commented on pull request #1631: SOLR-14599: Package manager support for cluster level plugins
chatman commented on pull request #1631: URL: https://github.com/apache/lucene-solr/pull/1631#issuecomment-652701845 Merged. Thanks. 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman closed pull request #1631: SOLR-14599: Package manager support for cluster level plugins
chatman closed pull request #1631: URL: https://github.com/apache/lucene-solr/pull/1631 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14592) Upgrade Zookeeper to 3.6.1
[ https://issues.apache.org/jira/browse/SOLR-14592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149747#comment-17149747 ] ASF subversion and git services commented on SOLR-14592: Commit 2ad1ad0164d144efcd98e7e30ef2af15d66cab6b in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2ad1ad0 ] SOLR-14592: Upgrade Zookeeper to 3.6.1 > Upgrade Zookeeper to 3.6.1 > -- > > Key: SOLR-14592 > URL: https://issues.apache.org/jira/browse/SOLR-14592 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > We're two releases behind, seems like A Good Thing to upgrade. I'm usually > reluctant to upgrade just before a release so I'll do this after the 8.6 > branch is cut. > Shouldn't be a big deal, from Zookeeper: > "This is the second release for 3.6 branch. > It is a bugfix release and it fixes a few compatibility issues with > applications built for ZooKeeper 3.5. The upgrade from 3.5.7 to 3.6.1 can be > executed as usual, no particular additional upgrade procedure is needed. > ZooKeeper 3.6.1 clients are compatible with 3.5 servers as long as you are > not using new APIs not present in 3.5." -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14592) Upgrade Zookeeper to 3.6.1
[ https://issues.apache.org/jira/browse/SOLR-14592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149748#comment-17149748 ] ASF subversion and git services commented on SOLR-14592: Commit 76e1d901cb9c35ac8fcec33a17d9e7e78f8b2790 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=76e1d90 ] SOLR-14592: Upgrade Zookeeper to 3.6.1 > Upgrade Zookeeper to 3.6.1 > -- > > Key: SOLR-14592 > URL: https://issues.apache.org/jira/browse/SOLR-14592 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > We're two releases behind, seems like A Good Thing to upgrade. I'm usually > reluctant to upgrade just before a release so I'll do this after the 8.6 > branch is cut. > Shouldn't be a big deal, from Zookeeper: > "This is the second release for 3.6 branch. > It is a bugfix release and it fixes a few compatibility issues with > applications built for ZooKeeper 3.5. The upgrade from 3.5.7 to 3.6.1 can be > executed as usual, no particular additional upgrade procedure is needed. > ZooKeeper 3.6.1 clients are compatible with 3.5 servers as long as you are > not using new APIs not present in 3.5." -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6152) Pre-populating values into search parameters on the query page of solr admin
[ https://issues.apache.org/jira/browse/SOLR-6152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149741#comment-17149741 ] Jakob Furrer edited comment on SOLR-6152 at 7/1/20, 11:34 PM: -- A friendly front-end colleague has helped me to develop a patch for the required improvements and the issues that have been mentioned in the linked ticket SOLR-6404. The attached patch changes the behavior of the admin UI as follows: - all form elements can no be preset/prefilled using the corresponding query parameters - presetting of check-boxes works correctly now - prefilling and manually adding multi-values is now possible for the parameter 'fq' - the button "Execute Query" generates an URL to re-open the query form (i.e. the present page with its current values prefilled in the form) - as before, the button "Execute Query" generates an URL to the specified handler (typically "select") to execute the search - both the URL to the query for and the URL to the rest result can now be copied to the clipboard using the respective button - the patch has been created on Master, merge to 8.x and 7.x should work as well Please confirm and commit. was (Author: jafurrer): A friendly front-end colleague has helped me to develop a patch for the required improvements and the issues that have been mentioned in the linked ticket SOLR-6404. The attached patch changes the behavior of the admin UI as follows: - all form elements can no be preset/prefilled using the corresponding query parameters - presetting of check-boxes works correctly now - prefilling and manually adding multi-values is now possible for the parameter 'fq' - the button "Execute Query" generates an URL to re-open the query form (i.e. the present page with its current values prefilled in the form) - as before, the button "Execute Query" generates an URL to the specified handler ([^SOLR-6152.patch]!copy_url_to_clipboard.png! typically "select") to execute the search - both the URL to the query for and the URL to the rest result can now be copied to the clipboard using the respective button - the patch has been created on Master, merge to 8.x and 7.x should work as well Please confirm and commit. > Pre-populating values into search parameters on the query page of solr admin > > > Key: SOLR-6152 > URL: https://issues.apache.org/jira/browse/SOLR-6152 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Affects Versions: 4.3.1 >Reporter: Dmitry Kan >Priority: Major > Attachments: SOLR-6152.patch, copy_url_to_clipboard.png, > prefilling_and_extending_the_multivalue_parameter_fq.png, > prepoluate_query_parameters_query_page.bmp > > > In some use cases, it is highly desirable to be able to pre-populate the > query page of solr admin with specific values. > In particular use case of mine, the solr admin user must pass a date range > value without which the query would fail. > It isn't easy to remember the value format for non-solr experts, so I would > like to have a way of hooking that value "example" into the query page. > See the screenshot attached, where I have inserted the fq parameter with date > range into the Raw Query Parameters. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-6152) Pre-populating values into search parameters on the query page of solr admin
[ https://issues.apache.org/jira/browse/SOLR-6152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Furrer updated SOLR-6152: --- Attachment: SOLR-6152.patch > Pre-populating values into search parameters on the query page of solr admin > > > Key: SOLR-6152 > URL: https://issues.apache.org/jira/browse/SOLR-6152 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Affects Versions: 4.3.1 >Reporter: Dmitry Kan >Priority: Major > Attachments: SOLR-6152.patch, copy_url_to_clipboard.png, > prefilling_and_extending_the_multivalue_parameter_fq.png, > prepoluate_query_parameters_query_page.bmp > > > In some use cases, it is highly desirable to be able to pre-populate the > query page of solr admin with specific values. > In particular use case of mine, the solr admin user must pass a date range > value without which the query would fail. > It isn't easy to remember the value format for non-solr experts, so I would > like to have a way of hooking that value "example" into the query page. > See the screenshot attached, where I have inserted the fq parameter with date > range into the Raw Query Parameters. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-6152) Pre-populating values into search parameters on the query page of solr admin
[ https://issues.apache.org/jira/browse/SOLR-6152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149741#comment-17149741 ] Jakob Furrer commented on SOLR-6152: A friendly front-end colleague has helped me to develop a patch for the required improvements and the issues that have been mentioned in the linked ticket SOLR-6404. The attached patch changes the behavior of the admin UI as follows: - all form elements can no be preset/prefilled using the corresponding query parameters - presetting of check-boxes works correctly now - prefilling and manually adding multi-values is now possible for the parameter 'fq' - the button "Execute Query" generates an URL to re-open the query form (i.e. the present page with its current values prefilled in the form) - as before, the button "Execute Query" generates an URL to the specified handler ([^SOLR-6152.patch]!copy_url_to_clipboard.png! typically "select") to execute the search - both the URL to the query for and the URL to the rest result can now be copied to the clipboard using the respective button - the patch has been created on Master, merge to 8.x and 7.x should work as well Please confirm and commit. > Pre-populating values into search parameters on the query page of solr admin > > > Key: SOLR-6152 > URL: https://issues.apache.org/jira/browse/SOLR-6152 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Affects Versions: 4.3.1 >Reporter: Dmitry Kan >Priority: Major > Attachments: SOLR-6152.patch, copy_url_to_clipboard.png, > prefilling_and_extending_the_multivalue_parameter_fq.png, > prepoluate_query_parameters_query_page.bmp > > > In some use cases, it is highly desirable to be able to pre-populate the > query page of solr admin with specific values. > In particular use case of mine, the solr admin user must pass a date range > value without which the query would fail. > It isn't easy to remember the value format for non-solr experts, so I would > like to have a way of hooking that value "example" into the query page. > See the screenshot attached, where I have inserted the fq parameter with date > range into the Raw Query Parameters. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-6152) Pre-populating values into search parameters on the query page of solr admin
[ https://issues.apache.org/jira/browse/SOLR-6152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Furrer updated SOLR-6152: --- Attachment: prefilling_and_extending_the_multivalue_parameter_fq.png copy_url_to_clipboard.png > Pre-populating values into search parameters on the query page of solr admin > > > Key: SOLR-6152 > URL: https://issues.apache.org/jira/browse/SOLR-6152 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Affects Versions: 4.3.1 >Reporter: Dmitry Kan >Priority: Major > Attachments: SOLR-6152.patch, copy_url_to_clipboard.png, > prefilling_and_extending_the_multivalue_parameter_fq.png, > prepoluate_query_parameters_query_page.bmp > > > In some use cases, it is highly desirable to be able to pre-populate the > query page of solr admin with specific values. > In particular use case of mine, the solr admin user must pass a date range > value without which the query would fail. > It isn't easy to remember the value format for non-solr experts, so I would > like to have a way of hooking that value "example" into the query page. > See the screenshot attached, where I have inserted the fq parameter with date > range into the Raw Query Parameters. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gerlowskija commented on a change in pull request #1574: SOLR-14566: Add request-ID to all distrib-search requests
gerlowskija commented on a change in pull request #1574:
URL: https://github.com/apache/lucene-solr/pull/1574#discussion_r448635969
##
File path:
solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java
##
@@ -510,14 +510,18 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
}
private void tagRequestWithRequestId(ResponseBuilder rb) {
-String rid = getRequestId(rb.req);
-if (StringUtils.isBlank(rb.req.getParams().get(CommonParams.REQUEST_ID))) {
- ModifiableSolrParams params = new
ModifiableSolrParams(rb.req.getParams());
- params.add(CommonParams.REQUEST_ID, rid);//add rid to the request so
that shards see it
- rb.req.setParams(params);
-}
-if (rb.isDistrib) {
- rb.rsp.addToLog(CommonParams.REQUEST_ID, rid); //to see it in the logs
of the landing core
+final String disableFlag =
rb.req.getParams().get(CommonParams.DISABLE_REQUEST_ID);
Review comment:
Man you're quick on the reviews.
I like a SolrParam better than a cluster property. Users might well have
reasons to enable/disable it differently based on the source or type of query.
A Cluster Property doesn't offer that sort of granularity (at least, as I
understand them).
I don't feel super strongly though, so if you disagree with that rationale,
lmk. I'm gearing up to commit soon-ish.
(I did change to getBool though as you suggested. I initially avoided this
because I thought it'd be nice to have any value for this param disable the
`rid`. But that didn't really fit in with how other similar flags work, so I
scrapped the idea.)
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gerlowskija commented on a change in pull request #1574: SOLR-14566: Add request-ID to all distrib-search requests
gerlowskija commented on a change in pull request #1574:
URL: https://github.com/apache/lucene-solr/pull/1574#discussion_r448635969
##
File path:
solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java
##
@@ -510,14 +510,18 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
}
private void tagRequestWithRequestId(ResponseBuilder rb) {
-String rid = getRequestId(rb.req);
-if (StringUtils.isBlank(rb.req.getParams().get(CommonParams.REQUEST_ID))) {
- ModifiableSolrParams params = new
ModifiableSolrParams(rb.req.getParams());
- params.add(CommonParams.REQUEST_ID, rid);//add rid to the request so
that shards see it
- rb.req.setParams(params);
-}
-if (rb.isDistrib) {
- rb.rsp.addToLog(CommonParams.REQUEST_ID, rid); //to see it in the logs
of the landing core
+final String disableFlag =
rb.req.getParams().get(CommonParams.DISABLE_REQUEST_ID);
Review comment:
Man you're quick on the reviews.
I like a SolrParam better than a cluster property. Users might well have
reasons to enable/disable it differently based on the source or type of query.
A Cluster Property doesn't offer that sort of granularity (at least, as I
understand them).
I don't feel super strongly though, so if you disagree with that rationale,
lmk. I'm gearing up to commit soon-ish.
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14614) Add Simplified Aggregation Interface to Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-14614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aroop updated SOLR-14614:
-
Description:
For the Data Analytics use cases the standard use case is:
# Find a pattern
# Then Aggregate by certain dimensions
# Then compute metrics (like count, sum, avg)
# Sort by a dimension or metric
# look at top-n
This functionality has been available over many different interfaces in the
past on solr, but only streaming expressions have the ability to deliver
results in a scalable, performant and stable manner for systems that have large
data to the tune of Big data systems.
However, one barrier to entry is the query interface, not being simple enough
in streaming expressions.
to give an example of how involved the corresponding streaming expression can
get, to get it to work on large scale systems,{color:#4c9aff} _find top 10
cities where someone named Alex works with the respective counts_{color}
{code:java}
qt=/stream=facet=
select( top( rollup(sort(by%3D"city+asc",
+plist(
select(facet(collection1,+q%3D"(*:*+AND+name:alex)",+buckets%3D"city",+bucketSizeLimit%3D"2010",+bucketSorts%3D"count(*)+desc",+count(*)),+city,+count(*)+as+Nj3bXa),
select(facet(collection2,+q%3D"(*:*+AND+name:alex)",+buckets%3D"city",+bucketSizeLimit%3D"2010",+bucketSorts%3D"count(*)+desc",+count(*)),+city,+count(*)+as+Nj3bXa)
)),
+over%3D"city",+sum(Nj3bXa)),
+n%3D"10",+sort%3D"sum(Nj3bXa)+desc"),
+city,+sum(Nj3bXa)+as+Nj3bXa)
{code}
This is a query on an alias with 2 collections behind it representing 2 data
partitions, which is a requirement of sorts in big data systems. This is one of
the only ways to get information from Billions of records in a matter of
seconds. This is awesome in terms of capability and performance.
But one can see how involved this syntax can be in the current scheme and is a
barrier to entry for new adopters.
This Jira is to track the work of creating a simplified analytics endpoint
augmenting streaming expressions.
a starting proposal is to have the endpoint have these query parameters:
{code:java}
/analytics?action=aggregate=*:*=name:alex=city=count=count=desc=10{code}
This is equivalent to a sql that an analyst would write:
{code:java}
select city, count(*) from collection where name = 'alex'
group by city order by count(*) desc limit 10;{code}
On the solr side this would get translated to the best possible streaming
expression using *rollups, top, sort, plist* etc.; but all done transparently
to the user.
Heres to making the power of Streaming expressions simpler to use for all.
was:
For the Data Analytics use cases the standard use case is:
# Find a pattern
# Then Aggregate by certain dimensions
# Then compute metrics (like count, sum, avg)
# Sort by a dimension or metric
# look at top-n
This functionality has been available over many different interfaces in the
past on solr, but only streaming expressions have the ability to deliver
results in a scalable, performant and stable manner for systems that have large
data to the tune of Big data systems.
However, one barrier to entry is the query interface, not being simple enough
in streaming expressions.
to give an example of how involved the corresponding streaming expression can
get, to get it to work on large scale systems, _find me top 10 cities where
someone named Alex works with the respective counts_
{code:java}
qt=/stream=facet=
select( top( rollup(sort(by%3D"city+asc",
+plist(
select(facet(collection1,+q%3D"(*:*+AND+name:alex)",+buckets%3D"city",+bucketSizeLimit%3D"2010",+bucketSorts%3D"count(*)+desc",+count(*)),+city,+count(*)+as+Nj3bXa),
select(facet(collection2,+q%3D"(*:*+AND+name:alex)",+buckets%3D"city",+bucketSizeLimit%3D"2010",+bucketSorts%3D"count(*)+desc",+count(*)),+city,+count(*)+as+Nj3bXa)
)),
+over%3D"city",+sum(Nj3bXa)),
+n%3D"10",+sort%3D"sum(Nj3bXa)+desc"),
+city,+sum(Nj3bXa)+as+Nj3bXa)
{code}
This is a query on an alias with 2 collections behind it representing 2 data
partitions, which is a requirement of sorts in big data systems. This is one of
the only ways to get information from Billions of records in a matter of
seconds. But one can see how involved this syntax can be in the current scheme
and is a barrier to entry for new adopters.
This Jira is to track the work of creating a simplified analytics endpoint
augmenting streaming expressions.
a starting proposal is to have the endpoint have these query parameters:
{code:java}
/analytics?action=aggregate=*:*=name:alex=city=count=count=desc=10{code}
This is equivalent to a sql that an analyst would write:
{code:java}
select city, count(*) from collection where name = 'alex'
group by city order by count(*) desc limit 10;{code}
On the solr side this would get translated to the best possible streaming
[GitHub] [lucene-solr] gerlowskija commented on a change in pull request #1574: SOLR-14566: Add request-ID to all distrib-search requests
gerlowskija commented on a change in pull request #1574:
URL: https://github.com/apache/lucene-solr/pull/1574#discussion_r448635969
##
File path:
solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java
##
@@ -510,14 +510,18 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
}
private void tagRequestWithRequestId(ResponseBuilder rb) {
-String rid = getRequestId(rb.req);
-if (StringUtils.isBlank(rb.req.getParams().get(CommonParams.REQUEST_ID))) {
- ModifiableSolrParams params = new
ModifiableSolrParams(rb.req.getParams());
- params.add(CommonParams.REQUEST_ID, rid);//add rid to the request so
that shards see it
- rb.req.setParams(params);
-}
-if (rb.isDistrib) {
- rb.rsp.addToLog(CommonParams.REQUEST_ID, rid); //to see it in the logs
of the landing core
+final String disableFlag =
rb.req.getParams().get(CommonParams.DISABLE_REQUEST_ID);
Review comment:
Man you're quick on the reviews.
I like a SolrParam better than a cluster property. Users might well have
reasons to enable/disable it differently based on the source or type of query.
A Cluster Property doesn't offer that sort of granularity (at least, as I
understand them).
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14614) Add Simplified Aggregation Interface to Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-14614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aroop updated SOLR-14614:
-
Description:
For the Data Analytics use cases the standard use case is:
# Find a pattern
# Then Aggregate by certain dimensions
# Then compute metrics (like count, sum, avg)
# Sort by a dimension or metric
# look at top-n
This functionality has been available over many different interfaces in the
past on solr, but only streaming expressions have the ability to deliver
results in a scalable, performant and stable manner for systems that have large
data to the tune of Big data systems.
However, one barrier to entry is the query interface, not being simple enough
in streaming expressions.
to give an example of how involved the corresponding streaming expression can
get, to get it to work on large scale systems, _find me top 10 cities where
someone named Alex works with the respective counts_
{code:java}
qt=/stream=facet=
select( top( rollup(sort(by%3D"city+asc",
+plist(
select(facet(collection1,+q%3D"(*:*+AND+name:alex)",+buckets%3D"city",+bucketSizeLimit%3D"2010",+bucketSorts%3D"count(*)+desc",+count(*)),+city,+count(*)+as+Nj3bXa),
select(facet(collection2,+q%3D"(*:*+AND+name:alex)",+buckets%3D"city",+bucketSizeLimit%3D"2010",+bucketSorts%3D"count(*)+desc",+count(*)),+city,+count(*)+as+Nj3bXa)
)),
+over%3D"city",+sum(Nj3bXa)),
+n%3D"10",+sort%3D"sum(Nj3bXa)+desc"),
+city,+sum(Nj3bXa)+as+Nj3bXa)
{code}
This is a query on an alias with 2 collections behind it representing 2 data
partitions, which is a requirement of sorts in big data systems. This is one of
the only ways to get information from Billions of records in a matter of
seconds. But one can see how involved this syntax can be in the current scheme
and is a barrier to entry for new adopters.
This Jira is to track the work of creating a simplified analytics endpoint
augmenting streaming expressions.
a starting proposal is to have the endpoint have these query parameters:
{code:java}
/analytics?action=aggregate=*:*=name:alex=city=count=count=desc=10{code}
This is equivalent to a sql that an analyst would write:
{code:java}
select city, count(*) from collection where name = 'alex'
group by city order by count(*) desc limit 10;{code}
On the solr side this would get translated to the best possible streaming
expression using *rollups, top, sort, plist* etc.; but all done transparently
to the user.
Heres to making the power of Streaming expressions simpler to use for all.
was:
For the Data Analytics use cases the standard use case is:
# Find a pattern
# Then Aggregate by certain dimensions
# Then compute metrics (like count, sum, avg)
# Sort by a dimension or metric
# look at top-n
This functionality has been available over many different interfaces in the
past on solr, but only streaming expressions have the ability to deliver
results in a scalable, performant and stable manner for systems that have large
data to the tune of Big data systems.
However, one barrier to entry is the query interface, not being simple enough
in streaming expressions.
to give an example of how involved the corresponding streaming expression can
get, to get it to work on large scale systems,
{code:java}
qt=/stream=facet=
select( top( rollup(sort(by%3D"city+asc",
+plist(
select(facet(collection1,+q%3D"(*:*+AND+name:alex)",+buckets%3D"city",+bucketSizeLimit%3D"2010",+bucketSorts%3D"count(*)+desc",+count(*)),+city,+count(*)+as+Nj3bXa),
select(facet(collection2,+q%3D"(*:*+AND+name:alex)",+buckets%3D"city",+bucketSizeLimit%3D"2010",+bucketSorts%3D"count(*)+desc",+count(*)),+city,+count(*)+as+Nj3bXa)
)),
+over%3D"city",+sum(Nj3bXa)),
+n%3D"10",+sort%3D"sum(Nj3bXa)+desc"),
+city,+sum(Nj3bXa)+as+Nj3bXa)
{code}
This is a query on an alias with 2 collections behind it representing 2 data
partitions, which is a requirement of sorts in big data systems. This is one of
the only ways to get information from Billions of records in a matter of
seconds. But one can see how involved this syntax can be in the current scheme
and is a barrier to entry for new adopters.
This Jira is to track the work of creating a simplified analytics endpoint
augmenting streaming expressions.
a starting proposal is to have the endpoint have these query parameters:
{code:java}
/analytics?action=aggregate=*:*=name:alex=city=count=count=desc=10{code}
This is equivalent to a sql that an analyst would write:
{code:java}
select city, count(*) from collection where name = 'alex'
group by city order by count(*) desc limit 10;{code}
On the solr side this would get translated to the best possible streaming
expression using *rollups, top, sort, plist* etc.; but all done transparently
to the user.
Heres to making the power of Streaming expressions simpler to use
[jira] [Updated] (SOLR-14614) Add Simplified Aggregation Interface to Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-14614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aroop updated SOLR-14614:
-
Description:
For the Data Analytics use cases the standard use case is:
# Find a pattern
# Then Aggregate by certain dimensions
# Then compute metrics (like count, sum, avg)
# Sort by a dimension or metric
# look at top-n
This functionality has been available over many different interfaces in the
past on solr, but only streaming expressions have the ability to deliver
results in a scalable, performant and stable manner for systems that have large
data to the tune of Big data systems.
However, one barrier to entry is the query interface, not being simple enough
in streaming expressions.
to give an example of how involved the corresponding streaming expression can
get, to get it to work on large scale systems,
{code:java}
qt=/stream=facet=
select( top( rollup(sort(by%3D"city+asc",
+plist(
select(facet(collection1,+q%3D"(*:*+AND+name:alex)",+buckets%3D"city",+bucketSizeLimit%3D"2010",+bucketSorts%3D"count(*)+desc",+count(*)),+city,+count(*)+as+Nj3bXa),
select(facet(collection2,+q%3D"(*:*+AND+name:alex)",+buckets%3D"city",+bucketSizeLimit%3D"2010",+bucketSorts%3D"count(*)+desc",+count(*)),+city,+count(*)+as+Nj3bXa)
)),
+over%3D"city",+sum(Nj3bXa)),
+n%3D"10",+sort%3D"sum(Nj3bXa)+desc"),
+city,+sum(Nj3bXa)+as+Nj3bXa)
{code}
This is a query on an alias with 2 collections behind it representing 2 data
partitions, which is a requirement of sorts in big data systems. This is one of
the only ways to get information from Billions of records in a matter of
seconds. But one can see how involved this syntax can be in the current scheme
and is a barrier to entry for new adopters.
This Jira is to track the work of creating a simplified analytics endpoint
augmenting streaming expressions.
a starting proposal is to have the endpoint have these query parameters:
{code:java}
/analytics?action=aggregate=*:*=name:alex=city=count=count=desc=10{code}
This is equivalent to a sql that an analyst would write:
{code:java}
select city, count(*) from collection where name = 'alex'
group by city order by count(*) desc limit 10;{code}
On the solr side this would get translated to the best possible streaming
expression using *rollups, top, sort, plist* etc.; but all done transparently
to the user.
Heres to making the power of Streaming expressions simpler to use for all.
was:
For the Data Analytics use cases the standard use case is:
# Find a pattern
# Then Aggregate by certain dimensions
# Then compute metrics (like count, sum, avg)
# Sort by a dimension or metric
# look at top-n
This functionality has been available over many different interfaces in the
past on solr, but only streaming expressions have the ability to deliver
results in a scalable, performant and stable manner for systems that have large
data to the tune of Big data systems.
However, one barrier to entry is the query interface, not being simple enough
in streaming expressions.
This Jira is to track the work of creating a simplified analytics endpoint
augmenting streaming expressions.
a starting proposal is to have the endpoint have these query parameters:
{code:java}
/analytics?action=aggregate=*:*=name:alex*=age,city=count=count=desc=10{code}
This is equivalent to a sql that an analyst would write:
{code:java}
select age, city, count(*) from collection where name like 'alex%'
group by age, city order by age desc limit 10;{code}
On the solr side this would get translated to the best possible streaming
expression using *rollups, top, sort, plist* etc.; but all done transparently
to the user.
> Add Simplified Aggregation Interface to Streaming Expression
>
>
> Key: SOLR-14614
> URL: https://issues.apache.org/jira/browse/SOLR-14614
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query, query parsers, streaming expressions
>Affects Versions: 7.7.2, 8.4.1
>Reporter: Aroop
>Priority: Major
>
> For the Data Analytics use cases the standard use case is:
> # Find a pattern
> # Then Aggregate by certain dimensions
> # Then compute metrics (like count, sum, avg)
> # Sort by a dimension or metric
> # look at top-n
> This functionality has been available over many different interfaces in the
> past on solr, but only streaming expressions have the ability to deliver
> results in a scalable, performant and stable manner for systems that have
> large data to the tune of Big data systems.
> However, one barrier to entry is the query interface, not being simple enough
> in streaming expressions.
> to give an example of how involved the
[GitHub] [lucene-solr] janhoy closed pull request #1604: Add No compression and Zstd Compression
janhoy closed pull request #1604: URL: https://github.com/apache/lucene-solr/pull/1604 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on pull request #1605: add no comoression and zstd compression
janhoy commented on pull request #1605: URL: https://github.com/apache/lucene-solr/pull/1605#issuecomment-652651405 Please stop adding random PRs without any explanation or JIRA links. We do not understand your intention here, sorry. Closing. 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy closed pull request #1605: add no comoression and zstd compression
janhoy closed pull request #1605: URL: https://github.com/apache/lucene-solr/pull/1605 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9379) Directory based approach for index encryption
[ https://issues.apache.org/jira/browse/LUCENE-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149694#comment-17149694 ] Bruno Roustant commented on LUCENE-9379: Watchers, I need your help. I need to know how you would use the encryption, and more precisely how you would provide the keys. Is my approach of using either an EncryptingDirectory (in the PR look at SimpleEncryptingDirectory) or a custom Codec (in the PR look at EncryptingCodec) appropriate for your use-case? Note that both SimpleEncryptingDirectory and EncryptingCodec are only in test packages as I expect the users to write some custom code to use encryption. If you have an idea of a standard code that could be added to make encryption easy, please share your idea here. > Directory based approach for index encryption > - > > Key: LUCENE-9379 > URL: https://issues.apache.org/jira/browse/LUCENE-9379 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Bruno Roustant >Assignee: Bruno Roustant >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > The goal is to provide optional encryption of the index, with a scope limited > to an encryptable Lucene Directory wrapper. > Encryption is at rest on disk, not in memory. > This simple approach should fit any Codec as it would be orthogonal, without > modifying APIs as much as possible. > Use a standard encryption method. Limit perf/memory impact as much as > possible. > Determine how callers provide encryption keys. They must not be stored on > disk. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9379) Directory based approach for index encryption
[ https://issues.apache.org/jira/browse/LUCENE-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149691#comment-17149691 ] Bruno Roustant commented on LUCENE-9379: I updated the PR. Now it is functional and complete, with javadoc. There should be no perf issue anymore because I replaced javax.crypto.Cipher by a much lighter code that is strictly equivalent, encryption/decryption is the same (tested randomly by 3 different tests). For reviewers, there are 33 changed files in the PR but only 10 source classes, the other are for tests. Look for the classes in store package (e.g. EncryptingDirectory, EncryptingIndexOutput, EncryptingIndexInput) and the new util.crypto package (e.g. AesCtrEncrypter). Now all tests pass when enabling the encryption with a test codec or a test directory. Next step: * Run luceneutil benchmark to evaluate the perf impact. > Directory based approach for index encryption > - > > Key: LUCENE-9379 > URL: https://issues.apache.org/jira/browse/LUCENE-9379 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Bruno Roustant >Assignee: Bruno Roustant >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > The goal is to provide optional encryption of the index, with a scope limited > to an encryptable Lucene Directory wrapper. > Encryption is at rest on disk, not in memory. > This simple approach should fit any Codec as it would be orthogonal, without > modifying APIs as much as possible. > Use a standard encryption method. Limit perf/memory impact as much as > possible. > Determine how callers provide encryption keys. They must not be stored on > disk. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mkhludnev commented on pull request #1628: SOLR-14539: Ref Guide changes
mkhludnev commented on pull request #1628: URL: https://github.com/apache/lucene-solr/pull/1628#issuecomment-652634407 Merged to 8.6. 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mkhludnev closed pull request #1628: SOLR-14539: Ref Guide changes
mkhludnev closed pull request #1628: URL: https://github.com/apache/lucene-solr/pull/1628 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14557) eDisMax parser unable to parse {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149687#comment-17149687
]
Mikhail Khludnev edited comment on SOLR-14557 at 7/1/20, 8:30 PM:
--
Attached pretty straightforward fix for the grammar
{noformat}
| )* (~["=","}"])+ ( "=" ( |
("'" (<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}")+ (~[")","
","\t","\n","{","^"])* >
+| )* (~["=","}"])+ ( "=" (
| ("'" (<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}" "(") (~[")","
","\t","\n","{","^"])* ")" >
|
}
@@ -253,6 +254,7 @@ Query Clause(String field) throws SyntaxError : {
| (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
+ | (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
{noformat}
Opinions?
was (Author: mkhludnev):
Attached pretty straightforward fix for the grammar
{noformat}
| )* (~["=","}"])+ ( "=" ( | ("'"
(<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}")+ (~[")","
","\t","\n","{","^"])* >
+| )* (~["=","}"])+ ( "=" (
| ("'" (<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}" "(") (~[")","
","\t","\n","{","^"])* ")" >
|
}
@@ -253,6 +254,7 @@ Query Clause(String field) throws SyntaxError : {
| q=Query(field) [ boost= ]
| ( { flags=startFilter(); } q=Query(field) [
boost= ] { q=getFilter(q); restoreFlags(flags); } )
| (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
+ | (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
{noformat}
Opinions?
> eDisMax parser unable to parse {!lucene}(gigabyte)
> --
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14557) eDisMax parser unable to parse {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149687#comment-17149687
]
Mikhail Khludnev edited comment on SOLR-14557 at 7/1/20, 8:29 PM:
--
Attached pretty straightforward fix for the grammar
{noformat}
| )* (~["=","}"])+ ( "=" ( | ("'"
(<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}")+ (~[")","
","\t","\n","{","^"])* >
+| )* (~["=","}"])+ ( "=" (
| ("'" (<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}" "(") (~[")","
","\t","\n","{","^"])* ")" >
|
}
@@ -253,6 +254,7 @@ Query Clause(String field) throws SyntaxError : {
| q=Query(field) [ boost= ]
| ( { flags=startFilter(); } q=Query(field) [
boost= ] { q=getFilter(q); restoreFlags(flags); } )
| (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
+ | (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
{noformat}
Opinions?
was (Author: mkhludnev):
Attached pretty straightforward fix for the grammar
{quote}
| )* (~["=","}"])+ ( "=" ( | ("'"
(<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}")+ (~[")","
","\t","\n","{","^"])* >
+| )* (~["=","}"])+ ( "=" (
| ("'" (<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}" "(") (~[")","
","\t","\n","{","^"])* ")" >
|
}
@@ -253,6 +254,7 @@ Query Clause(String field) throws SyntaxError : {
| q=Query(field) [ boost= ]
| ( { flags=startFilter(); } q=Query(field) [
boost= ] { q=getFilter(q); restoreFlags(flags); } )
| (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
+ | (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
{quote}
Opinions?
> eDisMax parser unable to parse {!lucene}(gigabyte)
> --
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14557) eDisMax parser unable to parse {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149687#comment-17149687
]
Mikhail Khludnev edited comment on SOLR-14557 at 7/1/20, 8:28 PM:
--
Attached pretty straightforward fix for the grammar
{quote}
| )* (~["=","}"])+ ( "=" ( | ("'"
(<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}")+ (~[")","
","\t","\n","{","^"])* >
+| )* (~["=","}"])+ ( "=" (
| ("'" (<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}" "(") (~[")","
","\t","\n","{","^"])* ")" >
|
}
@@ -253,6 +254,7 @@ Query Clause(String field) throws SyntaxError : {
| q=Query(field) [ boost= ]
| ( { flags=startFilter(); } q=Query(field) [
boost= ] { q=getFilter(q); restoreFlags(flags); } )
| (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
+ | (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
{quote}
Opinions?
was (Author: mkhludnev):
Attached pretty straightforward fix for the grammar
{code}
| )* (~["=","}"])+ ( "=" ( | ("'"
(<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}")+ (~[")","
","\t","\n","{","^"])* >
+| )* (~["=","}"])+ ( "=" (
| ("'" (<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}" "(") (~[")","
","\t","\n","{","^"])* ")" >
|
}
@@ -253,6 +254,7 @@ Query Clause(String field) throws SyntaxError : {
| q=Query(field) [ boost= ]
| ( { flags=startFilter(); } q=Query(field) [
boost= ] { q=getFilter(q); restoreFlags(flags); } )
| (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
+ | (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
{code}
Opinions?
> eDisMax parser unable to parse {!lucene}(gigabyte)
> --
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14557) eDisMax parser unable to parse {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149687#comment-17149687
]
Mikhail Khludnev commented on SOLR-14557:
-
Attached pretty straightforward fix for the grammar
{code}
| )* (~["=","}"])+ ( "=" ( | ("'"
(<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}")+ (~[")","
","\t","\n","{","^"])* >
+| )* (~["=","}"])+ ( "=" (
| ("'" (<_SQUOTED_CHAR>)* "'") | (~[" ","}"])+ )? )? )* "}" "(") (~[")","
","\t","\n","{","^"])* ")" >
|
}
@@ -253,6 +254,7 @@ Query Clause(String field) throws SyntaxError : {
| q=Query(field) [ boost= ]
| ( { flags=startFilter(); } q=Query(field) [
boost= ] { q=getFilter(q); restoreFlags(flags); } )
| (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
+ | (localParams = [ boost= ] {
q=getLocalParams(field, localParams.image); } )
{code}
Opinions?
> eDisMax parser unable to parse {!lucene}(gigabyte)
> --
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14557) eDisMax parser unable to parse {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14557:
Attachment: SOLR-14557.patch
Status: Patch Available (was: Patch Available)
> eDisMax parser unable to parse {!lucene}(gigabyte)
> --
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14539:
Assignee: Mikhail Khludnev
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Fix For: 8.6
>
> Attachments: SOLR-14539.patch, SOLR-14539.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1574: SOLR-14566: Add request-ID to all distrib-search requests
dsmiley commented on a change in pull request #1574:
URL: https://github.com/apache/lucene-solr/pull/1574#discussion_r448563603
##
File path:
solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java
##
@@ -510,14 +510,18 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
}
private void tagRequestWithRequestId(ResponseBuilder rb) {
-String rid = getRequestId(rb.req);
-if (StringUtils.isBlank(rb.req.getParams().get(CommonParams.REQUEST_ID))) {
- ModifiableSolrParams params = new
ModifiableSolrParams(rb.req.getParams());
- params.add(CommonParams.REQUEST_ID, rid);//add rid to the request so
that shards see it
- rb.req.setParams(params);
-}
-if (rb.isDistrib) {
- rb.rsp.addToLog(CommonParams.REQUEST_ID, rid); //to see it in the logs
of the landing core
+final String disableFlag =
rb.req.getParams().get(CommonParams.DISABLE_REQUEST_ID);
Review comment:
I don't think this flag should be a request parameter; I think it should
be a "Cluster Property".
Secondly, if you do need to get this from a SolrParams, see `getBool`
method, accepting a default.
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on pull request #1626: SOLR-14588: Implement Circuit Breakers
madrob commented on pull request #1626: URL: https://github.com/apache/lucene-solr/pull/1626#issuecomment-652595688 Overall, I'm wondering if there gets to be a hysteresis condition where we are using enough memory to trigger the circuit breakers but not enough to trigger GC and the server gets into an unavailable state with no remedy. I don't know how we detect this or fix it, short of a restart. 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on a change in pull request #1626: SOLR-14588: Implement Circuit Breakers
madrob commented on a change in pull request #1626:
URL: https://github.com/apache/lucene-solr/pull/1626#discussion_r448550485
##
File path:
solr/core/src/java/org/apache/solr/util/circuitbreaker/MemoryCircuitBreaker.java
##
@@ -0,0 +1,111 @@
+/*
+ * 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.solr.util.circuitbreaker;
+
+import java.lang.invoke.MethodHandles;
+import java.lang.management.ManagementFactory;
+import java.lang.management.MemoryMXBean;
+
+import org.apache.solr.core.SolrConfig;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+/**
+ *
+ * Tracks the current JVM heap usage and triggers if it exceeds the defined
percentage of the maximum
+ * heap size allocated to the JVM. This circuit breaker is a part of the
default CircuitBreakerManager
+ * so is checked for every request -- hence it is realtime. Once the memory
usage goes below the threshold,
+ * it will start allowing queries again.
+ *
+ *
+ *
+ * The memory threshold is defined as a percentage of the maximum memory
allocated -- see memoryCircuitBreakerThresholdPct
+ * in solrconfig.xml.
+ *
+ */
+
+public class MemoryCircuitBreaker extends CircuitBreaker {
+ private static final Logger log =
LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());
+ private static final MemoryMXBean MEMORY_MX_BEAN =
ManagementFactory.getMemoryMXBean();
+
+ private final long heapMemoryThreshold;
+
+ // Assumption -- the value of these parameters will be set correctly before
invoking getDebugInfo()
+ private final ThreadLocal seenMemory = new ThreadLocal<>();
+ private final ThreadLocal allowedMemory = new ThreadLocal<>();
+
+ public MemoryCircuitBreaker(SolrConfig solrConfig) {
+super(solrConfig);
+
+long currentMaxHeap = MEMORY_MX_BEAN.getHeapMemoryUsage().getMax();
+
+if (currentMaxHeap <= 0) {
+ throw new IllegalArgumentException("Invalid JVM state for the max heap
usage");
+}
+
+int thresholdValueInPercentage =
solrConfig.memoryCircuitBreakerThresholdPct;
+double thresholdInFraction = thresholdValueInPercentage / (double) 100;
+heapMemoryThreshold = (long) (currentMaxHeap * thresholdInFraction);
+
+if (heapMemoryThreshold <= 0) {
+ throw new IllegalStateException("Memory limit cannot be less than or
equal to zero");
+}
+ }
+
+ // TODO: An optimization can be to trip the circuit breaker for a duration
of time
+ // after the circuit breaker condition is matched. This will optimize for
per call
+ // overhead of calculating the condition parameters but can result in false
positives.
+ @Override
+ public boolean isTripped() {
+if (!isEnabled()) {
+ return false;
+}
+
+allowedMemory.set(getCurrentMemoryThreshold());
+
+seenMemory.set(calculateLiveMemoryUsage());
+
+return (seenMemory.get() >= allowedMemory.get());
Review comment:
this solution has an extra unboxing.
##
File path: solr/core/src/test/org/apache/solr/util/TestCircuitBreaker.java
##
@@ -0,0 +1,220 @@
+/*
+ * 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.solr.util;
+
+import java.util.HashMap;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.atomic.AtomicInteger;
+
+import com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule;
+import org.apache.solr.SolrTestCaseJ4;
+import
[jira] [Commented] (LUCENE-8574) ExpressionFunctionValues should cache per-hit value
[
https://issues.apache.org/jira/browse/LUCENE-8574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149623#comment-17149623
]
Haoyu Zhai commented on LUCENE-8574:
[~mikemccand] Yes it fixes the test case. Before the fix the test will cause
{{OutOfMemoryException}} and after the fix it finishes in a reasonable time
(like < 1s when I run it solely)
Thanks for reviewing that, I've addressed those comments!
> ExpressionFunctionValues should cache per-hit value
> ---
>
> Key: LUCENE-8574
> URL: https://issues.apache.org/jira/browse/LUCENE-8574
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 7.5, 8.0
>Reporter: Michael McCandless
>Assignee: Robert Muir
>Priority: Major
> Attachments: LUCENE-8574.patch, unit_test.patch
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> The original version of {{ExpressionFunctionValues}} had a simple per-hit
> cache, so that nested expressions that reference the same common variable
> would compute the value for that variable the first time it was referenced
> and then use that cached value for all subsequent invocations, within one
> hit. I think it was accidentally removed in LUCENE-7609?
> This is quite important if you have non-trivial expressions that reference
> the same variable multiple times.
> E.g. if I have these expressions:
> {noformat}
> x = c + d
> c = b + 2
> d = b * 2{noformat}
> Then evaluating x should only cause b's value to be computed once (for a
> given hit), but today it's computed twice. The problem is combinatoric if b
> then references another variable multiple times, etc.
> I think to fix this we just need to restore the per-hit cache?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14523) Enhance gradle logging calls validation: eliminate getMessage()
[
https://issues.apache.org/jira/browse/SOLR-14523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149620#comment-17149620
]
Lucene/Solr QA commented on SOLR-14523:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 7 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
21s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 0m 51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 0m 51s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
41s{color} | {color:green} dataimporthandler in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
20s{color} | {color:green} dataimporthandler-extras in the patch passed.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m
9s{color} | {color:green} ltr in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
19s{color} | {color:green} prometheus-exporter in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 45m
1s{color} | {color:green} core in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m
36s{color} | {color:green} solrj in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 58m 53s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-14523 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/13006833/SOLR-14523.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.15.0-108-generic #109-Ubuntu SMP Fri Jun 19
11:33:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 1f6de31db85 |
| 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-SOLR-Build/772/testReport/ |
| modules | C: solr/contrib/dataimporthandler
solr/contrib/dataimporthandler-extras solr/contrib/ltr
solr/contrib/prometheus-exporter solr/core solr/solrj U: solr |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/772/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Enhance gradle logging calls validation: eliminate getMessage()
> ---
>
> Key: SOLR-14523
> URL: https://issues.apache.org/jira/browse/SOLR-14523
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andras Salamon
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-14523.patch, validation.patch
>
>
> SOLR-14280 fixed a logging problem in SolrConfig by removing a few
> getMessage() calls. We could enhance this solution by modifying gradle's
> logging calls validation and forbid getMessage() calls during logging. We
> should check the existing code and eliminate such calls.
> It is possible to suppress the warning using {{//logok}}.
> [~erickerickson] [~gerlowskija]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on pull request #1626: SOLR-14588: Implement Circuit Breakers
atris commented on pull request #1626: URL: https://github.com/apache/lucene-solr/pull/1626#issuecomment-652569167 @madrob Updated. Please see and let me know your thoughts and comments. 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] zhaih commented on a change in pull request #1613: LUCENE-8574 Cache ExpressionFunctionValues
zhaih commented on a change in pull request #1613:
URL: https://github.com/apache/lucene-solr/pull/1613#discussion_r448527770
##
File path:
lucene/expressions/src/test/org/apache/lucene/expressions/TestExpressionValueSource.java
##
@@ -128,6 +128,34 @@ public void testDoubleValuesSourceEquals() throws
Exception {
assertFalse(vs1.equals(vs4));
}
+ public void testFibonacciExpr() throws Exception {
+int n = 40;
+SimpleBindings bindings = new SimpleBindings();
+bindings.add("f0", DoubleValuesSource.constant(0));
+bindings.add("f1", DoubleValuesSource.constant(1));
+for (int i = 2; i < n + 1; i++) {
Review comment:
Sure.
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] zhaih commented on a change in pull request #1613: LUCENE-8574 Cache ExpressionFunctionValues
zhaih commented on a change in pull request #1613:
URL: https://github.com/apache/lucene-solr/pull/1613#discussion_r448525725
##
File path:
lucene/expressions/src/java/org/apache/lucene/expressions/CachingExpressionValueSource.java
##
@@ -0,0 +1,70 @@
+/*
+ * 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.expressions;
+
+import java.io.IOException;
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.search.DoubleValues;
+import org.apache.lucene.search.DoubleValuesSource;
+
+final class CachingExpressionValueSource extends ExpressionValueSource {
+
+ CachingExpressionValueSource(Bindings bindings, Expression expression) {
+super(bindings, expression);
+ }
+
+ CachingExpressionValueSource(DoubleValuesSource[] variables, Expression
expression, boolean needsScores) {
+super(variables, expression, needsScores);
+ }
+
+ public CachingExpressionValueSource(ExpressionValueSource
expressionValueSource) {
+super(expressionValueSource.variables, expressionValueSource.expression,
expressionValueSource.needsScores);
+ }
+
+ @Override
+ public DoubleValues getValues(LeafReaderContext readerContext, DoubleValues
scores) throws IOException {
+return getValuesWithCache(readerContext, scores, new HashMap<>());
+ }
+
+ public DoubleValues getValuesWithCache(LeafReaderContext readerContext,
DoubleValues scores,
Review comment:
Good catch! Yes I think it should be `private`
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] zhaih commented on a change in pull request #1613: LUCENE-8574 Cache ExpressionFunctionValues
zhaih commented on a change in pull request #1613:
URL: https://github.com/apache/lucene-solr/pull/1613#discussion_r448525027
##
File path:
lucene/expressions/src/java/org/apache/lucene/expressions/CachingExpressionValueSource.java
##
@@ -0,0 +1,70 @@
+/*
+ * 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.expressions;
+
+import java.io.IOException;
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.search.DoubleValues;
+import org.apache.lucene.search.DoubleValuesSource;
+
+final class CachingExpressionValueSource extends ExpressionValueSource {
+
+ CachingExpressionValueSource(Bindings bindings, Expression expression) {
+super(bindings, expression);
+ }
+
+ CachingExpressionValueSource(DoubleValuesSource[] variables, Expression
expression, boolean needsScores) {
+super(variables, expression, needsScores);
+ }
+
+ public CachingExpressionValueSource(ExpressionValueSource
expressionValueSource) {
+super(expressionValueSource.variables, expressionValueSource.expression,
expressionValueSource.needsScores);
+ }
+
+ @Override
+ public DoubleValues getValues(LeafReaderContext readerContext, DoubleValues
scores) throws IOException {
+return getValuesWithCache(readerContext, scores, new HashMap<>());
+ }
+
+ public DoubleValues getValuesWithCache(LeafReaderContext readerContext,
DoubleValues scores,
+ Map
valuesCache) throws IOException {
+DoubleValues[] externalValues = new
DoubleValues[expression.variables.length];
+
+for (int i = 0; i < variables.length; ++i) {
+ String externalName = expression.variables[i];
+ DoubleValues values = valuesCache.get(externalName);
+ if (values == null) {
+if (variables[i] instanceof CachingExpressionValueSource) {
+ values =
((CachingExpressionValueSource)variables[i]).getValuesWithCache(readerContext,
scores, valuesCache);
+} else {
+ values = variables[i].getValues(readerContext, scores);
+}
+if (values == null) {
+ throw new RuntimeException("Internal error. External (" +
externalName + ") does not exist.");
Review comment:
Yeah I think this error is happened because of a dependent variable was
not bound. The message is actually inherited from
`ExpressionValueSource#getValue` so I believe we'd better not change it or
change both?
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14022) Deprecate CDCR from Solr in 8.x
[ https://issues.apache.org/jira/browse/SOLR-14022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149600#comment-17149600 ] Gus Heck commented on SOLR-14022: - Do we want to think about whether it's a good idea to have yet another set of technologies/servers to deploy to make solr work (fully)? Pulsar uses in Bookeeper and it looks like pulsar gets deployed as its own cluster. So this would lead to a minimum of 4 Solrs, 3 zookeepers and 3 pulsars for HA across regions. I've met clients who had trouble with the idea of separate zookeeper servers... Another thing I'd like to say is a weakness of the existing CDCR is the use of collection names in config, which made it incompatible with routed aliases (where collections are added dynamically). A solution relying on external tools seems even less likely to be able to account for that. > Deprecate CDCR from Solr in 8.x > --- > > Key: SOLR-14022 > URL: https://issues.apache.org/jira/browse/SOLR-14022 > Project: Solr > Issue Type: Improvement > Components: CDCR >Reporter: Joel Bernstein >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > > This ticket will deprecate CDCR in Solr 8x. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14614) Add Simplified Aggregation Interface to Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-14614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aroop updated SOLR-14614:
-
Description:
For the Data Analytics use cases the standard use case is:
# Find a pattern
# Then Aggregate by certain dimensions
# Then compute metrics (like count, sum, avg)
# Sort by a dimension or metric
# look at top-n
This functionality has been available over many different interfaces in the
past on solr, but only streaming expressions have the ability to deliver
results in a scalable, performant and stable manner for systems that have large
data to the tune of Big data systems.
However, one barrier to entry is the query interface, not being simple enough
in streaming expressions.
This Jira is to track the work of creating a simplified analytics endpoint
augmenting streaming expressions.
a starting proposal is to have the endpoint have these query parameters:
{code:java}
/analytics?action=aggregate=*:*=name:alex*=age,city=count=count=desc=10{code}
This is equivalent to a sql that an analyst would write:
{code:java}
select age, city, count(*) from collection where name like 'alex%'
group by age, city order by age desc limit 10;{code}
On the solr side this would get translated to the best possible streaming
expression using *rollups, top, sort, plist* etc.; but all done transparently
to the user.
was:
For the Data Analytics use cases the standard use case is:
# Find a pattern
# Then Aggregate by certain dimensions
# Then compute metrics (like count, sum, avg)
# Sort by a dimension or metric
# look at top-n
This functionality has been available over many different interfaces in the
past on solr, but only streaming expressions have the ability to deliver
results in a scalable, performant and stable manner for systems that have large
data to the tune of Big data systems.
However, one barrier to entry is the query interface, not being simple enough
in streaming expressions.
This Jira is to track the work of creating a simplified analytics endpoint
augmenting streaming expressions.
a starting proposal is to have the endpoint have these query parameters:
{code:java}
/analytics?q=*:*=name:alex*=age,city=count=count=desc=10{code}
This is equivalent to a sql that an analyst would write:
{code:java}
select age, city, count(*) from collection where name like 'alex%'
group by age, city order by age desc limit 10;{code}
On the solr side this would get translated to the best possible streaming
expression using *rollups, top, sort, plist* etc.; but all done transparently
to the user.
> Add Simplified Aggregation Interface to Streaming Expression
>
>
> Key: SOLR-14614
> URL: https://issues.apache.org/jira/browse/SOLR-14614
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query, query parsers, streaming expressions
>Affects Versions: 7.7.2, 8.4.1
>Reporter: Aroop
>Priority: Major
>
> For the Data Analytics use cases the standard use case is:
> # Find a pattern
> # Then Aggregate by certain dimensions
> # Then compute metrics (like count, sum, avg)
> # Sort by a dimension or metric
> # look at top-n
> This functionality has been available over many different interfaces in the
> past on solr, but only streaming expressions have the ability to deliver
> results in a scalable, performant and stable manner for systems that have
> large data to the tune of Big data systems.
> However, one barrier to entry is the query interface, not being simple enough
> in streaming expressions.
> This Jira is to track the work of creating a simplified analytics endpoint
> augmenting streaming expressions.
> a starting proposal is to have the endpoint have these query parameters:
> {code:java}
> /analytics?action=aggregate=*:*=name:alex*=age,city=count=count=desc=10{code}
> This is equivalent to a sql that an analyst would write:
> {code:java}
> select age, city, count(*) from collection where name like 'alex%'
> group by age, city order by age desc limit 10;{code}
>
> On the solr side this would get translated to the best possible streaming
> expression using *rollups, top, sort, plist* etc.; but all done transparently
> to the user.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14614) Add Simplified Aggregation Interface to Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-14614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aroop updated SOLR-14614:
-
Description:
For the Data Analytics use cases the standard use case is:
# Find a pattern
# Then Aggregate by certain dimensions
# Then compute metrics (like count, sum, avg)
# Sort by a dimension or metric
# look at top-n
This functionality has been available over many different interfaces in the
past on solr, but only streaming expressions have the ability to deliver
results in a scalable, performant and stable manner for systems that have large
data to the tune of Big data systems.
However, one barrier to entry is the query interface, not being simple enough
in streaming expressions.
This Jira is to track the work of creating a simplified analytics endpoint
augmenting streaming expressions.
a starting proposal is to have the endpoint have these query parameters:
{code:java}
/analytics?q=*:*=name:alex*=age,city=count=count=desc=10{code}
This is equivalent to a sql that an analyst would write:
{code:java}
select age, city, count(*) from collection where name like 'alex%'
group by age, city order by age desc limit 10;{code}
On the solr side this would get translated to the best possible streaming
expression using _*rollups, top, sort, plist* etc.; b_ut all done transparently
to the user.
was:
For the Data Analytics use cases the standard use case is:
# Find a pattern
# Then Aggregate by certain dimensions
# Then compute metrics (like count, sum, avg)
# Sort by a dimension or metric
# look at top-n
This functionality has been available over many different interfaces in the
past on solr, but only streaming expressions have the ability to deliver
results in a scalable, performant and stable manner for systems that have large
data to the tune of Big data systems.
However, one barrier to entry is the query interface, not being simple enough
in streaming expressions.
This Jira is to track the work of creating a simplified analytics endpoint
augmenting streaming expressions.
a starting proposal is to have the endpoint have these query parameters:
{code:java}
/analytics=*:*=name:alex*=age,city=count=count=desc=10{code}
This is equivalent to a sql that an analyst would write:
{code:java}
select age, city, count(*) from collection where name like 'alex%'
group by age, city order by age desc limit 10;{code}
On the solr side this would get translated to the best possible streaming
expression using _*rollups, top, sort, plist* etc.; b_ut all done transparently
to the user.
> Add Simplified Aggregation Interface to Streaming Expression
>
>
> Key: SOLR-14614
> URL: https://issues.apache.org/jira/browse/SOLR-14614
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query, query parsers, streaming expressions
>Affects Versions: 7.7.2, 8.4.1
>Reporter: Aroop
>Priority: Major
>
> For the Data Analytics use cases the standard use case is:
> # Find a pattern
> # Then Aggregate by certain dimensions
> # Then compute metrics (like count, sum, avg)
> # Sort by a dimension or metric
> # look at top-n
> This functionality has been available over many different interfaces in the
> past on solr, but only streaming expressions have the ability to deliver
> results in a scalable, performant and stable manner for systems that have
> large data to the tune of Big data systems.
> However, one barrier to entry is the query interface, not being simple enough
> in streaming expressions.
> This Jira is to track the work of creating a simplified analytics endpoint
> augmenting streaming expressions.
> a starting proposal is to have the endpoint have these query parameters:
> {code:java}
> /analytics?q=*:*=name:alex*=age,city=count=count=desc=10{code}
> This is equivalent to a sql that an analyst would write:
> {code:java}
> select age, city, count(*) from collection where name like 'alex%'
> group by age, city order by age desc limit 10;{code}
>
> On the solr side this would get translated to the best possible streaming
> expression using _*rollups, top, sort, plist* etc.; b_ut all done
> transparently to the user.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14614) Add Simplified Aggregation Interface to Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-14614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aroop updated SOLR-14614:
-
Description:
For the Data Analytics use cases the standard use case is:
# Find a pattern
# Then Aggregate by certain dimensions
# Then compute metrics (like count, sum, avg)
# Sort by a dimension or metric
# look at top-n
This functionality has been available over many different interfaces in the
past on solr, but only streaming expressions have the ability to deliver
results in a scalable, performant and stable manner for systems that have large
data to the tune of Big data systems.
However, one barrier to entry is the query interface, not being simple enough
in streaming expressions.
This Jira is to track the work of creating a simplified analytics endpoint
augmenting streaming expressions.
a starting proposal is to have the endpoint have these query parameters:
{code:java}
/analytics?q=*:*=name:alex*=age,city=count=count=desc=10{code}
This is equivalent to a sql that an analyst would write:
{code:java}
select age, city, count(*) from collection where name like 'alex%'
group by age, city order by age desc limit 10;{code}
On the solr side this would get translated to the best possible streaming
expression using *rollups, top, sort, plist* etc.; but all done transparently
to the user.
was:
For the Data Analytics use cases the standard use case is:
# Find a pattern
# Then Aggregate by certain dimensions
# Then compute metrics (like count, sum, avg)
# Sort by a dimension or metric
# look at top-n
This functionality has been available over many different interfaces in the
past on solr, but only streaming expressions have the ability to deliver
results in a scalable, performant and stable manner for systems that have large
data to the tune of Big data systems.
However, one barrier to entry is the query interface, not being simple enough
in streaming expressions.
This Jira is to track the work of creating a simplified analytics endpoint
augmenting streaming expressions.
a starting proposal is to have the endpoint have these query parameters:
{code:java}
/analytics?q=*:*=name:alex*=age,city=count=count=desc=10{code}
This is equivalent to a sql that an analyst would write:
{code:java}
select age, city, count(*) from collection where name like 'alex%'
group by age, city order by age desc limit 10;{code}
On the solr side this would get translated to the best possible streaming
expression using _*rollups, top, sort, plist* etc.; b_ut all done transparently
to the user.
> Add Simplified Aggregation Interface to Streaming Expression
>
>
> Key: SOLR-14614
> URL: https://issues.apache.org/jira/browse/SOLR-14614
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query, query parsers, streaming expressions
>Affects Versions: 7.7.2, 8.4.1
>Reporter: Aroop
>Priority: Major
>
> For the Data Analytics use cases the standard use case is:
> # Find a pattern
> # Then Aggregate by certain dimensions
> # Then compute metrics (like count, sum, avg)
> # Sort by a dimension or metric
> # look at top-n
> This functionality has been available over many different interfaces in the
> past on solr, but only streaming expressions have the ability to deliver
> results in a scalable, performant and stable manner for systems that have
> large data to the tune of Big data systems.
> However, one barrier to entry is the query interface, not being simple enough
> in streaming expressions.
> This Jira is to track the work of creating a simplified analytics endpoint
> augmenting streaming expressions.
> a starting proposal is to have the endpoint have these query parameters:
> {code:java}
> /analytics?q=*:*=name:alex*=age,city=count=count=desc=10{code}
> This is equivalent to a sql that an analyst would write:
> {code:java}
> select age, city, count(*) from collection where name like 'alex%'
> group by age, city order by age desc limit 10;{code}
>
> On the solr side this would get translated to the best possible streaming
> expression using *rollups, top, sort, plist* etc.; but all done transparently
> to the user.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14614) Add Simplified Aggregation Interface to Streaming Expression
Aroop created SOLR-14614:
Summary: Add Simplified Aggregation Interface to Streaming
Expression
Key: SOLR-14614
URL: https://issues.apache.org/jira/browse/SOLR-14614
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: query, query parsers, streaming expressions
Affects Versions: 8.4.1, 7.7.2
Reporter: Aroop
For the Data Analytics use cases the standard use case is:
# Find a pattern
# Then Aggregate by certain dimensions
# Then compute metrics (like count, sum, avg)
# Sort by a dimension or metric
# look at top-n
This functionality has been available over many different interfaces in the
past on solr, but only streaming expressions have the ability to deliver
results in a scalable, performant and stable manner for systems that have large
data to the tune of Big data systems.
However, one barrier to entry is the query interface, not being simple enough
in streaming expressions.
This Jira is to track the work of creating a simplified analytics endpoint
augmenting streaming expressions.
a starting proposal is to have the endpoint have these query parameters:
{code:java}
/analytics=*:*=name:alex*=age,city=count=count=desc=10{code}
This is equivalent to a sql that an analyst would write:
{code:java}
select age, city, count(*) from collection where name like 'alex%'
group by age, city order by age desc limit 10;{code}
On the solr side this would get translated to the best possible streaming
expression using _*rollups, top, sort, plist* etc.; b_ut all done transparently
to the user.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] sigram opened a new pull request #1637: SOLR-12847 Cut over implementation of maxShardsPerNode to a collection policy
sigram opened a new pull request #1637: URL: https://github.com/apache/lucene-solr/pull/1637 Note: this is for master (9.0) only. 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on a change in pull request #1626: SOLR-14588: Implement Circuit Breakers
atris commented on a change in pull request #1626:
URL: https://github.com/apache/lucene-solr/pull/1626#discussion_r448496902
##
File path:
solr/core/src/java/org/apache/solr/util/circuitbreaker/MemoryCircuitBreaker.java
##
@@ -0,0 +1,111 @@
+/*
+ * 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.solr.util.circuitbreaker;
+
+import java.lang.invoke.MethodHandles;
+import java.lang.management.ManagementFactory;
+import java.lang.management.MemoryMXBean;
+
+import org.apache.solr.core.SolrConfig;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+/**
+ *
+ * Tracks the current JVM heap usage and triggers if it exceeds the defined
percentage of the maximum
+ * heap size allocated to the JVM. This circuit breaker is a part of the
default CircuitBreakerManager
+ * so is checked for every request -- hence it is realtime. Once the memory
usage goes below the threshold,
+ * it will start allowing queries again.
+ *
+ *
+ *
+ * The memory threshold is defined as a percentage of the maximum memory
allocated -- see memoryCircuitBreakerThresholdPct
+ * in solrconfig.xml.
+ *
+ */
+
+public class MemoryCircuitBreaker extends CircuitBreaker {
+ private static final Logger log =
LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());
+ private static final MemoryMXBean MEMORY_MX_BEAN =
ManagementFactory.getMemoryMXBean();
+
+ private final long heapMemoryThreshold;
+
+ // Assumption -- the value of these parameters will be set correctly before
invoking getDebugInfo()
+ private final ThreadLocal seenMemory = new ThreadLocal<>();
+ private final ThreadLocal allowedMemory = new ThreadLocal<>();
+
+ public MemoryCircuitBreaker(SolrConfig solrConfig) {
+super(solrConfig);
+
+long currentMaxHeap = MEMORY_MX_BEAN.getHeapMemoryUsage().getMax();
+
+if (currentMaxHeap <= 0) {
+ throw new IllegalArgumentException("Invalid JVM state for the max heap
usage");
+}
+
+int thresholdValueInPercentage =
solrConfig.memoryCircuitBreakerThresholdPct;
+double thresholdInFraction = thresholdValueInPercentage / (double) 100;
+heapMemoryThreshold = (long) (currentMaxHeap * thresholdInFraction);
+
+if (heapMemoryThreshold <= 0) {
+ throw new IllegalStateException("Memory limit cannot be less than or
equal to zero");
+}
+ }
+
+ // TODO: An optimization can be to trip the circuit breaker for a duration
of time
+ // after the circuit breaker condition is matched. This will optimize for
per call
+ // overhead of calculating the condition parameters but can result in false
positives.
+ @Override
+ public boolean isTripped() {
+if (!isEnabled()) {
+ return false;
+}
+
+allowedMemory.set(getCurrentMemoryThreshold());
+
+seenMemory.set(calculateLiveMemoryUsage());
+
+return (seenMemory.get() >= allowedMemory.get());
Review comment:
It would be a two step process -- setting local value and then setting
the thread local. Seems cleaner this way? I doubt if it will really cause a
performance issue -- the variables are thread local
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on a change in pull request #1626: SOLR-14588: Implement Circuit Breakers
atris commented on a change in pull request #1626:
URL: https://github.com/apache/lucene-solr/pull/1626#discussion_r448495565
##
File path:
solr/core/src/java/org/apache/solr/util/circuitbreaker/CircuitBreakerManager.java
##
@@ -0,0 +1,130 @@
+/*
+ * 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.solr.util.circuitbreaker;
+
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.solr.core.SolrConfig;
+
+/**
+ * Manages all registered circuit breaker instances. Responsible for a
holistic view
+ * of whether a circuit breaker has tripped or not.
+ *
+ * There are two typical ways of using this class's instance:
+ * 1. Check if any circuit breaker has triggered -- and know which circuit
breaker has triggered.
+ * 2. Get an instance of a specific circuit breaker and perform checks.
+ *
+ * It is a good practice to register new circuit breakers here if you want
them checked for every
+ * request.
+ *
+ * NOTE: The current way of registering new default circuit breakers is
minimal and not a long term
+ * solution. There will be a follow up with a SIP for a schema API design.
+ */
+public class CircuitBreakerManager {
+ private final Map
circuitBreakerMap = new HashMap<>();
+
+ // Allows replacing of existing circuit breaker
+ public void register(CircuitBreaker.CircuitBreakerType circuitBreakerType,
CircuitBreaker circuitBreaker) {
+circuitBreakerMap.put(circuitBreakerType, circuitBreaker);
+ }
+
+ public CircuitBreaker getCircuitBreaker(CircuitBreaker.CircuitBreakerType
circuitBreakerType) {
Review comment:
Added for sanity.
##
File path:
solr/core/src/java/org/apache/solr/util/circuitbreaker/CircuitBreakerManager.java
##
@@ -0,0 +1,130 @@
+/*
+ * 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.solr.util.circuitbreaker;
+
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.solr.core.SolrConfig;
+
+/**
+ * Manages all registered circuit breaker instances. Responsible for a
holistic view
+ * of whether a circuit breaker has tripped or not.
+ *
+ * There are two typical ways of using this class's instance:
+ * 1. Check if any circuit breaker has triggered -- and know which circuit
breaker has triggered.
+ * 2. Get an instance of a specific circuit breaker and perform checks.
+ *
+ * It is a good practice to register new circuit breakers here if you want
them checked for every
+ * request.
+ *
+ * NOTE: The current way of registering new default circuit breakers is
minimal and not a long term
+ * solution. There will be a follow up with a SIP for a schema API design.
+ */
+public class CircuitBreakerManager {
+ private final Map
circuitBreakerMap = new HashMap<>();
+
+ // Allows replacing of existing circuit breaker
+ public void register(CircuitBreaker.CircuitBreakerType circuitBreakerType,
CircuitBreaker circuitBreaker) {
+circuitBreakerMap.put(circuitBreakerType, circuitBreaker);
+ }
+
+ public CircuitBreaker getCircuitBreaker(CircuitBreaker.CircuitBreakerType
circuitBreakerType) {
+assert circuitBreakerType != null;
+
+return circuitBreakerMap.get(circuitBreakerType);
+ }
+
+ /**
+ * Check and return circuit breakers that have triggered
+ * @return CircuitBreakers which have triggered, null otherwise.
+ */
+ public Map checkTripped()
{
+Map
triggeredCircuitBreakers = null;
+
+for (Map.Entry entry :
circuitBreakerMap.entrySet()) {
+
[GitHub] [lucene-solr] atris commented on a change in pull request #1626: SOLR-14588: Implement Circuit Breakers
atris commented on a change in pull request #1626:
URL: https://github.com/apache/lucene-solr/pull/1626#discussion_r448495347
##
File path:
solr/core/src/java/org/apache/solr/util/circuitbreaker/CircuitBreakerManager.java
##
@@ -0,0 +1,130 @@
+/*
+ * 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.solr.util.circuitbreaker;
+
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.solr.core.SolrConfig;
+
+/**
+ * Manages all registered circuit breaker instances. Responsible for a
holistic view
+ * of whether a circuit breaker has tripped or not.
+ *
+ * There are two typical ways of using this class's instance:
+ * 1. Check if any circuit breaker has triggered -- and know which circuit
breaker has triggered.
+ * 2. Get an instance of a specific circuit breaker and perform checks.
+ *
+ * It is a good practice to register new circuit breakers here if you want
them checked for every
+ * request.
+ *
+ * NOTE: The current way of registering new default circuit breakers is
minimal and not a long term
+ * solution. There will be a follow up with a SIP for a schema API design.
+ */
+public class CircuitBreakerManager {
+ private final Map
circuitBreakerMap = new HashMap<>();
+
+ // Allows replacing of existing circuit breaker
+ public void register(CircuitBreaker.CircuitBreakerType circuitBreakerType,
CircuitBreaker circuitBreaker) {
+circuitBreakerMap.put(circuitBreakerType, circuitBreaker);
+ }
+
+ public CircuitBreaker getCircuitBreaker(CircuitBreaker.CircuitBreakerType
circuitBreakerType) {
+assert circuitBreakerType != null;
+
+return circuitBreakerMap.get(circuitBreakerType);
+ }
+
+ /**
+ * Check and return circuit breakers that have triggered
+ * @return CircuitBreakers which have triggered, null otherwise.
+ */
+ public Map checkTripped()
{
+Map
triggeredCircuitBreakers = null;
+
+for (Map.Entry entry :
circuitBreakerMap.entrySet()) {
+ CircuitBreaker circuitBreaker = entry.getValue();
+
+ if (circuitBreaker.isEnabled() &&
+ circuitBreaker.isTripped()) {
+if (triggeredCircuitBreakers == null) {
+ triggeredCircuitBreakers = new HashMap<>();
+}
+
+triggeredCircuitBreakers.put(entry.getKey(), circuitBreaker);
+ }
+}
+
+return triggeredCircuitBreakers;
+ }
+
+ /**
+ * Returns true if *any* circuit breaker has triggered, false if none have
triggered.
+ *
+ *
+ * NOTE: This method short circuits the checking of circuit breakers -- the
method will
+ * return as soon as it finds a circuit breaker that is enabled and has
triggered.
+ *
+ */
+ public boolean checkAnyTripped() {
+for (Map.Entry entry :
circuitBreakerMap.entrySet()) {
Review comment:
Need both the key and the value in this loop, so values() wont work?
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on a change in pull request #1626: SOLR-14588: Implement Circuit Breakers
atris commented on a change in pull request #1626:
URL: https://github.com/apache/lucene-solr/pull/1626#discussion_r448494462
##
File path:
solr/core/src/java/org/apache/solr/util/circuitbreaker/CircuitBreaker.java
##
@@ -0,0 +1,64 @@
+/*
+ * 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.solr.util.circuitbreaker;
+
+import org.apache.solr.core.SolrConfig;
+
+/**
+ * Default class to define circuit breakers for Solr.
+ *
+ * There are two (typical) ways to use circuit breakers:
+ * 1. Have them checked at admission control by default (use
CircuitBreakerManager for the same).
+ * 2. Use the circuit breaker in a specific code path(s).
+ *
+ * TODO: This class should be grown as the scope of circuit breakers grow.
+ *
+ */
+public abstract class CircuitBreaker {
+ public static final String NAME = "circuitbreaker";
+
+ protected final SolrConfig solrConfig;
+
+ public CircuitBreaker(SolrConfig solrConfig) {
+this.solrConfig = solrConfig;
+ }
+
+ // Global config for all circuit breakers. For specific circuit breaker
configs, define
+ // your own config.
+ protected boolean isEnabled() {
+return solrConfig.useCircuitBreakers;
+ }
+
+ /**
+ * Check if circuit breaker is tripped.
+ */
+ public abstract boolean isTripped();
+
+ /**
+ * Get debug useful info.
+ */
+ public abstract String getDebugInfo();
+
+ /**
+ * Types of circuit breakers.
+ */
+ public enum CircuitBreakerType {
Review comment:
Preferably, they can add their own type when implementing a new one?
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on a change in pull request #1626: SOLR-14588: Implement Circuit Breakers
atris commented on a change in pull request #1626:
URL: https://github.com/apache/lucene-solr/pull/1626#discussion_r448493962
##
File path: solr/core/src/java/org/apache/solr/core/SolrConfig.java
##
@@ -224,6 +224,11 @@ private SolrConfig(SolrResourceLoader loader, String name,
boolean isConfigsetTr
queryResultWindowSize = Math.max(1, getInt("query/queryResultWindowSize",
1));
queryResultMaxDocsCached = getInt("query/queryResultMaxDocsCached",
Integer.MAX_VALUE);
enableLazyFieldLoading = getBool("query/enableLazyFieldLoading", false);
+
+useCircuitBreakers = getBool("circuitBreaker/useCircuitBreakers", false);
+memoryCircuitBreakerThresholdPct =
getInt("circuitBreaker/memoryCircuitBreakerThresholdPct", 100);
Review comment:
Changed to 95.
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on a change in pull request #1626: SOLR-14588: Implement Circuit Breakers
madrob commented on a change in pull request #1626:
URL: https://github.com/apache/lucene-solr/pull/1626#discussion_r448460273
##
File path:
solr/core/src/java/org/apache/solr/util/circuitbreaker/CircuitBreakerManager.java
##
@@ -0,0 +1,130 @@
+/*
+ * 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.solr.util.circuitbreaker;
+
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.solr.core.SolrConfig;
+
+/**
+ * Manages all registered circuit breaker instances. Responsible for a
holistic view
+ * of whether a circuit breaker has tripped or not.
+ *
+ * There are two typical ways of using this class's instance:
+ * 1. Check if any circuit breaker has triggered -- and know which circuit
breaker has triggered.
+ * 2. Get an instance of a specific circuit breaker and perform checks.
+ *
+ * It is a good practice to register new circuit breakers here if you want
them checked for every
+ * request.
+ *
+ * NOTE: The current way of registering new default circuit breakers is
minimal and not a long term
+ * solution. There will be a follow up with a SIP for a schema API design.
+ */
+public class CircuitBreakerManager {
+ private final Map
circuitBreakerMap = new HashMap<>();
+
+ // Allows replacing of existing circuit breaker
+ public void register(CircuitBreaker.CircuitBreakerType circuitBreakerType,
CircuitBreaker circuitBreaker) {
+circuitBreakerMap.put(circuitBreakerType, circuitBreaker);
+ }
+
+ public CircuitBreaker getCircuitBreaker(CircuitBreaker.CircuitBreakerType
circuitBreakerType) {
+assert circuitBreakerType != null;
+
+return circuitBreakerMap.get(circuitBreakerType);
+ }
+
+ /**
+ * Check and return circuit breakers that have triggered
+ * @return CircuitBreakers which have triggered, null otherwise.
+ */
+ public Map checkTripped()
{
+Map
triggeredCircuitBreakers = null;
+
+for (Map.Entry entry :
circuitBreakerMap.entrySet()) {
+ CircuitBreaker circuitBreaker = entry.getValue();
+
+ if (circuitBreaker.isEnabled() &&
+ circuitBreaker.isTripped()) {
+if (triggeredCircuitBreakers == null) {
+ triggeredCircuitBreakers = new HashMap<>();
+}
+
+triggeredCircuitBreakers.put(entry.getKey(), circuitBreaker);
+ }
+}
+
+return triggeredCircuitBreakers;
+ }
+
+ /**
+ * Returns true if *any* circuit breaker has triggered, false if none have
triggered.
+ *
+ *
+ * NOTE: This method short circuits the checking of circuit breakers -- the
method will
+ * return as soon as it finds a circuit breaker that is enabled and has
triggered.
+ *
+ */
+ public boolean checkAnyTripped() {
+for (Map.Entry entry :
circuitBreakerMap.entrySet()) {
+ CircuitBreaker circuitBreaker = entry.getValue();
+
+ if (circuitBreaker.isEnabled() &&
+ circuitBreaker.isTripped()) {
+return true;
+ }
+}
+
+return false;
+ }
+
+ /**
+ * Construct the final error message to be printed when circuit breakers
trip.
+ *
+ * @param circuitBreakerMap Input list for circuit breakers.
+ * @return Constructed error message.
+ */
+ public static String toErrorMessage(Map circuitBreakerMap) {
+assert circuitBreakerMap != null;
+
+StringBuilder sb = new StringBuilder();
+
+for (CircuitBreaker.CircuitBreakerType circuitBreakerType :
circuitBreakerMap.keySet()) {
+ sb.append(circuitBreakerType.toString() + " " +
circuitBreakerMap.get(circuitBreakerType).getDebugInfo() + "\n");
Review comment:
do multiple append calls instead of string concat.
##
File path:
solr/core/src/java/org/apache/solr/util/circuitbreaker/CircuitBreaker.java
##
@@ -0,0 +1,64 @@
+/*
+ * 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
[GitHub] [lucene-solr] ErickErickson closed pull request #1634: SOLR-14592: Upgrade Zookeeper to 3.6.1
ErickErickson closed pull request #1634: URL: https://github.com/apache/lucene-solr/pull/1634 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] bruno-roustant commented on a change in pull request #1608: LUCENE-9379: Encrypting Directory - functional but to optimize
bruno-roustant commented on a change in pull request #1608:
URL: https://github.com/apache/lucene-solr/pull/1608#discussion_r448472837
##
File path: lucene/core/src/java/org/apache/lucene/store/EncryptingDirectory.java
##
@@ -0,0 +1,60 @@
+/*
+ * 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.store;
+
+import java.io.IOException;
+
+public abstract class EncryptingDirectory extends FilterDirectory {
+
+ protected EncryptingDirectory(Directory directory) {
+super(directory);
+ }
+
+ @Override
+ public IndexOutput createOutput(String name, IOContext context)
+ throws IOException {
+IndexOutput indexOutput = in.createOutput(name, context);
+byte[] key = getKey(name);
+return key == null ? indexOutput :
createEncryptingIndexOutput(indexOutput, key);
+ }
+
+ @Override
+ public IndexOutput createTempOutput(String prefix, String suffix, IOContext
context) throws IOException {
+IndexOutput indexOutput = in.createTempOutput(prefix, suffix, context);
+byte[] key = getKey(indexOutput.getName());
+return key == null ? indexOutput :
createEncryptingIndexOutput(indexOutput, key);
+ }
+
+ @Override
+ public IndexInput openInput(String name, IOContext context)
+ throws IOException {
+IndexInput indexInput = in.openInput(name, context);
+byte[] key = getKey(name);
+return key == null ? indexInput : createEncryptingIndexInput(indexInput,
key);
+ }
+
+ /**
+ * Gets the encryption key for the provided file name.
+ * @return The key; or null if none, in this case the data is not encrypted.
+ */
+ protected abstract byte[] getKey(String fileName);
Review comment:
javax.crypto.Cipher clones the key. But another Encrypter implementation
could read the key bytes to create another AES key, without needing to clone.
I'll let it as a byte[] and I'll be clear in the javadoc it is not modified
and not referenced.
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] bruno-roustant commented on a change in pull request #1608: LUCENE-9379: Encrypting Directory - functional but to optimize
bruno-roustant commented on a change in pull request #1608:
URL: https://github.com/apache/lucene-solr/pull/1608#discussion_r448470152
##
File path:
lucene/core/src/java/org/apache/lucene/store/EncryptingIndexInput.java
##
@@ -0,0 +1,299 @@
+/*
+ * 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.store;
+
+import javax.crypto.Cipher;
+import javax.crypto.ShortBufferException;
+import javax.crypto.spec.IvParameterSpec;
+import java.io.EOFException;
+import java.io.IOException;
+import java.io.UncheckedIOException;
+import java.nio.ByteBuffer;
+import java.security.InvalidAlgorithmParameterException;
+import java.security.InvalidKeyException;
+import java.security.Key;
+
+import org.apache.lucene.codecs.CodecUtil;
+
+import static org.apache.lucene.store.EncryptingIndexOutput.HEADER_LENGTH;
+import static org.apache.lucene.store.EncryptingUtil.*;
+
+public class EncryptingIndexInput extends IndexInput {
+
+ /**
+ * Must be a multiple of {@link EncryptingUtil#AES_BLOCK_SIZE}.
+ */
+ private static final int BUFFER_SIZE = 64 * AES_BLOCK_SIZE; // 1024 B
+
+ private static final long AES_BLOCK_SIZE_MOD_MASK = AES_BLOCK_SIZE - 1;
+ static final int HEADER_IV_LENGTH = HEADER_LENGTH + IV_LENGTH;
+
+ private static final byte[] EMPTY_BYTES = new byte[0];
+
+ // Some fields are not final for the clone() method.
+ private boolean isClone;
+ private final long sliceOffset;
+ private final long sliceEnd;
+ private IndexInput indexInput;
+ private final Key key;
+ private Cipher cipher;
+ private final byte[] initialIv;
+ private byte[] iv;
+ private ReusableIvParameterSpec ivParameterSpec;
+ private ByteBuffer inBuffer;
+ private ByteBuffer outBuffer;
+ private byte[] inArray;
+ private byte[] oneByteBuf;
+ private int padding;
+ private boolean closed;
+
+ public EncryptingIndexInput(IndexInput indexInput, byte[] key) throws
IOException {
+this("Decrypting " + indexInput.toString(),
+HEADER_IV_LENGTH, indexInput.length() - HEADER_IV_LENGTH -
CodecUtil.footerLength(), false,
+indexInput, createAesKey(key), readInitialIv(indexInput));
+ }
+
+ private EncryptingIndexInput(String resourceDescription, long sliceOffset,
long sliceLength, boolean isClone,
+ IndexInput indexInput, Key key, byte[]
initialIv) throws IOException {
+super(resourceDescription);
+assert sliceOffset >= 0 && sliceLength >= 0;
+this.sliceOffset = sliceOffset;
+this.sliceEnd = sliceOffset + sliceLength;
+this.isClone = isClone;
+this.indexInput = indexInput;
+this.key = key;
+this.initialIv = initialIv;
+
+cipher = createAesCtrCipher();
+assert cipher.getBlockSize() == AES_BLOCK_SIZE : "Invalid AES block size:
" + cipher.getBlockSize();
+iv = initialIv.clone();
+ivParameterSpec = new ReusableIvParameterSpec(iv);
+try {
+ cipher.init(Cipher.DECRYPT_MODE, this.key, ivParameterSpec);
+} catch (InvalidKeyException | InvalidAlgorithmParameterException e) {
+ throw new IOException(e);
+}
+
+inBuffer = ByteBuffer.allocate(getBufferSize());
+outBuffer = ByteBuffer.allocate(getBufferSize() + AES_BLOCK_SIZE);
+outBuffer.limit(0);
+assert inBuffer.hasArray() && outBuffer.hasArray();
+assert inBuffer.arrayOffset() == 0;
+inArray = inBuffer.array();
+oneByteBuf = new byte[1];
+ }
+
+ /**
+ * Reads the initial IV at the beginning of the index input.
+ */
+ private static byte[] readInitialIv(IndexInput indexInput) throws
IOException {
+indexInput.seek(HEADER_LENGTH);
+byte[] initialIv = new byte[IV_LENGTH];
+indexInput.readBytes(initialIv, 0, initialIv.length, false);
+return initialIv;
+ }
+
+ /**
+ * Gets the buffer size. It must be a multiple of {@link
EncryptingUtil#AES_BLOCK_SIZE}.
+ */
+ protected int getBufferSize() {
+return BUFFER_SIZE;
+ }
+
+ @Override
+ public void close() throws IOException {
+if (!closed) {
+ closed = true;
+ if (!isClone) {
+indexInput.close();
+ }
+}
+ }
+
+ @Override
+ public long getFilePointer() {
+return getPosition() - sliceOffset;
+ }
+
+ /**
+ * Gets the current internal
[jira] [Updated] (SOLR-14523) Enhance gradle logging calls validation: eliminate getMessage()
[
https://issues.apache.org/jira/browse/SOLR-14523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andras Salamon updated SOLR-14523:
--
Attachment: SOLR-14523.patch
Status: Open (was: Open)
I added {{logOk}} to suppress the warnings in {{HttpSolrCall}} because we call
{{authResponse.getMessage()}} there. We could also put the message into a
variable and use that in the log call if we want to avoid {{logOk}}.
In {{TestRerankBase}} the warning was in an unused method, so I just deleted
the method.
> Enhance gradle logging calls validation: eliminate getMessage()
> ---
>
> Key: SOLR-14523
> URL: https://issues.apache.org/jira/browse/SOLR-14523
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andras Salamon
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-14523.patch, validation.patch
>
>
> SOLR-14280 fixed a logging problem in SolrConfig by removing a few
> getMessage() calls. We could enhance this solution by modifying gradle's
> logging calls validation and forbid getMessage() calls during logging. We
> should check the existing code and eliminate such calls.
> It is possible to suppress the warning using {{//logok}}.
> [~erickerickson] [~gerlowskija]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14523) Enhance gradle logging calls validation: eliminate getMessage()
[
https://issues.apache.org/jira/browse/SOLR-14523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andras Salamon updated SOLR-14523:
--
Status: Patch Available (was: Open)
> Enhance gradle logging calls validation: eliminate getMessage()
> ---
>
> Key: SOLR-14523
> URL: https://issues.apache.org/jira/browse/SOLR-14523
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andras Salamon
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-14523.patch, validation.patch
>
>
> SOLR-14280 fixed a logging problem in SolrConfig by removing a few
> getMessage() calls. We could enhance this solution by modifying gradle's
> logging calls validation and forbid getMessage() calls during logging. We
> should check the existing code and eliminate such calls.
> It is possible to suppress the warning using {{//logok}}.
> [~erickerickson] [~gerlowskija]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6205) Make SolrCloud Data-center, rack or zone aware
[ https://issues.apache.org/jira/browse/SOLR-6205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-6205. -- Resolution: Invalid This can be implemented using autoscaling > Make SolrCloud Data-center, rack or zone aware > -- > > Key: SOLR-6205 > URL: https://issues.apache.org/jira/browse/SOLR-6205 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Affects Versions: 4.8.1 >Reporter: Arcadius Ahouansou >Assignee: Noble Paul >Priority: Major > > Use case: > Let's say we have SolrCloud deployed across 2 Datacenters, racks or zones A > and B > There is a need to have a SolrCloud deployment that will make it possible to > have a working system even if one of the Datacenter/rack/zone A or B is lost. > - This has been discussed on the mailing list at > http://lucene.472066.n3.nabble.com/SolrCloud-multiple-data-center-support-td4115097.html > and there are many workarounds that require adding more moving parts to the > system. > - On the above thread, Daniel Collins mentioned > https://issues.apache.org/jira/browse/ZOOKEEPER-107 > which could help solve this issue. > - Note that this is a very important feature that is overlooked most of the > time. > - Note that this feature is available in ElasticSearch. > See > http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-cluster.html#allocation-awareness > and > http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-cluster.html#forced-awareness -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149395#comment-17149395
]
ASF subversion and git services commented on SOLR-14539:
Commit 51ce30d16f3c261143ff5c286e625c0858564383 in lucene-solr's branch
refs/heads/branch_8_6 from Mikhail Khludnev
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=51ce30d ]
SOLR-14539 Ref Guide update {!bool excludeTags}
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Fix For: 8.6
>
> Attachments: SOLR-14539.patch, SOLR-14539.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-6205) Make SolrCloud Data-center, rack or zone aware
[ https://issues.apache.org/jira/browse/SOLR-6205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149391#comment-17149391 ] Erick Erickson commented on SOLR-6205: -- ping [~noble.paul] Can we close this? > Make SolrCloud Data-center, rack or zone aware > -- > > Key: SOLR-6205 > URL: https://issues.apache.org/jira/browse/SOLR-6205 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Affects Versions: 4.8.1 >Reporter: Arcadius Ahouansou >Assignee: Noble Paul >Priority: Major > > Use case: > Let's say we have SolrCloud deployed across 2 Datacenters, racks or zones A > and B > There is a need to have a SolrCloud deployment that will make it possible to > have a working system even if one of the Datacenter/rack/zone A or B is lost. > - This has been discussed on the mailing list at > http://lucene.472066.n3.nabble.com/SolrCloud-multiple-data-center-support-td4115097.html > and there are many workarounds that require adding more moving parts to the > system. > - On the above thread, Daniel Collins mentioned > https://issues.apache.org/jira/browse/ZOOKEEPER-107 > which could help solve this issue. > - Note that this is a very important feature that is overlooked most of the > time. > - Note that this feature is available in ElasticSearch. > See > http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-cluster.html#allocation-awareness > and > http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-cluster.html#forced-awareness -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-8146) Allowing SolrJ CloudSolrClient to have preferred replica for query/read
[
https://issues.apache.org/jira/browse/SOLR-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149389#comment-17149389
]
Erick Erickson commented on SOLR-8146:
--
[~tflobbe] Can this JIRA be closed?
> Allowing SolrJ CloudSolrClient to have preferred replica for query/read
> ---
>
> Key: SOLR-8146
> URL: https://issues.apache.org/jira/browse/SOLR-8146
> Project: Solr
> Issue Type: New Feature
> Components: clients - java
>Affects Versions: 5.3
>Reporter: Arcadius Ahouansou
>Priority: Major
> Attachments: SOLR-8146.patch, SOLR-8146.patch, SOLR-8146.patch,
> SOLR-8146.patch
>
>
> h2. Backgrouds
> Currently, the CloudSolrClient randomly picks a replica to query.
> This is done by shuffling the list of live URLs to query then, picking the
> first item from the list.
> This ticket is to allow more flexibility and control to some extend which
> URLs will be picked up for queries.
> Note that this is for queries only and would not affect update/delete/admin
> operations.
> h2. Implementation
> The current patch uses regex pattern and moves to the top of the list of URLs
> only those matching the given regex specified by the system property
> {code}solr.preferredQueryNodePattern{code}
> Initially, I thought it may be good to have Solr nodes tagged with a string
> pattern (snitch?) and use that pattern for matching the URLs.
> Any comment, recommendation or feedback would be appreciated.
> h2. Use Cases
> There are many cases where the ability to choose the node where queries go
> can be very handy:
> h3. Special node for manual user queries and analytics
> One may have a SolrCLoud cluster where every node host the same set of
> collections with:
> - multiple large SolrCLoud nodes (L) used for production apps and
> - have 1 small node (S) in the same cluster with less ram/cpu used only for
> manual user queries, data export and other production issue investigation.
> This ticket would allow to configure the applications using SolrJ to query
> only the (L) nodes
> This use case is similar to the one described in SOLR-5501 raised by [~manuel
> lenormand]
> h3. Minimizing network traffic
>
> For simplicity, let's say that we have a SolrSloud cluster deployed on 2 (or
> N) separate racks: rack1 and rack2.
> On each rack, we have a set of SolrCloud VMs as well as a couple of client
> VMs querying solr using SolrJ.
> All solr nodes are identical and have the same number of collections.
> What we would like to achieve is:
> - clients on rack1 will by preference query only SolrCloud nodes on rack1,
> and
> - clients on rack2 will by preference query only SolrCloud nodes on rack2.
> - Cross-rack read will happen if and only if one of the racks has no
> available Solr node to serve a request.
> In other words, we want read operations to be local to a rack whenever
> possible.
> Note that write/update/delete/admin operations should not be affected.
> Note that in our use case, we have a cross DC deployment. So, replace
> rack1/rack2 by DC1/DC2
> Any comment would be very appreciated.
> Thanks.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149390#comment-17149390
]
ASF subversion and git services commented on SOLR-14539:
Commit 1ea62021f414039972f9e576792b835ebf67d83f in lucene-solr's branch
refs/heads/branch_8x from Mikhail Khludnev
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1ea6202 ]
SOLR-14539 Ref Guide update {!bool excludeTags}
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Fix For: 8.6
>
> Attachments: SOLR-14539.patch, SOLR-14539.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149385#comment-17149385
]
ASF subversion and git services commented on SOLR-14539:
Commit 1f6de31db858682348fa8e21a7d31b79a2e30be6 in lucene-solr's branch
refs/heads/master from Mikhail Khludnev
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1f6de31 ]
SOLR-14539 Ref Guide update {!bool excludeTags}
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Fix For: 8.6
>
> Attachments: SOLR-14539.patch, SOLR-14539.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on pull request #1636: Remove Compound file formation
atris commented on pull request #1636: URL: https://github.com/apache/lucene-solr/pull/1636#issuecomment-652347025 I am pretty sure I am missing the point of this PR? 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] DEVILCODER-SB99 opened a new pull request #1636: Remove Compound file formation
DEVILCODER-SB99 opened a new pull request #1636: URL: https://github.com/apache/lucene-solr/pull/1636 # Description Please provide a short description of the changes you're making with this pull request. # Solution Please provide a short description of the approach taken to implement your solution. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [ ] I have developed this patch against the `master` branch. - [ ] I have run `ant precommit` and the appropriate test suite. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on pull request #1626: SOLR-14588: Implement Circuit Breakers
atris commented on pull request #1626: URL: https://github.com/apache/lucene-solr/pull/1626#issuecomment-652328056 Thank you @sigram ! @ErickErickson provided his approval offline (thanks Erick!) so I am going to merge this tomorrow morning 9 am my time (UTC +5.30). If any objections, please speak up. 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14613) Provide a clean API for pluggable autoscaling implementations
Andrzej Bialecki created SOLR-14613:
---
Summary: Provide a clean API for pluggable autoscaling
implementations
Key: SOLR-14613
URL: https://issues.apache.org/jira/browse/SOLR-14613
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: AutoScaling
Reporter: Andrzej Bialecki
As described in SIP-8 the current autoscaling Policy implementation has several
limitations that make it difficult to use for very large clusters and very
large collections. SIP-8 also mentions the possible migration path by providing
alternative implementations of the placement strategies that are less complex
but more efficient in these very large environments.
We should review the existing APIs that the current autoscaling engine uses
({{SolrCloudManager}} , {{AssignStrategy}} , {{Suggester}} and related
interfaces) to see if they provide a sufficient and minimal API for plugging in
alternative autoscaling placement strategies, and if necessary refactor the
existing APIs.
Since these APIs are internal it should be possible to do this without breaking
back-compat.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14612) Cannot register custom plugins in instances with hostname starting with "solr"
[ https://issues.apache.org/jira/browse/SOLR-14612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Ortega updated SOLR-14612: - Description: This bug prevents to register custom plugins in instances which name starts with "solr" using the V2 API as is described in [https://lucene.apache.org/solr/guide/8_5/adding-custom-plugins-in-solrcloud-mode.html|https://lucene.apache.org/solr/guide/8_4/adding-custom-plugins-in-solrcloud-mode.html] As "/solr" is replaced by "/api" in [https://github.com/apache/lucene-solr/blob/6eb7bc3b7bd6dea2a104448e921f7234973f0197/solr/core/src/java/org/apache/solr/pkg/PackageAPI.java#L418], the solr instance hostnames can't start with "/solr" because will be replaced with "/api" when the api endpoint is used. *i.e:* "http://solrexample.domain/solr; will be converted to "http://apiexample.domain/api; and should be "http://solrexample.domain/api". was: This bug prevents to register custom plugins in instances which name starts with "solr" using the V2 API as is described in [https://lucene.apache.org/solr/guide/8_4/adding-custom-plugins-in-solrcloud-mode.html] As "/solr" is replaced by "/api" in [https://github.com/apache/lucene-solr/blob/6eb7bc3b7bd6dea2a104448e921f7234973f0197/solr/core/src/java/org/apache/solr/pkg/PackageAPI.java#L418], the solr instance hostnames can't start with "/solr" because will be replaced with "/api" when the api endpoint is used. *i.e:* "http://solrexample.domain/solr; will be converted to "http://apiexample.domain/api; and should be "http://solrexample.domain/api". > Cannot register custom plugins in instances with hostname starting with "solr" > -- > > Key: SOLR-14612 > URL: https://issues.apache.org/jira/browse/SOLR-14612 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Environment: Apache Solr 8.5.2 > Debian 9/10 >Reporter: Daniel Ortega >Priority: Major > > This bug prevents to register custom plugins in instances which name starts > with "solr" using the V2 API as is described in > [https://lucene.apache.org/solr/guide/8_5/adding-custom-plugins-in-solrcloud-mode.html|https://lucene.apache.org/solr/guide/8_4/adding-custom-plugins-in-solrcloud-mode.html] > As "/solr" is replaced by "/api" in > [https://github.com/apache/lucene-solr/blob/6eb7bc3b7bd6dea2a104448e921f7234973f0197/solr/core/src/java/org/apache/solr/pkg/PackageAPI.java#L418], > the solr instance hostnames can't start with "/solr" because will be > replaced with "/api" when the api endpoint is used. > *i.e:* "http://solrexample.domain/solr; will be converted to > "http://apiexample.domain/api; and should be "http://solrexample.domain/api". -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14612) Cannot register custom plugins in instances with hostname starting with "solr"
Daniel created SOLR-14612: - Summary: Cannot register custom plugins in instances with hostname starting with "solr" Key: SOLR-14612 URL: https://issues.apache.org/jira/browse/SOLR-14612 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Environment: Apache Solr 8.5.2 Debian 9/10 Reporter: Daniel This bug prevents to register custom plugins in instances which name starts with "solr" using the V2 API as is described in [https://lucene.apache.org/solr/guide/8_4/adding-custom-plugins-in-solrcloud-mode.html] As "/solr" is replaced by "/api" in [https://github.com/apache/lucene-solr/blob/6eb7bc3b7bd6dea2a104448e921f7234973f0197/solr/core/src/java/org/apache/solr/pkg/PackageAPI.java#L418], the solr instance hostnames can't start with "/solr" because will be replaced with "/api" when the api endpoint is used. *i.e:* "http://solrexample.domain/solr; will be converted to "http://apiexample.domain/api; and should be "http://solrexample.domain/api". -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dweiss commented on a change in pull request #1634: SOLR-14592: Upgrade Zookeeper to 3.6.1
dweiss commented on a change in pull request #1634:
URL: https://github.com/apache/lucene-solr/pull/1634#discussion_r448185712
##
File path: solr/core/build.gradle
##
@@ -138,6 +138,8 @@ dependencies {
testImplementation ('com.sun.jersey:jersey-servlet') { transitive = false }
+ // required for instantiating a Zookeeper server in tests or embedded
+ runtimeOnly ('org.xerial.snappy:snappy-java') { transitive = false }
Review comment:
gradlew dependencies is the way to go as it shows you exactly which
dependencies it includes (for each configuration). This means that
compilation-time dependencies may be different than runtime dependencies, for
example. For a given configuration it will show you the subtree of dependencies
for a given entry. If snappy doesn't have any sub-dependencies then the subtree
is empty.
Alternatively, you can take a look at the pom file directly. :)
https://repo1.maven.org/maven2/org/xerial/snappy/snappy-java/1.1.7.6/snappy-java-1.1.7.6.pom
I only see test dependencies and "provided" which isn't included
transitively. So you can remove that "transitive = false" block as it doesn't
do anything for snappy. It is weird to me that this dependency isn't included
by zookeeper itself (it should be!). Perhaps it's because zookeeper is declared
with transitive=false. If so then a much better way to solve this would be to
remove the explicit snappy dependency and just include it transitively with
zookeeper.
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149162#comment-17149162
]
ASF subversion and git services commented on SOLR-14539:
Commit d9b673e46d3dfc2d509b5ee21c4f6b15a0a3eb31 in lucene-solr's branch
refs/heads/branch_8x from Mikhail Khludnev
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d9b673e ]
SOLR-14539: fix imports in test
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Fix For: 8.6
>
> Attachments: SOLR-14539.patch, SOLR-14539.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149159#comment-17149159
]
ASF subversion and git services commented on SOLR-14539:
Commit 6b5b83a5fe7f718662ec1d29d1016c2f73222e91 in lucene-solr's branch
refs/heads/branch_8_6 from Mikhail Khludnev
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6b5b83a ]
SOLR-14539: fix imports in test
> Query DSL: Introducing {!bool excludeTags=foo,bar}
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
> Fix For: 8.6
>
> Attachments: SOLR-14539.patch, SOLR-14539.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> -Let \{!bool .. }... repeat \{!filters ... trick resolve parameter refs to
> many values-. *UPD* Already done.
> Let's introduce {{excludeTags}} trick in BoolQParser. It will be useful for
> facet exclusion in block-join facets.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
