[jira] [Updated] (SOLR-14583) Spell suggestion is returned even if hits are non-zero when spellcheck.maxResultsForSuggest=0
[
https://issues.apache.org/jira/browse/SOLR-14583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-14583:
Status: Patch Available (was: Open)
> Spell suggestion is returned even if hits are non-zero when
> spellcheck.maxResultsForSuggest=0
> -
>
> Key: SOLR-14583
> URL: https://issues.apache.org/jira/browse/SOLR-14583
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-14583.patch
>
>
> SOLR-4280 added to support fractional support for
> spellcheck.maxResultsForSuggest. After SOLR-4280,
> {{spellcheck.maxResultsForSuggest=0}} is treated same as not specify the
> {{spellcheck.maxResultsForSuggest}} parameter. This can cause spell
> suggestions to be returned even when hits are non-zero and greater than
> {{spellcheck.maxResultsForSuggest}} (i.e, greater than 0)
--
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-14583) Spell suggestion is returned even if hits are non-zero when spellcheck.maxResultsForSuggest=0
[
https://issues.apache.org/jira/browse/SOLR-14583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-14583:
Attachment: SOLR-14583.patch
> Spell suggestion is returned even if hits are non-zero when
> spellcheck.maxResultsForSuggest=0
> -
>
> Key: SOLR-14583
> URL: https://issues.apache.org/jira/browse/SOLR-14583
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-14583.patch
>
>
> SOLR-4280 added to support fractional support for
> spellcheck.maxResultsForSuggest. After SOLR-4280,
> {{spellcheck.maxResultsForSuggest=0}} is treated same as not specify the
> {{spellcheck.maxResultsForSuggest}} parameter. This can cause spell
> suggestions to be returned even when hits are non-zero and greater than
> {{spellcheck.maxResultsForSuggest}} (i.e, greater than 0)
--
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-14583) Spell suggestion is returned even if hits are non-zero when spellcheck.maxResultsForSuggest=0
[
https://issues.apache.org/jira/browse/SOLR-14583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17155901#comment-17155901
]
Munendra S N commented on SOLR-14583:
-
[^SOLR-14583.patch]
The patch with the support and simple test
> Spell suggestion is returned even if hits are non-zero when
> spellcheck.maxResultsForSuggest=0
> -
>
> Key: SOLR-14583
> URL: https://issues.apache.org/jira/browse/SOLR-14583
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-14583.patch
>
>
> SOLR-4280 added to support fractional support for
> spellcheck.maxResultsForSuggest. After SOLR-4280,
> {{spellcheck.maxResultsForSuggest=0}} is treated same as not specify the
> {{spellcheck.maxResultsForSuggest}} parameter. This can cause spell
> suggestions to be returned even when hits are non-zero and greater than
> {{spellcheck.maxResultsForSuggest}} (i.e, greater than 0)
--
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-11262) XML writer does not implement PushWriter
[ https://issues.apache.org/jira/browse/SOLR-11262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Munendra S N updated SOLR-11262: Attachment: SOLR-11262.patch > XML writer does not implement PushWriter > > > Key: SOLR-11262 > URL: https://issues.apache.org/jira/browse/SOLR-11262 > Project: Solr > Issue Type: Bug >Reporter: Yonik Seeley >Priority: Major > Attachments: SOLR-11262.patch > > > While implementing points support for the terms component in a streaming > manner (via PushWriter/MapWriter) I discovered that the XML response writer > does not implement this interface. > This means that any code using PushWriter (via MapWriter or IteratorWriter) > will be broken if one tries to use XML response format. This may easily go > unnoticed if one is not using XML response format in testing (JSON or binary > is frequently used). -- 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-11262) XML writer does not implement PushWriter
[ https://issues.apache.org/jira/browse/SOLR-11262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17155903#comment-17155903 ] Munendra S N commented on SOLR-11262: - [^SOLR-11262.patch] Implements writeMap and writeIterator in XmlWriter > XML writer does not implement PushWriter > > > Key: SOLR-11262 > URL: https://issues.apache.org/jira/browse/SOLR-11262 > Project: Solr > Issue Type: Bug >Reporter: Yonik Seeley >Priority: Major > Attachments: SOLR-11262.patch > > > While implementing points support for the terms component in a streaming > manner (via PushWriter/MapWriter) I discovered that the XML response writer > does not implement this interface. > This means that any code using PushWriter (via MapWriter or IteratorWriter) > will be broken if one tries to use XML response format. This may easily go > unnoticed if one is not using XML response format in testing (JSON or binary > is frequently used). -- 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-11262) XML writer does not implement PushWriter
[ https://issues.apache.org/jira/browse/SOLR-11262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Munendra S N updated SOLR-11262: Status: Patch Available (was: Open) > XML writer does not implement PushWriter > > > Key: SOLR-11262 > URL: https://issues.apache.org/jira/browse/SOLR-11262 > Project: Solr > Issue Type: Bug >Reporter: Yonik Seeley >Priority: Major > Attachments: SOLR-11262.patch > > > While implementing points support for the terms component in a streaming > manner (via PushWriter/MapWriter) I discovered that the XML response writer > does not implement this interface. > This means that any code using PushWriter (via MapWriter or IteratorWriter) > will be broken if one tries to use XML response format. This may easily go > unnoticed if one is not using XML response format in testing (JSON or binary > is frequently used). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] munendrasn opened a new pull request #1665: SOLR-11262: XML writer implements writeMap and writeIterator
munendrasn opened a new pull request #1665: URL: https://github.com/apache/lucene-solr/pull/1665 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 #1665: SOLR-11262: XML writer implements writeMap and writeIterator
noblepaul commented on a change in pull request #1665:
URL: https://github.com/apache/lucene-solr/pull/1665#discussion_r453166964
##
File path: solr/core/src/test/org/apache/solr/response/TestPushWriter.java
##
@@ -45,26 +46,47 @@
public void testStandardResponse() throws IOException {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
-OutputStreamWriter osw = new OutputStreamWriter(baos,
StandardCharsets.UTF_8);
-PushWriter pw = new JSONWriter(osw,
-new LocalSolrQueryRequest(null, new ModifiableSolrParams()), new
SolrQueryResponse());
-writeData(pw);
-osw.flush();
-if (log.isInfoEnabled()) {
- log.info("{}", new String(baos.toByteArray(), StandardCharsets.UTF_8));
+Map m;
+try (OutputStreamWriter osw = new OutputStreamWriter(baos,
StandardCharsets.UTF_8)) {
+ JSONWriter pw = new JSONWriter(osw,
+ new LocalSolrQueryRequest(null, new ModifiableSolrParams()), new
SolrQueryResponse());
+ writeData(null, pw);
+ osw.flush();
+ if (log.isInfoEnabled()) {
+log.info("{}", new String(baos.toByteArray(), StandardCharsets.UTF_8));
+ }
+ m = (Map) Utils.fromJSON(baos.toByteArray());
+ checkValues(m);
}
-@SuppressWarnings({"rawtypes"})
-Map m = (Map) Utils.fromJSON(baos.toByteArray());
-checkValues(m);
+
try (JavaBinCodec jbc = new JavaBinCodec(baos= new
ByteArrayOutputStream(), null)) {
writeData(jbc);
- try (JavaBinCodec jbcUn = new JavaBinCodec()) {
-m = (Map) jbcUn.unmarshal(new
ByteArrayInputStream(baos.toByteArray()));
- }
+ m = (Map) Utils.fromJavabin(baos.toByteArray());
}
checkValues(m);
}
+ public void testXmlWriter() throws Exception {
+try (ByteArrayOutputStream baos = new ByteArrayOutputStream();
+OutputStreamWriter osw = new OutputStreamWriter(baos,
StandardCharsets.UTF_8)) {
+ XMLWriter xml = new XMLWriter(osw,
+ new LocalSolrQueryRequest(null, new ModifiableSolrParams()), new
SolrQueryResponse());
Review comment:
what is this `LocalSolrQueryRequest` for?
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] [Assigned] (SOLR-14155) Load all other SolrCore plugins from packages
[ https://issues.apache.org/jira/browse/SOLR-14155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-14155: - Assignee: Noble Paul > Load all other SolrCore plugins from packages > - > > Key: SOLR-14155 > URL: https://issues.apache.org/jira/browse/SOLR-14155 > Project: Solr > Issue Type: Sub-task >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14155) Load all other SolrCore plugins from packages
[
https://issues.apache.org/jira/browse/SOLR-14155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-14155:
--
Description:
A few plugins configurable in {{solrconfig.xml}} still cannot be loaded from
packages
# DirectoryFactor
# Updatelog
# Cache
# SolrEventListener (improperly implemented)
> Load all other SolrCore plugins from packages
> -
>
> Key: SOLR-14155
> URL: https://issues.apache.org/jira/browse/SOLR-14155
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> A few plugins configurable in {{solrconfig.xml}} still cannot be loaded from
> packages
> # DirectoryFactor
> # Updatelog
> # Cache
> # SolrEventListener (improperly implemented)
--
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-14155) Load all other SolrCore plugins from packages
[
https://issues.apache.org/jira/browse/SOLR-14155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-14155:
--
Component/s: packages
> Load all other SolrCore plugins from packages
> -
>
> Key: SOLR-14155
> URL: https://issues.apache.org/jira/browse/SOLR-14155
> Project: Solr
> Issue Type: Sub-task
> Components: packages
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> A few plugins configurable in {{solrconfig.xml}} still cannot be loaded from
> packages
> # DirectoryFactor
> # Updatelog
> # Cache
> # SolrEventListener (improperly implemented)
> #1 to #3 should result in reloading the core. #4 can do in-place reload
--
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-14155) Load all other SolrCore plugins from packages
[
https://issues.apache.org/jira/browse/SOLR-14155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-14155:
--
Description:
A few plugins configurable in {{solrconfig.xml}} still cannot be loaded from
packages
# DirectoryFactor
# Updatelog
# Cache
# SolrEventListener (improperly implemented)
#1 to #3 should result in reloading the core. #4 can do in-place reload
was:
A few plugins configurable in {{solrconfig.xml}} still cannot be loaded from
packages
# DirectoryFactor
# Updatelog
# Cache
# SolrEventListener (improperly implemented)
> Load all other SolrCore plugins from packages
> -
>
> Key: SOLR-14155
> URL: https://issues.apache.org/jira/browse/SOLR-14155
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> A few plugins configurable in {{solrconfig.xml}} still cannot be loaded from
> packages
> # DirectoryFactor
> # Updatelog
> # Cache
> # SolrEventListener (improperly implemented)
> #1 to #3 should result in reloading the core. #4 can do in-place reload
--
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-14155) Load all other SolrCore plugins from packages
[
https://issues.apache.org/jira/browse/SOLR-14155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-14155:
--
Fix Version/s: 8.7
> Load all other SolrCore plugins from packages
> -
>
> Key: SOLR-14155
> URL: https://issues.apache.org/jira/browse/SOLR-14155
> Project: Solr
> Issue Type: Sub-task
> Components: packages
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.7
>
>
> A few plugins configurable in {{solrconfig.xml}} still cannot be loaded from
> packages
> # DirectoryFactor
> # Updatelog
> # Cache
> # SolrEventListener (improperly implemented)
> #1 to #3 should result in reloading the core. #4 can do in-place reload
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] munendrasn commented on a change in pull request #1665: SOLR-11262: XML writer implements writeMap and writeIterator
munendrasn commented on a change in pull request #1665:
URL: https://github.com/apache/lucene-solr/pull/1665#discussion_r453169160
##
File path: solr/core/src/test/org/apache/solr/response/TestPushWriter.java
##
@@ -45,26 +46,47 @@
public void testStandardResponse() throws IOException {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
-OutputStreamWriter osw = new OutputStreamWriter(baos,
StandardCharsets.UTF_8);
-PushWriter pw = new JSONWriter(osw,
-new LocalSolrQueryRequest(null, new ModifiableSolrParams()), new
SolrQueryResponse());
-writeData(pw);
-osw.flush();
-if (log.isInfoEnabled()) {
- log.info("{}", new String(baos.toByteArray(), StandardCharsets.UTF_8));
+Map m;
+try (OutputStreamWriter osw = new OutputStreamWriter(baos,
StandardCharsets.UTF_8)) {
+ JSONWriter pw = new JSONWriter(osw,
+ new LocalSolrQueryRequest(null, new ModifiableSolrParams()), new
SolrQueryResponse());
+ writeData(null, pw);
+ osw.flush();
+ if (log.isInfoEnabled()) {
+log.info("{}", new String(baos.toByteArray(), StandardCharsets.UTF_8));
+ }
+ m = (Map) Utils.fromJSON(baos.toByteArray());
+ checkValues(m);
}
-@SuppressWarnings({"rawtypes"})
-Map m = (Map) Utils.fromJSON(baos.toByteArray());
-checkValues(m);
+
try (JavaBinCodec jbc = new JavaBinCodec(baos= new
ByteArrayOutputStream(), null)) {
writeData(jbc);
- try (JavaBinCodec jbcUn = new JavaBinCodec()) {
-m = (Map) jbcUn.unmarshal(new
ByteArrayInputStream(baos.toByteArray()));
- }
+ m = (Map) Utils.fromJavabin(baos.toByteArray());
}
checkValues(m);
}
+ public void testXmlWriter() throws Exception {
+try (ByteArrayOutputStream baos = new ByteArrayOutputStream();
+OutputStreamWriter osw = new OutputStreamWriter(baos,
StandardCharsets.UTF_8)) {
+ XMLWriter xml = new XMLWriter(osw,
+ new LocalSolrQueryRequest(null, new ModifiableSolrParams()), new
SolrQueryResponse());
Review comment:
XmlWriter takes SolrQueryRequest as one of the arg. so, I have created
localSolrQueryRequest
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 opened a new pull request #1666: SOLR-14155: Load all other SolrCore plugins from packages
noblepaul opened a new pull request #1666: URL: https://github.com/apache/lucene-solr/pull/1666 WIP PR, do not commit 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] [Created] (SOLR-14644) Make security plugins loadable from packages
Noble Paul created SOLR-14644: - Summary: Make security plugins loadable from packages Key: SOLR-14644 URL: https://issues.apache.org/jira/browse/SOLR-14644 Project: Solr Issue Type: Sub-task Reporter: Noble Paul -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14583) Spell suggestion is returned even if hits are non-zero when spellcheck.maxResultsForSuggest=0
[
https://issues.apache.org/jira/browse/SOLR-14583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17155966#comment-17155966
]
Lucene/Solr QA commented on SOLR-14583:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
6s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 2s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 45m
13s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 49m 12s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-14583 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/13007462/SOLR-14583.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.15.0-108-generic #109-Ubuntu SMP Fri Jun 19
11:33:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / e355c616b3c |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/778/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/778/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Spell suggestion is returned even if hits are non-zero when
> spellcheck.maxResultsForSuggest=0
> -
>
> Key: SOLR-14583
> URL: https://issues.apache.org/jira/browse/SOLR-14583
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-14583.patch
>
>
> SOLR-4280 added to support fractional support for
> spellcheck.maxResultsForSuggest. After SOLR-4280,
> {{spellcheck.maxResultsForSuggest=0}} is treated same as not specify the
> {{spellcheck.maxResultsForSuggest}} parameter. This can cause spell
> suggestions to be returned even when hits are non-zero and greater than
> {{spellcheck.maxResultsForSuggest}} (i.e, greater than 0)
--
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-11262) XML writer does not implement PushWriter
[
https://issues.apache.org/jira/browse/SOLR-11262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17155980#comment-17155980
]
Lucene/Solr QA commented on SOLR-11262:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
11s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 0s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 43m
5s{color} | {color:green} core in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m
28s{color} | {color:green} solrj in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 51m 37s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-11262 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/13007463/SOLR-11262.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.15.0-108-generic #109-Ubuntu SMP Fri Jun 19
11:33:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / e355c616b3c |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/779/testReport/ |
| modules | C: solr/core solr/solrj U: solr |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/779/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> XML writer does not implement PushWriter
>
>
> Key: SOLR-11262
> URL: https://issues.apache.org/jira/browse/SOLR-11262
> Project: Solr
> Issue Type: Bug
>Reporter: Yonik Seeley
>Priority: Major
> Attachments: SOLR-11262.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> While implementing points support for the terms component in a streaming
> manner (via PushWriter/MapWriter) I discovered that the XML response writer
> does not implement this interface.
> This means that any code using PushWriter (via MapWriter or IteratorWriter)
> will be broken if one tries to use XML response format. This may easily go
> unnoticed if one is not using XML response format in testing (JSON or binary
> is frequently used).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14404) CoreContainer level custom requesthandlers
[
https://issues.apache.org/jira/browse/SOLR-14404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156038#comment-17156038
]
David Smiley commented on SOLR-14404:
-
{quote}I didn't make any changes to the test here
{quote}
Heh; looks like I was reviewing code too late ;)
Could you please summarize how you solved the eventual-consistency issue here?
> CoreContainer level custom requesthandlers
> --
>
> Key: SOLR-14404
> URL: https://issues.apache.org/jira/browse/SOLR-14404
> Project: Solr
> Issue Type: New Feature
> Components: packages
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.6
>
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/plugin}}
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin",
> "class": "full.ClassName",
> "path-prefix" : "some-path-prefix"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> add a plugin from a package
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin",
> "class": "pkgName:full.ClassName" ,
> "path-prefix" : "some-path-prefix" ,
> "version: "1.0"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName", "path-prefix" : "some-path-prefix" }
> }
> }
> {code}
> example plugin
> {code:java}
> public class MyPlugin {
> private final CoreContainer coreContainer;
> public MyPlugin(CoreContainer coreContainer) {
> this.coreContainer = coreContainer;
> }
> @EndPoint(path = "/$path-prefix/path1",
> method = METHOD.GET,
> permission = READ)
> public void call(SolrQueryRequest req, SolrQueryResponse rsp){
> rsp.add("myplugin.version", "2.0");
> }
> }
> {code}
> This plugin will be accessible on all nodes at
> {{/api/some-path-prefix/path1}}. It's possible to add more methods at
> different paths. Ensure that all paths start with {{$path-prefix}} because
> that is the prefix in which the plugin is registered with. So
> {{/some-path-prefix/path2}} , {{/some-path-prefix/my/deeply/nested/path}} are
> all valid paths.
> It's possible that the user chooses to register the plugin with a different
> name. In that case , use a template variable as follows in paths
> {{/cluster/some/other/path}}
--
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-14155) Load all other SolrCore plugins from packages
[
https://issues.apache.org/jira/browse/SOLR-14155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156084#comment-17156084
]
Erick Erickson commented on SOLR-14155:
---
IDK if you saw/want to include TransientCoreCache. The title here caught my eye
so I thought I'd mention it.
> Load all other SolrCore plugins from packages
> -
>
> Key: SOLR-14155
> URL: https://issues.apache.org/jira/browse/SOLR-14155
> Project: Solr
> Issue Type: Sub-task
> Components: packages
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A few plugins configurable in {{solrconfig.xml}} still cannot be loaded from
> packages
> # DirectoryFactor
> # Updatelog
> # Cache
> # SolrEventListener (improperly implemented)
> #1 to #3 should result in reloading the core. #4 can do in-place reload
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[ https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156130#comment-17156130 ] Mark Robert Miller commented on SOLR-14636: --- Yeah, now it's happening, SolrCloud is finding it's groove again. Good stuff. I'll start bringing some of the Ignored tests back online next week. > Provide a reference implementation for SolrCloud that is stable and fast. > - > > Key: SOLR-14636 > URL: https://issues.apache.org/jira/browse/SOLR-14636 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Robert Miller >Assignee: Mark Robert Miller >Priority: Major > > SolrCloud powers critical infrastructure and needs the ability to run quickly > with stability. This reference implementation will allow for this. > *location*: [https://github.com/apache/lucene-solr/tree/reference_impl] > *status*: alpha > *speed*: ludicrous > *tests***: > * *core*: passing with ignores (not solid*) > * *solrj*: passing with ignores (not solid*) > * *test-framework*: passing with ignores (not solid*) > * *contrib/analysis-extras*: passing with ignores (not solid*) > * *contrib/analytics*: passing with ignores (not solid*) > * *contrib/clustering*: passing with ignores (not solid*) > * *contrib/dataimporthandler*: passing with ignores (not solid*) > * *contrib/dataimporthandler-extras*: passing with ignores (not solid*) > * *contrib/extraction*: passing with ignores (not solid*) > * *contrib/jaegertracer-configurator*: passing with ignores (not solid*) > * *contrib/langid*: passing with ignores (not solid*) > * *contrib/prometheus-exporter*: passing with ignores (not solid*) > * *contrib/velocity*: passing with ignores (not solid*) > _* Running tests quickly and efficiently with strict policing will more > frequently find bugs and requires a period of hardening._ > _** Non Nightly currently, Nightly comes last._ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mariusneo closed pull request #1583: LUCENE-9407: change the visibility of the LatLonXQuery classes to public
mariusneo closed pull request #1583: URL: https://github.com/apache/lucene-solr/pull/1583 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] (LUCENE-9407) Change the visibility of LatLonXQuery classes to public
[
https://issues.apache.org/jira/browse/LUCENE-9407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marius Grama resolved LUCENE-9407.
--
Resolution: Won't Fix
> Change the visibility of LatLonXQuery classes to public
>
>
> Key: LUCENE-9407
> URL: https://issues.apache.org/jira/browse/LUCENE-9407
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: 8.5.2
>Reporter: Marius Grama
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h2. Problem description
>
> A few years ago the geospatial queries classes have been refactored to be
> package-private:
>
> {code:java}
> final class LatLonPointInPolygonQuery extends Query
> {code}
>
> I get that there must be a reason for making use of package-private
> constructors in the geospatial query classes, but I'm wondering whether it
> would hurt to leave the classes still public.
>
> Having the classes package-private means that they can't be used outside of
> the
>
>
> {{package org.apache.lucene.document;}}
>
> This is the PR in which the refactoring was made:
>
> [https://github.com/apache/lucene-solr/commit/2264600ffe4649abb0edbe7a6882ffc82f6e918b]
>
>
>
> h2. Background
> h3. Elasticsearch Percolator dealing with geospatial queries
> In the elasticsearch code (specifically over the percolator functionality) I
> have noticed that when using polygon queries at the moment there isn't
> possible to do a reversed search on the search queries index.
>
> This means that for all the geospatial queries are applied against the
> elasticsearch memory index in order to check for a percolation match.
>
> If the percolator deals with
>
> {{org.apache.lucene.document.LatLonPointInPolygonQuery}}
>
> then it should probably suffice making use of the
>
> {{org.apache.lucene.document.LatLonShapeBoundingBoxQuery}}
>
> for finding the search queries that have polygons containing the LatLonPoint
> of the location field of the document being percolated.
> h2. Proposed solution
>
> Increase the visibility of the LatLonXQuery classes to {{public}} so that
> they can
> be used in other packages (e.g. elasticsearch percolator code).
>
> *NOTE* that the constructors of the classes are still package-protected
> reason why the classes won't be able to be instantiated outside of their
> original package.
>
> In the elasticsearch percolator code I'd have to make use explicitly of the
> LatLonPointInPolygonQuery class (_instanceof_) when analyzing the search
> queries to be used in the percolation process:
>
>
> [https://github.com/elastic/elasticsearch/blob/master/modules/percolator/src/main/java/org/elasticsearch/percolator/QueryAnalyzer.java#L186]
>
> h3. Pull request
>
> [https://github.com/apache/lucene-solr/pull/1583]
>
>
--
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] [Closed] (LUCENE-9407) Change the visibility of LatLonXQuery classes to public
[
https://issues.apache.org/jira/browse/LUCENE-9407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marius Grama closed LUCENE-9407.
> Change the visibility of LatLonXQuery classes to public
>
>
> Key: LUCENE-9407
> URL: https://issues.apache.org/jira/browse/LUCENE-9407
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: 8.5.2
>Reporter: Marius Grama
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h2. Problem description
>
> A few years ago the geospatial queries classes have been refactored to be
> package-private:
>
> {code:java}
> final class LatLonPointInPolygonQuery extends Query
> {code}
>
> I get that there must be a reason for making use of package-private
> constructors in the geospatial query classes, but I'm wondering whether it
> would hurt to leave the classes still public.
>
> Having the classes package-private means that they can't be used outside of
> the
>
>
> {{package org.apache.lucene.document;}}
>
> This is the PR in which the refactoring was made:
>
> [https://github.com/apache/lucene-solr/commit/2264600ffe4649abb0edbe7a6882ffc82f6e918b]
>
>
>
> h2. Background
> h3. Elasticsearch Percolator dealing with geospatial queries
> In the elasticsearch code (specifically over the percolator functionality) I
> have noticed that when using polygon queries at the moment there isn't
> possible to do a reversed search on the search queries index.
>
> This means that for all the geospatial queries are applied against the
> elasticsearch memory index in order to check for a percolation match.
>
> If the percolator deals with
>
> {{org.apache.lucene.document.LatLonPointInPolygonQuery}}
>
> then it should probably suffice making use of the
>
> {{org.apache.lucene.document.LatLonShapeBoundingBoxQuery}}
>
> for finding the search queries that have polygons containing the LatLonPoint
> of the location field of the document being percolated.
> h2. Proposed solution
>
> Increase the visibility of the LatLonXQuery classes to {{public}} so that
> they can
> be used in other packages (e.g. elasticsearch percolator code).
>
> *NOTE* that the constructors of the classes are still package-protected
> reason why the classes won't be able to be instantiated outside of their
> original package.
>
> In the elasticsearch percolator code I'd have to make use explicitly of the
> LatLonPointInPolygonQuery class (_instanceof_) when analyzing the search
> queries to be used in the percolation process:
>
>
> [https://github.com/elastic/elasticsearch/blob/master/modules/percolator/src/main/java/org/elasticsearch/percolator/QueryAnalyzer.java#L186]
>
> h3. Pull request
>
> [https://github.com/apache/lucene-solr/pull/1583]
>
>
--
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-13101) Shared storage support in SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-13101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156146#comment-17156146 ] David Smiley commented on SOLR-13101: - Noble; you asked on the 21st of December last year (13 comments up) and Yonik answered the next day. In summary, the approach here is not at all pluggable, just as our other current replica types (NRT/PULL/TLOG) aren't pluggable either. > Shared storage support in SolrCloud > --- > > Key: SOLR-13101 > URL: https://issues.apache.org/jira/browse/SOLR-13101 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Yonik Seeley >Priority: Major > Time Spent: 15h 50m > Remaining Estimate: 0h > > Solr should have first-class support for shared storage (blob/object stores > like S3, google cloud storage, etc. and shared filesystems like HDFS, NFS, > etc). > The key component will likely be a new replica type for shared storage. It > would have many of the benefits of the current "pull" replicas (not indexing > on all replicas, all shards identical with no shards getting out-of-sync, > etc), but would have additional benefits: > - Any shard could become leader (the blob store always has the index) > - Better elasticity scaling down >- durability not linked to number of replcias.. a single replica could be > common for write workloads >- could drop to 0 replicas for a shard when not needed (blob store always > has index) > - Allow for higher performance write workloads by skipping the transaction > log >- don't pay for what you don't need >- a commit will be necessary to flush to stable storage (blob store) > - A lot of the complexity and failure modes go away > An additional component a Directory implementation that will work well with > blob stores. We probably want one that treats local disk as a cache since > the latency to remote storage is so large. I think there are still some > "locking" issues to be solved here (ensuring that more than one writer to the > same index won't corrupt it). This should probably be pulled out into a > different JIRA issue. -- 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-13101) Shared storage support in SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-13101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156149#comment-17156149 ] Ishan Chattopadhyaya commented on SOLR-13101: - How do we know that this support won't suffer the same neglect that HDFS and CDCR suffered? I haven't seen a design document for the proposed work here, so I can't comment on specifics, but in general we do not want such a massive patch into Solr core for a non essential feature such as this. We should start with defining the interfaces that can stay in core and concrete implementations that should stay outside. > Shared storage support in SolrCloud > --- > > Key: SOLR-13101 > URL: https://issues.apache.org/jira/browse/SOLR-13101 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Yonik Seeley >Priority: Major > Time Spent: 15h 50m > Remaining Estimate: 0h > > Solr should have first-class support for shared storage (blob/object stores > like S3, google cloud storage, etc. and shared filesystems like HDFS, NFS, > etc). > The key component will likely be a new replica type for shared storage. It > would have many of the benefits of the current "pull" replicas (not indexing > on all replicas, all shards identical with no shards getting out-of-sync, > etc), but would have additional benefits: > - Any shard could become leader (the blob store always has the index) > - Better elasticity scaling down >- durability not linked to number of replcias.. a single replica could be > common for write workloads >- could drop to 0 replicas for a shard when not needed (blob store always > has index) > - Allow for higher performance write workloads by skipping the transaction > log >- don't pay for what you don't need >- a commit will be necessary to flush to stable storage (blob store) > - A lot of the complexity and failure modes go away > An additional component a Directory implementation that will work well with > blob stores. We probably want one that treats local disk as a cache since > the latency to remote storage is so large. I think there are still some > "locking" issues to be solved here (ensuring that more than one writer to the > same index won't corrupt it). This should probably be pulled out into a > different JIRA issue. -- 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-14155) Load all other SolrCore plugins from packages
[
https://issues.apache.org/jira/browse/SOLR-14155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156178#comment-17156178
]
David Smiley commented on SOLR-14155:
-
I attempted to do this in [https://github.com/apache/lucene-solr/pull/1109] but
we didn't reach consensus on the approach. My approach there, in a nutshell,
was modifying SolrResourceLoader to know about plugins and consult the package
manager. We did agree SolrResourceLoader has some tech-debt that was
interfering. I removed some of that but I definitely have more to do.
Can you please summarize your approach in #1666 before I look closer?
> Load all other SolrCore plugins from packages
> -
>
> Key: SOLR-14155
> URL: https://issues.apache.org/jira/browse/SOLR-14155
> Project: Solr
> Issue Type: Sub-task
> Components: packages
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A few plugins configurable in {{solrconfig.xml}} still cannot be loaded from
> packages
> # DirectoryFactor
> # Updatelog
> # Cache
> # SolrEventListener (improperly implemented)
> #1 to #3 should result in reloading the core. #4 can do in-place reload
--
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-14155) Load all other SolrCore plugins from packages
[
https://issues.apache.org/jira/browse/SOLR-14155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156179#comment-17156179
]
David Smiley commented on SOLR-14155:
-
Erick: based on the title of this issue and the description, it's focused on
plugins referenced from solrconfig.xml only, and consequently wouldn't include
any Node (CoreContainer) level plugins like the one you mentioned. FWIW my
approach in #1109 would have been near all-encompassing since everything is
loaded with a SRL.
> Load all other SolrCore plugins from packages
> -
>
> Key: SOLR-14155
> URL: https://issues.apache.org/jira/browse/SOLR-14155
> Project: Solr
> Issue Type: Sub-task
> Components: packages
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A few plugins configurable in {{solrconfig.xml}} still cannot be loaded from
> packages
> # DirectoryFactor
> # Updatelog
> # Cache
> # SolrEventListener (improperly implemented)
> #1 to #3 should result in reloading the core. #4 can do in-place reload
--
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-14155) Load all other SolrCore plugins from packages
[
https://issues.apache.org/jira/browse/SOLR-14155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156180#comment-17156180
]
Noble Paul commented on SOLR-14155:
---
[~dsmiley]
The approach is as explained in the description. I'm not sure exactly what are
you asking for
> Load all other SolrCore plugins from packages
> -
>
> Key: SOLR-14155
> URL: https://issues.apache.org/jira/browse/SOLR-14155
> Project: Solr
> Issue Type: Sub-task
> Components: packages
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A few plugins configurable in {{solrconfig.xml}} still cannot be loaded from
> packages
> # DirectoryFactor
> # Updatelog
> # Cache
> # SolrEventListener (improperly implemented)
> #1 to #3 should result in reloading the core. #4 can do in-place reload
--
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-13101) Shared storage support in SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-13101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156182#comment-17156182 ] Noble Paul commented on SOLR-13101: --- As ishan mentioned, I see this as a problem of lack of modularity. We are not thinking in terms of separation of concerns. Why are we not able to define the interaction points with existing Solr? If this is not an integral part of Solr, it should have a set of interfaces thorough which it interacts with Solr. When people say that it has to be intertwined with Solr, the onus is on them to explain why it is so. > Shared storage support in SolrCloud > --- > > Key: SOLR-13101 > URL: https://issues.apache.org/jira/browse/SOLR-13101 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Yonik Seeley >Priority: Major > Time Spent: 15h 50m > Remaining Estimate: 0h > > Solr should have first-class support for shared storage (blob/object stores > like S3, google cloud storage, etc. and shared filesystems like HDFS, NFS, > etc). > The key component will likely be a new replica type for shared storage. It > would have many of the benefits of the current "pull" replicas (not indexing > on all replicas, all shards identical with no shards getting out-of-sync, > etc), but would have additional benefits: > - Any shard could become leader (the blob store always has the index) > - Better elasticity scaling down >- durability not linked to number of replcias.. a single replica could be > common for write workloads >- could drop to 0 replicas for a shard when not needed (blob store always > has index) > - Allow for higher performance write workloads by skipping the transaction > log >- don't pay for what you don't need >- a commit will be necessary to flush to stable storage (blob store) > - A lot of the complexity and failure modes go away > An additional component a Directory implementation that will work well with > blob stores. We probably want one that treats local disk as a cache since > the latency to remote storage is so large. I think there are still some > "locking" issues to be solved here (ensuring that more than one writer to the > same index won't corrupt it). This should probably be pulled out into a > different JIRA issue. -- 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-14155) Load all other SolrCore plugins from packages
[
https://issues.apache.org/jira/browse/SOLR-14155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156181#comment-17156181
]
David Smiley commented on SOLR-14155:
-
I mean *how*. For example, how might it compare to my SRL centric approach?
> Load all other SolrCore plugins from packages
> -
>
> Key: SOLR-14155
> URL: https://issues.apache.org/jira/browse/SOLR-14155
> Project: Solr
> Issue Type: Sub-task
> Components: packages
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A few plugins configurable in {{solrconfig.xml}} still cannot be loaded from
> packages
> # DirectoryFactor
> # Updatelog
> # Cache
> # SolrEventListener (improperly implemented)
> #1 to #3 should result in reloading the core. #4 can do in-place reload
--
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-14155) Load all other SolrCore plugins from packages
[
https://issues.apache.org/jira/browse/SOLR-14155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156183#comment-17156183
]
Noble Paul commented on SOLR-14155:
---
I'm not sure it is very different from an SRL centric approach (for those
plugins that require core reload). for others, I stick to hot-reloading
> Load all other SolrCore plugins from packages
> -
>
> Key: SOLR-14155
> URL: https://issues.apache.org/jira/browse/SOLR-14155
> Project: Solr
> Issue Type: Sub-task
> Components: packages
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A few plugins configurable in {{solrconfig.xml}} still cannot be loaded from
> packages
> # DirectoryFactor
> # Updatelog
> # Cache
> # SolrEventListener (improperly implemented)
> #1 to #3 should result in reloading the core. #4 can do in-place reload
--
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-13101) Shared storage support in SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-13101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156184#comment-17156184 ] Noble Paul commented on SOLR-13101: --- [~dsmiley] I do not see any answers to [this question|https://issues.apache.org/jira/browse/SOLR-13101?focusedCommentId=17002508&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17002508] > Shared storage support in SolrCloud > --- > > Key: SOLR-13101 > URL: https://issues.apache.org/jira/browse/SOLR-13101 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Yonik Seeley >Priority: Major > Time Spent: 15h 50m > Remaining Estimate: 0h > > Solr should have first-class support for shared storage (blob/object stores > like S3, google cloud storage, etc. and shared filesystems like HDFS, NFS, > etc). > The key component will likely be a new replica type for shared storage. It > would have many of the benefits of the current "pull" replicas (not indexing > on all replicas, all shards identical with no shards getting out-of-sync, > etc), but would have additional benefits: > - Any shard could become leader (the blob store always has the index) > - Better elasticity scaling down >- durability not linked to number of replcias.. a single replica could be > common for write workloads >- could drop to 0 replicas for a shard when not needed (blob store always > has index) > - Allow for higher performance write workloads by skipping the transaction > log >- don't pay for what you don't need >- a commit will be necessary to flush to stable storage (blob store) > - A lot of the complexity and failure modes go away > An additional component a Directory implementation that will work well with > blob stores. We probably want one that treats local disk as a cache since > the latency to remote storage is so large. I think there are still some > "locking" issues to be solved here (ensuring that more than one writer to the > same index won't corrupt it). This should probably be pulled out into a > different JIRA issue. -- 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 commented on pull request #1665: SOLR-11262: XML writer implements writeMap and writeIterator
noblepaul commented on pull request #1665: URL: https://github.com/apache/lucene-solr/pull/1665#issuecomment-657168228 Add an entry to the CHANGES.txt as well and I can merge this straight away 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-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[ https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156206#comment-17156206 ] Mark Robert Miller commented on SOLR-14636: --- You hear people argue things like, oh System.nano, I don't know if it's worth it, currentTimeMili has problems but it's fast. That volatile might not be necessary and looks expensive! Leaf peapers! Those arguments are crazy until you can assemble and disassemble your universe in a blink of a blink, and you get to a blink by doing crap right. > Provide a reference implementation for SolrCloud that is stable and fast. > - > > Key: SOLR-14636 > URL: https://issues.apache.org/jira/browse/SOLR-14636 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Robert Miller >Assignee: Mark Robert Miller >Priority: Major > > SolrCloud powers critical infrastructure and needs the ability to run quickly > with stability. This reference implementation will allow for this. > *location*: [https://github.com/apache/lucene-solr/tree/reference_impl] > *status*: alpha > *speed*: ludicrous > *tests***: > * *core*: passing with ignores (not solid*) > * *solrj*: passing with ignores (not solid*) > * *test-framework*: passing with ignores (not solid*) > * *contrib/analysis-extras*: passing with ignores (not solid*) > * *contrib/analytics*: passing with ignores (not solid*) > * *contrib/clustering*: passing with ignores (not solid*) > * *contrib/dataimporthandler*: passing with ignores (not solid*) > * *contrib/dataimporthandler-extras*: passing with ignores (not solid*) > * *contrib/extraction*: passing with ignores (not solid*) > * *contrib/jaegertracer-configurator*: passing with ignores (not solid*) > * *contrib/langid*: passing with ignores (not solid*) > * *contrib/prometheus-exporter*: passing with ignores (not solid*) > * *contrib/velocity*: passing with ignores (not solid*) > _* Running tests quickly and efficiently with strict policing will more > frequently find bugs and requires a period of hardening._ > _** Non Nightly currently, Nightly comes last._ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14155) Load all other SolrCore plugins from packages
[
https://issues.apache.org/jira/browse/SOLR-14155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156213#comment-17156213
]
David Smiley commented on SOLR-14155:
-
I had a productive 1-on-1 chat with Noble on Slack, and I'm mostly through a
code-review. The underlying "how" that matters for the purpose of my above
inquiry is that the specific plugins listed in the description were modified
instead of SRL. In that sense, it's _not_ like the SRL approach of my PR that
loaded nearly all plugin types; no changes to call sites most of the time. We
don't yet agree on wether SRL is the right spot to do this, but it's on me to
present a better case for SRL once I clear it of more tech debt to thus allow a
more compelling PR (by me; different issue). When I counted plugin types in
Solr early this year, I counted 114 loaded via SRL and even more via
Class.forName. I could have been more thorough and found more, I think. The
number blew me away that it's so high, and at least to me makes it clear that
we don't want to go modify 114 call-sites to custom integrate each with the
plugin system when we could instead reasonably update SRL to do it. In the
mean time, I don't want a "great" (by my subjective opinion) to get in the way
of the "good" here.
The DirectoryFactory & UpdateLog plugin types were done here motivated by being
able to move Solr's HDFS support out of core and into a package. This
particular issue doesn't literally do that but it's a prerequisite. +1 for me
but I'll have specific by-line code comments in the PR.
The SolrEventListener plugin type was made hot-loadable and doing so
fundamentally requires some changes (SRL alone won't cut it). +1 for me but
I'll have specific by-line code comments in the PR.
The SolrCache plugin type was made to load from a package. I'd rather this be
removed from this PR (which was much more invasive than for DirectoryFactory
and UpdateLog) and await a future decision on use of SRL or whatever we come up
with at this time. So "-0" for me on this in the PR.
IMO the title was misleading; I propose "Package support: DirectoryFactory,
UpdateLog, SolrEventListener, SolrCache" (ideally removing SolrCache)
> Load all other SolrCore plugins from packages
> -
>
> Key: SOLR-14155
> URL: https://issues.apache.org/jira/browse/SOLR-14155
> Project: Solr
> Issue Type: Sub-task
> Components: packages
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A few plugins configurable in {{solrconfig.xml}} still cannot be loaded from
> packages
> # DirectoryFactor
> # Updatelog
> # Cache
> # SolrEventListener (improperly implemented)
> #1 to #3 should result in reloading the core. #4 can do in-place reload
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1666: SOLR-14155: Load all other SolrCore plugins from packages
dsmiley commented on a change in pull request #1666:
URL: https://github.com/apache/lucene-solr/pull/1666#discussion_r453258414
##
File path: solr/core/src/java/org/apache/solr/core/CoreContainer.java
##
@@ -1588,20 +1576,28 @@ private CoreDescriptor
reloadCoreDescriptor(CoreDescriptor oldDesc) {
return ret;
}
+ public void reload(String name) {
Review comment:
Very much needs a javadoc line saying *what* it is that is being
reloaded. My initial and incorrect thought was the CoreContainer itself.
##
File path: solr/core/src/java/org/apache/solr/core/SolrConfig.java
##
@@ -971,6 +974,21 @@ public RequestParams getRequestParams() {
return requestParams;
}
+ /**
+ * The version of package that should be loaded for a given package name
+ * This information is stored in the params.json in the same configset
+ * If params.json is absent or there is no corresponding version specified
for a given package,
+ * the latest is used
Review comment:
The code shows null can be returned but javadoc says "latest".
##
File path: solr/core/src/java/org/apache/solr/core/CoreContainer.java
##
@@ -1588,20 +1576,28 @@ private CoreDescriptor
reloadCoreDescriptor(CoreDescriptor oldDesc) {
return ret;
}
+ public void reload(String name) {
+reload(name, null);
+ }
/**
* Recreates a SolrCore.
* While the new core is loading, requests will continue to be dispatched to
* and processed by the old core
*
* @param name the name of the SolrCore to reload
+ * @param coreId The unique identifier of the core
Review comment:
This is new. Can you explain why this new ID is needed?
##
File path: solr/core/src/java/org/apache/solr/core/SolrCore.java
##
@@ -626,25 +615,26 @@ public void deleteNonSnapshotIndexFiles(String
indexDirPath) throws IOException
}
+ @SuppressWarnings("unchecked")
private void initListeners() {
final Class clazz = SolrEventListener.class;
final String label = "Event Listener";
for (PluginInfo info :
solrConfig.getPluginInfos(SolrEventListener.class.getName())) {
final String event = info.attributes.get("event");
if ("firstSearcher".equals(event)) {
-SolrEventListener obj = createInitInstance(info, clazz, label, null);
+PluginHolder obj =
(PluginHolder)PackagePluginHolder.createHolder(info, this,
SolrEventListener.class, label);
firstSearcherListeners.add(obj);
-log.debug("[{}] Added SolrEventListener for firstSearcher: [{}]",
logid, obj);
+log.debug("[{}] Added SolrEventListener for firstSearcher: [{}]",
logid, obj.get());
} else if ("newSearcher".equals(event)) {
-SolrEventListener obj = createInitInstance(info, clazz, label, null);
+PluginHolder obj =
(PluginHolder)PackagePluginHolder.createHolder(info, this,
SolrEventListener.class, label);
newSearcherListeners.add(obj);
-log.debug("[{}] Added SolrEventListener for newSearcher: [{}]", logid,
obj);
+log.debug("[{}] Added SolrEventListener for newSearcher: [{}]", logid,
obj.get());
}
}
}
- final List firstSearcherListeners = new ArrayList<>();
- final List newSearcherListeners = new ArrayList<>();
+ final List> firstSearcherListeners = new
ArrayList<>();
Review comment:
Can we use a PluginBag instead of List, which is shorter
and more consistent with how SolrCore tracks some plugins like
SearchComponents, URPs, and RequestHandlers?
##
File path: solr/core/src/java/org/apache/solr/core/SolrCore.java
##
@@ -191,6 +175,11 @@
private String name;
private String logid; // used to show what name is set
+ /**
+ * A unique id to differentiate multiple instances of the same core
+ * If we reload a core, the name remains same , but the id will be new
+ */
+ public final UUID uniqueId = UUID.randomUUID();
Review comment:
If this ID is completely internal to the node (never passed in as a
parameter), then can't we just use some AtomicLong?
##
File path: solr/core/src/java/org/apache/solr/core/SolrCore.java
##
@@ -626,25 +615,26 @@ public void deleteNonSnapshotIndexFiles(String
indexDirPath) throws IOException
}
+ @SuppressWarnings("unchecked")
private void initListeners() {
final Class clazz = SolrEventListener.class;
final String label = "Event Listener";
for (PluginInfo info :
solrConfig.getPluginInfos(SolrEventListener.class.getName())) {
final String event = info.attributes.get("event");
if ("firstSearcher".equals(event)) {
-SolrEventListener obj = createInitInstance(info, clazz, label, null);
+PluginHolder obj =
(PluginHolder)PackagePluginHolder.createHolder(info, this,
SolrEventListener.class, label);
firstSearcherListeners.add(obj);
-log.debug("[{}] Added SolrEventListener for firstSearcher: [{}]",
logid, o
