[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=17151729#comment-17151729
]
David Smiley commented on SOLR-13749:
-
BTW I filed an issue with PR for the refactoring: SOLR-14619
> 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 the local collection|
> |v|See Note|The query to be executed against the external Solr collection to
> retrieve the set of join key values.
> Note: The original query can be passed at the end of the string or as the
> "v" parameter.
> It's recommended to use query parameter substitution with the "v" parameter
> to ensure no issues arise with the default query parsers.|
> |routed| |true / false. If true, the XCJF query will use each shard's hash
> range to determine the set of join keys to retrieve for that shard.
> This parameter improves the performance of the cross-collection join, but
> it depends on the local collection being routed by the toField. If this
> parameter is not specified,
> the XCJF query will try to determine the correct value automatically.|
> |ttl| |The length of time that an XCJF query in the cache will be considered
> valid, in seconds. Defaults to 3600 (one hour).
> The XCJF query will not be aware of changes to the remote collection, so
> if the remote collection is updated, cached XCJF queries may give inaccurate
> results.
> After the ttl period has expired, the XCJF query will re-execute the join
> against the remote collection.|
> |_All others_| |Any normal Solr parameter can also be specified as a local
> param.|
>
> Example Solr Config.xml changes:
>
> {{<}}{{cache}} {{name}}{{=}}{{"hash_vin"}}
> {{ }}{{class}}{{=}}{{"solr.LRUCache"}}
> {{ }}{{size}}{{=}}{{"128"}}
> {{ }}{{initialSize}}{{=}}{{"0"}}
> {{ }}{{regenerator}}{{=}}{{"solr.NoOpRegenerator"}}{{/>}}
>
> {{<}}{{queryParser}} {{name}}{{=}}{{"xcjf"}}
> {{class}}{{=}}{{"org.apache.solr.search.join.XCJFQueryParserPlugin"}}{{>}}
> {{ }}{{<}}{{str}}
[jira] [Commented] (SOLR-10317) Solr Nightly Benchmarks
[ https://issues.apache.org/jira/browse/SOLR-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151723#comment-17151723 ] David Smiley commented on SOLR-10317: - Thanks for re-opening. I have my heart set on "Solr nightly benchmarks" (the title!) becoming a reality some day. It's been a journey with an important milestone reached but we're still not there yet. For "e-commerce centric data sets", maybe ask on solr-user; I'm not sure. Wikipedia has certain strengths but _perhaps_ not enough "structure" for some more interesting tests. Geonames has decent structured data. > Solr Nightly Benchmarks > --- > > Key: SOLR-10317 > URL: https://issues.apache.org/jira/browse/SOLR-10317 > Project: Solr > Issue Type: Task >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Major > Labels: gsoc2017, mentor > Attachments: > Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks-FINAL-PROPOSAL.pdf, > Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks.docx, SOLR-10317.patch, > SOLR-10317.patch, Screenshot from 2017-07-30 20-30-05.png, > changes-lucene-20160907.json, changes-solr-20160907.json, managed-schema, > solrconfig.xml > > > The benchmarking suite is now here: > [https://github.com/thesearchstack/solr-bench] > Actual datasets and queries are TBD yet. > > --- Original description --- > Solr needs nightly benchmarks reporting. Similar Lucene benchmarks can be > found here, [https://home.apache.org/~mikemccand/lucenebench/]. > > Preferably, we need: > # A suite of benchmarks that build Solr from a commit point, start Solr > nodes, both in SolrCloud and standalone mode, and record timing information > of various operations like indexing, querying, faceting, grouping, > replication etc. > # It should be possible to run them either as an independent suite or as a > Jenkins job, and we should be able to report timings as graphs (Jenkins has > some charting plugins). > # The code should eventually be integrated in the Solr codebase, so that it > never goes out of date. > > There is some prior work / discussion: > # [https://github.com/shalinmangar/solr-perf-tools] (Shalin) > # [https://github.com/chatman/solr-upgrade-tests/blob/master/BENCHMARKS.md] > (Ishan/Vivek) > # SOLR-2646 & SOLR-9863 (Mark Miller) > # [https://home.apache.org/~mikemccand/lucenebench/] (Mike McCandless) > # [https://github.com/lucidworks/solr-scale-tk] (Tim Potter) > > There is support for building, starting, indexing/querying and stopping Solr > in some of these frameworks above. However, the benchmarks run are very > limited. Any of these can be a starting point, or a new framework can as well > be used. The motivation is to be able to cover every functionality of Solr > with a corresponding benchmark that is run every night. > > Proposing this as a GSoC 2017 project. I'm willing to mentor, and I'm sure > [~shalinmangar] and [~[markrmil...@gmail.com|mailto:markrmil...@gmail.com]] > would help here. -- 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] hanbj closed pull request #596: Under this branch, the dataDimensionCount is definitely not zero.
hanbj closed pull request #596: URL: https://github.com/apache/lucene-solr/pull/596 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-13132) Improve JSON "terms" facet performance when sorted by relatedness
[
https://issues.apache.org/jira/browse/SOLR-13132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151677#comment-17151677
]
Chris M. Hostetter commented on SOLR-13132:
---
bq. ... perhaps the only remaining question is "what is the allBucketSlotNum
when sweeping?". I'm definitely comfortable with the initial "hackish" approach
as you've refined it in your recent commit ...
Yep, I haven't been able to think of a better solution that balances
"HACKishness" vs "overly complex change to APIs" ... so let's move forward.
[~mgibney] - can you please merge in the latests apache/master branch to pick
up fea6c1b9daa243e48297b4ba5a1ece68b8790a5b & confirm precommit still passes?
(there have been some additional stricntess checks put into place that may
require dealing with some compiler warnings in order for the build to continue
to work -- not sure if that affects us) ... and then i'll (hopefully) have time
to do one final review of the overall diff & merge to master to commit later
this week.
> Improve JSON "terms" facet performance when sorted by relatedness
> --
>
> Key: SOLR-13132
> URL: https://issues.apache.org/jira/browse/SOLR-13132
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Affects Versions: 7.4, master (9.0)
>Reporter: Michael Gibney
>Priority: Major
> Attachments: SOLR-13132-with-cache-01.patch,
> SOLR-13132-with-cache.patch, SOLR-13132.patch, SOLR-13132_testSweep.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> When sorting buckets by {{relatedness}}, JSON "terms" facet must calculate
> {{relatedness}} for every term.
> The current implementation uses a standard uninverted approach (either
> {{docValues}} or {{UnInvertedField}}) to get facet counts over the domain
> base docSet, and then uses that initial pass as a pre-filter for a
> second-pass, inverted approach of fetching docSets for each relevant term
> (i.e., {{count > minCount}}?) and calculating intersection size of those sets
> with the domain base docSet.
> Over high-cardinality fields, the overhead of per-term docSet creation and
> set intersection operations increases request latency to the point where
> relatedness sort may not be usable in practice (for my use case, even after
> applying the patch for SOLR-13108, for a field with ~220k unique terms per
> core, QTime for high-cardinality domain docSets were, e.g.: cardinality
> 1816684=9000ms, cardinality 5032902=18000ms).
> The attached patch brings the above example QTimes down to a manageable
> ~300ms and ~250ms respectively. The approach calculates uninverted facet
> counts over domain base, foreground, and background docSets in parallel in a
> single pass. This allows us to take advantage of the efficiencies built into
> the standard uninverted {{FacetFieldProcessorByArray[DV|UIF]}}), and avoids
> the per-term docSet creation and set intersection overhead.
--
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-14595) json.facet subfacet 'sort:"index asc", refine:true' can return diff results using method:enum
[
https://issues.apache.org/jira/browse/SOLR-14595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151676#comment-17151676
]
ASF subversion and git services commented on SOLR-14595:
Commit 87436b0b9af2aedcf86904dbe78c0c4631d6c551 in lucene-solr's branch
refs/heads/branch_8x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=87436b0 ]
SOLR-14595: add AwaitsFix test to TestJsonFacetRefinement demonstrating
problem, and work around to randomized testing in TestCloudJSONFacetSKGEquiv
(cherry picked from commit fea6c1b9daa243e48297b4ba5a1ece68b8790a5b)
> json.facet subfacet 'sort:"index asc", refine:true' can return diff results
> using method:enum
> -
>
> Key: SOLR-14595
> URL: https://issues.apache.org/jira/browse/SOLR-14595
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-14595.patch, SOLR-14595.patch
>
>
> jenkins found a failing seed for TestCloudJSONFacetSKGEquiv that has nothing
> to do with SKG -- it shows that using {{method:enum}} can sometimes return
> different set of buckets then {{method:smart}} when computing a facet that
> uses {{"sort":"index asc", "refine":true}} _as a subfacet_ of some other
> facet.
> (In all the cases i've been able to trigger with more targetted testing, the
> "parent facet" needs to use a sort option that cause buckets to "sort worse"
> when more data is known about them -- ie: "count asc" or SKG -- but i haven't
> determined if that's actaully neccessary to trigger the fialure)
> original jenkins failure...
> {noformat}
> master jenkins (@ 541fc984e90) ...
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestCloudJSONFacetSKGEquiv -Dtests.method=testRandom
> -Dtests.seed=356C5A0B17DE491 -Dtests.multiplier=2 -Dtests.slow=true
> -Dtests.badapples=true -Dtests.locale=en-KN -Dtests.timezone=Asia/Ho_Chi_Minh
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 1.05s | TestCloudJSONFacetSKGEquiv.testRandom <<<
>[junit4]> Throwable #1: java.lang.AssertionError:
> rows=0=(field_7_multi_sds:19+OR+field_11_multi_sdsS:61+OR+field_8_multi_sdsS:45+OR+field_10_multi_sds:21+OR+field_2_multi_sdsS:28+OR+field_8_multi_sdsS:33+OR+field_10_multi_sds:54+OR+field_12_multi_ss:41)=(field_5_multi_sdsS:48+OR+field_7_multi_sds:24+OR+field_13_multi_sds:61+OR+field_10_multi_sds:32+OR+field_9_multi_ss:45+OR+field_10_multi_sds:16+OR+field_11_multi_sdsS:28+OR+field_2_multi_sdsS:33+OR+field_8_multi_sdsS:43+OR+field_7_multi_sds:9)=(field_2_multi_sdsS:5+OR+field_9_multi_ss:16+OR+field_0_multi_ss:40+OR+field_0_multi_ss:16+OR+field_10_multi_sds:34+OR+field_10_multi_sds:58+OR+field_9_multi_ss:15+OR+field_1_multi_sds:44+OR+field_13_multi_sds:51+OR+field_10_multi_sds:21)={"facet_1":{"method":"${method_val:smart}","limit":12,"sort":"count+asc","refine":true,"type":"terms","field":"field_12_multi_ss","facet":{"skg":{"type":"func","func":"relatedness($fore,$back)"},"facet_2":{"method":"${method_val:smart}","limit":1,"overrequest":38,"prefix":"2","sort":"index+asc","refine":true,"type":"terms","field":"field_3_multi_ss","facet":{"skg":{"type":"func","func":"relatedness($fore,$back)"},"facet_3":{"method":"${method_val:smart}","overrequest":0,"perSeg":false,"sort":"skg+desc","refine":true,"type":"terms","field":"field_8_multi_idsS","facet":{"skg":{"type":"func","func":"relatedness($fore,$back)"&_stateVer_=org.apache.solr.search.facet.TestCloudJSONFacetSKGEquiv_collection:4
> ===> Mismatch: .facet_1.buckets[8][facet_2].buckets.length:1!=0 using
> method_val=enum
> {noformat}
--
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-14595) json.facet subfacet 'sort:"index asc", refine:true' can return diff results using method:enum
[
https://issues.apache.org/jira/browse/SOLR-14595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151656#comment-17151656
]
ASF subversion and git services commented on SOLR-14595:
Commit fea6c1b9daa243e48297b4ba5a1ece68b8790a5b in lucene-solr's branch
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fea6c1b ]
SOLR-14595: add AwaitsFix test to TestJsonFacetRefinement demonstrating
problem, and work around to randomized testing in TestCloudJSONFacetSKGEquiv
> json.facet subfacet 'sort:"index asc", refine:true' can return diff results
> using method:enum
> -
>
> Key: SOLR-14595
> URL: https://issues.apache.org/jira/browse/SOLR-14595
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-14595.patch, SOLR-14595.patch
>
>
> jenkins found a failing seed for TestCloudJSONFacetSKGEquiv that has nothing
> to do with SKG -- it shows that using {{method:enum}} can sometimes return
> different set of buckets then {{method:smart}} when computing a facet that
> uses {{"sort":"index asc", "refine":true}} _as a subfacet_ of some other
> facet.
> (In all the cases i've been able to trigger with more targetted testing, the
> "parent facet" needs to use a sort option that cause buckets to "sort worse"
> when more data is known about them -- ie: "count asc" or SKG -- but i haven't
> determined if that's actaully neccessary to trigger the fialure)
> original jenkins failure...
> {noformat}
> master jenkins (@ 541fc984e90) ...
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestCloudJSONFacetSKGEquiv -Dtests.method=testRandom
> -Dtests.seed=356C5A0B17DE491 -Dtests.multiplier=2 -Dtests.slow=true
> -Dtests.badapples=true -Dtests.locale=en-KN -Dtests.timezone=Asia/Ho_Chi_Minh
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 1.05s | TestCloudJSONFacetSKGEquiv.testRandom <<<
>[junit4]> Throwable #1: java.lang.AssertionError:
> rows=0=(field_7_multi_sds:19+OR+field_11_multi_sdsS:61+OR+field_8_multi_sdsS:45+OR+field_10_multi_sds:21+OR+field_2_multi_sdsS:28+OR+field_8_multi_sdsS:33+OR+field_10_multi_sds:54+OR+field_12_multi_ss:41)=(field_5_multi_sdsS:48+OR+field_7_multi_sds:24+OR+field_13_multi_sds:61+OR+field_10_multi_sds:32+OR+field_9_multi_ss:45+OR+field_10_multi_sds:16+OR+field_11_multi_sdsS:28+OR+field_2_multi_sdsS:33+OR+field_8_multi_sdsS:43+OR+field_7_multi_sds:9)=(field_2_multi_sdsS:5+OR+field_9_multi_ss:16+OR+field_0_multi_ss:40+OR+field_0_multi_ss:16+OR+field_10_multi_sds:34+OR+field_10_multi_sds:58+OR+field_9_multi_ss:15+OR+field_1_multi_sds:44+OR+field_13_multi_sds:51+OR+field_10_multi_sds:21)={"facet_1":{"method":"${method_val:smart}","limit":12,"sort":"count+asc","refine":true,"type":"terms","field":"field_12_multi_ss","facet":{"skg":{"type":"func","func":"relatedness($fore,$back)"},"facet_2":{"method":"${method_val:smart}","limit":1,"overrequest":38,"prefix":"2","sort":"index+asc","refine":true,"type":"terms","field":"field_3_multi_ss","facet":{"skg":{"type":"func","func":"relatedness($fore,$back)"},"facet_3":{"method":"${method_val:smart}","overrequest":0,"perSeg":false,"sort":"skg+desc","refine":true,"type":"terms","field":"field_8_multi_idsS","facet":{"skg":{"type":"func","func":"relatedness($fore,$back)"&_stateVer_=org.apache.solr.search.facet.TestCloudJSONFacetSKGEquiv_collection:4
> ===> Mismatch: .facet_1.buckets[8][facet_2].buckets.length:1!=0 using
> method_val=enum
> {noformat}
--
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-14610) ReflectMapWriter to use VarHandle instead of old legacy reflection
[ https://issues.apache.org/jira/browse/SOLR-14610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151556#comment-17151556 ] ASF subversion and git services commented on SOLR-14610: Commit 7f9328dbe19eb5fb3362aa8dfa1ff38600e2f976 in lucene-solr's branch refs/heads/branch_8x from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7f9328d ] Revert "SOLR-14610: ReflectMapWriter to use VarHandle instead of old legacy reflection (#1635)" This reverts commit 1de187edb41694f9329ea9a2bbef7d94aa57aa25. This does not work with java8. Must have committed accidently > ReflectMapWriter to use VarHandle instead of old legacy reflection > -- > > Key: SOLR-14610 > URL: https://issues.apache.org/jira/browse/SOLR-14610 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > The same reason why we changed to MethodHandles in SOLR-14404 -- 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 #1622: SOLR-14603: update Restlet version
chatman commented on pull request #1622: URL: https://github.com/apache/lucene-solr/pull/1622#issuecomment-653857121 This is merged. Please close the PR. Thanks! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[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=17151487#comment-17151487
]
ASF subversion and git services commented on SOLR-14404:
Commit 3642aa3d4e1a92e46c916445feb7eabc88eb4bcd in lucene-solr's branch
refs/heads/master from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3642aa3 ]
SOLR-14404: update was not working
> CoreContainer level custom requesthandlers
> --
>
> Key: SOLR-14404
> URL: https://issues.apache.org/jira/browse/SOLR-14404
> Project: Solr
> Issue Type: New Feature
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/plugin}}
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "full.ClassName"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> add a plugin from a package
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "pkgName:full.ClassName" ,
> "version: "1.0"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName" }
> }
> }
> {code}
> example plugin
> {code:java}
> public class MyPlugin {
> private final CoreContainer coreContainer;
> public MyPlugin(CoreContainer coreContainer) {
> this.coreContainer = coreContainer;
> }
> @EndPoint(path = "/myplugin/path1",
> method = METHOD.GET,
> permission = READ)
> public void call(SolrQueryRequest req, SolrQueryResponse rsp){
> rsp.add("myplugin.version", "2.0");
> }
> }
> {code}
> This plugin will be accessible on all nodes at {{/api/myplugin/path1}}. It's
> possible to add more methods at different paths. Ensure that all paths start
> with {{myplugin}} because that is the name in which the plugin is registered
> with. So {{/myplugin/path2}} , {{/myplugin/my/deeply/nested/path}} are all
> valid paths.
> It's possible that the user chooses to register the plugin with a different
> name. In that case , use a template variable as follows in paths
> {{$plugin-name/path1}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14404) CoreContainer level custom requesthandlers
[
https://issues.apache.org/jira/browse/SOLR-14404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151486#comment-17151486
]
ASF subversion and git services commented on SOLR-14404:
Commit 4c3ea27336a41d31d067768afe5f99624c905fb9 in lucene-solr's branch
refs/heads/branch_8x from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4c3ea27 ]
SOLR-14404: update was not working
> CoreContainer level custom requesthandlers
> --
>
> Key: SOLR-14404
> URL: https://issues.apache.org/jira/browse/SOLR-14404
> Project: Solr
> Issue Type: New Feature
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/plugin}}
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "full.ClassName"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> add a plugin from a package
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "pkgName:full.ClassName" ,
> "version: "1.0"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName" }
> }
> }
> {code}
> example plugin
> {code:java}
> public class MyPlugin {
> private final CoreContainer coreContainer;
> public MyPlugin(CoreContainer coreContainer) {
> this.coreContainer = coreContainer;
> }
> @EndPoint(path = "/myplugin/path1",
> method = METHOD.GET,
> permission = READ)
> public void call(SolrQueryRequest req, SolrQueryResponse rsp){
> rsp.add("myplugin.version", "2.0");
> }
> }
> {code}
> This plugin will be accessible on all nodes at {{/api/myplugin/path1}}. It's
> possible to add more methods at different paths. Ensure that all paths start
> with {{myplugin}} because that is the name in which the plugin is registered
> with. So {{/myplugin/path2}} , {{/myplugin/my/deeply/nested/path}} are all
> valid paths.
> It's possible that the user chooses to register the plugin with a different
> name. In that case , use a template variable as follows in paths
> {{$plugin-name/path1}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14610) ReflectMapWriter to use VarHandle instead of old legacy reflection
[ https://issues.apache.org/jira/browse/SOLR-14610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151485#comment-17151485 ] ASF subversion and git services commented on SOLR-14610: Commit 1de187edb41694f9329ea9a2bbef7d94aa57aa25 in lucene-solr's branch refs/heads/branch_8x from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1de187e ] SOLR-14610: ReflectMapWriter to use VarHandle instead of old legacy reflection (#1635) > ReflectMapWriter to use VarHandle instead of old legacy reflection > -- > > Key: SOLR-14610 > URL: https://issues.apache.org/jira/browse/SOLR-14610 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > The same reason why we changed to MethodHandles in SOLR-14404 -- 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=17151484#comment-17151484
]
ASF subversion and git services commented on SOLR-14404:
Commit 925799d4b60aa6bf7d292ac9e3c09a21567f50f4 in lucene-solr's branch
refs/heads/branch_8_6 from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=925799d ]
SOLR-14404: update was not working
> 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] dsmiley opened a new pull request #1651: SOLR-14628: hl.fragsizeIsMinimum now defaults to true
dsmiley opened a new pull request #1651: URL: https://github.com/apache/lucene-solr/pull/1651 Fragments size like <= Solr 8.4 and addresses a significant performance regression 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
