[jira] [Resolved] (SOLR-14693) Using `fl=[explain]` (ExplainAugmenterFactory) does not work when grouping is enabled and collection has only one shard
[ https://issues.apache.org/jira/browse/SOLR-14693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Munendra S N resolved SOLR-14693. - Resolution: Duplicate [~cburnettlw] This is duplicate of SOLR-9622. Let me know if you are interested in fixing this. > Using `fl=[explain]` (ExplainAugmenterFactory) does not work when grouping is > enabled and collection has only one shard > --- > > Key: SOLR-14693 > URL: https://issues.apache.org/jira/browse/SOLR-14693 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 8.4.1 > Environment: Linux kernel 5.4.0-42-generic > OpenJDK 64-bit Server VM 11.0.8 11.0.8+10 >Reporter: Charles Burnett >Priority: Minor > > Explain field is added, as expected, in the following scenarios: > * Grouping is disabled > * Grouping is enabled and collection has more than one shard > Explain field is NOT added to documents in the following scenario: > * Grouping is enabled and collection has only one shard > -- 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 commented on a change in pull request #1707: SOLR-14692: Allow 'method' specification on JSON Facet join domain transforms
munendrasn commented on a change in pull request #1707:
URL: https://github.com/apache/lucene-solr/pull/1707#discussion_r463944761
##
File path: solr/core/src/java/org/apache/solr/search/JoinQParserPlugin.java
##
@@ -182,9 +203,34 @@ public Query parse() throws SyntaxError {
* @param subQuery the query to define the starting set of documents on the
"left side" of the join
* @param fromField "left side" field name to use in the join
* @param toField "right side" field name to use in the join
+ * @param method indicates which implementation should be used to process
the join. Currently only 'index',
+ * 'dvWithScore', and 'topLevelDV' are supported.
*/
- public static Query createJoinQuery(Query subQuery, String fromField, String
toField) {
-return new JoinQuery(fromField, toField, null, subQuery);
+ public static Query createJoinQuery(Query subQuery, String fromField, String
toField, String method) {
+final EnumSet methodWhitelist = EnumSet.of(Method.index,
Method.topLevelDV, Method.dvWithScore);
Review comment:
I think this could be reused by creating static enumSet
##
File path: solr/core/src/java/org/apache/solr/search/facet/FacetRequest.java
##
@@ -163,15 +166,23 @@ public boolean canBecomeNonEmpty() {
/** Are we doing a query time join across other documents */
public static class JoinField {
+ public static final String FROM_PARAM = "from";
+ public static final String TO_PARAM = "to";
+ public static final String METHOD_PARAM = "method";
+ public static final Set SUPPORTED_JOIN_PROPERTIES =
Sets.newHashSet(FROM_PARAM, TO_PARAM, METHOD_PARAM);
Review comment:
these variables could be package-private or preferably private
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] munendrasn commented on a change in pull request #1707: SOLR-14692: Allow 'method' specification on JSON Facet join domain transforms
munendrasn commented on a change in pull request #1707:
URL: https://github.com/apache/lucene-solr/pull/1707#discussion_r463944894
##
File path: solr/core/src/java/org/apache/solr/search/facet/FacetRequest.java
##
@@ -163,15 +166,23 @@ public boolean canBecomeNonEmpty() {
/** Are we doing a query time join across other documents */
public static class JoinField {
+ public static final String FROM_PARAM = "from";
+ public static final String TO_PARAM = "to";
+ public static final String METHOD_PARAM = "method";
+ public static final Set SUPPORTED_JOIN_PROPERTIES =
Sets.newHashSet(FROM_PARAM, TO_PARAM, METHOD_PARAM);
Review comment:
these variables could be package-private
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-14657) spurious ERRORs due to race condition between SolrIndexSearcher metrics and IndexReader closing
[
https://issues.apache.org/jira/browse/SOLR-14657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17169269#comment-17169269
]
Lucene/Solr QA commented on SOLR-14657:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
30s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 2m 50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 2m 50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 2m 50s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 68m
47s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 75m 52s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-14657 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/13008855/SOLR-14657.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 / 07a89e7 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/787/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/787/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> spurious ERRORs due to race condition between SolrIndexSearcher metrics and
> IndexReader closing
> ---
>
> Key: SOLR-14657
> URL: https://issues.apache.org/jira/browse/SOLR-14657
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-14657.patch, SOLR-14657.patch
>
>
> I've seen situations in the wild where systems monitoring/polling metrics can
> trigger scary looking - but otherwise benign - ERRORs due to
> AlreadyClosedExceptions if/when the searcher/reader is in the process of
> being re-opened and the Gauge tries to call reader.numDocs(), etc...
> We should tweak the metrics logic to just ignore these exceptions
--
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-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17169287#comment-17169287
]
Mark Robert Miller commented on SOLR-14636:
---
Back to easy mode. Expect a beta quality level announce this week - right in
time for my birthday.
I won't miss fighting this stuff in hard mode - the first time is was
rewarding, the second time it was annoying and every time after you can hear me
swearing a fair a bit of the day. My wife exclaims "tests!? you are not working
on tests are you? I hope not." The problem is, it's too much stuff and too much
in between and I don't remember a lot and so I end up following the same dumb
dead ends and bad paths to get to the same point and as I'm hitting the new key
frames, I'm recalling and its like, jesus, did I really have to spend another
day to come to the same thing when if I'd remembered details any better it
would have been 15 min.
I'm in a pretty good place to level out at though. If anyone wants any further
details on anything Solr/SolrCloud deep dive, making it actually good and fast
and stable, sooner is better than later, I'm like that guy from Memento. I know
it offends some people to offer to show you how to make Solr good, especially
when so much of it ends up sounding condescending, but I'm sure everyone is
better at 1000 other things than me, smarter in 100 ways - but I'm also pretty
sure I'm ahead of everyone else on making Solr work. It's not my fault a lot of
the problems come back to basics in the end. That's how I found the place, it's
not my invention.
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg, jenkins.png
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> *tests***:
> * *core*: {color:#00875a}*extremely stable*{color} with
> *{color:#de350b}ignores{color}*
> * *solrj*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *test-framework*: *extremely stable* with {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: *extremely stable* with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: {color:#00875a}*extremely stable*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: {color:#00875a}*extremely
> stable*{color} with *{color:#de350b}ignores{color}*
> * *contrib/extraction*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: {color:#00875a}*extremely
> stable*{color} with {color:#de350b}*ignores*{color}
> * *contrib/langid*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: {color:#00875a}*extremely stable*{color}
> with {color:#de350b}*ignores*{color}
> * *contrib/velocity*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
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-14700) CloudSolrClient cannot be used without setting an explicit streamContext
Mads Bondo Dydensborg created SOLR-14700:
Summary: CloudSolrClient cannot be used without setting an
explicit streamContext
Key: SOLR-14700
URL: https://issues.apache.org/jira/browse/SOLR-14700
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: clients - java
Affects Versions: 8.6
Reporter: Mads Bondo Dydensborg
A naive approach to using CloudSolrClient, such as on this page:
[http://joelsolr.blogspot.com/2015/04/the-streaming-api-solrjio-basics.html] -
will not work: opening the stream will throw an IOException with an embedded
NullPointerException.
This took me a while to figure out, and I think it would be good to either
update the documentation or "fix" the constructor to set the needed
streamContext as appropriate.
I found this snippet of code in TuppleStream.java, that seems to "almost" work
without a streamContext:
{code:java}
// line 127 in the sources to TuppleStream.java:
public static List getShards(String zkHost,
String collection,
StreamContext streamContext,
SolrParams requestParams)
...
// line 135
if(streamContext != null) {
shardsMap = (Map>)streamContext.get("shards");
}
...
// line 144
CloudSolrClient cloudSolrClient =
Optional.ofNullable(streamContext.getSolrClientCache()).orElseGet(SolrClientCache::new).getCloudSolrClient(zkHost);
{code}
if streamContext is null in the last statement, a NullPointerException will be
thrown and open'ening the stream will fail.
This took me way too long time to figure out.
--
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-14700) CloudSolrClient cannot be used without setting an explicit streamContext
[
https://issues.apache.org/jira/browse/SOLR-14700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17169295#comment-17169295
]
Mads Bondo Dydensborg commented on SOLR-14700:
--
Workaround is to set a default streamContext:
{code:java}
try (CloudSolrStream cstream = new CloudSolrStream(zkHost, collection, params))
{
StreamContext streamContext = new StreamContext();
cstream.setStreamContext(streamContext);
cstream.open();
{code}
still think this should be clearer though.
> CloudSolrClient cannot be used without setting an explicit streamContext
>
>
> Key: SOLR-14700
> URL: https://issues.apache.org/jira/browse/SOLR-14700
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java
>Affects Versions: 8.6
>Reporter: Mads Bondo Dydensborg
>Priority: Minor
>
> A naive approach to using CloudSolrClient, such as on this page:
> [http://joelsolr.blogspot.com/2015/04/the-streaming-api-solrjio-basics.html]
> - will not work: opening the stream will throw an IOException with an
> embedded NullPointerException.
> This took me a while to figure out, and I think it would be good to either
> update the documentation or "fix" the constructor to set the needed
> streamContext as appropriate.
> I found this snippet of code in TuppleStream.java, that seems to "almost"
> work without a streamContext:
> {code:java}
> // line 127 in the sources to TuppleStream.java:
> public static List getShards(String zkHost,
>String collection,
>StreamContext streamContext,
>SolrParams requestParams)
> ...
> // line 135
> if(streamContext != null) {
> shardsMap = (Map>)streamContext.get("shards");
> }
> ...
> // line 144
> CloudSolrClient cloudSolrClient =
>
> Optional.ofNullable(streamContext.getSolrClientCache()).orElseGet(SolrClientCache::new).getCloudSolrClient(zkHost);
> {code}
> if streamContext is null in the last statement, a NullPointerException will
> be thrown and open'ening the stream will fail.
> This took me way too long time to figure out.
--
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=17169319#comment-17169319 ] Ankur commented on LUCENE-9444: --- Any thoughts folks ? > 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 > > 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] [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=17169367#comment-17169367
]
Michael McCandless commented on LUCENE-9444:
Yeah +1 for some simple sugar API here. We want to make it easy for users to
get back their originally indexed facet labels.
Maybe {{String[] getLabels(int docId, String dim)}} so the caller can filter to
a specific dimension (facet field)?
But one tricky part of this is, under the hood, this API must pull a
{{BinaryDocValues}} iterator, {{advanceExact}} to that {{docId}}, retrieve the
{{byte[]}} and then decode the ordinals. Should we maybe allow/require caller
to pass in the {{BinaryDocValues}} for reuse?
Another trickiness is what to do with hierarchical fields? Would we return a
{{String}} that joined with the standard separator character? Maybe we should
return {{FacetLabel[]}} instead?
> 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
>
> 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
