[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=17147215#comment-17147215
]
David Smiley commented on SOLR-14601:
-
> child has only three allowed parameters: parentFilter,childFilter and limit.
Not only those; it clearly supports "fl". It's in the docs and also in the code
snippet you shared.
I think in this case the solution is to be explicit in the "fl" inside child:
{code:java}
fl=*,[child fl=*],customer:[subquery]
{code}
Assuming that works, maybe it wasn't obvious enough and maybe it'd be nice if
Solr could somehow figure out this case automatically. I definitely don't like
the idea of ChildDocTransformer somehow expressly excluding certain other
transformers because it would preclude 3rd party plugins. Instead, I'd prefer
some sort of solution where a TransformerFactory could detect it's being
activated from child's field list and then choose to opt itself out, or instead
declare this preference.
> 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-14404) CoreContainer level custom requesthandlers
[
https://issues.apache.org/jira/browse/SOLR-14404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147212#comment-17147212
]
ASF subversion and git services commented on SOLR-14404:
Commit 00650552780225897e48cdf333a8c3f9f9ee963f in lucene-solr's branch
refs/heads/branch_8x from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0065055 ]
SOLR-14404: support for openResource() in PackageResourceLoader & path-prefix
for container plugins
> 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] [Assigned] (SOLR-11741) Offline training mode for schema guessing
[ https://issues.apache.org/jira/browse/SOLR-11741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya reassigned SOLR-11741: --- Assignee: Ishan Chattopadhyaya > Offline training mode for schema guessing > - > > Key: SOLR-11741 > URL: https://issues.apache.org/jira/browse/SOLR-11741 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Major > Attachments: RuleForMostAccomodatingField.png, SOLR-11741-temp.patch, > SOLR-11741.patch, SOLR-11741.patch, SOLR-11741.patch, screenshot-1.png, > screenshot-3.png > > > Our data driven schema guessing doesn't work under many situations. For > example, if the first document has a field with value "0", it is guessed as > Long and subsequent fields with "0.0" are rejected. Similarly, if the same > field had alphanumeric contents for a latter document, those documents are > rejected. Also, single vs. multi valued field guessing is not ideal. > Proposing an offline training mode where Solr accepts bunch of documents and > returns a guessed schema (without indexing). This schema can then be used for > actual indexing. I think the original idea is from Hoss. > I think initial implementation can be based on an UpdateRequestProcessor. We > can hash out the API soon, as we go along. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14404) CoreContainer level custom requesthandlers
[
https://issues.apache.org/jira/browse/SOLR-14404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147207#comment-17147207
]
ASF subversion and git services commented on SOLR-14404:
Commit 1590ed56bb4a4fec9ffb27a42b81106a934ac898 in lucene-solr's branch
refs/heads/master from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1590ed5 ]
SOLR-14404: support for openResource() in PackageResourceLoader & path-prefix
for container plugins
> CoreContainer level custom requesthandlers
> --
>
> Key: SOLR-14404
> URL: https://issues.apache.org/jira/browse/SOLR-14404
> Project: Solr
> Issue Type: New Feature
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/plugin}}
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "full.ClassName"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> add a plugin from a package
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "pkgName:full.ClassName" ,
> "version: "1.0"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName" }
> }
> }
> {code}
> example plugin
> {code:java}
> public class MyPlugin {
> private final CoreContainer coreContainer;
> public MyPlugin(CoreContainer coreContainer) {
> this.coreContainer = coreContainer;
> }
> @EndPoint(path = "/myplugin/path1",
> method = METHOD.GET,
> permission = READ)
> public void call(SolrQueryRequest req, SolrQueryResponse rsp){
> rsp.add("myplugin.version", "2.0");
> }
> }
> {code}
> This plugin will be accessible on all nodes at {{/api/myplugin/path1}}. It's
> possible to add more methods at different paths. Ensure that all paths start
> with {{myplugin}} because that is the name in which the plugin is registered
> with. So {{/myplugin/path2}} , {{/myplugin/my/deeply/nested/path}} are all
> valid paths.
> It's possible that the user chooses to register the plugin with a different
> name. In that case , use a template variable as follows in paths
> {{$plugin-name/path1}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul merged pull request #1621: SOLR-14404: support for openResource() in PackageResourceLoader
noblepaul merged pull request #1621: URL: https://github.com/apache/lucene-solr/pull/1621 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-13749) Implement support for joining across collections with multiple shards ( XCJF )
[
https://issues.apache.org/jira/browse/SOLR-13749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147203#comment-17147203
]
David Smiley commented on SOLR-13749:
-
As I was browsing through Solr's DocSet related code, I noticed something a
little surprising to me -- CrossCollectionJoinQuery internally uses
{{DocSetUtil.createDocSet(...)}} to get a DocSet instead of
{{SolrIndexSearcher.getDocSet(query)}} --
https://github.com/apache/lucene-solr/blob/54e6528304027ab15bbac2b62746b34eed7b4f40/solr/core/src/java/org/apache/solr/search/join/CrossCollectionJoinQuery.java#L173
DocSetUtil.createDocSet does _not_ use the filter cache whereas
SolrIndexSearcher.getDocSet will (provided you have one and that the query
doesn't declare itself as not being cacheable). IMO to avoid confusion, this
method ought to be inlined into its only caller which is just a one-liner any
way.
Was it intentional that this query not be cached? Perhaps it's debatable and
maybe the query should have a flag for this, since maybe it'd just pollute the
filter cache. Or maybe it's basically always pointless. I hope Dan/Kevin can
respond as you probably have more insights here than I.
Also, it's not evident to me why this join query demands this DocSet
internally.
{{org.apache.solr.search.join.CrossCollectionJoinQuery.JoinKeyCollector#getDocSet}}
exists but couldn't it be {{getQuery}}? The caller ultimately wants a Scorer
so why materialize a DocSet when you could go from {{Query->Weight->Scorer}}?
One answer might be to benefit from a cache, but as I explained, you routed
around it ;-). To produce the Query: In the Terms case, I see you collect the
postings early and thus you have a DocSet so you could call DocSet.getTopFilter
(Filter subclasses Query) and in the numeric case, just return the Query that
you already have. I don't know why the Terms vs Numerics case has to vary so
much here; the Terms case could have been a TermInSetQuery.
> Implement support for joining across collections with multiple shards ( XCJF )
> --
>
> Key: SOLR-13749
> URL: https://issues.apache.org/jira/browse/SOLR-13749
> Project: Solr
> Issue Type: New Feature
>Reporter: Kevin Watters
>Assignee: Gus Heck
>Priority: Blocker
> Fix For: 8.6
>
> Attachments: 2020-03 Smiley with ASF hat.jpeg
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> This ticket includes 2 query parsers.
> The first one is the "Cross collection join filter" (XCJF) parser. This is
> the "Cross-collection join filter" query parser. It can do a call out to a
> remote collection to get a set of join keys to be used as a filter against
> the local collection.
> The second one is the Hash Range query parser that you can specify a field
> name and a hash range, the result is that only the documents that would have
> hashed to that range will be returned.
> This query parser will do an intersection based on join keys between 2
> collections.
> The local collection is the collection that you are searching against.
> The remote collection is the collection that contains the join keys that you
> want to use as a filter.
> Each shard participating in the distributed request will execute a query
> against the remote collection. If the local collection is setup with the
> compositeId router to be routed on the join key field, a hash range query is
> applied to the remote collection query to only match the documents that
> contain a potential match for the documents that are in the local shard/core.
>
>
> Here's some vocab to help with the descriptions of the various parameters.
> ||Term||Description||
> |Local Collection|This is the main collection that is being queried.|
> |Remote Collection|This is the collection that the XCJFQuery will query to
> resolve the join keys.|
> |XCJFQuery|The lucene query that executes a search to get back a set of join
> keys from a remote collection|
> |HashRangeQuery|The lucene query that matches only the documents whose hash
> code on a field falls within a specified range.|
>
>
> ||Param ||Required ||Description||
> |collection|Required|The name of the external Solr collection to be queried
> to retrieve the set of join key values ( required )|
> |zkHost|Optional|The connection string to be used to connect to Zookeeper.
> zkHost and solrUrl are both optional parameters, and at most one of them
> should be specified.
> If neither of zkHost or solrUrl are specified, the local Zookeeper cluster
> will be used. ( optional )|
> |solrUrl|Optional|The URL of the external Solr node to be queried ( optional
> )|
> |from|Required|The join key field name in the external collection ( required
> )|
> |to|Required|The join key field name in
[jira] [Commented] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147202#comment-17147202
]
Ishan Chattopadhyaya commented on SOLR-14598:
-
Apologies for jumping the gun and committing the issue without waiting for a
review.
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
> Attachments: SOLR-14598.patch
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(Eat
[jira] [Resolved] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya resolved SOLR-14598.
-
Resolution: Invalid
I think this issue can be closed. It was indeed an instructional usecase. It
was improper usage and security manager saved the day.
For reference on how it was fixed:
https://issues.apache.org/jira/browse/SOLR-14404?focusedCommentId=17147200&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17147200
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
> Attachments: SOLR-14598.patch
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.
[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=17147200#comment-17147200
]
Ishan Chattopadhyaya commented on SOLR-14404:
-
I tested with https://github.com/apache/lucene-solr/pull/1624 and there are no
security exceptions any more. Thanks a lot, [~uschindler] and [~rcmuir]! It is
troubling, though, that same issue cannot be reproduced by our tests. Tests
enjoy much more relaxed restrictions with the security manager and issues like
these can only be caught by running Solr as a user would. I strongly feel we
should have same restrictions on tests too, even if that means throwing out
things like Mockito and reworking our tests. Or, alternatively, split up the
tests into unit tests and integration tests.
> 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 10m
> Remaining Estimate: 0h
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/plugin}}
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "full.ClassName"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> add a plugin from a package
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "pkgName:full.ClassName" ,
> "version: "1.0"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName" }
> }
> }
> {code}
> example plugin
> {code:java}
> public class MyPlugin {
> private final CoreContainer coreContainer;
> public MyPlugin(CoreContainer coreContainer) {
> this.coreContainer = coreContainer;
> }
> @EndPoint(path = "/myplugin/path1",
> method = METHOD.GET,
> permission = READ)
> public void call(SolrQueryRequest req, SolrQueryResponse rsp){
> rsp.add("myplugin.version", "2.0");
> }
> }
> {code}
> This plugin will be accessible on all nodes at {{/api/myplugin/path1}}. It's
> possible to add more methods at different paths. Ensure that all paths start
> with {{myplugin}} because that is the name in which the plugin is registered
> with. So {{/myplugin/path2}} , {{/myplugin/my/deeply/nested/path}} are all
> valid paths.
> It's possible that the user chooses to register the plugin with a different
> name. In that case , use a template variable as follows in paths
> {{$plugin-name/path1}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman commented on pull request #1624: use MethodHandles in AnnotatedAPI
chatman commented on pull request #1624: URL: https://github.com/apache/lucene-solr/pull/1624#issuecomment-650691271 With this PR, the security exceptions are gone. +1 to merge. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1624: use MethodHandles in AnnotatedAPI
noblepaul commented on a change in pull request #1624:
URL: https://github.com/apache/lucene-solr/pull/1624#discussion_r446597787
##
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:
`methodhandle.invoke()` throws `Throwable`. What choice do we have?
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=17147179#comment-17147179
]
Lucene/Solr QA commented on SOLR-14539:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
0s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 2m 15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 2m 15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 2m 15s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 70m 28s{color}
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 78m 1s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.handler.component.DebugComponentTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-14539 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/13006600/SOLR-14539.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene2-us-west.apache.org 4.4.0-170-generic #199-Ubuntu SMP
Thu Nov 14 01:45:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / fb3c5d2 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
| unit |
https://builds.apache.org/job/PreCommit-SOLR-Build/768/artifact/out/patch-unit-solr_core.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/768/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/768/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> 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] dsmiley commented on a change in pull request #1624: use MethodHandles in AnnotatedAPI
dsmiley commented on a change in pull request #1624:
URL: https://github.com/apache/lucene-solr/pull/1624#discussion_r446592665
##
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:
Catching Throwable is generally something to avoid. Why here do you
think it makes sense?
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] [Resolved] (LUCENE-9420) Restlet Dependency
[ https://issues.apache.org/jira/browse/LUCENE-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eagan resolved LUCENE-9420. -- Resolution: Fixed closing and moving to SOLR project for now. > Restlet Dependency > -- > > Key: LUCENE-9420 > URL: https://issues.apache.org/jira/browse/LUCENE-9420 > Project: Lucene - Core > Issue Type: New Feature > Components: core/other >Reporter: Marcus Eagan >Priority: Minor > Time Spent: 50m > Remaining Estimate: 0h > > I noticed that the Restlet dependency's location was no longer resolving at: > https://repo1.maven.org/maven2/org/restlet/jee/org.restlet/2.4.0/org.restlet-2.4.0.jar. > Now, of course, I could change it to a location that does resolve or download > directly. However, I looking at the changelog I thought that maybe I should > raise with the community that it an upgrade might be helpful given the CVEs. > I will leave it to the experts as to whether it makes a difference, but > here's [the changelog for > reference|https://restlet.talend.com/documentation/2.4/changelog]. > The Lucene tests passed when I upgraded to 2.4.3 but I'm still digging in. > It is very likely that 2.4.1 would be better. I'd leave that, again, to the > experts and post my findings. -- 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] (LUCENE-9322) Discussing a unified vectors format API
[ https://issues.apache.org/jira/browse/LUCENE-9322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julie Tibshirani updated LUCENE-9322: - Description: Two different approximate nearest neighbor approaches are currently being developed, one based on HNSW (LUCENE-9004) and another based on coarse quantization ([#LUCENE-9136]). Each prototype proposes to add a new format to handle vectors. In LUCENE-9136 we discussed the possibility of a unified API that could support both approaches. The two ANN strategies give different trade-offs in terms of speed, memory, and complexity, and it’s likely that we’ll want to support both. Vector search is also an active research area, and it would be great to be able to prototype and incorporate new approaches without introducing more formats. To me it seems like a good time to begin discussing a unified API. The prototype for coarse quantization ([https://github.com/apache/lucene-solr/pull/1314]) could be ready to commit soon (this depends on everyone's feedback of course). The approach is simple and shows solid search performance, as seen [here|https://github.com/apache/lucene-solr/pull/1314#issuecomment-608645326]. I think this API discussion is an important step in moving that implementation forward. The goals of the API would be # Support for storing and retrieving individual float vectors. # Support for approximate nearest neighbor search -- given a query vector, return the indexed vectors that are closest to it. was: Two different approximate nearest neighbor approaches are currently being developed, one based on HNSW ([#LUCENE-9004]) and another based on coarse quantization ([#LUCENE-9136]). Each prototype proposes to add a new format to handle vectors. In LUCENE-9136 we discussed the possibility of a unified API that could support both approaches. The two ANN strategies give different trade-offs in terms of speed, memory, and complexity, and it’s likely that we’ll want to support both. Vector search is also an active research area, and it would be great to be able to prototype and incorporate new approaches without introducing more formats. To me it seems like a good time to begin discussing a unified API. The prototype for coarse quantization ([https://github.com/apache/lucene-solr/pull/1314]) could be ready to commit soon (this depends on everyone's feedback of course). The approach is simple and shows solid search performance, as seen [here|https://github.com/apache/lucene-solr/pull/1314#issuecomment-608645326]. I think this API discussion is an important step in moving that implementation forward. The goals of the API would be # Support for storing and retrieving individual float vectors. # Support for approximate nearest neighbor search -- given a query vector, return the indexed vectors that are closest to it. > Discussing a unified vectors format API > --- > > Key: LUCENE-9322 > URL: https://issues.apache.org/jira/browse/LUCENE-9322 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Julie Tibshirani >Priority: Major > > Two different approximate nearest neighbor approaches are currently being > developed, one based on HNSW (LUCENE-9004) and another based on coarse > quantization ([#LUCENE-9136]). Each prototype proposes to add a new format to > handle vectors. In LUCENE-9136 we discussed the possibility of a unified API > that could support both approaches. The two ANN strategies give different > trade-offs in terms of speed, memory, and complexity, and it’s likely that > we’ll want to support both. Vector search is also an active research area, > and it would be great to be able to prototype and incorporate new approaches > without introducing more formats. > To me it seems like a good time to begin discussing a unified API. The > prototype for coarse quantization > ([https://github.com/apache/lucene-solr/pull/1314]) could be ready to commit > soon (this depends on everyone's feedback of course). The approach is simple > and shows solid search performance, as seen > [here|https://github.com/apache/lucene-solr/pull/1314#issuecomment-608645326]. > I think this API discussion is an important step in moving that > implementation forward. > The goals of the API would be > # Support for storing and retrieving individual float vectors. > # Support for approximate nearest neighbor search -- given a query vector, > return the indexed vectors that are closest to it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14404) CoreContainer level custom requesthandlers
[
https://issues.apache.org/jira/browse/SOLR-14404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147141#comment-17147141
]
Noble Paul edited comment on SOLR-14404 at 6/28/20, 1:09 AM:
-
I've opened a new [https://github.com/apache/lucene-solr/pull/1624]
[~uschindler]
Please review
was (Author: noble.paul):
I've opened a new [PR|[https://github.com/apache/lucene-solr/pull/1624]]
[~uschindler]
Please review
> 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 10m
> Remaining Estimate: 0h
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/plugin}}
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "full.ClassName"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> add a plugin from a package
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "pkgName:full.ClassName" ,
> "version: "1.0"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName" }
> }
> }
> {code}
> example plugin
> {code:java}
> public class MyPlugin {
> private final CoreContainer coreContainer;
> public MyPlugin(CoreContainer coreContainer) {
> this.coreContainer = coreContainer;
> }
> @EndPoint(path = "/myplugin/path1",
> method = METHOD.GET,
> permission = READ)
> public void call(SolrQueryRequest req, SolrQueryResponse rsp){
> rsp.add("myplugin.version", "2.0");
> }
> }
> {code}
> This plugin will be accessible on all nodes at {{/api/myplugin/path1}}. It's
> possible to add more methods at different paths. Ensure that all paths start
> with {{myplugin}} because that is the name in which the plugin is registered
> with. So {{/myplugin/path2}} , {{/myplugin/my/deeply/nested/path}} are all
> valid paths.
> It's possible that the user chooses to register the plugin with a different
> name. In that case , use a template variable as follows in paths
> {{$plugin-name/path1}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14404) CoreContainer level custom requesthandlers
[
https://issues.apache.org/jira/browse/SOLR-14404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147141#comment-17147141
]
Noble Paul commented on SOLR-14404:
---
I've opened a new [PR|[https://github.com/apache/lucene-solr/pull/1624]]
[~uschindler]
Please review
> 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 10m
> Remaining Estimate: 0h
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/plugin}}
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "full.ClassName"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> add a plugin from a package
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "pkgName:full.ClassName" ,
> "version: "1.0"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName" }
> }
> }
> {code}
> example plugin
> {code:java}
> public class MyPlugin {
> private final CoreContainer coreContainer;
> public MyPlugin(CoreContainer coreContainer) {
> this.coreContainer = coreContainer;
> }
> @EndPoint(path = "/myplugin/path1",
> method = METHOD.GET,
> permission = READ)
> public void call(SolrQueryRequest req, SolrQueryResponse rsp){
> rsp.add("myplugin.version", "2.0");
> }
> }
> {code}
> This plugin will be accessible on all nodes at {{/api/myplugin/path1}}. It's
> possible to add more methods at different paths. Ensure that all paths start
> with {{myplugin}} because that is the name in which the plugin is registered
> with. So {{/myplugin/path2}} , {{/myplugin/my/deeply/nested/path}} are all
> valid paths.
> It's possible that the user chooses to register the plugin with a different
> name. In that case , use a template variable as follows in paths
> {{$plugin-name/path1}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul opened a new pull request #1624: use MethodHandles in AnnotatedAPI
noblepaul opened a new pull request #1624: URL: https://github.com/apache/lucene-solr/pull/1624 @uschindler Please review 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-14404) CoreContainer level custom requesthandlers
[
https://issues.apache.org/jira/browse/SOLR-14404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147130#comment-17147130
]
Noble Paul commented on SOLR-14404:
---
Thanks [~uschindler] .
> 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 10m
> Remaining Estimate: 0h
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/plugin}}
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "full.ClassName"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> add a plugin from a package
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "pkgName:full.ClassName" ,
> "version: "1.0"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName" }
> }
> }
> {code}
> example plugin
> {code:java}
> public class MyPlugin {
> private final CoreContainer coreContainer;
> public MyPlugin(CoreContainer coreContainer) {
> this.coreContainer = coreContainer;
> }
> @EndPoint(path = "/myplugin/path1",
> method = METHOD.GET,
> permission = READ)
> public void call(SolrQueryRequest req, SolrQueryResponse rsp){
> rsp.add("myplugin.version", "2.0");
> }
> }
> {code}
> This plugin will be accessible on all nodes at {{/api/myplugin/path1}}. It's
> possible to add more methods at different paths. Ensure that all paths start
> with {{myplugin}} because that is the name in which the plugin is registered
> with. So {{/myplugin/path2}} , {{/myplugin/my/deeply/nested/path}} are all
> valid paths.
> It's possible that the user chooses to register the plugin with a different
> name. In that case , use a template variable as follows in paths
> {{$plugin-name/path1}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on pull request #1623: LUCENE-8962: Merge segments on getReader
mikemccand commented on pull request #1623: URL: https://github.com/apache/lucene-solr/pull/1623#issuecomment-650640435 Wow! This is incredibly simple! Thanks to the clean approach @s1monw worked out for commit-on-merge, awesome! I think tests would exercise this due to `MockRandomMergePolicy`? I'll try beasting :) 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] s1monw commented on pull request #1623: LUCENE-8962: Merge segments on getReader
s1monw commented on pull request #1623: URL: https://github.com/apache/lucene-solr/pull/1623#issuecomment-650638907 @mikemccand @msokolov @msfroh I tried to build the minimal necessary code to enable this feature. I do actually think that the refresh / getReader change is much simpler than the commit part since we don't need to keep a cloned SegmentInfos in sync. I opened this really as a question if it can be that simple? 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] s1monw opened a new pull request #1623: LUCENE-8962: Merge segments on getReader
s1monw opened a new pull request #1623: URL: https://github.com/apache/lucene-solr/pull/1623 Add IndexWriter merge-on-refresh feature to selectively merge small segments on getReader, subject to a configurable timeout, to improve search performance by reducing the number of small segments for searching. 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: LUCENE-9420: update restlet version [DRAFT]
MarcusSorealheis edited a comment on pull request #1622: URL: https://github.com/apache/lucene-solr/pull/1622#issuecomment-650637869 > Need to update gradle build and sha files too :) I just read that I need to update checksums. On it. Thanks for the heads up. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] MarcusSorealheis edited a comment on pull request #1622: LUCENE-9420: update restlet version [DRAFT]
MarcusSorealheis edited a comment on pull request #1622: URL: https://github.com/apache/lucene-solr/pull/1622#issuecomment-650637869 > Need to update gradle build and sha files too :) I just read that I need to update checksums. On it. 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: LUCENE-9420: update restlet version [DRAFT]
MarcusSorealheis commented on pull request #1622: URL: https://github.com/apache/lucene-solr/pull/1622#issuecomment-650637869 > Need to update gradle build and sha files too :) I just read that I need to update checksums. On it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on pull request #1622: LUCENE-9420: update restlet version [DRAFT]
janhoy commented on pull request #1622: URL: https://github.com/apache/lucene-solr/pull/1622#issuecomment-650637615 Need to update gradle build and sha files too :) 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-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14539:
Status: Patch Available (was: Open)
> 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] MarcusSorealheis opened a new pull request #1622: LUCENE-9420: update restlet version
MarcusSorealheis opened a new pull request #1622: URL: https://github.com/apache/lucene-solr/pull/1622 # Description CVEs in current version # Solution Upgrade the version to `2.4.3` # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [ ] I have developed this patch against the `master` branch. - [ ] I have run `ant precommit` and the appropriate test suite. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9420) Restlet Dependency
Marcus Eagan created LUCENE-9420: Summary: Restlet Dependency Key: LUCENE-9420 URL: https://issues.apache.org/jira/browse/LUCENE-9420 Project: Lucene - Core Issue Type: New Feature Components: core/other Reporter: Marcus Eagan I noticed that the Restlet dependency's location was no longer resolving at: https://repo1.maven.org/maven2/org/restlet/jee/org.restlet/2.4.0/org.restlet-2.4.0.jar. Now, of course, I could change it to a location that does resolve or download directly. However, I looking at the changelog I thought that maybe I should raise with the community that it an upgrade might be helpful given the CVEs. I will leave it to the experts as to whether it makes a difference, but here's [the changelog for reference|https://restlet.talend.com/documentation/2.4/changelog]. The Lucene tests passed when I upgraded to 2.4.3 but I'm still digging in. It is very likely that 2.4.1 would be better. I'd leave that, again, to the experts and post my findings. -- 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=17147119#comment-17147119
]
Mikhail Khludnev commented on SOLR-14539:
-
Hi, [~caomanhdat], would you mind to have a look. I want to bring it into 8.6.
> 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] [Updated] (SOLR-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14539:
Attachment: SOLR-14539.patch
Status: Open (was: Open)
> 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] [Updated] (SOLR-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14539:
Description:
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.
was:
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.
> 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
>
> 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] [Updated] (SOLR-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14539:
Description:
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.
was:
It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
Let {{\{!bool .. }...}} repeat {{\{!filters ..}..}} trick resolve parameter
refs to many values. Now if there are many params under the same name it picks
the first one that awkward.
> 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
>
> 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] [Updated] (SOLR-14539) Query DSL: Introducing {!bool excludeTags=foo,bar}
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14539:
Summary: Query DSL: Introducing {!bool excludeTags=foo,bar} (was: Query
DSL {!bool filter=$ref} to resolve multiple param values )
> 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
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> Let {{\{!bool .. }...}} repeat {{\{!filters ..}..}} trick resolve parameter
> refs to many values. Now if there are many params under the same name it
> picks the first one that awkward.
--
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=17147117#comment-17147117
]
Mikhail Khludnev commented on SOLR-14601:
-
{quote}child has only three allowed parameters: parentFilter,childFilter and
limit.
{quote}
I've checked
[https://lucene.apache.org/solr/guide/8_5/transforming-result-documents.html#child-childdoctransformerfactory]
it says that there's fl in child. Has it been changed since it was documented?
[~dsmiley], wdyt?
> 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] [Resolved] (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:all-tabpanel
]
Simon Willnauer resolved LUCENE-8962.
-
Fix Version/s: master (9.0)
Resolution: Fixed
added to 8.6 and master. Thanks everyone here!
> 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 10m
> 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=17147105#comment-17147105
]
ASF subversion and git services commented on LUCENE-8962:
-
Commit 9b1c92809e730a70c1d9bf9e5b65a4b521bddc8b in lucene-solr's branch
refs/heads/branch_8x from Simon Willnauer
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9b1c928 ]
LUCENE-8962: Merge small segments on commit (#1617)
Add IndexWriter merge-on-commit feature to selectively merge small segments on
commit,
subject to a configurable timeout, to improve search performance by reducing
the number of small
segments for searching.
Co-authored-by: Michael Froh
Co-authored-by: Michael Sokolov
Co-authored-by: Mike McCandless
> 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 10m
> 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] [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=17147101#comment-17147101
]
Thomas Taroni edited comment on SOLR-14601 at 6/27/20, 8:34 PM:
Have checked that, it looks not that this is working.
child has only three allowed parameters: parentFilter,childFilter and limit.
Have now investigated the Problem a bit more deeper. It's some kind of
recursion.
In ChildDocTransformerFactory the variable childReturnFields also includes the
other augmenter queries like customer:[subquery] because it picks the full "fl"
parameter. It calls then the SolrReturnFields with that. Inside the
SolrReturnFields its adding all the Augementers in a for loop for all the
fiels. It means if [child] is processed the customer:[subquery] is also
processed. If then the customer:[subquery] will be processed by the
SubQueryAugmenterFactory the field customer:[subquery] is already there. This
ends up then in the "is duplicate" Exception.
In my Opinion the ChildDocTransformerFactory should not process things like
[subquery] or [shard] or the SubQueryAugmenterFactory should not check that for
duplicates.
I dont really now the exactly reason why in ChildDocTransformerFactory the
full "fl" is processed and not only the "[child]" fields.
Have forked the Project to: [https://github.com/phoenix-systems/lucene-solr]
and done a short hack, that solves for us the Problem.
Commit:
[https://github.com/phoenix-systems/lucene-solr/commit/5ce0461ae5da6cf226f435d7e8837132fb045c9d]
But i think the better Solution is to change the ChildDocTransformerFactory.
was (Author: thomas taroni):
Have checked that, it looks not that this is working.
child has only three allowed parameters: parentFilter,childFilter and limit.
Have now investigated the Problem a bit more deeper. It's some kind of
recursion.
In ChildDocTransformerFactory the variable childReturnFields also includes the
other augmenter queries like customer:[subquery] because it picks the full "fl"
parameter. It calls then the SolrReturnFields with that. Inside the
SolrReturnFields its adding all the Augementers in a for loop for all the
fiels. It means if [child] is processed the customer:[subquery] is also
processed. If then the customer:[subquery] will be processed by the
SubQueryAugmenterFactory the field customer:[subquery] is already there. This
ends up then in the "is duplicate" Exception.
In my Opinion the ChildDocTransformerFactory should not process things like
[subquery] or [shard] or the SubQueryAugmenterFactory should not check that for
duplicates.
I dont really now the exactly reason why in ChildDocTransformerFactory the full
"fl" is processed and not only the "[child]" fields.
Have simpli forked the Project to:
[https://github.com/phoenix-systems/lucene-solr] and done a short hack, that
solves for us the Problem.
Commit:
[https://github.com/phoenix-systems/lucene-solr/commit/5ce0461ae5da6cf226f435d7e8837132fb045c9d]
But i think the better Solution is to change the ChildDocTransformerFactory.
> 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
[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=17147100#comment-17147100
]
ASF subversion and git services commented on LUCENE-8962:
-
Commit fb3c5d23537c650f7c0ba020f5e08f128e0a9b5a in lucene-solr's branch
refs/heads/master from Simon Willnauer
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fb3c5d2 ]
LUCENE-8962: Fix changes entry. This feature is added to 8.6
> 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: 8.6
>
> Attachments: LUCENE-8962_demo.png, failed-tests.patch,
> failure_log.txt, test.diff
>
> Time Spent: 22h 10m
> 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] (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=17147101#comment-17147101
]
Thomas Taroni commented on SOLR-14601:
--
Have checked that, it looks not that this is working.
child has only three allowed parameters: parentFilter,childFilter and limit.
Have now investigated the Problem a bit more deeper. It's some kind of
recursion.
In ChildDocTransformerFactory the variable childReturnFields also includes the
other augmenter queries like customer:[subquery] because it picks the full "fl"
parameter. It calls then the SolrReturnFields with that. Inside the
SolrReturnFields its adding all the Augementers in a for loop for all the
fiels. It means if [child] is processed the customer:[subquery] is also
processed. If then the customer:[subquery] will be processed by the
SubQueryAugmenterFactory the field customer:[subquery] is already there. This
ends up then in the "is duplicate" Exception.
In my Opinion the ChildDocTransformerFactory should not process things like
[subquery] or [shard] or the SubQueryAugmenterFactory should not check that for
duplicates.
I dont really now the exactly reason why in ChildDocTransformerFactory the full
"fl" is processed and not only the "[child]" fields.
Have simpli forked the Project to:
[https://github.com/phoenix-systems/lucene-solr] and done a short hack, that
solves for us the Problem.
Commit:
[https://github.com/phoenix-systems/lucene-solr/commit/5ce0461ae5da6cf226f435d7e8837132fb045c9d]
But i think the better Solution is to change the ChildDocTransformerFactory.
> 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] (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=17147099#comment-17147099
]
ASF subversion and git services commented on LUCENE-8962:
-
Commit 7f352a96659b4d304ae3ef0c7a1b62784ce2a406 in lucene-solr's branch
refs/heads/master from Simon Willnauer
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7f352a9 ]
LUCENE-8962: Merge small segments on commit (#1617)
Add IndexWriter merge-on-commit feature to selectively merge small segments on
commit,
subject to a configurable timeout, to improve search performance by reducing
the number of small
segments for searching.
Co-authored-by: Michael Froh
Co-authored-by: Michael Sokolov
Co-authored-by: Mike McCandless
> 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: 8.6
>
> Attachments: LUCENE-8962_demo.png, failed-tests.patch,
> failure_log.txt, test.diff
>
> Time Spent: 22h 10m
> 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
[GitHub] [lucene-solr] s1monw commented on pull request #1617: LUCENE-8962: Merge small segments on commit
s1monw commented on pull request #1617: URL: https://github.com/apache/lucene-solr/pull/1617#issuecomment-650619003 merged into master. Thanks everybody involved!! 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] s1monw merged pull request #1617: LUCENE-8962: Merge small segments on commit
s1monw merged pull request #1617: URL: https://github.com/apache/lucene-solr/pull/1617 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-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=17147076#comment-17147076
]
Mikhail Khludnev commented on SOLR-14601:
-
Hi, [~Thomas Taroni], is it possible to specify {{fl}} inside of {{[child
fl...}}] ?
> 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=17147046#comment-17147046 ] ASF subversion and git services commented on SOLR-14588: Commit 698c9cce6c661738ef6ada2135f09646cae3a4b9 in lucene-solr's branch refs/heads/master from Atri Sharma [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=698c9cc ] Revert "CHANGES.txt entry for SOLR-14588" This reverts commit aba7a6159465abef12c47934c8e77e34fe197b50. > 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 10m > 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] [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=17147044#comment-17147044 ] ASF subversion and git services commented on SOLR-14588: Commit 45763b65317df3caf182b8a4d7a00b80478baa58 in lucene-solr's branch refs/heads/master from Atri Sharma [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=45763b6 ] Revert "SOLR-14588: Follow Up Fixes and Documentation (#1615)" This reverts commit 74ac97e40252a8808c882a22b25181fa999af276. > 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 10m > 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] [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=17147045#comment-17147045 ] ASF subversion and git services commented on SOLR-14588: Commit 529faf124127c8790e64c548598a14788602357c in lucene-solr's branch refs/heads/master from Atri Sharma [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=529faf1 ] Revert "SOLR-14588: Implement Circuit Breakers (#1606)" This reverts commit 7b54902f681542ae49293df9bc9e5ac1694d465c. > 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 10m > 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] [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=17147043#comment-17147043 ] Atri Sharma commented on SOLR-14588: Ok, based on the discussion here, I am reverting this commit and will raise another PR tomorrow afternoon my time. [~ab][~dsmiley][~mdrob][~erickerickson] Requesting you to please take a look so that we have a holistic view and a consensus on the feature. Thanks everyone for taking a look. > 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 10m > 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] [Commented] (SOLR-10742) SolrCores.getNamesForCore is quite inefficient and blocks other core operations
[
https://issues.apache.org/jira/browse/SOLR-10742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147040#comment-17147040
]
Erick Erickson commented on SOLR-10742:
---
I played around a bit with making a wrapper class that maintains a parallel
map>. That reduces the getNamesForCore to
{code}
Set ret = namesForCore.get(core);
return ret == null ? Collections.emptySet() : ret;
{code}
Which should be much more efficient at the cost that every modification of the
cores map requires that we also maintain the parallel "inverted" structure
Map, Set>. I don't think it'd be much extra work in terms of
CPU though.
It's technically do-able, but... it adds complexity for something I'm still
unsure is needed. The method in question is marked Experimental so could
theoretically be removed without violating any contracts.
It doesn't even break back-compat. If anyone is implementing their own
TransientSolrCoreCache with a LinkedHashMap, they'd have to make a small code
change to automatically get this optimization. If they didn't make the change,
it would continue to work as before.
If they're using something other than LinkedHashMap, they'd have to implement
something similar in their plugin.
I haven't yet written tests for it, all I'm doing here is getting a feel for
what it would take. And I really don't like adding the complexity.
I'll wait for Andrzej to weigh in about whether we can do something else here
before pursuing.
> SolrCores.getNamesForCore is quite inefficient and blocks other core
> operations
> ---
>
> Key: SOLR-10742
> URL: https://issues.apache.org/jira/browse/SOLR-10742
> Project: Solr
> Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> SolrCores.getNamesForCore iterates through all the cores to find all the
> aliases to this core. It does this in a synchronized block which blocks other
> core operations.
> For installations with many cores this can be a performance issue. I'm not
> sure it makes sense to do it this way anyway, perhaps SolrCore should have a
> list of its current aliases and we can be more efficient about this? Or
> otherwise get this information in a less heavy-weight fashion?
> I'm assigning this to myself to keep track of it, but anyone who wants to
> grab it please feel free.
--
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=17147037#comment-17147037 ] Erick Erickson commented on SOLR-14588: --- Even with more review, it should probably wait until the 8.6 branch is cut and deliver in 8.7... > 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 10m > 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] [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=17147035#comment-17147035 ] Andrzej Bialecki commented on SOLR-14588: - I agree. We need a much better analysis of the impact of this feature, since it affects the most common usage - eg. performance impact, new failure modes, recovery on the client / server side, etc. And we need solid end-user documentation that clearly explains the config params and the tradeoffs. > 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 10m > 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] [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=17147027#comment-17147027 ] David Smiley commented on SOLR-14588: - I think a feature of this nature should get more peer review before committing. > 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 10m > 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] [Resolved] (SOLR-14602) Filter Classes not working in 8.5.2 it was working in 7.5.0
[ https://issues.apache.org/jira/browse/SOLR-14602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-14602. --- Resolution: Invalid First, Please raise questions like this on the user's list, we try to reserve JIRAs for known bugs/enhancements rather than usage questions. See: http://lucene.apache.org/solr/community.html#mailing-lists-irc there are links to both Lucene and Solr mailing lists there. A _lot_ more people will see your question on that list and may be able to help more quickly. Second, there's not enough information here to even speculate. "we have custom code that doesn't work any more" gives no clues. You might want to review: https://wiki.apache.org/solr/UsingMailingLists If it's determined that this really is a code issue or enhancement to Lucene or Solr and not a configuration/usage problem, we can raise a new JIRA or reopen this one. > Filter Classes not working in 8.5.2 it was working in 7.5.0 > --- > > Key: SOLR-14602 > URL: https://issues.apache.org/jira/browse/SOLR-14602 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.5.2 >Reporter: Ashok Mahendran >Priority: Blocker > > Hi Team, > > We are using some custom filters in our solr using HttpServlet. > When I hit /createcore it was working in 7.5.0 version but in new 8.5.2 it > is not invoking Solr not invoking that filter. > > Is there anything changed in solr 8.5.2 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14404) CoreContainer level custom requesthandlers
[
https://issues.apache.org/jira/browse/SOLR-14404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147013#comment-17147013
]
Uwe Schindler commented on SOLR-14404:
--
Reflection is not the issue. The issue is that it uses getDeclaredMethods()
which returns all methods in the class.
IMHO, also for Performance reasons the whole thing should use MethodHandles
with a public lookup to ensure only public methods are found. This also moves
the linking phase of the API to the annotation lookups and the calls to the API
methods are then directly linked. All errors caused by security issues are
catched early, when the {{AnnotatedApi#Cmd}} are instantiated. I would
implement it like that:
- Lookup all methods like your do currently, but also check that only public
methods are found
- Convert them to MethodHandle using a public Lookup ({{Lookup.publicLookup()}}
with {{unreflectMethod}} on instantiation of the {{Cmd}} object
- At runtime only call {{invoke()}} (ideally {{invokeExact()}} with correctly
casted types, but that might not be possible with dynamic stuff). This then
gets inlined by Hotspot and will be faster, especially when APIs are invoked
all the time.
> 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 10m
> Remaining Estimate: 0h
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/plugin}}
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "full.ClassName"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> add a plugin from a package
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "pkgName:full.ClassName" ,
> "version: "1.0"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName" }
> }
> }
> {code}
> example plugin
> {code:java}
> public class MyPlugin {
> private final CoreContainer coreContainer;
> public MyPlugin(CoreContainer coreContainer) {
> this.coreContainer = coreContainer;
> }
> @EndPoint(path = "/myplugin/path1",
> method = METHOD.GET,
> permission = READ)
> public void call(SolrQueryRequest req, SolrQueryResponse rsp){
> rsp.add("myplugin.version", "2.0");
> }
> }
> {code}
> This plugin will be accessible on all nodes at {{/api/myplugin/path1}}. It's
> possible to add more methods at different paths. Ensure that all paths start
> with {{myplugin}} because that is the name in which the plugin is registered
> with. So {{/myplugin/path2}} , {{/myplugin/my/deeply/nested/path}} are all
> valid paths.
> It's possible that the user chooses to register the plugin with a different
> name. In that case , use a template variable as follows in paths
> {{$plugin-name/path1}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146990#comment-17146990 ] Ilan Ginzburg commented on SOLR-14066: -- Side note: I have recently completely rewritten test TestZKPropertiesWriter in commit [https://github.com/apache/lucene-solr/commit/62dd94d26b054f3fe1032ab3096db1148e59ed57] This only went to Solr 9.0. I hope if DIH is deprecated in 8x that this work is not lost (it will be needed for this test in 9.0 regardless of where DIH and the test sit). > Deprecate DIH > - > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 40m > Remaining Estimate: 0h > > DataImportHandler has outlived its utility. DIH doesn't need to remain inside > Solr anymore. Plan is to deprecate DIH in 8.5, remove from 9.0. Also, work on > handing it off to volunteers in the community (so far, [~rohitcse] has > volunteered to maintain it). > Update: A community supported version of DIH would be > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14597) Advanced Query Parser
[ https://issues.apache.org/jira/browse/SOLR-14597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Nibeck updated SOLR-14597: --- Description: This JIRA ticket tracks the progress of SIP-9, the Advanced Query Parser that is being donated by the Library of Congress. Full description of the feature can be found on the SIP Page. [https://cwiki.apache.org/confluence/display/SOLR/SIP-9+Advanced+Query+Parser] Briefly, this parser provides a comprehensive syntax for users that use search on a daily basis. It also reserves a smaller set of punctuators than other parsers. This facilitates easier handling of acronyms and punctuated patterns with meaning ( such as C++ or 401(k) ). The new syntax opens up some advanced features while also preventing access to arbitrary features via local parameters. This parser will be safe for accepting user queries directly with minimal pre-parsing, but for use cases beyond it's established features alternate query paths (using other parsers) will need to be supplied. The code drop is being prepared and will be supplied as soon as we receive guidance from the PMC regarding the proper process. Given that the Library already has a signed CCLA we need to understand which of these (or other processes) apply: [http://incubator.apache.org/ip-clearance/ip-clearance-template.html] and [https://www.apache.org/licenses/contributor-agreements.html#grants] was: This JIRA ticket tracks the progress of SIP-, the Advanced Query Parser that is being donated by the Library of Congress. Full description of the feature can be found on the SIP Page. [https://cwiki.apache.org/confluence/display/SOLR/SIP-9+Advanced+Query+Parser] Briefly, this parser provides a comprehensive syntax for users that use search on a daily basis. It also reserves a smaller set of punctuators than other parsers. This facilitates easier handling of acronyms and punctuated patterns with meaning ( such as C++ or 401(k) ). The new syntax opens up some advanced features while also preventing access to arbitrary features via local parameters. This parser will be safe for accepting user queries directly with minimal pre-parsing, but for use cases beyond it's established features alternate query paths (using other parsers) will need to be supplied. The code drop is being prepared and will be supplied as soon as we receive guidance from the PMC regarding the proper process. Given that the Library already has a signed CCLA we need to understand which of these (or other processes) apply: [http://incubator.apache.org/ip-clearance/ip-clearance-template.html] and [https://www.apache.org/licenses/contributor-agreements.html#grants] > Advanced Query Parser > - > > Key: SOLR-14597 > URL: https://issues.apache.org/jira/browse/SOLR-14597 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Affects Versions: 8.6 >Reporter: Mike Nibeck >Assignee: Gus Heck >Priority: Major > > This JIRA ticket tracks the progress of SIP-9, the Advanced Query Parser that > is being donated by the Library of Congress. Full description of the feature > can be found on the SIP Page. > [https://cwiki.apache.org/confluence/display/SOLR/SIP-9+Advanced+Query+Parser] > Briefly, this parser provides a comprehensive syntax for users that use > search on a daily basis. It also reserves a smaller set of punctuators than > other parsers. This facilitates easier handling of acronyms and punctuated > patterns with meaning ( such as C++ or 401(k) ). The new syntax opens up some > advanced features while also preventing access to arbitrary features via > local parameters. This parser will be safe for accepting user queries > directly with minimal pre-parsing, but for use cases beyond it's established > features alternate query paths (using other parsers) will need to be supplied. > The code drop is being prepared and will be supplied as soon as we receive > guidance from the PMC regarding the proper process. Given that the Library > already has a signed CCLA we need to understand which of these (or other > processes) apply: > [http://incubator.apache.org/ip-clearance/ip-clearance-template.html] > and > [https://www.apache.org/licenses/contributor-agreements.html#grants] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14597) Advanced Query Parser
[ https://issues.apache.org/jira/browse/SOLR-14597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Nibeck updated SOLR-14597: --- Description: This JIRA ticket tracks the progress of SIP-, the Advanced Query Parser that is being donated by the Library of Congress. Full description of the feature can be found on the SIP Page. [https://cwiki.apache.org/confluence/display/SOLR/SIP-9+Advanced+Query+Parser] Briefly, this parser provides a comprehensive syntax for users that use search on a daily basis. It also reserves a smaller set of punctuators than other parsers. This facilitates easier handling of acronyms and punctuated patterns with meaning ( such as C++ or 401(k) ). The new syntax opens up some advanced features while also preventing access to arbitrary features via local parameters. This parser will be safe for accepting user queries directly with minimal pre-parsing, but for use cases beyond it's established features alternate query paths (using other parsers) will need to be supplied. The code drop is being prepared and will be supplied as soon as we receive guidance from the PMC regarding the proper process. Given that the Library already has a signed CCLA we need to understand which of these (or other processes) apply: [http://incubator.apache.org/ip-clearance/ip-clearance-template.html] and [https://www.apache.org/licenses/contributor-agreements.html#grants] was: This JIRA ticket tracks the progress of SIP-, the Advanced Query Parser that is being donated by the Library of Congress. Full description of the feature can be found on the SIP Page. Briefly, this parser provides a comprehensive syntax for users that use search on a daily basis. It also reserves a smaller set of punctuators than other parsers. This facilitates easier handling of acronyms and punctuated patterns with meaning ( such as C++ or 401(k) ). The new syntax opens up some advanced features while also preventing access to arbitrary features via local parameters. This parser will be safe for accepting user queries directly with minimal pre-parsing, but for use cases beyond it's established features alternate query paths (using other parsers) will need to be supplied. The code drop is being prepared and will be supplied as soon as we receive guidance from the PMC regarding the proper process. Given that the Library already has a signed CCLA we need to understand which of these (or other processes) apply: [http://incubator.apache.org/ip-clearance/ip-clearance-template.html] and [https://www.apache.org/licenses/contributor-agreements.html#grants] > Advanced Query Parser > - > > Key: SOLR-14597 > URL: https://issues.apache.org/jira/browse/SOLR-14597 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Affects Versions: 8.6 >Reporter: Mike Nibeck >Assignee: Gus Heck >Priority: Major > > This JIRA ticket tracks the progress of SIP-, the Advanced Query Parser that > is being donated by the Library of Congress. Full description of the feature > can be found on the SIP Page. > [https://cwiki.apache.org/confluence/display/SOLR/SIP-9+Advanced+Query+Parser] > Briefly, this parser provides a comprehensive syntax for users that use > search on a daily basis. It also reserves a smaller set of punctuators than > other parsers. This facilitates easier handling of acronyms and punctuated > patterns with meaning ( such as C++ or 401(k) ). The new syntax opens up some > advanced features while also preventing access to arbitrary features via > local parameters. This parser will be safe for accepting user queries > directly with minimal pre-parsing, but for use cases beyond it's established > features alternate query paths (using other parsers) will need to be supplied. > The code drop is being prepared and will be supplied as soon as we receive > guidance from the PMC regarding the proper process. Given that the Library > already has a signed CCLA we need to understand which of these (or other > processes) apply: > [http://incubator.apache.org/ip-clearance/ip-clearance-template.html] > and > [https://www.apache.org/licenses/contributor-agreements.html#grants] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14602) Filter Classes not working in 8.5.2 it was working in 7.5.0
Ashok Mahendran created SOLR-14602: -- Summary: Filter Classes not working in 8.5.2 it was working in 7.5.0 Key: SOLR-14602 URL: https://issues.apache.org/jira/browse/SOLR-14602 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 8.5.2 Reporter: Ashok Mahendran Hi Team, We are using some custom filters in our solr using HttpServlet. When I hit /createcore it was working in 7.5.0 version but in new 8.5.2 it is not invoking Solr not invoking that filter. Is there anything changed in solr 8.5.2 -- 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-10742) SolrCores.getNamesForCore is quite inefficient and blocks other core operations
[ https://issues.apache.org/jira/browse/SOLR-10742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146961#comment-17146961 ] Erick Erickson commented on SOLR-10742: --- Not quite sure what you're thinking might be removed. The call from metrics or getNamesForCore? The latter is public in CoreContainer unfortunately. I'm starting to wonder myself what the point of that method is. It's been there since I made transient cores pluggable. Maybe Andrzej has a clue. If it's OK for Solr to, say, just use the core name and _not_ report on all the aliases, perhaps we can just not use it at all in Solr and add some docs about how "if your custom implementation needs this, make it efficient". [~ab] Do you know why metrics needs a list of all the aliases a particular core is referenced under? More to the point, if the call to getNamesForCore in SolrCore.initializeMetrics just changed to get the name from "this", would that be bad? It'd certainly be a change but IDK whether it'd be impactful. > SolrCores.getNamesForCore is quite inefficient and blocks other core > operations > --- > > Key: SOLR-10742 > URL: https://issues.apache.org/jira/browse/SOLR-10742 > Project: Solr > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > SolrCores.getNamesForCore iterates through all the cores to find all the > aliases to this core. It does this in a synchronized block which blocks other > core operations. > For installations with many cores this can be a performance issue. I'm not > sure it makes sense to do it this way anyway, perhaps SolrCore should have a > list of its current aliases and we can be more efficient about this? Or > otherwise get this information in a less heavy-weight fashion? > I'm assigning this to myself to keep track of it, but anyone who wants to > grab it please feel free. -- 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-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146948#comment-17146948
]
Noble Paul commented on SOLR-14598:
---
Almost every modem Java framework uses annotation reflection. I find them
appealing and useful too.
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
> Attachments: SOLR-14598.patch
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhat
[jira] [Commented] (SOLR-14549) Listing of Files in a Directory on Solr Admin is Broken
[ https://issues.apache.org/jira/browse/SOLR-14549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146943#comment-17146943 ] David Eric Pugh commented on SOLR-14549: I spent some time poking at this some more, tried upgrading to the latest jstree version, but no luck. I did confirm that the API responses are the same in 8.4.1 and 8.5.0. [~krisden] maybe you could come up with some pointers? > Listing of Files in a Directory on Solr Admin is Broken > --- > > Key: SOLR-14549 > URL: https://issues.apache.org/jira/browse/SOLR-14549 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: master (9.0), 8.5.1, 8.5.2 >Reporter: David Eric Pugh >Priority: Major > Attachments: Screenshot at Jun 09 07-40-06.png > > > The Admin interface for showing files only lets you see the top level files, > no nested files in a directory: > http://localhost:8983/solr/#/gettingstarted/files?file=lang%2F > Choosing a nested directory doesn't generate any console errors, but the tree > doesn't open. > I believe this was introduced during SOLR-14209 upgrade in Jquery. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146937#comment-17146937
]
Ishan Chattopadhyaya edited comment on SOLR-14598 at 6/27/20, 12:41 PM:
How to implement annotations without using reflection? How is doing so a
security threat?
was (Author: ichattopadhyaya):
How to implement annotations without using reflection?
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
> Attachments: SOLR-14598.patch
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jetty.u
[jira] [Commented] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146937#comment-17146937
]
Ishan Chattopadhyaya commented on SOLR-14598:
-
How to implement annotations without using reflection?
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
> Attachments: SOLR-14598.patch
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
> a
[jira] [Updated] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya updated SOLR-14598:
Description:
With SOLR-14404, after few requests (around 10 requests), every request is
failing with:
{code}
2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
null:org.apache.solr.common.SolrException:
java.security.AccessControlException: access denied
("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
at
org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
at
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
at
org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:500)
at
org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
at
org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.security.AccessControlException: access denied
("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
at
java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at
java.base/java.security.AccessController.checkPermission(AccessController.java:897)
at
[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=17146930#comment-17146930
]
ASF subversion and git services commented on SOLR-14404:
Commit 2522292b04aed2a776d1d2b67a326e3fdee8b304 in lucene-solr's branch
refs/heads/branch_8x from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2522292 ]
Revert "SOLR-14598: Granting reflection access for using annotations in
SOLR-14404"
This reverts commit e6ffa8e9e263a0251202f2ca1bbd3a47cc8c2727.
> 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 10m
> Remaining Estimate: 0h
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/plugin}}
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "full.ClassName"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> add a plugin from a package
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "pkgName:full.ClassName" ,
> "version: "1.0"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName" }
> }
> }
> {code}
> example plugin
> {code:java}
> public class MyPlugin {
> private final CoreContainer coreContainer;
> public MyPlugin(CoreContainer coreContainer) {
> this.coreContainer = coreContainer;
> }
> @EndPoint(path = "/myplugin/path1",
> method = METHOD.GET,
> permission = READ)
> public void call(SolrQueryRequest req, SolrQueryResponse rsp){
> rsp.add("myplugin.version", "2.0");
> }
> }
> {code}
> This plugin will be accessible on all nodes at {{/api/myplugin/path1}}. It's
> possible to add more methods at different paths. Ensure that all paths start
> with {{myplugin}} because that is the name in which the plugin is registered
> with. So {{/myplugin/path2}} , {{/myplugin/my/deeply/nested/path}} are all
> valid paths.
> It's possible that the user chooses to register the plugin with a different
> name. In that case , use a template variable as follows in paths
> {{$plugin-name/path1}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146929#comment-17146929
]
ASF subversion and git services commented on SOLR-14598:
Commit 2522292b04aed2a776d1d2b67a326e3fdee8b304 in lucene-solr's branch
refs/heads/branch_8x from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2522292 ]
Revert "SOLR-14598: Granting reflection access for using annotations in
SOLR-14404"
This reverts commit e6ffa8e9e263a0251202f2ca1bbd3a47cc8c2727.
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
> Attachments: SOLR-14598.patch
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
>
[jira] [Commented] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146927#comment-17146927
]
ASF subversion and git services commented on SOLR-14598:
Commit 20f39b9c62708e5440f8c8a271f9f9f7b5a00385 in lucene-solr's branch
refs/heads/master from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=20f39b9 ]
Revert "SOLR-14598: Granting reflection access for using annotations in
SOLR-14404"
This reverts commit e6ffa8e9e263a0251202f2ca1bbd3a47cc8c2727.
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
> Attachments: SOLR-14598.patch
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
[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=17146928#comment-17146928
]
ASF subversion and git services commented on SOLR-14404:
Commit 20f39b9c62708e5440f8c8a271f9f9f7b5a00385 in lucene-solr's branch
refs/heads/master from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=20f39b9 ]
Revert "SOLR-14598: Granting reflection access for using annotations in
SOLR-14404"
This reverts commit e6ffa8e9e263a0251202f2ca1bbd3a47cc8c2727.
> 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 10m
> Remaining Estimate: 0h
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/plugin}}
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "full.ClassName"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> add a plugin from a package
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "pkgName:full.ClassName" ,
> "version: "1.0"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName" }
> }
> }
> {code}
> example plugin
> {code:java}
> public class MyPlugin {
> private final CoreContainer coreContainer;
> public MyPlugin(CoreContainer coreContainer) {
> this.coreContainer = coreContainer;
> }
> @EndPoint(path = "/myplugin/path1",
> method = METHOD.GET,
> permission = READ)
> public void call(SolrQueryRequest req, SolrQueryResponse rsp){
> rsp.add("myplugin.version", "2.0");
> }
> }
> {code}
> This plugin will be accessible on all nodes at {{/api/myplugin/path1}}. It's
> possible to add more methods at different paths. Ensure that all paths start
> with {{myplugin}} because that is the name in which the plugin is registered
> with. So {{/myplugin/path2}} , {{/myplugin/my/deeply/nested/path}} are all
> valid paths.
> It's possible that the user chooses to register the plugin with a different
> name. In that case , use a template variable as follows in paths
> {{$plugin-name/path1}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146924#comment-17146924
]
Ishan Chattopadhyaya commented on SOLR-14598:
-
For reference, this is the offending code:
https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/api/AnnotatedApi.java#L178
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
> Attachments: SOLR-14598.patch
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
>
[jira] [Commented] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146921#comment-17146921
]
Ishan Chattopadhyaya commented on SOLR-14598:
-
Thanks [~rcmuir]. I'm making this a blocker for SOLR-14404, which should also
be reverted unless we find a fix for this.
Any suggestions on how this could've been done better? [~noble.paul], any ideas?
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
> Attachments: SOLR-14598.patch
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYo
[jira] [Commented] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146922#comment-17146922
]
Noble Paul commented on SOLR-14598:
---
What's wrong with reflection? Can you be more clear?
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
> Attachments: SOLR-14598.patch
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
> at
> org.eclipse.jetty
[jira] [Commented] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146917#comment-17146917
]
Robert Muir commented on SOLR-14598:
I've reopened the issue as this is really the wrong way. If SOLR does things
this way (add shitty code, then blame security manager, and just add
exceptions), then security manager will be useless in 6 months time.
The actual code needs to be fixed.
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
> Attachments: SOLR-14598.patch
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jett
[jira] [Reopened] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir reopened SOLR-14598:
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
> Attachments: SOLR-14598.patch
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
> at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375)
> at
> org.e
[jira] [Commented] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146913#comment-17146913
]
Robert Muir commented on SOLR-14598:
The change here should be reverted: you should never grant access to this
package like this!
The issue should be reworded: securitymanager didn't cause anything, someone
wrote garbage reflection code, and that is what needs to be fixed.
seems like this is an educational issue...
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
> Attachments: SOLR-14598.patch
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
[jira] [Updated] (SOLR-14601) Using [child] and [subquery] DocTransformer / FieldList
[
https://issues.apache.org/jira/browse/SOLR-14601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Taroni updated SOLR-14601:
-
Description:
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
was:
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]
> 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 <
[jira] [Created] (SOLR-14601) Using [child] and [subquery] DocTransformer / FieldList
Thomas Taroni created SOLR-14601:
Summary: 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: 8.5.2, master (9.0)
Environment: Docker Container 8.5.2 from Docker Hub
Already existing in 9.0.0
Reporter: Thomas Taroni
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]
--
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-10229) See what it would take to shift many of our one-off schemas used for testing to managed schema and construct them as part of the tests
[ https://issues.apache.org/jira/browse/SOLR-10229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-10229: -- Issue Type: Wish (was: Improvement) > See what it would take to shift many of our one-off schemas used for testing > to managed schema and construct them as part of the tests > -- > > Key: SOLR-10229 > URL: https://issues.apache.org/jira/browse/SOLR-10229 > Project: Solr > Issue Type: Wish >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-10229-straw-man.patch, SOLR-10229.patch, > SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, > SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch > > > The test schema files are intimidating. There are about a zillion of them, > and making a change in any of them risks breaking some _other_ test. That > leaves people three choices: > 1> add what they need to some existing schema. Which makes schemas bigger and > bigger and bigger. > 2> create a new schema file, adding to the proliferation thereof. > 3> Look through all the existing tests to see if they have something that > works. > The recent work on LUCENE-7705 is a case in point. We're adding a maxLen > parameter to some tokenizers. Putting those parameters into any of the > existing schemas, especially to test < 255 char tokens is virtually > guaranteed to break other tests, so the only safe thing to do is make another > schema file. Adding to the multiplication of files. > As part of SOLR-5260 I tried creating the schema on the fly rather than > creating a new static schema file and it's not hard. WDYT about making this > into some better thought-out utility? > At present, this is pretty fuzzy, I wanted to get some reactions before > putting much effort into it. I expect that the utility methods would > eventually get a bunch of canned types. It's reasonably straightforward for > primitive types, if lengthy. But when you get into solr.TextField-based types > it gets less straight-forward. > We could manage to just move the "intimidation" from the plethora of schema > files to a zillion fieldTypes in the utility to choose from... > Also, forcing every test to define the fields up-front is arguably less > convenient than just having _some_ canned schemas we can use. And erroneous > schemas to test failure modes are probably not very good fits for any such > framework. > [~steve_rowe] and [~hossman_luc...@fucit.org] in particular might have > something to say. -- 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] [Assigned] (SOLR-10229) See what it would take to shift many of our one-off schemas used for testing to managed schema and construct them as part of the tests
[ https://issues.apache.org/jira/browse/SOLR-10229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson reassigned SOLR-10229: - Assignee: (was: Erick Erickson) > See what it would take to shift many of our one-off schemas used for testing > to managed schema and construct them as part of the tests > -- > > Key: SOLR-10229 > URL: https://issues.apache.org/jira/browse/SOLR-10229 > Project: Solr > Issue Type: Wish >Reporter: Erick Erickson >Priority: Minor > Attachments: SOLR-10229-straw-man.patch, SOLR-10229.patch, > SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, > SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch > > > The test schema files are intimidating. There are about a zillion of them, > and making a change in any of them risks breaking some _other_ test. That > leaves people three choices: > 1> add what they need to some existing schema. Which makes schemas bigger and > bigger and bigger. > 2> create a new schema file, adding to the proliferation thereof. > 3> Look through all the existing tests to see if they have something that > works. > The recent work on LUCENE-7705 is a case in point. We're adding a maxLen > parameter to some tokenizers. Putting those parameters into any of the > existing schemas, especially to test < 255 char tokens is virtually > guaranteed to break other tests, so the only safe thing to do is make another > schema file. Adding to the multiplication of files. > As part of SOLR-5260 I tried creating the schema on the fly rather than > creating a new static schema file and it's not hard. WDYT about making this > into some better thought-out utility? > At present, this is pretty fuzzy, I wanted to get some reactions before > putting much effort into it. I expect that the utility methods would > eventually get a bunch of canned types. It's reasonably straightforward for > primitive types, if lengthy. But when you get into solr.TextField-based types > it gets less straight-forward. > We could manage to just move the "intimidation" from the plethora of schema > files to a zillion fieldTypes in the utility to choose from... > Also, forcing every test to define the fields up-front is arguably less > convenient than just having _some_ canned schemas we can use. And erroneous > schemas to test failure modes are probably not very good fits for any such > framework. > [~steve_rowe] and [~hossman_luc...@fucit.org] in particular might have > something to say. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14600) Download package jars from external locations
[ https://issues.apache.org/jira/browse/SOLR-14600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya resolved SOLR-14600. - Fix Version/s: (was: 8.6) Resolution: Not A Problem Thanks for the confirmation, [~kezhenxu94]. > Download package jars from external locations > - > > Key: SOLR-14600 > URL: https://issues.apache.org/jira/browse/SOLR-14600 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Blocker > > Currently, artifacts for a package should be co-located with the > repository.json (and publickey.der). However, as [~kezhenxu94] brought up, it > would be nice to have jars hosted via Github released artifacts. In such a > case, the repository.json will include URLs to download the jars from. -- 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-14600) Download package jars from external locations
[ https://issues.apache.org/jira/browse/SOLR-14600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146889#comment-17146889 ] Zhenxu Ke commented on SOLR-14600: -- https://github.com/yasa-org/yasa/blob/master/repo/repository.json > Download package jars from external locations > - > > Key: SOLR-14600 > URL: https://issues.apache.org/jira/browse/SOLR-14600 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > > Currently, artifacts for a package should be co-located with the > repository.json (and publickey.der). However, as [~kezhenxu94] brought up, it > would be nice to have jars hosted via Github released artifacts. In such a > case, the repository.json will include URLs to download the jars from. -- 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-14600) Download package jars from external locations
[ https://issues.apache.org/jira/browse/SOLR-14600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146888#comment-17146888 ] Zhenxu Ke commented on SOLR-14600: -- Downloading jars from external locations seems to work at the moment, actually I’m installing my plugin YASA in that way, https://github.com/yasa-org/yasa/tree/v0.5.1#solr-plugin-recommended > Download package jars from external locations > - > > Key: SOLR-14600 > URL: https://issues.apache.org/jira/browse/SOLR-14600 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > > Currently, artifacts for a package should be co-located with the > repository.json (and publickey.der). However, as [~kezhenxu94] brought up, it > would be nice to have jars hosted via Github released artifacts. In such a > case, the repository.json will include URLs to download the jars from. -- 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-14600) Download package jars from external locations
[ https://issues.apache.org/jira/browse/SOLR-14600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-14600: Priority: Blocker (was: Major) > Download package jars from external locations > - > > Key: SOLR-14600 > URL: https://issues.apache.org/jira/browse/SOLR-14600 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > > Currently, artifacts for a package should be co-located with the > repository.json (and publickey.der). However, as [~kezhenxu94] brought up, it > would be nice to have jars hosted via Github released artifacts. In such a > case, the repository.json will include URLs to download the jars from. -- 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-14600) Download package jars from external locations
Ishan Chattopadhyaya created SOLR-14600: --- Summary: Download package jars from external locations Key: SOLR-14600 URL: https://issues.apache.org/jira/browse/SOLR-14600 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Ishan Chattopadhyaya Currently, artifacts for a package should be co-located with the repository.json (and publickey.der). However, as [~kezhenxu94] brought up, it would be nice to have jars hosted via Github released artifacts. In such a case, the repository.json will include URLs to download the jars from. -- 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-14600) Download package jars from external locations
[ https://issues.apache.org/jira/browse/SOLR-14600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-14600: Fix Version/s: 8.6 > Download package jars from external locations > - > > Key: SOLR-14600 > URL: https://issues.apache.org/jira/browse/SOLR-14600 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Fix For: 8.6 > > > Currently, artifacts for a package should be co-located with the > repository.json (and publickey.der). However, as [~kezhenxu94] brought up, it > would be nice to have jars hosted via Github released artifacts. In such a > case, the repository.json will include URLs to download the jars from. -- 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-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: Priority: Blocker (was: Major) > 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 > > > 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] [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: Fix Version/s: 8.6 > 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: Major > Fix For: 8.6 > > > 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] [Created] (SOLR-14599) Introduce cluster level plugins through packages
Ishan Chattopadhyaya created SOLR-14599: --- Summary: 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 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] [Updated] (LUCENE-9419) TestLongBitSet.testHugeCapacity sometimes fails on nightly
[
https://issues.apache.org/jira/browse/LUCENE-9419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer updated LUCENE-9419:
Description:
I see this once in a while on our CI with -Dtests.nightly=true
{noformat}
00:05:30[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestLongBitSet -Dtests.method=testHugeCapacity
-Dtests.seed=FB56CEB40315E44E -Dtests.nightly=true -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=lu -Dtests.timezone=Africa/Casablanca
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
00:05:30[junit4] ERROR 0.08s J1 | TestLongBitSet.testHugeCapacity <<<
00:05:30[junit4]> Throwable #1: java.lang.OutOfMemoryError: Java heap
space
00:05:30[junit4]> at
__randomizedtesting.SeedInfo.seed([FB56CEB40315E44E:8116844FEAE5C24A]:0)
00:05:30[junit4]> at
org.apache.lucene.util.ArrayUtil.growExact(ArrayUtil.java:323)
00:05:30[junit4]> at
org.apache.lucene.util.ArrayUtil.grow(ArrayUtil.java:332)
00:05:30[junit4]> at
org.apache.lucene.util.LongBitSet.ensureCapacity(LongBitSet.java:54)
00:05:30[junit4]> at
org.apache.lucene.util.TestLongBitSet.testHugeCapacity(TestLongBitSet.java:343)
00:05:30[junit4]> at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
00:05:30[junit4]> at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
00:05:30[junit4]> at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
00:05:30[junit4]> at
java.base/java.lang.reflect.Method.invoke(Method.java:566)
00:05:30[junit4] 2> NOTE: test params are: codec=Asserting(Lucene86): {},
docValues:{}, maxPointsInLeafNode=246, maxMBSortInHeap=6.097958740443044,
sim=Asserting(RandomSimilarity(queryNorm=false): {}), locale=lu,
timezone=Africa/Casablanca
00:05:30[junit4] 2> NOTE: Linux 4.12.14-122.26-default amd64/Oracle
Corporation 11.0.2 (64-bit)/cpus=32,threads=1,free=346124224,total=362807296
00:05:30[junit4] 2> NOTE: All tests run in this JVM: [TestSynonymQuery,
TestCachingCollector, TestLucene86PointsFormat, TestSizeBoundedForceMerge,
TestSimpleWKTShapeParsing, TestMergeRateLimiter, TestAxiomaticSimilarity,
TestReaderClosed, TestSpanExplanations, TestSingleInstanceLockFactory,
TestIndexSorting, TestIndexInput, TestBasicModelIn, TestPoint2D,
TestAtomicUpdate, TestOneMergeWrappingMergePolicy,
TestTragicIndexWriterDeadlock, TestRollingUpdates, TestCodecHoldsOpenFiles,
TestLucene50StoredFieldsFormatHighCompression, TestFieldsReader,
TestAxiomaticF2EXP, TestPointValues, TestIndependenceStandardized,
TestTwoPhaseCommitTool, TestLongBitSet]
00:05:30[junit4] Completed [87/566 (1!)] on J1 in 3.30s, 11 tests, 1 error
<<< FAILURES!
{noformat}
my suspicion is that some other test is holding on to memory here. I am trying
to record all failures here maybe we find some tests in common. The test itself
needs about 300MB to run so that should be ok with a 512M JVM
> TestLongBitSet.testHugeCapacity sometimes fails on nightly
> ---
>
> Key: LUCENE-9419
> URL: https://issues.apache.org/jira/browse/LUCENE-9419
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Simon Willnauer
>Priority: Minor
>
> I see this once in a while on our CI with -Dtests.nightly=true
> {noformat}
> 00:05:30[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestLongBitSet -Dtests.method=testHugeCapacity
> -Dtests.seed=FB56CEB40315E44E -Dtests.nightly=true -Dtests.slow=true
> -Dtests.badapples=true -Dtests.locale=lu -Dtests.timezone=Africa/Casablanca
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> 00:05:30[junit4] ERROR 0.08s J1 | TestLongBitSet.testHugeCapacity <<<
> 00:05:30[junit4]> Throwable #1: java.lang.OutOfMemoryError: Java heap
> space
> 00:05:30[junit4]> at
> __randomizedtesting.SeedInfo.seed([FB56CEB40315E44E:8116844FEAE5C24A]:0)
> 00:05:30[junit4]> at
> org.apache.lucene.util.ArrayUtil.growExact(ArrayUtil.java:323)
> 00:05:30[junit4]> at
> org.apache.lucene.util.ArrayUtil.grow(ArrayUtil.java:332)
> 00:05:30[junit4]> at
> org.apache.lucene.util.LongBitSet.ensureCapacity(LongBitSet.java:54)
> 00:05:30[junit4]> at
> org.apache.lucene.util.TestLongBitSet.testHugeCapacity(TestLongBitSet.java:343)
> 00:05:30[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 00:05:30[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 00:05:30[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccess
[jira] [Updated] (LUCENE-9419) TestLongBitSet.testHugeCapacity sometimes fails on nightly
[
https://issues.apache.org/jira/browse/LUCENE-9419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer updated LUCENE-9419:
Environment: (was: I see this once in a while on our CI with
-Dtests.nightly=true
{noformat}
00:05:30[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestLongBitSet -Dtests.method=testHugeCapacity
-Dtests.seed=FB56CEB40315E44E -Dtests.nightly=true -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=lu -Dtests.timezone=Africa/Casablanca
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
00:05:30[junit4] ERROR 0.08s J1 | TestLongBitSet.testHugeCapacity <<<
00:05:30[junit4]> Throwable #1: java.lang.OutOfMemoryError: Java heap
space
00:05:30[junit4]> at
__randomizedtesting.SeedInfo.seed([FB56CEB40315E44E:8116844FEAE5C24A]:0)
00:05:30[junit4]> at
org.apache.lucene.util.ArrayUtil.growExact(ArrayUtil.java:323)
00:05:30[junit4]> at
org.apache.lucene.util.ArrayUtil.grow(ArrayUtil.java:332)
00:05:30[junit4]> at
org.apache.lucene.util.LongBitSet.ensureCapacity(LongBitSet.java:54)
00:05:30[junit4]> at
org.apache.lucene.util.TestLongBitSet.testHugeCapacity(TestLongBitSet.java:343)
00:05:30[junit4]> at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
00:05:30[junit4]> at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
00:05:30[junit4]> at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
00:05:30[junit4]> at
java.base/java.lang.reflect.Method.invoke(Method.java:566)
00:05:30[junit4] 2> NOTE: test params are: codec=Asserting(Lucene86): {},
docValues:{}, maxPointsInLeafNode=246, maxMBSortInHeap=6.097958740443044,
sim=Asserting(RandomSimilarity(queryNorm=false): {}), locale=lu,
timezone=Africa/Casablanca
00:05:30[junit4] 2> NOTE: Linux 4.12.14-122.26-default amd64/Oracle
Corporation 11.0.2 (64-bit)/cpus=32,threads=1,free=346124224,total=362807296
00:05:30[junit4] 2> NOTE: All tests run in this JVM: [TestSynonymQuery,
TestCachingCollector, TestLucene86PointsFormat, TestSizeBoundedForceMerge,
TestSimpleWKTShapeParsing, TestMergeRateLimiter, TestAxiomaticSimilarity,
TestReaderClosed, TestSpanExplanations, TestSingleInstanceLockFactory,
TestIndexSorting, TestIndexInput, TestBasicModelIn, TestPoint2D,
TestAtomicUpdate, TestOneMergeWrappingMergePolicy,
TestTragicIndexWriterDeadlock, TestRollingUpdates, TestCodecHoldsOpenFiles,
TestLucene50StoredFieldsFormatHighCompression, TestFieldsReader,
TestAxiomaticF2EXP, TestPointValues, TestIndependenceStandardized,
TestTwoPhaseCommitTool, TestLongBitSet]
00:05:30[junit4] Completed [87/566 (1!)] on J1 in 3.30s, 11 tests, 1 error
<<< FAILURES!
{noformat}
my suspicion is that some other test is holding on to memory here. I am trying
to record all failures here maybe we find some tests in common. The test itself
needs about 300MB to run so that should be ok with a 512M JVM
)
> TestLongBitSet.testHugeCapacity sometimes fails on nightly
> ---
>
> Key: LUCENE-9419
> URL: https://issues.apache.org/jira/browse/LUCENE-9419
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Simon Willnauer
>Priority: Minor
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya resolved SOLR-14598.
-
Resolution: Fixed
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
> Attachments: SOLR-14598.patch
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
> at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThre
[jira] [Assigned] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya reassigned SOLR-14598:
---
Assignee: Ishan Chattopadhyaya
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
> Attachments: SOLR-14598.patch
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
> at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThrea
[jira] [Commented] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146878#comment-17146878
]
ASF subversion and git services commented on SOLR-14598:
Commit eaddd374f1a632eddbc60380f2ca6cb2c272b680 in lucene-solr's branch
refs/heads/branch_8x from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=eaddd37 ]
SOLR-14598: Granting reflection access for using annotations in SOLR-14404
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> 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-14598.patch
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.ecli
[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=17146879#comment-17146879
]
ASF subversion and git services commented on SOLR-14404:
Commit eaddd374f1a632eddbc60380f2ca6cb2c272b680 in lucene-solr's branch
refs/heads/branch_8x from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=eaddd37 ]
SOLR-14598: Granting reflection access for using annotations in SOLR-14404
> 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 10m
> Remaining Estimate: 0h
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/plugin}}
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "full.ClassName"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> add a plugin from a package
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "pkgName:full.ClassName" ,
> "version: "1.0"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName" }
> }
> }
> {code}
> example plugin
> {code:java}
> public class MyPlugin {
> private final CoreContainer coreContainer;
> public MyPlugin(CoreContainer coreContainer) {
> this.coreContainer = coreContainer;
> }
> @EndPoint(path = "/myplugin/path1",
> method = METHOD.GET,
> permission = READ)
> public void call(SolrQueryRequest req, SolrQueryResponse rsp){
> rsp.add("myplugin.version", "2.0");
> }
> }
> {code}
> This plugin will be accessible on all nodes at {{/api/myplugin/path1}}. It's
> possible to add more methods at different paths. Ensure that all paths start
> with {{myplugin}} because that is the name in which the plugin is registered
> with. So {{/myplugin/path2}} , {{/myplugin/my/deeply/nested/path}} are all
> valid paths.
> It's possible that the user chooses to register the plugin with a different
> name. In that case , use a template variable as follows in paths
> {{$plugin-name/path1}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14404) CoreContainer level custom requesthandlers
[
https://issues.apache.org/jira/browse/SOLR-14404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146877#comment-17146877
]
ASF subversion and git services commented on SOLR-14404:
Commit e6ffa8e9e263a0251202f2ca1bbd3a47cc8c2727 in lucene-solr's branch
refs/heads/master from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e6ffa8e ]
SOLR-14598: Granting reflection access for using annotations in SOLR-14404
> 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 10m
> Remaining Estimate: 0h
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/plugin}}
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "full.ClassName"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> add a plugin from a package
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "pkgName:full.ClassName" ,
> "version: "1.0"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName" }
> }
> }
> {code}
> example plugin
> {code:java}
> public class MyPlugin {
> private final CoreContainer coreContainer;
> public MyPlugin(CoreContainer coreContainer) {
> this.coreContainer = coreContainer;
> }
> @EndPoint(path = "/myplugin/path1",
> method = METHOD.GET,
> permission = READ)
> public void call(SolrQueryRequest req, SolrQueryResponse rsp){
> rsp.add("myplugin.version", "2.0");
> }
> }
> {code}
> This plugin will be accessible on all nodes at {{/api/myplugin/path1}}. It's
> possible to add more methods at different paths. Ensure that all paths start
> with {{myplugin}} because that is the name in which the plugin is registered
> with. So {{/myplugin/path2}} , {{/myplugin/my/deeply/nested/path}} are all
> valid paths.
> It's possible that the user chooses to register the plugin with a different
> name. In that case , use a template variable as follows in paths
> {{$plugin-name/path1}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146876#comment-17146876
]
ASF subversion and git services commented on SOLR-14598:
Commit e6ffa8e9e263a0251202f2ca1bbd3a47cc8c2727 in lucene-solr's branch
refs/heads/master from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e6ffa8e ]
SOLR-14598: Granting reflection access for using annotations in SOLR-14404
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> 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-14598.patch
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse
[jira] [Created] (LUCENE-9419) TestLongBitSet.testHugeCapacity sometimes fails on nightly
Simon Willnauer created LUCENE-9419:
---
Summary: TestLongBitSet.testHugeCapacity sometimes fails on
nightly
Key: LUCENE-9419
URL: https://issues.apache.org/jira/browse/LUCENE-9419
Project: Lucene - Core
Issue Type: Test
Environment: I see this once in a while on our CI with
-Dtests.nightly=true
{noformat}
00:05:30[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestLongBitSet -Dtests.method=testHugeCapacity
-Dtests.seed=FB56CEB40315E44E -Dtests.nightly=true -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=lu -Dtests.timezone=Africa/Casablanca
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
00:05:30[junit4] ERROR 0.08s J1 | TestLongBitSet.testHugeCapacity <<<
00:05:30[junit4]> Throwable #1: java.lang.OutOfMemoryError: Java heap
space
00:05:30[junit4]> at
__randomizedtesting.SeedInfo.seed([FB56CEB40315E44E:8116844FEAE5C24A]:0)
00:05:30[junit4]> at
org.apache.lucene.util.ArrayUtil.growExact(ArrayUtil.java:323)
00:05:30[junit4]> at
org.apache.lucene.util.ArrayUtil.grow(ArrayUtil.java:332)
00:05:30[junit4]> at
org.apache.lucene.util.LongBitSet.ensureCapacity(LongBitSet.java:54)
00:05:30[junit4]> at
org.apache.lucene.util.TestLongBitSet.testHugeCapacity(TestLongBitSet.java:343)
00:05:30[junit4]> at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
00:05:30[junit4]> at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
00:05:30[junit4]> at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
00:05:30[junit4]> at
java.base/java.lang.reflect.Method.invoke(Method.java:566)
00:05:30[junit4] 2> NOTE: test params are: codec=Asserting(Lucene86): {},
docValues:{}, maxPointsInLeafNode=246, maxMBSortInHeap=6.097958740443044,
sim=Asserting(RandomSimilarity(queryNorm=false): {}), locale=lu,
timezone=Africa/Casablanca
00:05:30[junit4] 2> NOTE: Linux 4.12.14-122.26-default amd64/Oracle
Corporation 11.0.2 (64-bit)/cpus=32,threads=1,free=346124224,total=362807296
00:05:30[junit4] 2> NOTE: All tests run in this JVM: [TestSynonymQuery,
TestCachingCollector, TestLucene86PointsFormat, TestSizeBoundedForceMerge,
TestSimpleWKTShapeParsing, TestMergeRateLimiter, TestAxiomaticSimilarity,
TestReaderClosed, TestSpanExplanations, TestSingleInstanceLockFactory,
TestIndexSorting, TestIndexInput, TestBasicModelIn, TestPoint2D,
TestAtomicUpdate, TestOneMergeWrappingMergePolicy,
TestTragicIndexWriterDeadlock, TestRollingUpdates, TestCodecHoldsOpenFiles,
TestLucene50StoredFieldsFormatHighCompression, TestFieldsReader,
TestAxiomaticF2EXP, TestPointValues, TestIndependenceStandardized,
TestTwoPhaseCommitTool, TestLongBitSet]
00:05:30[junit4] Completed [87/566 (1!)] on J1 in 3.30s, 11 tests, 1 error
<<< FAILURES!
{noformat}
my suspicion is that some other test is holding on to memory here. I am trying
to record all failures here maybe we find some tests in common. The test itself
needs about 300MB to run so that should be ok with a 512M JVM
Reporter: Simon Willnauer
--
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-9418) Ordered intervals can give inaccurate hits on interleaved terms
[ https://issues.apache.org/jira/browse/LUCENE-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146870#comment-17146870 ] Alan Woodward commented on LUCENE-9418: --- This was uncovered by an elasticsearch user and reported here: https://github.com/elastic/elasticsearch/issues/58576 > Ordered intervals can give inaccurate hits on interleaved terms > --- > > Key: LUCENE-9418 > URL: https://issues.apache.org/jira/browse/LUCENE-9418 > Project: Lucene - Core > Issue Type: Bug >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Given the text 'A B A C', an ordered interval over 'A B C' will return the > inaccurate interval [2, 3], due to the way minimization is handled after > matches are found. -- 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-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya updated SOLR-14598:
Attachment: SOLR-14598.patch
Status: Open (was: Open)
Attaching a patch here. Planning to commit this soon, unless someone has any
objections.
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> 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-14598.patch
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
>
[jira] [Commented] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146858#comment-17146858
]
Ishan Chattopadhyaya commented on SOLR-14598:
-
Finally, the following worked.
{code}
permission java.lang.RuntimePermission
"accessClassInPackage.jdk.internal.reflect";
{code}
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
> at
> org.
[jira] [Commented] (SOLR-14598) Security Manager causing reflection exceptions
[
https://issues.apache.org/jira/browse/SOLR-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146853#comment-17146853
]
Ishan Chattopadhyaya commented on SOLR-14598:
-
Adding the following doesn't help either:
{code}
permission java.lang.reflect.ReflectPermission
"accessClassInPackage.jdk.internal.reflect";
{code}
> Security Manager causing reflection exceptions
> --
>
> Key: SOLR-14598
> URL: https://issues.apache.org/jira/browse/SOLR-14598
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
>
> With SOLR-14404, after few requests (around 10 requests), every request is
> failing with:
> {code}
> 2020-06-27 08:26:00.708 ERROR (qtp65488937-22) [ ] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException:
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
> at org.apache.solr.api.AnnotatedApi$Cmd.invoke(AnnotatedApi.java:311)
> at org.apache.solr.api.AnnotatedApi.call(AnnotatedApi.java:178)
> at
> org.apache.solr.api.CustomContainerPlugins$ApiHolder.call(CustomContainerPlugins.java:166)
> at org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:340)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
