[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&focusedCommentId=17147535#comment-17147535
]
ASF subversion and git services commented on SOLR-14404:
Commit e94912e2f824769895b51b50f88ba4e347d2bede in lucene-solr's branch
refs/heads/branch_8x from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e94912e ]
SOLR-14404: openResource() to use classloader
> 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] [Issue Comment Deleted] (SOLR-14481) Add drill Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-14481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-14481:
--
Comment: was deleted
(was: Commit d883cd69fc2884352e0a363b98e3d5a37142dd52 in lucene-solr's branch
refs/heads/master from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d883cd6 ]
SOLR-14481: use classloader to open resource
)
> Add drill Streaming Expression
> --
>
> Key: SOLR-14481
> URL: https://issues.apache.org/jira/browse/SOLR-14481
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 8.6
>
> Attachments: SOLR-14481.patch, SOLR-14481.patch
>
>
> This ticket will add the *drill* Streaming Expression. The drill Streaming
> Expression is a wrapper around the functionality that is described in
> SOLR-14470. The idea is for drill to contact the /export handler on one
> replica in each shard of a collection and pass four parameters:
> * q: query
> * fl: field list
> * sort: sort spec
> * expr: The Streaming Expression sent to the /export handler to be executed.
> The export handler will pass the result set through the streaming expression
> performing an aggregation on the sorted result set and return the aggregated
> tuples. The drill expression will simply maintain the sort order of the
> tuples and emit them so that a wrapper expression can perform operations on
> the sorted aggregate tuples.
> Sample syntax:
> {code:java}
> drill(collection1, q="*:*", fl="a,b,c", sort="a desc, b desc",
> rollup(input(), over="a,b", sum(c))) {code}
> In order to finish the aggregation other expressions can be used:
> {code:java}
> rollup(
> select(
>drill(collection1,
> q="*:*",
> fl="a,b,c",
> sort="a desc, b desc",
> rollup(input(), over="a,b", sum(c))),
>a,
>b,
>sum(c) as sums),
> over="a, b",
> sum(sums))
>
> {code}
> This provides fast aggregation over fields with infinite cardinality by
> pushing down the first level of aggregation into the /export handler.
>
>
--
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-13205) StringIndexOutOfBoundsException in SolrQueryParserBase.getFieldQuery
[
https://issues.apache.org/jira/browse/SOLR-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147532#comment-17147532
]
Pramod Kumar commented on SOLR-13205:
-
Thanks Erick.
Will pick up the task.
I did see the PR, but I would like to make a slightly more comprehensive fix.
> StringIndexOutOfBoundsException in SolrQueryParserBase.getFieldQuery
>
>
> Key: SOLR-13205
> URL: https://issues.apache.org/jira/browse/SOLR-13205
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> * Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection and reproducing the bug
> We followed [Exercise
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from
> the [Solr
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html].
> {noformat}
> mkdir -p /tmp/home
> echo '' >
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field":
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}'
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}'
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> curl -v “URL_BUG”
> {noformat}
> Please check the issue description below to find the “URL_BUG” that will
> allow you to reproduce the issue reported.
>Reporter: Johannes Kloos
>Priority: Minor
> Labels: diffblue, newdev
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?df=&explainOther=debug=all&debugQuery=on
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> at java.lang.String.charAt(String.java:658)
> at
> org.apache.solr.parser.SolrQueryParserBase.getFieldQuery(SolrQueryParserBase.java:1045)
> at
> org.apache.solr.parser.SolrQueryParserBase.handleBareTokenQuery(SolrQueryParserBase.java:801)
> at org.apache.solr.parser.QueryParser.Term(QueryParser.java:421)
> at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:278)
> at org.apache.solr.parser.QueryParser.Query(QueryParser.java:162)
> at org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:131)
> at
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:255)
> at org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:49)
> at org.apache.solr.search.QParser.getQuery(QParser.java:173)
> at
> org.apache.solr.util.SolrPluginUtils.doSimpleQuery(SolrPluginUtils.java:479)
> at
> org.apache.solr.util.SolrPluginUtils.doStandardResultsDebug(SolrPluginUtils.java:390)
> at
> org.apache.solr.util.SolrPluginUtils.doStandardDebug(SolrPluginUtils.java:343)
> at
> org.apache.solr.handler.component.DebugComponent.process(DebugComponent.java:100)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:306)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> {noformat}
> The “df” parameter means that we set the empty string as default field(!).
> Since we do not give a field in the query, the default field is substituted
> in getFieldQuery. We then check if the field starts with “_” by using
> charAt(0).
> A trivial fix would be to replace field.charAt(0) == ‘_’ with
> field.startsWith(“_”).
> To set up an environment to reproduce this bug, follow the description in the
> ‘Environment’ field.
> We automatically found this issue and ~70 more like this using [Diffblue
> Microservices Testing|https://www.diffblue.com/labs/?utm_source=solr-br].
> Find more information on this [fuzz testing
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product
[jira] [Commented] (SOLR-14481) Add drill Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-14481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147530#comment-17147530
]
ASF subversion and git services commented on SOLR-14481:
Commit d883cd69fc2884352e0a363b98e3d5a37142dd52 in lucene-solr's branch
refs/heads/master from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d883cd6 ]
SOLR-14481: use classloader to open resource
> Add drill Streaming Expression
> --
>
> Key: SOLR-14481
> URL: https://issues.apache.org/jira/browse/SOLR-14481
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 8.6
>
> Attachments: SOLR-14481.patch, SOLR-14481.patch
>
>
> This ticket will add the *drill* Streaming Expression. The drill Streaming
> Expression is a wrapper around the functionality that is described in
> SOLR-14470. The idea is for drill to contact the /export handler on one
> replica in each shard of a collection and pass four parameters:
> * q: query
> * fl: field list
> * sort: sort spec
> * expr: The Streaming Expression sent to the /export handler to be executed.
> The export handler will pass the result set through the streaming expression
> performing an aggregation on the sorted result set and return the aggregated
> tuples. The drill expression will simply maintain the sort order of the
> tuples and emit them so that a wrapper expression can perform operations on
> the sorted aggregate tuples.
> Sample syntax:
> {code:java}
> drill(collection1, q="*:*", fl="a,b,c", sort="a desc, b desc",
> rollup(input(), over="a,b", sum(c))) {code}
> In order to finish the aggregation other expressions can be used:
> {code:java}
> rollup(
> select(
>drill(collection1,
> q="*:*",
> fl="a,b,c",
> sort="a desc, b desc",
> rollup(input(), over="a,b", sum(c))),
>a,
>b,
>sum(c) as sums),
> over="a, b",
> sum(sums))
>
> {code}
> This provides fast aggregation over fields with infinite cardinality by
> pushing down the first level of aggregation into the /export handler.
>
>
--
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-14481) Add drill Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-14481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147525#comment-17147525
]
ASF subversion and git services commented on SOLR-14481:
Commit ac2fa27fd902b5ff497b186c77dad837e2e4c4de in lucene-solr's branch
refs/heads/branch_8x from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ac2fa27 ]
SOLR-14481: precommit error
> Add drill Streaming Expression
> --
>
> Key: SOLR-14481
> URL: https://issues.apache.org/jira/browse/SOLR-14481
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 8.6
>
> Attachments: SOLR-14481.patch, SOLR-14481.patch
>
>
> This ticket will add the *drill* Streaming Expression. The drill Streaming
> Expression is a wrapper around the functionality that is described in
> SOLR-14470. The idea is for drill to contact the /export handler on one
> replica in each shard of a collection and pass four parameters:
> * q: query
> * fl: field list
> * sort: sort spec
> * expr: The Streaming Expression sent to the /export handler to be executed.
> The export handler will pass the result set through the streaming expression
> performing an aggregation on the sorted result set and return the aggregated
> tuples. The drill expression will simply maintain the sort order of the
> tuples and emit them so that a wrapper expression can perform operations on
> the sorted aggregate tuples.
> Sample syntax:
> {code:java}
> drill(collection1, q="*:*", fl="a,b,c", sort="a desc, b desc",
> rollup(input(), over="a,b", sum(c))) {code}
> In order to finish the aggregation other expressions can be used:
> {code:java}
> rollup(
> select(
>drill(collection1,
> q="*:*",
> fl="a,b,c",
> sort="a desc, b desc",
> rollup(input(), over="a,b", sum(c))),
>a,
>b,
>sum(c) as sums),
> over="a, b",
> sum(sums))
>
> {code}
> This provides fast aggregation over fields with infinite cardinality by
> pushing down the first level of aggregation into the /export handler.
>
>
--
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-14481) Add drill Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-14481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147524#comment-17147524
]
ASF subversion and git services commented on SOLR-14481:
Commit 94684cc0146277deb74ea77c185e86845561f58e in lucene-solr's branch
refs/heads/master from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=94684cc ]
SOLR-14481: precommit error
> Add drill Streaming Expression
> --
>
> Key: SOLR-14481
> URL: https://issues.apache.org/jira/browse/SOLR-14481
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 8.6
>
> Attachments: SOLR-14481.patch, SOLR-14481.patch
>
>
> This ticket will add the *drill* Streaming Expression. The drill Streaming
> Expression is a wrapper around the functionality that is described in
> SOLR-14470. The idea is for drill to contact the /export handler on one
> replica in each shard of a collection and pass four parameters:
> * q: query
> * fl: field list
> * sort: sort spec
> * expr: The Streaming Expression sent to the /export handler to be executed.
> The export handler will pass the result set through the streaming expression
> performing an aggregation on the sorted result set and return the aggregated
> tuples. The drill expression will simply maintain the sort order of the
> tuples and emit them so that a wrapper expression can perform operations on
> the sorted aggregate tuples.
> Sample syntax:
> {code:java}
> drill(collection1, q="*:*", fl="a,b,c", sort="a desc, b desc",
> rollup(input(), over="a,b", sum(c))) {code}
> In order to finish the aggregation other expressions can be used:
> {code:java}
> rollup(
> select(
>drill(collection1,
> q="*:*",
> fl="a,b,c",
> sort="a desc, b desc",
> rollup(input(), over="a,b", sum(c))),
>a,
>b,
>sum(c) as sums),
> over="a, b",
> sum(sums))
>
> {code}
> This provides fast aggregation over fields with infinite cardinality by
> pushing down the first level of aggregation into the /export handler.
>
>
--
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-14604) Uninstall Command for the Plugin Framework
Marcus Eagan created SOLR-14604: --- Summary: Uninstall Command for the Plugin Framework Key: SOLR-14604 URL: https://issues.apache.org/jira/browse/SOLR-14604 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Components: Plugin system Affects Versions: master (9.0) Reporter: Marcus Eagan I would like to be able to cleanly uninstall all artifacts associated with a plugin and the plugin itself from the command line. I'm not sure how many people want to work with the plugins yet, but as they grow in use and popularity, I'm sure this functionality will be desired by more people than just me. Today, the solution is to run the git command to remove all the files and directories that are un-versioned. -- 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-13205) StringIndexOutOfBoundsException in SolrQueryParserBase.getFieldQuery
[
https://issues.apache.org/jira/browse/SOLR-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147503#comment-17147503
]
Erick Erickson commented on SOLR-13205:
---
Welcome and thanks!
JIRAs can only be assigned to committers. So what happens is:
1> you just add a comment like you already have saying you're working on it
2> when you're ready, add a patch or a PR
3> nudge committers to review/push to the repo.
Make sure you look at the PR already attached BTW.
Best,
Erick
> StringIndexOutOfBoundsException in SolrQueryParserBase.getFieldQuery
>
>
> Key: SOLR-13205
> URL: https://issues.apache.org/jira/browse/SOLR-13205
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> * Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection and reproducing the bug
> We followed [Exercise
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from
> the [Solr
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html].
> {noformat}
> mkdir -p /tmp/home
> echo '' >
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field":
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}'
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}'
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> curl -v “URL_BUG”
> {noformat}
> Please check the issue description below to find the “URL_BUG” that will
> allow you to reproduce the issue reported.
>Reporter: Johannes Kloos
>Priority: Minor
> Labels: diffblue, newdev
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?df=&explainOther=debug=all&debugQuery=on
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> at java.lang.String.charAt(String.java:658)
> at
> org.apache.solr.parser.SolrQueryParserBase.getFieldQuery(SolrQueryParserBase.java:1045)
> at
> org.apache.solr.parser.SolrQueryParserBase.handleBareTokenQuery(SolrQueryParserBase.java:801)
> at org.apache.solr.parser.QueryParser.Term(QueryParser.java:421)
> at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:278)
> at org.apache.solr.parser.QueryParser.Query(QueryParser.java:162)
> at org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:131)
> at
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:255)
> at org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:49)
> at org.apache.solr.search.QParser.getQuery(QParser.java:173)
> at
> org.apache.solr.util.SolrPluginUtils.doSimpleQuery(SolrPluginUtils.java:479)
> at
> org.apache.solr.util.SolrPluginUtils.doStandardResultsDebug(SolrPluginUtils.java:390)
> at
> org.apache.solr.util.SolrPluginUtils.doStandardDebug(SolrPluginUtils.java:343)
> at
> org.apache.solr.handler.component.DebugComponent.process(DebugComponent.java:100)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:306)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> {noformat}
> The “df” parameter means that we set the empty string as default field(!).
> Since we do not give a field in the query, the default field is substituted
> in getFieldQuery. We then check if the field starts with “_” by using
> charAt(0).
> A trivial fix would be to replace field.charAt(0) == ‘_’ with
> field.startsWith(“_”).
> To set up an environment to reproduce this bug, follow the description in the
> ‘Environment’ field.
> We automatically found this issue and ~70 more like this using [Diffblue
> Microservices Testing|https://www.diffb
[jira] [Commented] (SOLR-13205) StringIndexOutOfBoundsException in SolrQueryParserBase.getFieldQuery
[
https://issues.apache.org/jira/browse/SOLR-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147495#comment-17147495
]
Pramod Kumar commented on SOLR-13205:
-
Hi - I am a newbie here. Looking to pick up this task as my first, and get a
quick patch up.
There are actually a couple of places with this issue.
Can this be assigned to me (I can't seem to assign it to myself)?
> StringIndexOutOfBoundsException in SolrQueryParserBase.getFieldQuery
>
>
> Key: SOLR-13205
> URL: https://issues.apache.org/jira/browse/SOLR-13205
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> * Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection and reproducing the bug
> We followed [Exercise
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from
> the [Solr
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html].
> {noformat}
> mkdir -p /tmp/home
> echo '' >
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field":
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}'
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}'
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> curl -v “URL_BUG”
> {noformat}
> Please check the issue description below to find the “URL_BUG” that will
> allow you to reproduce the issue reported.
>Reporter: Johannes Kloos
>Priority: Minor
> Labels: diffblue, newdev
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?df=&explainOther=debug=all&debugQuery=on
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> at java.lang.String.charAt(String.java:658)
> at
> org.apache.solr.parser.SolrQueryParserBase.getFieldQuery(SolrQueryParserBase.java:1045)
> at
> org.apache.solr.parser.SolrQueryParserBase.handleBareTokenQuery(SolrQueryParserBase.java:801)
> at org.apache.solr.parser.QueryParser.Term(QueryParser.java:421)
> at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:278)
> at org.apache.solr.parser.QueryParser.Query(QueryParser.java:162)
> at org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:131)
> at
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:255)
> at org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:49)
> at org.apache.solr.search.QParser.getQuery(QParser.java:173)
> at
> org.apache.solr.util.SolrPluginUtils.doSimpleQuery(SolrPluginUtils.java:479)
> at
> org.apache.solr.util.SolrPluginUtils.doStandardResultsDebug(SolrPluginUtils.java:390)
> at
> org.apache.solr.util.SolrPluginUtils.doStandardDebug(SolrPluginUtils.java:343)
> at
> org.apache.solr.handler.component.DebugComponent.process(DebugComponent.java:100)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:306)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> {noformat}
> The “df” parameter means that we set the empty string as default field(!).
> Since we do not give a field in the query, the default field is substituted
> in getFieldQuery. We then check if the field starts with “_” by using
> charAt(0).
> A trivial fix would be to replace field.charAt(0) == ‘_’ with
> field.startsWith(“_”).
> To set up an environment to reproduce this bug, follow the description in the
> ‘Environment’ field.
> We automatically found this issue and ~70 more like this using [Diffblue
> Microservices Testing|https://www.diffblue.com/labs/?utm_source=solr-br].
> Find more information on this [fuzz testing
> campaign|https://
[jira] [Updated] (SOLR-14481) Add drill Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-14481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-14481:
--
Fix Version/s: 8.6
> Add drill Streaming Expression
> --
>
> Key: SOLR-14481
> URL: https://issues.apache.org/jira/browse/SOLR-14481
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 8.6
>
> Attachments: SOLR-14481.patch, SOLR-14481.patch
>
>
> This ticket will add the *drill* Streaming Expression. The drill Streaming
> Expression is a wrapper around the functionality that is described in
> SOLR-14470. The idea is for drill to contact the /export handler on one
> replica in each shard of a collection and pass four parameters:
> * q: query
> * fl: field list
> * sort: sort spec
> * expr: The Streaming Expression sent to the /export handler to be executed.
> The export handler will pass the result set through the streaming expression
> performing an aggregation on the sorted result set and return the aggregated
> tuples. The drill expression will simply maintain the sort order of the
> tuples and emit them so that a wrapper expression can perform operations on
> the sorted aggregate tuples.
> Sample syntax:
> {code:java}
> drill(collection1, q="*:*", fl="a,b,c", sort="a desc, b desc",
> rollup(input(), over="a,b", sum(c))) {code}
> In order to finish the aggregation other expressions can be used:
> {code:java}
> rollup(
> select(
>drill(collection1,
> q="*:*",
> fl="a,b,c",
> sort="a desc, b desc",
> rollup(input(), over="a,b", sum(c))),
>a,
>b,
>sum(c) as sums),
> over="a, b",
> sum(sums))
>
> {code}
> This provides fast aggregation over fields with infinite cardinality by
> pushing down the first level of aggregation into the /export handler.
>
>
--
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-14481) Add drill Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-14481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147489#comment-17147489
]
ASF subversion and git services commented on SOLR-14481:
Commit 43a29220c287d99dba7caf76b561678f1b85af70 in lucene-solr's branch
refs/heads/branch_8x from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=43a2922 ]
SOLR-14481: Add drill Streaming Expression
> Add drill Streaming Expression
> --
>
> Key: SOLR-14481
> URL: https://issues.apache.org/jira/browse/SOLR-14481
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: SOLR-14481.patch, SOLR-14481.patch
>
>
> This ticket will add the *drill* Streaming Expression. The drill Streaming
> Expression is a wrapper around the functionality that is described in
> SOLR-14470. The idea is for drill to contact the /export handler on one
> replica in each shard of a collection and pass four parameters:
> * q: query
> * fl: field list
> * sort: sort spec
> * expr: The Streaming Expression sent to the /export handler to be executed.
> The export handler will pass the result set through the streaming expression
> performing an aggregation on the sorted result set and return the aggregated
> tuples. The drill expression will simply maintain the sort order of the
> tuples and emit them so that a wrapper expression can perform operations on
> the sorted aggregate tuples.
> Sample syntax:
> {code:java}
> drill(collection1, q="*:*", fl="a,b,c", sort="a desc, b desc",
> rollup(input(), over="a,b", sum(c))) {code}
> In order to finish the aggregation other expressions can be used:
> {code:java}
> rollup(
> select(
>drill(collection1,
> q="*:*",
> fl="a,b,c",
> sort="a desc, b desc",
> rollup(input(), over="a,b", sum(c))),
>a,
>b,
>sum(c) as sums),
> over="a, b",
> sum(sums))
>
> {code}
> This provides fast aggregation over fields with infinite cardinality by
> pushing down the first level of aggregation into the /export handler.
>
>
--
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-14481) Add drill Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-14481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147485#comment-17147485
]
ASF subversion and git services commented on SOLR-14481:
Commit 7bb9926ef282321361a7f90a6f577a72121c6582 in lucene-solr's branch
refs/heads/master from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7bb9926 ]
SOLR-14481: Add drill Streaming Expression
> Add drill Streaming Expression
> --
>
> Key: SOLR-14481
> URL: https://issues.apache.org/jira/browse/SOLR-14481
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: SOLR-14481.patch, SOLR-14481.patch
>
>
> This ticket will add the *drill* Streaming Expression. The drill Streaming
> Expression is a wrapper around the functionality that is described in
> SOLR-14470. The idea is for drill to contact the /export handler on one
> replica in each shard of a collection and pass four parameters:
> * q: query
> * fl: field list
> * sort: sort spec
> * expr: The Streaming Expression sent to the /export handler to be executed.
> The export handler will pass the result set through the streaming expression
> performing an aggregation on the sorted result set and return the aggregated
> tuples. The drill expression will simply maintain the sort order of the
> tuples and emit them so that a wrapper expression can perform operations on
> the sorted aggregate tuples.
> Sample syntax:
> {code:java}
> drill(collection1, q="*:*", fl="a,b,c", sort="a desc, b desc",
> rollup(input(), over="a,b", sum(c))) {code}
> In order to finish the aggregation other expressions can be used:
> {code:java}
> rollup(
> select(
>drill(collection1,
> q="*:*",
> fl="a,b,c",
> sort="a desc, b desc",
> rollup(input(), over="a,b", sum(c))),
>a,
>b,
>sum(c) as sums),
> over="a, b",
> sum(sums))
>
> {code}
> This provides fast aggregation over fields with infinite cardinality by
> pushing down the first level of aggregation into the /export handler.
>
>
--
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&focusedCommentId=17147449#comment-17147449
]
Mikhail Khludnev commented on SOLR-14539:
-
Hi, [~dsmiley].
Absolutely https://github.com/apache/lucene-solr/pull/1628
> 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
> Attachments: SOLR-14539.patch
>
> Time Spent: 10m
> 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] MarcusSorealheis edited a comment on pull request #1622: SOLR-14603: update Restlet version
MarcusSorealheis edited a comment on pull request #1622: URL: https://github.com/apache/lucene-solr/pull/1622#issuecomment-650824077 Everything is fine. I don't where I got those incorrect checksums from initially. I don't recall specifying a different algorithm. :) 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 opened a new pull request #1628: SOLR-14539: Ref Guide changes
mkhludnev opened a new 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
[GitHub] [lucene-solr] MarcusSorealheis commented on pull request #1622: SOLR-14603: update Restlet version
MarcusSorealheis commented on pull request #1622: URL: https://github.com/apache/lucene-solr/pull/1622#issuecomment-650824077 Everything is fine. I don't where I got those first checksums from. I don't recall specifying a different algorithm. :) 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-14585) Check the current user in SysV init script
[ https://issues.apache.org/jira/browse/SOLR-14585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147441#comment-17147441 ] Roman Kosenko commented on SOLR-14585: -- [~cpoerschke], I've added some comments - see the following pull request: [https://github.com/apache/lucene-solr/pull/1627] BTW, this change is not in `bin/solr` script. It is in `bin/init.d/solr` - this is just example SysV init script that executes `bin/solr` under the hood. > Check the current user in SysV init script > -- > > Key: SOLR-14585 > URL: https://issues.apache.org/jira/browse/SOLR-14585 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Affects Versions: 8.5.2 >Reporter: Roman Kosenko >Priority: Minor > Labels: sysinit, systemd > Attachments: init.d-solr.diff > > Time Spent: 10m > Remaining Estimate: 0h > > While SOLR-14410 is still open I propose a quick fix/improvement for init.d > script - check the current user and, if it is the same as RUNAS user, then > don't execute "su". > > Background: > Systemd has backward compatibility with SysV and able to run scripts from > /etc/init.d, but SELinux policies in many distros encourage changing user > before this stage and prohibits executing of "su" binary, so it would be > logical to do this at systemd level > (/etc/systemd/system/solr.service.d/override.conf). In this case, the current > init.d script for Solr is missing one very trivial check - `"$RUNAS" != > "$USER"`. See the diff-file in the attachment. > > Pull request: https://github.com/apache/lucene-solr/pull/1627 -- 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-14585) Check the current user in SysV init script
[ https://issues.apache.org/jira/browse/SOLR-14585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kosenko updated SOLR-14585: - Description: While SOLR-14410 is still open I propose a quick fix/improvement for init.d script - check the current user and, if it is the same as RUNAS user, then don't execute "su". Background: Systemd has backward compatibility with SysV and able to run scripts from /etc/init.d, but SELinux policies in many distros encourage changing user before this stage and prohibits executing of "su" binary, so it would be logical to do this at systemd level (/etc/systemd/system/solr.service.d/override.conf). In this case, the current init.d script for Solr is missing one very trivial check - `"$RUNAS" != "$USER"`. See the diff-file in the attachment. Pull request: https://github.com/apache/lucene-solr/pull/1627 was: While SOLR-14410 is still open I propose a quick fix/improvement for init.d script - check the current user and, if it is the same as RUNAS user, then don't execute "su". Background: Systemd has backward compatibility with SysV and able to run scripts from /etc/init.d, but SELinux policies in many distros encourage changing user before this stage and prohibits executing of "su" binary, so it would be logical to do this at systemd level (/etc/systemd/system/solr.service.d/override.conf). In this case, the current init.d script for Solr is missing one very trivial check - `"$RUNAS" != "$USER"`. See the diff-file in the attachment. > Check the current user in SysV init script > -- > > Key: SOLR-14585 > URL: https://issues.apache.org/jira/browse/SOLR-14585 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Affects Versions: 8.5.2 >Reporter: Roman Kosenko >Priority: Minor > Labels: sysinit, systemd > Attachments: init.d-solr.diff > > Time Spent: 10m > Remaining Estimate: 0h > > While SOLR-14410 is still open I propose a quick fix/improvement for init.d > script - check the current user and, if it is the same as RUNAS user, then > don't execute "su". > > Background: > Systemd has backward compatibility with SysV and able to run scripts from > /etc/init.d, but SELinux policies in many distros encourage changing user > before this stage and prohibits executing of "su" binary, so it would be > logical to do this at systemd level > (/etc/systemd/system/solr.service.d/override.conf). In this case, the current > init.d script for Solr is missing one very trivial check - `"$RUNAS" != > "$USER"`. See the diff-file in the attachment. > > Pull request: https://github.com/apache/lucene-solr/pull/1627 -- 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] rkosenko opened a new pull request #1627: SOLR-14585: Check the current user in SysV init script
rkosenko opened a new pull request #1627: URL: https://github.com/apache/lucene-solr/pull/1627 Run "su" only if the current user is not "solr" - this allows executing of /etc/init.d/solr using user "solr". 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 edited a comment on pull request #1622: SOLR-14603: update Restlet version
MarcusSorealheis edited a comment on pull request #1622: URL: https://github.com/apache/lucene-solr/pull/1622#issuecomment-650812066 I think this is finally ready. @janhoy i need to dig into my OS’s crypto libraries. I’m doing a final pass on those. 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] ErickErickson commented on pull request #1626: SOLR-14588: Implement Circuit Breakers
ErickErickson commented on pull request #1626: URL: https://github.com/apache/lucene-solr/pull/1626#issuecomment-650812400 I left some comments, I need to look at the code more closely before I finish. > On Jun 28, 2020, at 2:03 PM, Atri Sharma wrote: > > This commit consists of two parts: add circuit breakers infrastructure and a "real" JVM heap memory based > circuit breaker which monitors incoming search requests and rejects them with SERVICE_TOO_BUSY error > if the defined threshold is breached, thus giving headroom to existing indexing and search requests > to complete. > > You can view, comment on, or merge this pull request online at: > > https://github.com/apache/lucene-solr/pull/1626 > > Commit Summary > >• SOLR-14588: Implement Circuit Breakers > File Changes > >• M solr/CHANGES.txt (1) >• M solr/contrib/clustering/src/test-files/clustering/solr/collection1/conf/solrconfig.xml (11) >• M solr/contrib/prometheus-exporter/src/test-files/solr/collection1/conf/solrconfig.xml (4) >• M solr/core/src/java/org/apache/solr/core/SolrConfig.java (19) >• M solr/core/src/java/org/apache/solr/core/SolrCore.java (16) >• M solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java (32) >• A solr/core/src/java/org/apache/solr/util/circuitbreaker/CircuitBreaker.java (55) >• A solr/core/src/java/org/apache/solr/util/circuitbreaker/CircuitBreakerManager.java (128) >• A solr/core/src/java/org/apache/solr/util/circuitbreaker/CircuitBreakerType.java (26) >• A solr/core/src/java/org/apache/solr/util/circuitbreaker/MemoryCircuitBreaker.java (97) >• M solr/core/src/resources/EditableSolrConfigAttributes.json (2) >• M solr/core/src/test-files/solr/collection1/conf/solrconfig-cache-enable-disable.xml (4) >• M solr/core/src/test-files/solr/collection1/conf/solrconfig-elevate.xml (4) >• M solr/core/src/test-files/solr/collection1/conf/solrconfig-implicitproperties.xml (2) >• A solr/core/src/test-files/solr/collection1/conf/solrconfig-memory-circuitbreaker.xml (91) >• M solr/core/src/test-files/solr/collection1/conf/solrconfig-sortingresponse.xml (4) >• M solr/core/src/test-files/solr/collection1/conf/solrconfig.xml (10) >• M solr/core/src/test-files/solr/collection1/conf/solrconfig_perf.xml (2) >• M solr/core/src/test/org/apache/solr/core/SolrCoreTest.java (2) >• M solr/core/src/test/org/apache/solr/core/TestConfigOverlay.java (2) >• A solr/core/src/test/org/apache/solr/util/TestCircuitBreaker.java (227) >• M solr/example/example-DIH/solr/db/conf/solrconfig.xml (10) >• M solr/example/example-DIH/solr/mail/conf/solrconfig.xml (10) >• M solr/example/example-DIH/solr/solr/conf/solrconfig.xml (10) >• M solr/example/files/conf/solrconfig.xml (30) >• M solr/server/solr/configsets/_default/conf/solrconfig.xml (10) >• M solr/server/solr/configsets/sample_techproducts_configs/conf/solrconfig.xml (10) >• A solr/solr-ref-guide/src/circuit-breakers.adoc (81) >• M solr/solr-ref-guide/src/config-api.adoc (7) >• M solr/solr-ref-guide/src/index.adoc (3) >• M solr/solr-ref-guide/src/query-settings-in-solrconfig.adoc (20) > Patch Links: > >• https://github.com/apache/lucene-solr/pull/1626.patch >• https://github.com/apache/lucene-solr/pull/1626.diff > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or unsubscribe. > 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 commented on pull request #1622: SOLR-14603: update Restlet version
MarcusSorealheis commented on pull request #1622: URL: https://github.com/apache/lucene-solr/pull/1622#issuecomment-650812066 I think this finally ready. For some reason, my checksums locally were not working well. 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-14601) Using [child] and [subquery] DocTransformer / FieldList
[
https://issues.apache.org/jira/browse/SOLR-14601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147415#comment-17147415
]
Thomas Taroni edited comment on SOLR-14601 at 6/28/20, 6:52 PM:
*,[child fl='*'],customer:[subquery] -> Has worked as you described.
After a few more checks i could say the following:
if [child] will be react and processed in the same way as [child fl=*] that is
a possible expected behavior.
currently it heavy to predict what exactly it has for side effects if [child]
is picking up every field from fl=.
I am absolutely also at the case that is it a bad idea to exclude something
here from ChildDocTransformer. On the other side it looks like the duplicate
check in SubQueryAugmenterFactory could also be improved. Is a [subquery] is
already processed by [child] it should be not processed a second time in fl=.
Will check that firstly a little bit deeper. Thanks for answering.
was (Author: thomas taroni):
*,[child fl='*'],customer:[subquery] -> Has worked as you described expected.
After a few more checks i could say the following:
if [child] will be react and processed in the same way as [child fl=*] that is
a possible expected behavior.
currently it heavy to predict what exactly it has for side effects if [child]
is picking up every field from fl=.
I am absolutely also at the case that is it a bad idea to exclude something
here from ChildDocTransformer. On the other side it looks like the duplicate
check in SubQueryAugmenterFactory could also be improved. Is a [subquery] is
already processed by [child] it should be not processed a second time in fl=.
Will check that firstly a little bit deeper. Thanks for answering.
> Using [child] and [subquery] DocTransformer / FieldList
> ---
>
> Key: SOLR-14601
> URL: https://issues.apache.org/jira/browse/SOLR-14601
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SearchComponents - other
>Affects Versions: master (9.0), 8.5.2
> Environment: Docker Container 8.5.2 from Docker Hub
> Already existing in 9.0.0
>Reporter: Thomas Taroni
>Priority: Major
>
> If you are using in the fl parameter something like that and
> luceneMatchVersion is higher or equals then 8.0.0 :
> fl=*,[child],customer:[subquery] or
> fl=*,customer:[subquery],[child]
> It ends Up in any case in the following error (BadRequest) inside the
> SubQueryAugmenterFactory:
> {code:java}
> // code placeholder
> if (conflictMap.containsKey(field)) {
> throw new SolrException(ErrorCode.BAD_REQUEST,"[subquery] name "+field+" is
> uplicated");
> } else {
> conflictMap.put(field, true);
> }
> {code}
> It looks like that the following Snippet in ChildDocTransformerFactory(8.5.2
> and 9.0.0) already have added that field to the context.
> {code:java}
> // code placeholder 8.5.2
> String childReturnFields = params.get("fl");
> SolrReturnFields childSolrReturnFields;
> if(childReturnFields != null) {
> childSolrReturnFields = new SolrReturnFields(childReturnFields, req);
> } else if(req.getSchema().getDefaultLuceneMatchVersion().major < 8) {
> // ensure backwards for versions prior to SOLR 8
> childSolrReturnFields = new SolrReturnFields();
> } else {
> childSolrReturnFields = new SolrReturnFields(req);
> }
> {code}
> {code:java}
> // code placeholder master 9.0.0
> String childReturnFields = params.get("fl");
> SolrReturnFields childSolrReturnFields;
> if (childReturnFields != null) {
> childSolrReturnFields = new SolrReturnFields(childReturnFields, req);
> } else {
> childSolrReturnFields = new SolrReturnFields(req);
> }
> {code}
> It looks like childReturnFields includes also the customer:[subquery],
> eventually is a good idea to remove fields from other AugmenterFactories like
> [shard] or [subquery] from the childReturnFields variable
>
--
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-14601) Using [child] and [subquery] DocTransformer / FieldList
[
https://issues.apache.org/jira/browse/SOLR-14601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147415#comment-17147415
]
Thomas Taroni commented on SOLR-14601:
--
*,[child fl='*'],customer:[subquery] -> Has worked as you described expected.
After a few more checks i could say the following:
if [child] will be react and processed in the same way as [child fl=*] that is
a possible expected behavior.
currently it heavy to predict what exactly it has for side effects if [child]
is picking up every field from fl=.
I am absolutely also at the case that is it a bad idea to exclude something
here from ChildDocTransformer. On the other side it looks like the duplicate
check in SubQueryAugmenterFactory could also be improved. Is a [subquery] is
already processed by [child] it should be not processed a second time in fl=.
Will check that firstly a little bit deeper. Thanks for answering.
> Using [child] and [subquery] DocTransformer / FieldList
> ---
>
> Key: SOLR-14601
> URL: https://issues.apache.org/jira/browse/SOLR-14601
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SearchComponents - other
>Affects Versions: master (9.0), 8.5.2
> Environment: Docker Container 8.5.2 from Docker Hub
> Already existing in 9.0.0
>Reporter: Thomas Taroni
>Priority: Major
>
> If you are using in the fl parameter something like that and
> luceneMatchVersion is higher or equals then 8.0.0 :
> fl=*,[child],customer:[subquery] or
> fl=*,customer:[subquery],[child]
> It ends Up in any case in the following error (BadRequest) inside the
> SubQueryAugmenterFactory:
> {code:java}
> // code placeholder
> if (conflictMap.containsKey(field)) {
> throw new SolrException(ErrorCode.BAD_REQUEST,"[subquery] name "+field+" is
> uplicated");
> } else {
> conflictMap.put(field, true);
> }
> {code}
> It looks like that the following Snippet in ChildDocTransformerFactory(8.5.2
> and 9.0.0) already have added that field to the context.
> {code:java}
> // code placeholder 8.5.2
> String childReturnFields = params.get("fl");
> SolrReturnFields childSolrReturnFields;
> if(childReturnFields != null) {
> childSolrReturnFields = new SolrReturnFields(childReturnFields, req);
> } else if(req.getSchema().getDefaultLuceneMatchVersion().major < 8) {
> // ensure backwards for versions prior to SOLR 8
> childSolrReturnFields = new SolrReturnFields();
> } else {
> childSolrReturnFields = new SolrReturnFields(req);
> }
> {code}
> {code:java}
> // code placeholder master 9.0.0
> String childReturnFields = params.get("fl");
> SolrReturnFields childSolrReturnFields;
> if (childReturnFields != null) {
> childSolrReturnFields = new SolrReturnFields(childReturnFields, req);
> } else {
> childSolrReturnFields = new SolrReturnFields(req);
> }
> {code}
> It looks like childReturnFields includes also the customer:[subquery],
> eventually is a good idea to remove fields from other AugmenterFactories like
> [shard] or [subquery] from the childReturnFields variable
>
--
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-14588) Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker
[ https://issues.apache.org/jira/browse/SOLR-14588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147410#comment-17147410 ] Atri Sharma commented on SOLR-14588: [~ab] Not able to find your git ID hence couldnt tag you for review. > Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker > -- > > Key: SOLR-14588 > URL: https://issues.apache.org/jira/browse/SOLR-14588 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Time Spent: 8h 20m > Remaining Estimate: 0h > > This Jira tracks addition of circuit breakers in the search path and > implements JVM based circuit breaker which rejects incoming search requests > if the JVM heap usage exceeds a defined percentage. -- 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-14481) Add drill Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-14481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-14481:
--
Attachment: SOLR-14481.patch
> Add drill Streaming Expression
> --
>
> Key: SOLR-14481
> URL: https://issues.apache.org/jira/browse/SOLR-14481
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: SOLR-14481.patch, SOLR-14481.patch
>
>
> This ticket will add the *drill* Streaming Expression. The drill Streaming
> Expression is a wrapper around the functionality that is described in
> SOLR-14470. The idea is for drill to contact the /export handler on one
> replica in each shard of a collection and pass four parameters:
> * q: query
> * fl: field list
> * sort: sort spec
> * expr: The Streaming Expression sent to the /export handler to be executed.
> The export handler will pass the result set through the streaming expression
> performing an aggregation on the sorted result set and return the aggregated
> tuples. The drill expression will simply maintain the sort order of the
> tuples and emit them so that a wrapper expression can perform operations on
> the sorted aggregate tuples.
> Sample syntax:
> {code:java}
> drill(collection1, q="*:*", fl="a,b,c", sort="a desc, b desc",
> rollup(input(), over="a,b", sum(c))) {code}
> In order to finish the aggregation other expressions can be used:
> {code:java}
> rollup(
> select(
>drill(collection1,
> q="*:*",
> fl="a,b,c",
> sort="a desc, b desc",
> rollup(input(), over="a,b", sum(c))),
>a,
>b,
>sum(c) as sums),
> over="a, b",
> sum(sums))
>
> {code}
> This provides fast aggregation over fields with infinite cardinality by
> pushing down the first level of aggregation into the /export handler.
>
>
--
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-14588) Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker
[ https://issues.apache.org/jira/browse/SOLR-14588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147406#comment-17147406 ] Atri Sharma commented on SOLR-14588: I have raised an updated PR -- please see and provide comments and feedback. > Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker > -- > > Key: SOLR-14588 > URL: https://issues.apache.org/jira/browse/SOLR-14588 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Time Spent: 8h 20m > Remaining Estimate: 0h > > This Jira tracks addition of circuit breakers in the search path and > implements JVM based circuit breaker which rejects incoming search requests > if the JVM heap usage exceeds a defined percentage. -- 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 opened a new pull request #1626: SOLR-14588: Implement Circuit Breakers
atris opened a new pull request #1626: URL: https://github.com/apache/lucene-solr/pull/1626 This commit consists of two parts: add circuit breakers infrastructure and a "real" JVM heap memory based circuit breaker which monitors incoming search requests and rejects them with SERVICE_TOO_BUSY error if the defined threshold is breached, thus giving headroom to existing indexing and search requests to complete. 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-14599) Introduce cluster level plugins through packages
[
https://issues.apache.org/jira/browse/SOLR-14599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya updated SOLR-14599:
Attachment: SOLR-14599.patch
Status: Open (was: Open)
Here's a WIP patch. Here is the user interface:
{code}
bin/solr package deploy -y -cluster
bin/solr package undeploy -y -cluster
{code}
> Introduce cluster level plugins through packages
>
>
> Key: SOLR-14599
> URL: https://issues.apache.org/jira/browse/SOLR-14599
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
> Attachments: SOLR-14599.patch
>
>
> SOLR-14404 made it possible to write request handlers that are registered at
> core container level. This makes it possible for packages to have two types
> of plugins:
> # Collection level
> # Cluster level
> This issue intends to introduce the latter via package manager. The manifest
> for a package will now specify the type of the plugin. Such plugins can be
> deployed directly without specifying a collection.
--
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&focusedCommentId=17147368#comment-17147368
]
David Smiley commented on SOLR-14539:
-
Please introduce a ref-guide update for this.
> 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
> Attachments: SOLR-14539.patch
>
>
> 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-14592) Upgrade Zookeeper to 3.6.1
[
https://issues.apache.org/jira/browse/SOLR-14592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147366#comment-17147366
]
Erick Erickson commented on SOLR-14592:
---
Well, this will be a little trickier than I thought. The background is here:
https://github.com/apache/zookeeper/pull/1048/files, see the comments in the
file zookeeperAdmin.md
Root question. Do we need SolrZKServer.getMyServerId()? It's only used if the
myId file is missing. Is this a legitimate patch-up? The code is very old, it's
possible this was put in there for reasons that are no longer valid. Starting
up with embedded ZK doesn't seem to use this code
tl;dr;
SolrZKServer.getMyServerId
won't compile any more.
{code}
for (QuorumPeer.QuorumServer server : slist.values()) {
if (server.addr.getHostName().equals(myHost)) {
{code}
The thing I see in the Zookeeper code is something like
{code}
sever.addr.getReachableAddress().getHostName()...
{code}
Problem there is that the return from getReachableAddress is indeterminate, so
inferring the id from the address is probably not the right thing to do.
Before going down the path of trying to find the right thing to do I thought
I'd ask if this rings any bells. Meanwhile, I'll remove the code and see if
tests fail.
The kind of issue is a very good reason _NOT_ to try to get this into 8.6. BTW.
> 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
>
> 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] (LUCENE-9328) Sorting by DocValues while grouping is slower than old good FieldCache
[ https://issues.apache.org/jira/browse/LUCENE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147307#comment-17147307 ] Mikhail Khludnev commented on LUCENE-9328: -- Updating ref guide with the sad truth https://github.com/apache/lucene-solr/pull/1625/files > Sorting by DocValues while grouping is slower than old good FieldCache > -- > > Key: LUCENE-9328 > URL: https://issues.apache.org/jira/browse/LUCENE-9328 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/grouping >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Minor > Attachments: LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, > LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, > LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, > LUCENE-9328.patch > > Time Spent: 2h > Remaining Estimate: 0h > > That's why > https://issues.apache.org/jira/browse/LUCENE-7701?focusedCommentId=17084365&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17084365 -- 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 opened a new pull request #1625: Highlighting the actual state observed in LUCENE-9328
mkhludnev opened a new pull request #1625: URL: https://github.com/apache/lucene-solr/pull/1625 Hi, @ctargett. I'm not sure if it's valid to stroke through, or it's better to just drop this word? 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] uschindler commented on a change in pull request #1624: use MethodHandles in AnnotatedAPI
uschindler commented on a change in pull request #1624:
URL: https://github.com/apache/lucene-solr/pull/1624#discussion_r446632932
##
File path: solr/core/src/java/org/apache/solr/api/AnnotatedApi.java
##
@@ -113,7 +116,7 @@ public EndPoint getEndPoint() {
return Collections.singletonList(new AnnotatedApi(specProvider,
endPoint, commands, null));
} else {
List apis = new ArrayList<>();
- for (Method m : klas.getDeclaredMethods()) {
+ for (Method m : klas.getMethods()) {
EndPoint endPoint = m.getAnnotation(EndPoint.class);
if (endPoint == null) continue;
if (!Modifier.isPublic(m.getModifiers())) {
Review comment:
The if statement is not needed, because the public checks are done by
unreflect().
This code is from reflection times to catch error early. By using method
handles everything is checked and linked early, so you can't get any surprises
later. So the public checks is complete obsolete, all this is handled by
unreflect.
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] uschindler commented on a change in pull request #1624: use MethodHandles in AnnotatedAPI
uschindler commented on a change in pull request #1624:
URL: https://github.com/apache/lucene-solr/pull/1624#discussion_r446632680
##
File path: solr/core/src/java/org/apache/solr/api/AnnotatedApi.java
##
@@ -225,7 +228,11 @@ public void call(SolrQueryRequest req, SolrQueryResponse
rsp) {
if (Modifier.isPublic(method.getModifiers())) {
this.command = command;
this.obj = obj;
-this.method = method;
+try {
+ this.method = MethodHandles.publicLookup().unreflect(method);
+} catch (IllegalAccessException e) {
+ throw new RuntimeException("Unable to unlookup method");
Review comment:
The exception text should not mention internal details. It should just
say that the method cannot be called, as it's not accessible (non public, class
not visible, different classloader,...)
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] uschindler commented on a change in pull request #1624: use MethodHandles in AnnotatedAPI
uschindler commented on a change in pull request #1624:
URL: https://github.com/apache/lucene-solr/pull/1624#discussion_r446632522
##
File path: solr/core/src/java/org/apache/solr/api/AnnotatedApi.java
##
@@ -113,7 +116,7 @@ public EndPoint getEndPoint() {
return Collections.singletonList(new AnnotatedApi(specProvider,
endPoint, commands, null));
} else {
List apis = new ArrayList<>();
- for (Method m : klas.getDeclaredMethods()) {
+ for (Method m : klas.getMethods()) {
EndPoint endPoint = m.getAnnotation(EndPoint.class);
if (endPoint == null) continue;
if (!Modifier.isPublic(m.getModifiers())) {
Review comment:
Yes. For both branches.
In 8.x we have to fix the class accessibility check (unrelated to the if
statement).
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&focusedCommentId=17147300#comment-17147300
]
Mikhail Khludnev commented on SOLR-14539:
-
I believe the failure above ^ is caused by SOLR-14588. Beside of that, I this
this one is ready to go.
> 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
> Attachments: SOLR-14539.patch
>
>
> 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] uschindler commented on a change in pull request #1624: use MethodHandles in AnnotatedAPI
uschindler commented on a change in pull request #1624:
URL: https://github.com/apache/lucene-solr/pull/1624#discussion_r446632093
##
File path: solr/core/src/java/org/apache/solr/api/AnnotatedApi.java
##
@@ -87,16 +88,18 @@ public EndPoint getEndPoint() {
public static List getApis(Object obj) {
return getApis(obj.getClass(), obj);
}
- public static List getApis(Class klas , Object obj) {
-if (!Modifier.isPublic(klas.getModifiers())) {
- throw new RuntimeException(klas.getName() + " is not public");
+ public static List getApis(Class theClass , Object
obj) {
+Class klas = null;
+try {
+ klas = MethodHandles.publicLookup().accessClass(theClass);
+} catch (IllegalAccessException e) {
+ throw new RuntimeException(klas.getName() + " is not public", e);
Review comment:
Good catch. The code here is a mess, as you declare the variable as
null. You should declare it final before catch block and not assign null. Then
compiler would have been complained.
The current code is a horrible antipattern. Always declare variables as
final before try and assign once.
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] uschindler commented on a change in pull request #1624: use MethodHandles in AnnotatedAPI
uschindler commented on a change in pull request #1624:
URL: https://github.com/apache/lucene-solr/pull/1624#discussion_r446631519
##
File path: solr/core/src/java/org/apache/solr/api/AnnotatedApi.java
##
@@ -306,7 +313,7 @@ void invoke(SolrQueryRequest req, SolrQueryResponse rsp,
CommandOperation cmd) {
} catch (InvocationTargetException ite) {
log.error("Error executing command ", ite);
throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
ite.getCause());
- } catch (Exception e) {
+ } catch (Throwable e) {
Review comment:
There are two things to do:
- have the try-catch only around the invoke and nothing else, so we don't
accidentally catch any unwanted exception in the surrounding code
- only checked exceptions should be wrapped, everything else rethrown. This
keeps stack traces clean.
The reason for the declaration of "Throwable" comes from the fact that the
method handle always throws the original Exception and it's now wrapped like
for reflection. As checked exceptions is a compiler thing, normal code using
method handles in bytecode or invokedynamic never needs to catch Throwable.
It's only the stupid Java compiler that enforces us to catch everything,
because it can't know if the handle might possibly throw a checked exception.
When writing scripting languages you just ignore the Throwable when you produce
bytecode. 🤓
Here we should catch all possible exceptions that are commonly thrown by
plugins: SolrException, Runtime exception, Error and rethrown those. The last
catch block would catch Throwable and log it separately as some fatal error.
The code above should check the possible exceptions a method may throw and
forbid e.g. a plugin to throw Interrupted exception. So maybe get all throws
clauses of method and have whitelist. In the catch clause then throw
AssertionError if the "unknown" exception happens.
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] uschindler commented on a change in pull request #1624: use MethodHandles in AnnotatedAPI
uschindler commented on a change in pull request #1624:
URL: https://github.com/apache/lucene-solr/pull/1624#discussion_r446631519
##
File path: solr/core/src/java/org/apache/solr/api/AnnotatedApi.java
##
@@ -306,7 +313,7 @@ void invoke(SolrQueryRequest req, SolrQueryResponse rsp,
CommandOperation cmd) {
} catch (InvocationTargetException ite) {
log.error("Error executing command ", ite);
throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
ite.getCause());
- } catch (Exception e) {
+ } catch (Throwable e) {
Review comment:
There are two things to do:
- have they try catch only around the invoke and nothing else, so we don't
accidentally catch any unwanted exception in the surrounding code
- only checked exceptions should be wrapped, everything else rethrown. This
keeps stack traces clean.
The reason for the declaration of "Throwable" comes from the fact that the
method handle always throws the original Exception and it's now wrapped like
for reflection. As checked exceptions is a compiler thing, normal code using
method handles in bytecode or invokedynamic never needs to catch Throwable.
It's only the stupid Java compiler that enforces us to catch everything,
because it can't know if the handle might possibly throw a checked exception.
When writing scripting languages you just ignore the Throwable when you produce
bytecode. 🤓
Here we should catch all possible exceptions that are commonly thrown by
plugins: SolrException, Runtime exception, Error and rethrown those. The last
catch block would catch Throwable and log it separately as some fatal error.
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] murblanc commented on a change in pull request #1624: use MethodHandles in AnnotatedAPI
murblanc commented on a change in pull request #1624:
URL: https://github.com/apache/lucene-solr/pull/1624#discussion_r446631311
##
File path: solr/core/src/java/org/apache/solr/api/AnnotatedApi.java
##
@@ -113,7 +116,7 @@ public EndPoint getEndPoint() {
return Collections.singletonList(new AnnotatedApi(specProvider,
endPoint, commands, null));
} else {
List apis = new ArrayList<>();
- for (Method m : klas.getDeclaredMethods()) {
+ for (Method m : klas.getMethods()) {
EndPoint endPoint = m.getAnnotation(EndPoint.class);
if (endPoint == null) continue;
if (!Modifier.isPublic(m.getModifiers())) {
Review comment:
So you agree @uschindler that the `if` can be removed in the `master`
branch we're looking at, did I understand you correctly?
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] uschindler commented on a change in pull request #1624: use MethodHandles in AnnotatedAPI
uschindler commented on a change in pull request #1624:
URL: https://github.com/apache/lucene-solr/pull/1624#discussion_r446630480
##
File path: solr/core/src/java/org/apache/solr/api/AnnotatedApi.java
##
@@ -113,7 +116,7 @@ public EndPoint getEndPoint() {
return Collections.singletonList(new AnnotatedApi(specProvider,
endPoint, commands, null));
} else {
List apis = new ArrayList<>();
- for (Method m : klas.getDeclaredMethods()) {
+ for (Method m : klas.getMethods()) {
EndPoint endPoint = m.getAnnotation(EndPoint.class);
if (endPoint == null) continue;
if (!Modifier.isPublic(m.getModifiers())) {
Review comment:
Yes, we still need some way to check public methods. The accessClass()
method above returns itsself, but the check for public is not needed if we use
getMethods() instead of getDeclaredMethods().
The accessClass() check can't be backported to 8.x as it is new in Java 9.
So we need to somehow do the check for accessibility manually.
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] murblanc commented on a change in pull request #1624: use MethodHandles in AnnotatedAPI
murblanc commented on a change in pull request #1624:
URL: https://github.com/apache/lucene-solr/pull/1624#discussion_r446623850
##
File path: solr/core/src/java/org/apache/solr/api/AnnotatedApi.java
##
@@ -87,16 +88,18 @@ public EndPoint getEndPoint() {
public static List getApis(Object obj) {
return getApis(obj.getClass(), obj);
}
- public static List getApis(Class klas , Object obj) {
-if (!Modifier.isPublic(klas.getModifiers())) {
- throw new RuntimeException(klas.getName() + " is not public");
+ public static List getApis(Class theClass , Object
obj) {
+Class klas = null;
+try {
+ klas = MethodHandles.publicLookup().accessClass(theClass);
+} catch (IllegalAccessException e) {
+ throw new RuntimeException(klas.getName() + " is not public", e);
Review comment:
You obviously meant `theClass.getName()` here and not `klas.getName()`.
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] murblanc commented on a change in pull request #1624: use MethodHandles in AnnotatedAPI
murblanc commented on a change in pull request #1624:
URL: https://github.com/apache/lucene-solr/pull/1624#discussion_r446627210
##
File path: solr/core/src/java/org/apache/solr/api/AnnotatedApi.java
##
@@ -113,7 +116,7 @@ public EndPoint getEndPoint() {
return Collections.singletonList(new AnnotatedApi(specProvider,
endPoint, commands, null));
} else {
List apis = new ArrayList<>();
- for (Method m : klas.getDeclaredMethods()) {
+ for (Method m : klas.getMethods()) {
EndPoint endPoint = m.getAnnotation(EndPoint.class);
if (endPoint == null) continue;
if (!Modifier.isPublic(m.getModifiers())) {
Review comment:
Is this still needed? Wouldn't
`MethodHandles.publicLookup().accessClass(theClass)` only return `public`
methods?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on a change in pull request #1624: use MethodHandles in AnnotatedAPI
murblanc commented on a change in pull request #1624:
URL: https://github.com/apache/lucene-solr/pull/1624#discussion_r446626784
##
File path: solr/core/src/java/org/apache/solr/api/AnnotatedApi.java
##
@@ -306,7 +313,7 @@ void invoke(SolrQueryRequest req, SolrQueryResponse rsp,
CommandOperation cmd) {
} catch (InvocationTargetException ite) {
log.error("Error executing command ", ite);
throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
ite.getCause());
- } catch (Exception e) {
+ } catch (Throwable e) {
Review comment:
I think a comment referencing the `MethodHandle` Javadoc would be
helpful here, as the Javadoc explains `Throwable` should be caught and the
exception wrapped.
> But in Java source code, methods which perform method handle calls must
either explicitly throw Throwable, or else must catch all throwables locally,
rethrowing only those which are legal in the context, and wrapping ones which
are illegal.
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] murblanc commented on a change in pull request #1624: use MethodHandles in AnnotatedAPI
murblanc commented on a change in pull request #1624:
URL: https://github.com/apache/lucene-solr/pull/1624#discussion_r446626404
##
File path: solr/core/src/java/org/apache/solr/api/AnnotatedApi.java
##
@@ -225,7 +228,11 @@ public void call(SolrQueryRequest req, SolrQueryResponse
rsp) {
if (Modifier.isPublic(method.getModifiers())) {
this.command = command;
this.obj = obj;
-this.method = method;
+try {
+ this.method = MethodHandles.publicLookup().unreflect(method);
+} catch (IllegalAccessException e) {
+ throw new RuntimeException("Unable to unlookup method");
Review comment:
unlookup? (did you mean unreflect?)
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] murblanc commented on a change in pull request #1624: use MethodHandles in AnnotatedAPI
murblanc commented on a change in pull request #1624:
URL: https://github.com/apache/lucene-solr/pull/1624#discussion_r446625933
##
File path: solr/core/src/java/org/apache/solr/api/AnnotatedApi.java
##
@@ -225,7 +228,11 @@ public void call(SolrQueryRequest req, SolrQueryResponse
rsp) {
if (Modifier.isPublic(method.getModifiers())) {
this.command = command;
this.obj = obj;
-this.method = method;
+try {
+ this.method = MethodHandles.publicLookup().unreflect(method);
+} catch (IllegalAccessException e) {
+ throw new RuntimeException("Unable to unlookup method");
Review comment:
Unrelated to to this PR (i.e. comment holds for previous version of the
code), maybe `InterruptedException` should be caught separately and
`Thread.currentThread().interrupt()` be called.
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 a change in pull request #1624: use MethodHandles in AnnotatedAPI
chatman commented on a change in pull request #1624:
URL: https://github.com/apache/lucene-solr/pull/1624#discussion_r446625191
##
File path: solr/core/src/java/org/apache/solr/api/AnnotatedApi.java
##
@@ -225,7 +228,11 @@ public void call(SolrQueryRequest req, SolrQueryResponse
rsp) {
if (Modifier.isPublic(method.getModifiers())) {
this.command = command;
this.obj = obj;
-this.method = method;
+try {
+ this.method = MethodHandles.publicLookup().unreflect(method);
+} catch (IllegalAccessException e) {
+ throw new RuntimeException("Unable to unlookup method");
Review comment:
Lets throw SolrException here.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on a change in pull request #1624: use MethodHandles in AnnotatedAPI
murblanc commented on a change in pull request #1624:
URL: https://github.com/apache/lucene-solr/pull/1624#discussion_r446623850
##
File path: solr/core/src/java/org/apache/solr/api/AnnotatedApi.java
##
@@ -87,16 +88,18 @@ public EndPoint getEndPoint() {
public static List getApis(Object obj) {
return getApis(obj.getClass(), obj);
}
- public static List getApis(Class klas , Object obj) {
-if (!Modifier.isPublic(klas.getModifiers())) {
- throw new RuntimeException(klas.getName() + " is not public");
+ public static List getApis(Class theClass , Object
obj) {
+Class klas = null;
+try {
+ klas = MethodHandles.publicLookup().accessClass(theClass);
+} catch (IllegalAccessException e) {
+ throw new RuntimeException(klas.getName() + " is not public", e);
Review comment:
If the exception is thrown, `klas` will be null and `klass.getName()`
will throw NPE
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-8962) Can we merge small segments during refresh, for faster searching?
[
https://issues.apache.org/jira/browse/LUCENE-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147239#comment-17147239
]
ASF subversion and git services commented on LUCENE-8962:
-
Commit f8b1d698af981251120e4e96255dbc0ee42e3ed8 in lucene-solr's branch
refs/heads/branch_8x from Simon Willnauer
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f8b1d69 ]
LUCENE-8962: Ensure we never flush by ram buffer or doc count in test
> Can we merge small segments during refresh, for faster searching?
> -
>
> Key: LUCENE-8962
> URL: https://issues.apache.org/jira/browse/LUCENE-8962
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/index
>Reporter: Michael McCandless
>Priority: Major
> Fix For: master (9.0), 8.6
>
> Attachments: LUCENE-8962_demo.png, failed-tests.patch,
> failure_log.txt, test.diff
>
> Time Spent: 22h 40m
> Remaining Estimate: 0h
>
> With near-real-time search we ask {{IndexWriter}} to write all in-memory
> segments to disk and open an {{IndexReader}} to search them, and this is
> typically a quick operation.
> However, when you use many threads for concurrent indexing, {{IndexWriter}}
> will accumulate write many small segments during {{refresh}} and this then
> adds search-time cost as searching must visit all of these tiny segments.
> The merge policy would normally quickly coalesce these small segments if
> given a little time ... so, could we somehow improve {{IndexWriter'}}s
> refresh to optionally kick off merge policy to merge segments below some
> threshold before opening the near-real-time reader? It'd be a bit tricky
> because while we are waiting for merges, indexing may continue, and new
> segments may be flushed, but those new segments shouldn't be included in the
> point-in-time segments returned by refresh ...
> One could almost do this on top of Lucene today, with a custom merge policy,
> and some hackity logic to have the merge policy target small segments just
> written by refresh, but it's tricky to then open a near-real-time reader,
> excluding newly flushed but including newly merged segments since the refresh
> originally finished ...
> I'm not yet sure how best to solve this, so I wanted to open an issue for
> discussion!
--
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-8962) Can we merge small segments during refresh, for faster searching?
[
https://issues.apache.org/jira/browse/LUCENE-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147238#comment-17147238
]
ASF subversion and git services commented on LUCENE-8962:
-
Commit 3377b09fcbf46315ac64350ab259a45b1ec2889c in lucene-solr's branch
refs/heads/master from Simon Willnauer
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3377b09 ]
LUCENE-8962: Ensure we never flush by ram buffer or doc count in test
> Can we merge small segments during refresh, for faster searching?
> -
>
> Key: LUCENE-8962
> URL: https://issues.apache.org/jira/browse/LUCENE-8962
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/index
>Reporter: Michael McCandless
>Priority: Major
> Fix For: master (9.0), 8.6
>
> Attachments: LUCENE-8962_demo.png, failed-tests.patch,
> failure_log.txt, test.diff
>
> Time Spent: 22h 40m
> Remaining Estimate: 0h
>
> With near-real-time search we ask {{IndexWriter}} to write all in-memory
> segments to disk and open an {{IndexReader}} to search them, and this is
> typically a quick operation.
> However, when you use many threads for concurrent indexing, {{IndexWriter}}
> will accumulate write many small segments during {{refresh}} and this then
> adds search-time cost as searching must visit all of these tiny segments.
> The merge policy would normally quickly coalesce these small segments if
> given a little time ... so, could we somehow improve {{IndexWriter'}}s
> refresh to optionally kick off merge policy to merge segments below some
> threshold before opening the near-real-time reader? It'd be a bit tricky
> because while we are waiting for merges, indexing may continue, and new
> segments may be flushed, but those new segments shouldn't be included in the
> point-in-time segments returned by refresh ...
> One could almost do this on top of Lucene today, with a custom merge policy,
> and some hackity logic to have the merge policy target small segments just
> written by refresh, but it's tricky to then open a near-real-time reader,
> excluding newly flushed but including newly merged segments since the refresh
> originally finished ...
> I'm not yet sure how best to solve this, so I wanted to open an issue for
> discussion!
--
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
