[jira] [Commented] (SOLR-15016) Replica placement plugins should use container plugins API / configs
[
https://issues.apache.org/jira/browse/SOLR-15016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244803#comment-17244803
]
ASF subversion and git services commented on SOLR-15016:
Commit cced5078ea13797a49658cdf76f693a79788c533 in lucene-solr's branch
refs/heads/master from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cced507 ]
SOLR-15016: Replica placement plugins should use container plugins API /
configs.
> Replica placement plugins should use container plugins API / configs
>
>
> Key: SOLR-15016
> URL: https://issues.apache.org/jira/browse/SOLR-15016
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Plugin system
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Time Spent: 6h 20m
> Remaining Estimate: 0h
>
> Replica placement API currently uses its own way of loading plugin
> implementations and their config.
> Instead it should use a more robust mechanism supported by
> {{ContainerPluginsAPI}} and {{ContainerPluginsRegistry}}.
--
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-15016) Replica placement plugins should use container plugins API / configs
[
https://issues.apache.org/jira/browse/SOLR-15016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244806#comment-17244806
]
ASF subversion and git services commented on SOLR-15016:
Commit 478c6cb0f5618b0877342f3fffc416e2a263f5de in lucene-solr's branch
refs/heads/master from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=478c6cb ]
SOLR-15016: Fix javadoc so that the example matches the current API.
> Replica placement plugins should use container plugins API / configs
>
>
> Key: SOLR-15016
> URL: https://issues.apache.org/jira/browse/SOLR-15016
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Plugin system
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Time Spent: 6h 20m
> Remaining Estimate: 0h
>
> Replica placement API currently uses its own way of loading plugin
> implementations and their config.
> Instead it should use a more robust mechanism supported by
> {{ContainerPluginsAPI}} and {{ContainerPluginsRegistry}}.
--
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-9632) Replace our TimSort with JDK TimSort
[ https://issues.apache.org/jira/browse/LUCENE-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244823#comment-17244823 ] Michael Sokolov commented on LUCENE-9632: - I just found a new use for IntroSorter - please don't remove! As for the util methods, they're not doing any harm? I'd be -0 to migrate JDK impl for those cases where we can; I mean sure, why not, but on the other hand if it's not broke, why fix it? The test coverage is a benefit, although we could always find another way, but like Uwe points out, we wouldn't really be saving any maintenance costs, since we still need to maintain the core algorithm for the parallel sorting case. > Replace our TimSort with JDK TimSort > > > Key: LUCENE-9632 > URL: https://issues.apache.org/jira/browse/LUCENE-9632 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: master (9.0) >Reporter: Mike Drob >Priority: Major > > JDK 11 has a TimSort with very similar lineage to our TimSort (written by > Josh Bloch, based on Tim Peter's python list sort), we should consider > replacing our fork with a version that we don't have to maintain. -- 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-14928) Remove Overseer ClusterStateUpdater
[
https://issues.apache.org/jira/browse/SOLR-14928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244869#comment-17244869
]
Ilan Ginzburg commented on SOLR-14928:
--
As I resumed work on this, I rebased on latest master. See branch
[here|https://github.com/murblanc/lucene-solr/tree/SOLR-14928_ClusterStateUpdater]
(forced pushed so the commits mentioned in previous posts are no longer
relevant).
Collection creation and deletion works and goes through distributed
{{state.json}} updates. The rest of the Collection API is still broken :)
The main issue with this change seems to be the assumptions made on the
completeness of the cached cluster state rather than the actual updates, at
least at this stage.
WIP, I figured out I'd post progress updates here...
> Remove Overseer ClusterStateUpdater
> ---
>
> Key: SOLR-14928
> URL: https://issues.apache.org/jira/browse/SOLR-14928
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Ilan Ginzburg
>Assignee: Ilan Ginzburg
>Priority: Major
> Labels: cluster, collection-api, overseer
>
> Remove the Overseer {{ClusterStateUpdater}} thread and associated Zookeeper
> queue at {{<_chroot_>/overseer/queue}}.
> Change cluster state updates so that each (Collection API) command execution
> does the update directly in Zookeeper using optimistic locking (Compare and
> Swap on the {{state.json}} Zookeeper files).
> Following this change cluster state updates would still be happening only
> from the Overseer node (that's where Collection API commands are executing),
> but the code will be ready for distribution once such commands can be
> executed by any node (other work done in the context of parent task
> SOLR-14927).
> See the [Cluster State
> Updater|https://docs.google.com/document/d/1u4QHsIHuIxlglIW6hekYlXGNOP0HjLGVX5N6inkj6Ok/edit#heading=h.ymtfm3p518c]
> section in the Removing Overseer doc.
--
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-9537) Add Indri Search Engine Functionality to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-9537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244947#comment-17244947 ] Cameron VandenBerg commented on LUCENE-9537: Hi [~mikemccand], Thank you for your comments on my pull request. I did address each one and updated my pull request with additional comments. I wasn't sure if I was supposed to just respond on the PR or also update this ticket. Let me know if there is anything else I could do. Thanks, Cameron VandenBerg > Add Indri Search Engine Functionality to Lucene > --- > > Key: LUCENE-9537 > URL: https://issues.apache.org/jira/browse/LUCENE-9537 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Cameron VandenBerg >Priority: Major > Labels: patch > Attachments: LUCENE-9537.patch, LUCENE-INDRI.patch > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Indri ([http://lemurproject.org/indri.php]) is an academic search engine > developed by The University of Massachusetts and Carnegie Mellon University. > The major difference between Lucene and Indri is that Indri will give a > document a "smoothing score" to a document that does not contain the search > term, which has improved the search ranking accuracy in our experiments. I > have created an Indri patch, which adds the search code needed to implement > the Indri AND logic as well as Indri's implementation of Dirichlet Smoothing. -- 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] munendrasn opened a new pull request #2123: SOLR-10732: short circuit calls to searcher#numDocs when base is empty
munendrasn opened a new pull request #2123: URL: https://github.com/apache/lucene-solr/pull/2123 This avoids constructing redundant queries 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-10732) potential optimizations in callers of SolrIndexSearcher.numDocs when docset is empty
[
https://issues.apache.org/jira/browse/SOLR-10732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244970#comment-17244970
]
Munendra S N commented on SOLR-10732:
-
I have created the Github PR and requested for the review
> potential optimizations in callers of SolrIndexSearcher.numDocs when docset
> is empty
>
>
> Key: SOLR-10732
> URL: https://issues.apache.org/jira/browse/SOLR-10732
> Project: Solr
> Issue Type: Improvement
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-10732.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> spin off of SOLR-10727...
> {quote}
> ...why not (also) optimize it slightly higher up and completely avoid the
> construction of the Query objects? (and in some cases: additional overhead)
> for example: the first usage of {{SolrIndexSearcher.numDocs(Query,DocSet)}} i
> found was {{RangeFacetProcessor.rangeCount(DocSet subset,...)}} ... if the
> first line of that method was {{if (0 == subset.size()) return 0}} then we'd
> not only optimize away the SolrIndexSearcher hit, but also fetching the
> SchemaField & building the range query (not to mention the much more
> expensive {{getGroupedFacetQueryCount}} in the grouping case)
> At a glance, most other callers of
> {{SolrIndexSearcher.numDocs(Query,DocSet)}} could be trivially optimize this
> way as well -- at a minimum to eliminate Query parsing/construction.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mkhludnev merged pull request #2111: SOLR-8673 Enable custom aggregate functions by opening up FacetContex…
mkhludnev merged pull request #2111: URL: https://github.com/apache/lucene-solr/pull/2111 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-8673) o.a.s.search.facet classes not public/extendable
[
https://issues.apache.org/jira/browse/SOLR-8673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244989#comment-17244989
]
ASF subversion and git services commented on SOLR-8673:
---
Commit 510f96c69c559c53a4f62281b48937a5f887dcc2 in lucene-solr's branch
refs/heads/master from Tim Owen
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=510f96c ]
SOLR-8673: Enable custom aggregate functions by opening up FacetContext
Prior to this change, it was not feasible to write a custom aggregate function
in plugin code
because the FacetContext class did not expose its fields for access outside its
package. Also
some of the useful abstract classes for SlotAcc were package-private too
> o.a.s.search.facet classes not public/extendable
>
>
> Key: SOLR-8673
> URL: https://issues.apache.org/jira/browse/SOLR-8673
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Affects Versions: 5.4.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 6.2, 7.0
>
> Attachments: SOLR-8673.patch, SOLR-8673.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It is not easy to create a custom JSON facet function. A simple function
> based on AvgAgg quickly results in the following compilation failures:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile)
> on project openindex-solr: Compilation failure: Compilation failure:
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[22,36]
> org.apache.solr.search.facet.FacetContext is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[23,36]
> org.apache.solr.search.facet.FacetDoubleMerger is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[40,32]
> cannot find symbol
> [ERROR] symbol: class FacetContext
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[49,39]
> cannot find symbol
> [ERROR] symbol: class FacetDoubleMerger
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[54,43]
> cannot find symbol
> [ERROR] symbol: class Context
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg.Merger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[41,16]
> cannot find symbol
> [ERROR] symbol: class AvgSlotAcc
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[46,12]
> incompatible types: i.o.s.search.facet.CustomAvgAgg.Merger cannot be
> converted to org.apache.solr.search.facet.FacetMerger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[53,5]
> method does not override or implement a method from a supertype
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[60,5]
> method does not override or implement a method from a supertype
> {code}
> It seems lots of classes are tucked away in FacetModule, which we can't reach
> from outside.
> Originates from this thread:
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201602.mbox/%3ccab_8yd9ldbg_0zxm_h1igkfm6bqeypd5ilyy7tty8cztscv...@mail.gmail.com%3E
> ( also available at
> https://lists.apache.org/thread.html/9fddcad3136ec908ce1c57881f8d3069e5d153f08b71f80f3e18d995%401455019826%40%3Csolr-user.lucene.apache.org%3E
> )
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mkhludnev opened a new pull request #2124: SOLR-8673: Open JSON Facet for extension
mkhludnev opened a new pull request #2124: URL: https://github.com/apache/lucene-solr/pull/2124 # Description Please provide a short description of the changes you're making with this pull request. # Solution Please provide a short description of the approach taken to implement your solution. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [ ] I have developed this patch against the `master` branch. - [ ] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mkhludnev closed pull request #2124: SOLR-8673: Open JSON Facet for extension
mkhludnev closed pull request #2124: URL: https://github.com/apache/lucene-solr/pull/2124 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
