[GitHub] [lucene-solr] munendrasn commented on a change in pull request #1371: SOLR-14333: print readable version of CollapsedPostFilter query
munendrasn commented on a change in pull request #1371:
URL: https://github.com/apache/lucene-solr/pull/1371#discussion_r491312573
##
File path:
solr/core/src/java/org/apache/solr/search/CollapsingQParserPlugin.java
##
@@ -188,6 +206,11 @@ public int hashCode() {
return 17 * (31 + selectorText.hashCode()) * (31 + type.hashCode());
}
+@Override
+public String toString(){
+ return "groupHeadSelectorText=" +this.selectorText + ",
groupHeadSelectorType=" +this.type;
Review comment:
would it be better to include the class name too here?
```suggestion
return "GroupHeadSelector[selectorText=" +this.selectorText + ",
type=" +this.type + "]";
```
##
File path:
solr/core/src/java/org/apache/solr/search/CollapsingQParserPlugin.java
##
@@ -128,6 +128,28 @@ field collapsing (with ngroups) when the number of
distinct groups
public static final String HINT_TOP_FC = "top_fc";
public static final String HINT_MULTI_DOCVALUES = "multi_docvalues";
+ public enum NullPolicy {
+IGNORE("ignore", 0),
Review comment:
I agree with @madrob about removing the unused declarations but as
access the public for these variables. I think we should deprecate it in this
PR(for 8x) and remove it in different PR
wdyt?
##
File path:
solr/core/src/java/org/apache/solr/search/CollapsingQParserPlugin.java
##
@@ -279,7 +299,12 @@ public int getCost() {
}
public String toString(String s) {
- return s;
+ return "{!collapse field=" + this.collapseField +
+ ", nullPolicy=" + this.nullPolicy.getName() + ", " +
+ this.groupHeadSelector.toString() +
+ (hint == null ? "": ", hint=" + this.hint) +
+ ", size=" + this.size
+ + "}";
Review comment:
The above suggestion might lead cause this in debug response
```
CollapsingPostFilter([CollapsingPostFilter field=id, nullPolicy=expand,
GroupHeadSelector[selectorText=_version_ asc, type=SORT], hint=top_fc,
size=5000])
```
This is caused due to how Query is converted to String by `QueryParsing`
Class but I think that should be handled separately as issue exists for
different query type
https://github.com/apache/lucene-solr/blob/ab3f1f0d1d0fcdbe58958197b11ba3837795a24a/solr/core/src/java/org/apache/solr/search/QueryParsing.java#L336
##
File path:
solr/core/src/java/org/apache/solr/search/CollapsingQParserPlugin.java
##
@@ -279,7 +299,12 @@ public int getCost() {
}
public String toString(String s) {
- return s;
+ return "{!collapse field=" + this.collapseField +
+ ", nullPolicy=" + this.nullPolicy.getName() + ", " +
+ this.groupHeadSelector.toString() +
+ (hint == null ? "": ", hint=" + this.hint) +
+ ", size=" + this.size
+ + "}";
Review comment:
`{!collapse` specifies the query parser, I think we shouldn't include it
in toString()
```suggestion
return "CollapsingPostFilter[field=" + this.collapseField +
", nullPolicy=" + this.nullPolicy.getName() + ", " +
this.groupHeadSelector +
(hint == null ? "": ", hint=" + this.hint) +
", size=" + this.size
+ "]";
```
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-14802) Sorting by min of two geodist functions
[
https://issues.apache.org/jira/browse/SOLR-14802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17198706#comment-17198706
]
Tom Edge commented on SOLR-14802:
-
Excellent! Sounds good to me, this will be really useful for some work our team
are doing at the moment
> Sorting by min of two geodist functions
> ---
>
> Key: SOLR-14802
> URL: https://issues.apache.org/jira/browse/SOLR-14802
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: spatial
>Reporter: Shaun Storey
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Previously using geo field with type LatLonType you could implement a query
> like
> {code:java}
> /select?q=*:*&fl=ID&fq={!geofilt}&d=50&pt=53.4721936,-2.24703&sfield=MAIN_LOCATION&sort=min(geodist(),
> geodist(ALT_LOCATION,53.4721936,-2.24703)) asc{code}
> to sort results on minium distance from multiple different locations. Moving
> the fields to advised LatLonPointSpatialField gives
> "geodist() does not support field names in its arguments when stated fields
> are solr.LatLonPointSpatialField spatial type, requires sfield param instead"
> This has been reviewed before SOLR-11601 but not for my actual actual
> use-case so it seems the choice was to just change the error message rather
> than to implement the previous functionality. Can this be re-reviewed or let
> me know if there is another way to achieve the same result.
>
--
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-9444) Need an API to easily fetch facet labels for a field in a document
[
https://issues.apache.org/jira/browse/LUCENE-9444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17198780#comment-17198780
]
Ankur commented on LUCENE-9444:
---
Thanks [~mikemccand] for making those changes. I made a couple of minor edits
* Fixed typo in javadoc
* Replaced
{code:java}
if (parentOrd == INVALID_ORDINAL) {
throw new AssertionError("Root ordinal not found for facet dimension: "
+ facetDimension);
}{code}
with single line
{code:java}
assert parentOrd != INVALID_ORDINAL : "Category ordinal not found for facet
dimension: " + facetDimension; {code}
in method
{code:java}
public FacetLabel nextFacetLabel(int docId, String facetDimension) throws
IOException{code}
* Created a pull request as you suggested in one of your earlier comments :)
**
[https://github.com/apache/lucene-solr/pull/1893/commits/bf8eaf98901cbe83f23067bea90dfb2f3102603a]
Can you take a look and see if it's ready to be committed ?
> Need an API to easily fetch facet labels for a field in a document
> --
>
> Key: LUCENE-9444
> URL: https://issues.apache.org/jira/browse/LUCENE-9444
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/facet
>Affects Versions: 8.6
>Reporter: Ankur
>Priority: Major
> Labels: facet
> Attachments: LUCENE-9444.patch, LUCENE-9444.patch,
> LUCENE-9444.v2.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A facet field may be included in the list of fields whose values are to be
> returned for each hit.
> In order to get the facet labels for each hit we need to
> # Create an instance of _DocValuesOrdinalsReader_ and invoke
> _getReader(LeafReaderContext context)_ method to obtain an instance of
> _OrdinalsSegmentReader()_
> # _OrdinalsSegmentReader.get(int docID, IntsRef ordinals)_ method is then
> used to fetch and decode the binary payload in the document's BinaryDocValues
> field. This provides the ordinals that refer to facet labels in the
> taxonomy.**
> # Lastly TaxonomyReader.getPath(ord) is used to fetch the labels to be
> returned.
>
> Ideally there should be a simple API - *String[] getLabels(docId)* that hides
> all the above details and gives us the string labels. This can be part of
> *TaxonomyFacets* but that's just one idea.
> I am opening this issue to get community feedback and suggestions.
>
--
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] (LUCENE-9444) Need an API to easily fetch facet labels for a field in a document
[
https://issues.apache.org/jira/browse/LUCENE-9444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17198780#comment-17198780
]
Ankur edited comment on LUCENE-9444 at 9/19/20, 6:30 PM:
-
Thanks [~mikemccand] for making those changes. I made a couple of minor edits
to _TaxonomyFacetLabels.java_
* Removed the reference to \{@link java.util.Iterator} as it is no longer used.
* Fixed typo in javadoc.
* Replaced
{code:java}
if (parentOrd == INVALID_ORDINAL) {
throw new AssertionError("Root ordinal not found for facet dimension: "
+ facetDimension);
}{code}
with single line
{code:java}
assert parentOrd != INVALID_ORDINAL : "Category ordinal not found for facet
dimension: " + facetDimension; {code}
in method
{code:java}
public FacetLabel nextFacetLabel(int docId, String facetDimension) throws
IOException{code}
* Created a pull request as you suggested in one of your earlier comments :)
**
[https://github.com/apache/lucene-solr/pull/1893/commits/bf8eaf98901cbe83f23067bea90dfb2f3102603a]
Can you take a look and see if it's ready to be committed ?
was (Author: goankur):
Thanks [~mikemccand] for making those changes. I made a couple of minor edits
* Fixed typo in javadoc
* Replaced
{code:java}
if (parentOrd == INVALID_ORDINAL) {
throw new AssertionError("Root ordinal not found for facet dimension: "
+ facetDimension);
}{code}
with single line
{code:java}
assert parentOrd != INVALID_ORDINAL : "Category ordinal not found for facet
dimension: " + facetDimension; {code}
in method
{code:java}
public FacetLabel nextFacetLabel(int docId, String facetDimension) throws
IOException{code}
* Created a pull request as you suggested in one of your earlier comments :)
**
[https://github.com/apache/lucene-solr/pull/1893/commits/bf8eaf98901cbe83f23067bea90dfb2f3102603a]
Can you take a look and see if it's ready to be committed ?
> Need an API to easily fetch facet labels for a field in a document
> --
>
> Key: LUCENE-9444
> URL: https://issues.apache.org/jira/browse/LUCENE-9444
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/facet
>Affects Versions: 8.6
>Reporter: Ankur
>Priority: Major
> Labels: facet
> Attachments: LUCENE-9444.patch, LUCENE-9444.patch,
> LUCENE-9444.v2.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A facet field may be included in the list of fields whose values are to be
> returned for each hit.
> In order to get the facet labels for each hit we need to
> # Create an instance of _DocValuesOrdinalsReader_ and invoke
> _getReader(LeafReaderContext context)_ method to obtain an instance of
> _OrdinalsSegmentReader()_
> # _OrdinalsSegmentReader.get(int docID, IntsRef ordinals)_ method is then
> used to fetch and decode the binary payload in the document's BinaryDocValues
> field. This provides the ordinals that refer to facet labels in the
> taxonomy.**
> # Lastly TaxonomyReader.getPath(ord) is used to fetch the labels to be
> returned.
>
> Ideally there should be a simple API - *String[] getLabels(docId)* that hides
> all the above details and gives us the string labels. This can be part of
> *TaxonomyFacets* but that's just one idea.
> I am opening this issue to get community feedback and suggestions.
>
--
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-14878) SystemInfoHandler need to expose coreRootDirectory
Alexandre Rafalovitch created SOLR-14878: Summary: SystemInfoHandler need to expose coreRootDirectory Key: SOLR-14878 URL: https://issues.apache.org/jira/browse/SOLR-14878 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Alexandre Rafalovitch Assignee: Alexandre Rafalovitch solr.xml allows to define *coreRootDirectory* but it is currently impossible to get this value through API, which makes external commands (like /bin/solr create_core) fail when this parameter is set. Expose this property if it is set to a value different from solr_home. -- 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-14878) SystemInfoHandler need to expose coreRootDirectory
[ https://issues.apache.org/jira/browse/SOLR-14878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch updated SOLR-14878: - Description: solr.xml allows to define *coreRootDirectory* but it is currently impossible to get this value through API, which makes external commands (like /bin/solr create_core) fail when this parameter is set. Expose this property if it is set to a value different from solr_home. It will be accessible under the name *solr_core_root* and accessible from both System Settings API end-points * /solr/admin/info/system * /api/node/system was: solr.xml allows to define *coreRootDirectory* but it is currently impossible to get this value through API, which makes external commands (like /bin/solr create_core) fail when this parameter is set. Expose this property if it is set to a value different from solr_home. > SystemInfoHandler need to expose coreRootDirectory > -- > > Key: SOLR-14878 > URL: https://issues.apache.org/jira/browse/SOLR-14878 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > > solr.xml allows to define *coreRootDirectory* but it is currently impossible > to get this value through API, which makes external commands (like /bin/solr > create_core) fail when this parameter is set. > Expose this property if it is set to a value different from solr_home. > It will be accessible under the name *solr_core_root* and accessible from > both System Settings API end-points > * /solr/admin/info/system > * /api/node/system -- 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] arafalov opened a new pull request #1894: SOLR-14878: Expose solr.xml's coreRootDirectory property via the System Settings API
arafalov opened a new pull request #1894: URL: https://github.com/apache/lucene-solr/pull/1894 # Description Even if coreRootDirectory was set in solr.xml, external applications could not access it through the API. It was not exposed. This means it is not possible to run a command such as *bin/solr create_core -c test* as the code that pre-populates the core directory is doing it in the wrong place (if at all). # Solution Expose the property if it is defined and is different from solr_home # Checklist Please review the following and check all that apply: - [X] 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. - [X] I have created a Jira issue and added the issue ID to my pull request title. - [X] 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) - [X] I have developed this patch against the `master` branch. - [X] I have run `./gradlew check`. 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] arafalov merged pull request #1894: SOLR-14878: Expose solr.xml's coreRootDirectory property via the System Settings API
arafalov merged pull request #1894: URL: https://github.com/apache/lucene-solr/pull/1894 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] (SOLR-14878) SystemInfoHandler need to expose coreRootDirectory
[ https://issues.apache.org/jira/browse/SOLR-14878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch resolved SOLR-14878. -- Resolution: Fixed > SystemInfoHandler need to expose coreRootDirectory > -- > > Key: SOLR-14878 > URL: https://issues.apache.org/jira/browse/SOLR-14878 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Fix For: master (9.0) > > Time Spent: 20m > Remaining Estimate: 0h > > solr.xml allows to define *coreRootDirectory* but it is currently impossible > to get this value through API, which makes external commands (like /bin/solr > create_core) fail when this parameter is set. > Expose this property if it is set to a value different from solr_home. > It will be accessible under the name *solr_core_root* and accessible from > both System Settings API end-points > * /solr/admin/info/system > * /api/node/system -- 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-14878) SystemInfoHandler need to expose coreRootDirectory
[ https://issues.apache.org/jira/browse/SOLR-14878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch updated SOLR-14878: - Fix Version/s: master (9.0) > SystemInfoHandler need to expose coreRootDirectory > -- > > Key: SOLR-14878 > URL: https://issues.apache.org/jira/browse/SOLR-14878 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Fix For: master (9.0) > > Time Spent: 20m > Remaining Estimate: 0h > > solr.xml allows to define *coreRootDirectory* but it is currently impossible > to get this value through API, which makes external commands (like /bin/solr > create_core) fail when this parameter is set. > Expose this property if it is set to a value different from solr_home. > It will be accessible under the name *solr_core_root* and accessible from > both System Settings API end-points > * /solr/admin/info/system > * /api/node/system -- 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-14878) SystemInfoHandler need to expose coreRootDirectory
[ https://issues.apache.org/jira/browse/SOLR-14878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17198858#comment-17198858 ] ASF subversion and git services commented on SOLR-14878: Commit f6e8bc8c31fac48d8196cd8a94de743e755597df in lucene-solr's branch refs/heads/master from Alexandre Rafalovitch [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f6e8bc8 ] SOLR-14878: Expose solr.xml's coreRootDirectory property via the System Settings API (#1894) > SystemInfoHandler need to expose coreRootDirectory > -- > > Key: SOLR-14878 > URL: https://issues.apache.org/jira/browse/SOLR-14878 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > solr.xml allows to define *coreRootDirectory* but it is currently impossible > to get this value through API, which makes external commands (like /bin/solr > create_core) fail when this parameter is set. > Expose this property if it is set to a value different from solr_home. > It will be accessible under the name *solr_core_root* and accessible from > both System Settings API end-points > * /solr/admin/info/system > * /api/node/system -- 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-14879) address TestPackages test failures
Noble Paul created SOLR-14879: - Summary: address TestPackages test failures Key: SOLR-14879 URL: https://issues.apache.org/jira/browse/SOLR-14879 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul -- 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-14880) bin/solr create_core should work when coreRootDirectory is defined
Alexandre Rafalovitch created SOLR-14880: Summary: bin/solr create_core should work when coreRootDirectory is defined Key: SOLR-14880 URL: https://issues.apache.org/jira/browse/SOLR-14880 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: SolrCLI Reporter: Alexandre Rafalovitch Assignee: Alexandre Rafalovitch If coreRootDirectory is defined in solr.xml, new core creation command fails (in standalone Solr). Looking at the code, it tries to populate solr_home, even if the core should go somewhere else. So, when the actual core creation command is called, it cannot find its pre-populated files and bails with bq. ERROR: Error CREATEing SolrCore 'test3': Unable to create core [test3] Caused by: Can't find resource 'solrconfig.xml' in classpath or '/tmp/test3' -- 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-14879) address TestPackages test failures
[ https://issues.apache.org/jira/browse/SOLR-14879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-14879: - Assignee: Noble Paul > address TestPackages test failures > -- > > Key: SOLR-14879 > URL: https://issues.apache.org/jira/browse/SOLR-14879 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > -- 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 #1895: SOLR-14879: address TestPackages test failures
noblepaul opened a new pull request #1895: URL: https://github.com/apache/lucene-solr/pull/1895 Looks like the problem is with ManagedSchema. I've modified the test to not use ManagedSchema 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 merged pull request #1895: SOLR-14879: address TestPackages test failures
noblepaul merged pull request #1895: URL: https://github.com/apache/lucene-solr/pull/1895 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-14879) address TestPackages test failures
[ https://issues.apache.org/jira/browse/SOLR-14879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17198868#comment-17198868 ] ASF subversion and git services commented on SOLR-14879: Commit 3664182d24ef9f9efddd684cc1b3b6b9eeb6f966 in lucene-solr's branch refs/heads/master from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3664182 ] SOLR-14879: address TestPackages test failures (#1895) > address TestPackages test failures > -- > > Key: SOLR-14879 > URL: https://issues.apache.org/jira/browse/SOLR-14879 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- 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-14879) address TestPackages test failures
[ https://issues.apache.org/jira/browse/SOLR-14879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17198869#comment-17198869 ] ASF subversion and git services commented on SOLR-14879: Commit 798b6198558033796e748a50411f6dd85e0242cb in lucene-solr's branch refs/heads/branch_8x from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=798b619 ] SOLR-14879: address TestPackages test failures > address TestPackages test failures > -- > > Key: SOLR-14879 > URL: https://issues.apache.org/jira/browse/SOLR-14879 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- 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] arafalov opened a new pull request #1896: SOLR-14880: Support coreRootDirectory setting when create new cores from command line, in standalone mode
arafalov opened a new pull request #1896: URL: https://github.com/apache/lucene-solr/pull/1896 # Description **bin/solr create_core -c test** was failing if solr.xml for the server defined coreRootDirectory different from solr_home. That's because the utility code was assuming solr_home, but was then failing when invoking the server that expected it somewhere else. # Solution Check for extra parameter being present and fall back to solr_home. # Checklist Please review the following and check all that apply: - [X] 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. - [X] I have created a Jira issue and added the issue ID to my pull request title. - [X] 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) - [X] I have developed this patch against the `master` branch. - [X] I have run `./gradlew check`. 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-14788) Solr: The Next Big Thing
[
https://issues.apache.org/jira/browse/SOLR-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Robert Miller updated SOLR-14788:
--
Description:
h3.
[!https://www.unicode.org/consortium/aacimg/1F46E.png!|https://www.unicode.org/consortium/adopted-characters.html#b1F46E]{color:#00875a}*The
Policeman is on duty!*{color}
{quote}_{color:#de350b}*When The Policeman is on duty, sit back, relax, and
have some fun. Try to make some progress. Don't stress too much about the
impact of your changes or maintaining stability and performance and correctness
so much. Until the end of phase 1, I've got your back. I have a variety of
tools and contraptions I have been building over the years and I will continue
training them on this branch. I will review your changes and peer out across
the land and course correct where needed. As Mike D will be thinking, "Sounds
like a bottleneck Mark." And indeed it will be to some extent. Which is why
once stage one is completed, I will flip The Policeman to off duty. When off
duty, I'm always* {color:#de350b}*occasionally*{color} *down for some vigilante
justice, but I won't be walking the beat, all that stuff about sit back and
relax goes out the window.*{color}_
{quote}
I have stolen this title from Ishan or Noble and Ishan.
This issue is meant to capture the work of a small team that is forming to push
Solr and SolrCloud to the next phase.
I have kicked off the work with an effort to create a very fast and solid base.
That work is not 100% done, but it's ready to join the fight.
Tim Potter has started giving me a tremendous hand in finishing up. Ishan and
Noble have already contributed support and testing and have plans for
additional work to shore up some of our current shortcomings.
Others have expressed an interest in helping and hopefully they will pop up
here as well.
Let's organize and discuss our efforts here and in various sub issues.
was:
I have stolen this title from Ishan or Noble and Ishan.
This issue is meant to capture the work of a small team that is forming to push
Solr and SolrCloud to the next phase.
I have kicked off the work with an effort to create a very fast and solid base.
That work is not 100% done, but it's ready to join the fight.
Tim Potter has started giving me a tremendous hand in finishing up. Ishan and
Noble have already contributed support and testing and have plans for
additional work to shore up some of our current shortcomings.
Others have expressed an interest in helping and hopefully they will pop up
here as well.
Let's organize and discuss our efforts here and in various sub issues.
> Solr: The Next Big Thing
>
>
> Key: SOLR-14788
> URL: https://issues.apache.org/jira/browse/SOLR-14788
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mark Robert Miller
>Priority: Critical
>
> h3.
> [!https://www.unicode.org/consortium/aacimg/1F46E.png!|https://www.unicode.org/consortium/adopted-characters.html#b1F46E]{color:#00875a}*The
> Policeman is on duty!*{color}
> {quote}_{color:#de350b}*When The Policeman is on duty, sit back, relax, and
> have some fun. Try to make some progress. Don't stress too much about the
> impact of your changes or maintaining stability and performance and
> correctness so much. Until the end of phase 1, I've got your back. I have a
> variety of tools and contraptions I have been building over the years and I
> will continue training them on this branch. I will review your changes and
> peer out across the land and course correct where needed. As Mike D will be
> thinking, "Sounds like a bottleneck Mark." And indeed it will be to some
> extent. Which is why once stage one is completed, I will flip The Policeman
> to off duty. When off duty, I'm always* {color:#de350b}*occasionally*{color}
> *down for some vigilante justice, but I won't be walking the beat, all that
> stuff about sit back and relax goes out the window.*{color}_
> {quote}
>
> I have stolen this title from Ishan or Noble and Ishan.
> This issue is meant to capture the work of a small team that is forming to
> push Solr and SolrCloud to the next phase.
> I have kicked off the work with an effort to create a very fast and solid
> base. That work is not 100% done, but it's ready to join the fight.
> Tim Potter has started giving me a tremendous hand in finishing up. Ishan and
> Noble have already contributed support and testing and have plans for
> additional work to shore up some of our current shortcomings.
> Others have expressed an interest in helping and hopefully they will pop up
> here as well.
> Let's organize and discuss our efforts here and in various sub issues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
--
[jira] [Commented] (SOLR-14354) HttpShardHandler send requests in async
[
https://issues.apache.org/jira/browse/SOLR-14354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17198892#comment-17198892
]
Mark Robert Miller commented on SOLR-14354:
---
Okay, I'm not really going to be able to give an opinion on this for master.
I certainly think this is the way to go, but there is likely going to be some
fallout if you merge this thing back and release it. You need some really good
scale testing even on top of performance testing I'd wager.
So, sorry, was not much help after all. I will be going this route on the ref
branch though, but just keep in mind, it has major ramifications and
implications that the tests won't even begin to bother about.
> HttpShardHandler send requests in async
> ---
>
> Key: SOLR-14354
> URL: https://issues.apache.org/jira/browse/SOLR-14354
> Project: Solr
> Issue Type: Improvement
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Blocker
> Fix For: master (9.0), 8.7
>
> Attachments: image-2020-03-23-10-04-08-399.png,
> image-2020-03-23-10-09-10-221.png, image-2020-03-23-10-12-00-661.png
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> h2. 1. Current approach (problem) of Solr
> Below is the diagram describe the model on how currently handling a request.
> !image-2020-03-23-10-04-08-399.png!
> The main-thread that handles the search requests, will submit n requests (n
> equals to number of shards) to an executor. So each request will correspond
> to a thread, after sending a request that thread basically do nothing just
> waiting for response from other side. That thread will be swapped out and CPU
> will try to handle another thread (this is called context switch, CPU will
> save the context of the current thread and switch to another one). When some
> data (not all) come back, that thread will be called to parsing these data,
> then it will wait until more data come back. So there will be lots of context
> switching in CPU. That is quite inefficient on using threads.Basically we
> want less threads and most of them must busy all the time, because threads
> are not free as well as context switching. That is the main idea behind
> everything, like executor
> h2. 2. Async call of Jetty HttpClient
> Jetty HttpClient offers async API like this.
> {code:java}
> httpClient.newRequest("http://domain.com/path";)
> // Add request hooks
> .onRequestQueued(request -> { ... })
> .onRequestBegin(request -> { ... })
> // Add response hooks
> .onResponseBegin(response -> { ... })
> .onResponseHeaders(response -> { ... })
> .onResponseContent((response, buffer) -> { ... })
> .send(result -> { ... }); {code}
> Therefore after calling {{send()}} the thread will return immediately without
> any block. Then when the client received the header from other side, it will
> call {{onHeaders()}} listeners. When the client received some {{byte[]}} (not
> all response) from the data it will call {{onContent(buffer)}} listeners.
> When everything finished it will call {{onComplete}} listeners. One main
> thing that will must notice here is all listeners should finish quick, if the
> listener block, all further data of that request won’t be handled until the
> listener finish.
> h2. 3. Solution 1: Sending requests async but spin one thread per response
> Jetty HttpClient already provides several listeners, one of them is
> InputStreamResponseListener. This is how it is get used
> {code:java}
> InputStreamResponseListener listener = new InputStreamResponseListener();
> client.newRequest(...).send(listener);
> // Wait for the response headers to arrive
> Response response = listener.get(5, TimeUnit.SECONDS);
> if (response.getStatus() == 200) {
> // Obtain the input stream on the response content
> try (InputStream input = listener.getInputStream()) {
> // Read the response content
> }
> } {code}
> In this case, there will be 2 thread
> * one thread trying to read the response content from InputStream
> * one thread (this is a short-live task) feeding content to above
> InputStream whenever some byte[] is available. Note that if this thread
> unable to feed data into InputStream, this thread will wait.
> By using this one, the model of HttpShardHandler can be written into
> something like this
> {code:java}
> handler.sendReq(req, (is) -> {
> executor.submit(() ->
> try (is) {
> // Read the content from InputStream
> }
> )
> }) {code}
> The first diagram will be changed into this
> !image-2020-03-23-10-09-10-221.png!
> Notice that although “sending req to shard1” is wide, it won’t take long time
> since sending req is a very quick operation. With this operation, handling
> threads won’t be spin up until first byte
