[GitHub] [solr] gezapeti commented on a diff in pull request #1108: SOLR-14251 Add option skipFreeSpaceCheck to split shard operation
gezapeti commented on code in PR #1108: URL: https://github.com/apache/solr/pull/1108#discussion_r1002375679 ## solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java: ## @@ -199,8 +200,17 @@ public boolean split(ClusterState clusterState, ZkNodeProps message, NamedList
[GitHub] [solr] dsmiley commented on a diff in pull request #1106: SOLR-16433: Upgrade Jackson bom to 2.13.4.20221013
dsmiley commented on code in PR #1106:
URL: https://github.com/apache/solr/pull/1106#discussion_r1002332354
##
solr/core/build.gradle:
##
@@ -191,6 +191,9 @@ dependencies {
// For faster XML processing than the JDK
implementation 'org.codehaus.woodstox:stax2-api'
implementation 'com.fasterxml.woodstox:woodstox-core'
+ // See https://issues.apache.org/jira/browse/LOG4J2-3609 due to needing
these annotations
+ compileOnly 'biz.aQute.bnd:biz.aQute.bnd.annotation'
+ compileOnly 'org.osgi:osgi.annotation'
Review Comment:
annoying but okay.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] dsmiley commented on a diff in pull request #1108: SOLR-14251 Add option skipFreeSpaceCheck to split shard operation
dsmiley commented on code in PR #1108: URL: https://github.com/apache/solr/pull/1108#discussion_r1002329395 ## solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java: ## @@ -199,8 +200,17 @@ public boolean split(ClusterState clusterState, ZkNodeProps message, NamedList
[GitHub] [solr] dsmiley commented on a diff in pull request #585: SOLR-15955: Update Jetty dependency to 10
dsmiley commented on code in PR #585:
URL: https://github.com/apache/solr/pull/585#discussion_r1002323308
##
solr/core/src/java/org/apache/solr/client/solrj/embedded/JettySolrRunner.java:
##
@@ -304,7 +304,11 @@ private void init(int port) {
ServerConnector connector;
if (sslcontext != null) {
configuration.setSecureScheme("https");
-configuration.addCustomizer(new SecureRequestCustomizer());
+SecureRequestCustomizer customizer = new
SecureRequestCustomizer(false);
+sslcontext.setSniRequired(false);
+customizer.setSniHostCheck(false);
Review Comment:
Because tests don't need security, I assume? If JettySolrRunner were moved
to the test framework, this'd be clearer. There doesn't appear to be anything
stopping that. For another time I suppose.
##
solr/core/src/java/org/apache/solr/client/solrj/embedded/JettySolrRunner.java:
##
@@ -452,9 +457,6 @@ public void lifeCycleFailure(LifeCycle arg0, Throwable
arg1) {
gzipHandler.setHandler(chain);
gzipHandler.setMinGzipSize(23); //
https://github.com/eclipse/jetty.project/issues/4191
-gzipHandler.setCheckGzExists(false);
-gzipHandler.setCompressionLevel(-1);
-gzipHandler.setExcludedAgentPatterns(".*MSIE.6\\.0.*");
Review Comment:
why?
##
versions.lock:
##
@@ -369,8 +367,8 @@ org.apache.kerby:kerb-common:1.0.1 (2 constraints: a51841ca)
org.apache.kerby:kerb-identity:1.0.1 (1 constraints: 5f0cb602)
org.apache.kerby:kerb-server:1.0.1 (1 constraints: d10b65f2)
org.apache.kerby:kerb-simplekdc:1.0.1 (1 constraints: dc0d7e3e)
+org.apache.tomcat.embed:tomcat-embed-el:9.0.63 (1 constraints: d01553cf)
Review Comment:
Where are we using this?
##
solr/core/src/java/org/apache/solr/servlet/SolrRequestParsers.java:
##
@@ -670,9 +662,15 @@ public InputStream getStream() throws IOException {
}
}
+ public static boolean isMultipart(HttpServletRequest req) {
+// Jetty utilities
Review Comment:
*not* Jetty utilities. It *was* using Jetty utilities. I wrote the code
being replaced.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-13626) broken links in solr/solr-ref-guide/src/implicit-requesthandlers.adoc
[ https://issues.apache.org/jira/browse/SOLR-13626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622504#comment-17622504 ] Tony Cook commented on SOLR-13626: -- Thanks, "Tony Cook" is fine. I have no opinion on any changes, I haven't touched Solr in a long while now. > broken links in solr/solr-ref-guide/src/implicit-requesthandlers.adoc > - > > Key: SOLR-13626 > URL: https://issues.apache.org/jira/browse/SOLR-13626 > Project: Solr > Issue Type: Bug > Components: documentation >Affects Versions: 8.1.1 >Reporter: Tony Cook >Assignee: Eric Pugh >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > At line 109 in the source, this page links to > [https://wiki.apache.org/solr/SystemInformationRequestHandlers#SystemInfoHandler] > which no longer exists, if it ever did, I don't see such a page under > [https://cwiki.apache.org/confluence/display/SOLR/Old+Wiki] > It also links to: > line 52: [http://wiki.apache.org/solr/LukeRequestHandler] > line 148: [https://wiki.apache.org/solr/AnalysisRequestHandler] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] gezapeti opened a new pull request, #1108: SOLR-14251 Add option skipFreeSpaceCheck to split shard operation
gezapeti opened a new pull request, #1108: URL: https://github.com/apache/solr/pull/1108 …le disk space before splitting shards. Useful with shared file systems like HDFS https://issues.apache.org/jira/browse/SOLR-14251 # Description Adding an option to the SPLIT_SHARD_OP command to make it possible to skip free space checking before splitting shards. This is a workaround as the check logic is broken for shared filesystems. # Solution The option skips the disk space check as a workaround. # Tests None. # Checklist - [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 `main` branch. - [x] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [x] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] raveendrabikkina-metcash commented on pull request #210: SOLR-13360: Collation code fails with non-increasing token order
raveendrabikkina-metcash commented on PR #210: URL: https://github.com/apache/solr/pull/210#issuecomment-1287466123 Unfortunately i don't have merge permission. Please reach out to admin. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-9775) NPE in QueryResultKey constructor (when executing a clustering search query?)
[
https://issues.apache.org/jira/browse/SOLR-9775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622496#comment-17622496
]
Eric Pugh commented on SOLR-9775:
-
What if we change the logic in SolrIndexSearcher.java
key =
{color:#cc7832}new {color}QueryResultKey(q{color:#cc7832},
{color}cmd.getFilterList(){color:#cc7832}, {color}cmd.getSort(){color:#cc7832},
{color}flags{color:#cc7832}, {color}cmd.getMinExactCount())
So that Sort is never null and getFilterList is never null, and indeed, then
also purge any nulls in the sort fields and filterlist? That might simplify a
lot of the logic in QueryResultKey hashcode and equals methods.
> NPE in QueryResultKey constructor (when executing a clustering search query?)
> -
>
> Key: SOLR-9775
> URL: https://issues.apache.org/jira/browse/SOLR-9775
> Project: Solr
> Issue Type: Bug
>Reporter: Christine Poerschke
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> https://github.com/apache/lucene-solr/pull/116 from Roman Kagan yesterday
> (November 2016) has a fix.
> On the solr-user mailing list (in March) Tim Hearn
> [reported|http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201603.mbox/%3CCAFoZJmC87Lbuj%2BaYwcVh%2B5ay_%3Dwi5n8TGs7gBPcF%3Djjo%2BW7vGg%40mail.gmail.com%3E]
> encountering what sounds like the same NPE when executing a clustering
> search query.
> This ticket to tentatively link the two together. Open question: do we want
> to include a reproducing test case along with the fix or just commit the fix
> alone?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] epugh commented on pull request #1107: SOLR-9775 fixed NPEs
epugh commented on PR #1107: URL: https://github.com/apache/solr/pull/1107#issuecomment-1287447435 Okay, look at my most recent tests...While they pass, I am not sure I am actually making things better -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16485) Solr 9 standalone mode nullPointerException when ShardHandlerFactory defined
[
https://issues.apache.org/jira/browse/SOLR-16485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman updated SOLR-16485:
--
Fix Version/s: 9.1
main (10.0)
Assignee: Houston Putman
Resolution: Fixed
Status: Resolved (was: Patch Available)
Thanks for reporting this [~vladiceanu]!
> Solr 9 standalone mode nullPointerException when ShardHandlerFactory defined
>
>
> Key: SOLR-16485
> URL: https://issues.apache.org/jira/browse/SOLR-16485
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.0
> Environment: Kubernetes using solr-operator 0.6.0
>Reporter: Nick Vladiceanu
>Assignee: Houston Putman
>Priority: Major
> Fix For: 9.1, main (10.0)
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {color:#00} Solr fails to create cores with a “NullPointerException"
> error when “shardHandlerFactory” is defined for any handlers in the
> solrconfig.xml file.{color}
> *Snippet from solrconfig.xml:*
> {code:java}
> class="HttpShardHandlerFactory">
> ${socketTimeout:800}
> ${connTimeout:500}
>
> {code}
> *Snippet of NullPointerException*{color:#00} (full text here:
> {color}[https://justpaste.it/5lntq]{color:#00} ):{color}
> {color:#00}o{color}
> {code:java}
> lxeu-atlas-web-dist-solr-1 | Caused by: java.lang.NullPointerException
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.handler.component.HttpShardHandlerFactory.setSecurityBuilder(HttpShardHandlerFactory.java:299)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.handler.component.SearchHandler.inform(SearchHandler.java:185)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:722)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrCore.(SolrCore.java:1155) ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrCore.(SolrCore.java:1048) ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1560)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.CoreContainer.lambda$load$10(CoreContainer.java:950)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202)
> ~[metrics-core-4.1.5.jar:4.1.5]{code}
> {*}Steps{*}{color:#00}:{color}
> {color:#00}1. Run library/solr:9.0.0 in docker (default config, no
> tunings); mount a volume with solrconfig.xml that contains
> shardHandlerFactory and schema.xml;{color}
> {color:#00}2. Create a core using the solrconfig.xml:
> {color}[http://localhost:8983/solr/admin/cores?action=CREATE&name=test&instanceDir=/var/solr/data/test&config=solrconfig.xml&dataDir=data/]
> 3. Failure with nullPointerException;
> 4. Remove the shardHandlerFactory block;
> 5. Repeat step 2;
> 6. Success.
>
> Works fine when running Solr in SolrCloud mode.
> Works fine in Solr 8.11 and all older versions in both, standalone and
> SolrCloud.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-15733) Separate out a solrj-streaming module
[
https://issues.apache.org/jira/browse/SOLR-15733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622487#comment-17622487
]
Joel Bernstein edited comment on SOLR-15733 at 10/21/22 9:11 PM:
-
[~krisden] mentions that this can be done without users even noticing which is
not a bad idea in 9x. In 10x we can make streaming expressions optional on the
Solrj client entirely.
>From a code organizational standpoint I think its a clear win and I'll feel
>much more comfortable contributing to it knowing its not adding more code to
>the main Solrj client lib.
was (Author: joel.bernstein):
[~krisden] mentions that this can be done without users even noticing which is
not a bad idea in 9x. In 10x we can make streaming expression optional on the
Solrj client entirely.
>From a code organizational standpoint I think its a clear win and I'll feel
>much more comfortable contributing to it knowing its not adding more code to
>the main Solrj client lib.
> Separate out a solrj-streaming module
> -
>
> Key: SOLR-15733
> URL: https://issues.apache.org/jira/browse/SOLR-15733
> Project: Solr
> Issue Type: Sub-task
>Reporter: Jan Høydahl
>Assignee: Joel Bernstein
>Priority: Major
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> The huge amount of streaming expression code under
> {{org.apache.solr.client.solrj.io}} package can be shipped as an optional
> jar. The {{solrj-jdbc}} (or {{solrj-sql}}) modules would then have a
> dependency on this...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16485) Solr 9 standalone mode nullPointerException when ShardHandlerFactory defined
[
https://issues.apache.org/jira/browse/SOLR-16485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622488#comment-17622488
]
ASF subversion and git services commented on SOLR-16485:
Commit 88978b68abf9d9ac41a038b84a76f2e8a587b807 in solr's branch
refs/heads/branch_9_1 from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=88978b68abf ]
SOLR-16485: Fix NPE in ShardHandlerFactory for standalone (#1100)
(cherry picked from commit 422d6fe8a00e3afefdcc26ceab434cce03b4a048)
> Solr 9 standalone mode nullPointerException when ShardHandlerFactory defined
>
>
> Key: SOLR-16485
> URL: https://issues.apache.org/jira/browse/SOLR-16485
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.0
> Environment: Kubernetes using solr-operator 0.6.0
>Reporter: Nick Vladiceanu
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {color:#00} Solr fails to create cores with a “NullPointerException"
> error when “shardHandlerFactory” is defined for any handlers in the
> solrconfig.xml file.{color}
> *Snippet from solrconfig.xml:*
> {code:java}
> class="HttpShardHandlerFactory">
> ${socketTimeout:800}
> ${connTimeout:500}
>
> {code}
> *Snippet of NullPointerException*{color:#00} (full text here:
> {color}[https://justpaste.it/5lntq]{color:#00} ):{color}
> {color:#00}o{color}
> {code:java}
> lxeu-atlas-web-dist-solr-1 | Caused by: java.lang.NullPointerException
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.handler.component.HttpShardHandlerFactory.setSecurityBuilder(HttpShardHandlerFactory.java:299)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.handler.component.SearchHandler.inform(SearchHandler.java:185)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:722)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrCore.(SolrCore.java:1155) ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrCore.(SolrCore.java:1048) ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1560)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.CoreContainer.lambda$load$10(CoreContainer.java:950)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202)
> ~[metrics-core-4.1.5.jar:4.1.5]{code}
> {*}Steps{*}{color:#00}:{color}
> {color:#00}1. Run library/solr:9.0.0 in docker (default config, no
> tunings); mount a volume with solrconfig.xml that contains
> shardHandlerFactory and schema.xml;{color}
> {color:#00}2. Create a core using the solrconfig.xml:
> {color}[http://localhost:8983/solr/admin/cores?action=CREATE&name=test&instanceDir=/var/solr/data/test&config=solrconfig.xml&dataDir=data/]
> 3. Failure with nullPointerException;
> 4. Remove the shardHandlerFactory block;
> 5. Repeat step 2;
> 6. Success.
>
> Works fine when running Solr in SolrCloud mode.
> Works fine in Solr 8.11 and all older versions in both, standalone and
> SolrCloud.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16485) Solr 9 standalone mode nullPointerException when ShardHandlerFactory defined
[
https://issues.apache.org/jira/browse/SOLR-16485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622486#comment-17622486
]
ASF subversion and git services commented on SOLR-16485:
Commit d1a39e50f2a0e005b4e4d1a7ec736df77f7fdeda in solr's branch
refs/heads/branch_9x from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=d1a39e50f2a ]
SOLR-16485: Fix NPE in ShardHandlerFactory for standalone (#1100)
(cherry picked from commit 422d6fe8a00e3afefdcc26ceab434cce03b4a048)
> Solr 9 standalone mode nullPointerException when ShardHandlerFactory defined
>
>
> Key: SOLR-16485
> URL: https://issues.apache.org/jira/browse/SOLR-16485
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.0
> Environment: Kubernetes using solr-operator 0.6.0
>Reporter: Nick Vladiceanu
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {color:#00} Solr fails to create cores with a “NullPointerException"
> error when “shardHandlerFactory” is defined for any handlers in the
> solrconfig.xml file.{color}
> *Snippet from solrconfig.xml:*
> {code:java}
> class="HttpShardHandlerFactory">
> ${socketTimeout:800}
> ${connTimeout:500}
>
> {code}
> *Snippet of NullPointerException*{color:#00} (full text here:
> {color}[https://justpaste.it/5lntq]{color:#00} ):{color}
> {color:#00}o{color}
> {code:java}
> lxeu-atlas-web-dist-solr-1 | Caused by: java.lang.NullPointerException
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.handler.component.HttpShardHandlerFactory.setSecurityBuilder(HttpShardHandlerFactory.java:299)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.handler.component.SearchHandler.inform(SearchHandler.java:185)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:722)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrCore.(SolrCore.java:1155) ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrCore.(SolrCore.java:1048) ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1560)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.CoreContainer.lambda$load$10(CoreContainer.java:950)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202)
> ~[metrics-core-4.1.5.jar:4.1.5]{code}
> {*}Steps{*}{color:#00}:{color}
> {color:#00}1. Run library/solr:9.0.0 in docker (default config, no
> tunings); mount a volume with solrconfig.xml that contains
> shardHandlerFactory and schema.xml;{color}
> {color:#00}2. Create a core using the solrconfig.xml:
> {color}[http://localhost:8983/solr/admin/cores?action=CREATE&name=test&instanceDir=/var/solr/data/test&config=solrconfig.xml&dataDir=data/]
> 3. Failure with nullPointerException;
> 4. Remove the shardHandlerFactory block;
> 5. Repeat step 2;
> 6. Success.
>
> Works fine when running Solr in SolrCloud mode.
> Works fine in Solr 8.11 and all older versions in both, standalone and
> SolrCloud.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15733) Separate out a solrj-streaming module
[
https://issues.apache.org/jira/browse/SOLR-15733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622487#comment-17622487
]
Joel Bernstein commented on SOLR-15733:
---
[~krisden] mentions that this can be done without users even noticing which is
not a bad idea in 9x. In 10x we can make streaming expression optional on the
Solrj client entirely.
>From a code organizational standpoint I think its a clear win and I'll feel
>much more comfortable contributing to it knowing its not adding more code to
>the main Solrj client lib.
> Separate out a solrj-streaming module
> -
>
> Key: SOLR-15733
> URL: https://issues.apache.org/jira/browse/SOLR-15733
> Project: Solr
> Issue Type: Sub-task
>Reporter: Jan Høydahl
>Assignee: Joel Bernstein
>Priority: Major
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> The huge amount of streaming expression code under
> {{org.apache.solr.client.solrj.io}} package can be shipped as an optional
> jar. The {{solrj-jdbc}} (or {{solrj-sql}}) modules would then have a
> dependency on this...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16485) Solr 9 standalone mode nullPointerException when ShardHandlerFactory defined
[
https://issues.apache.org/jira/browse/SOLR-16485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622483#comment-17622483
]
ASF subversion and git services commented on SOLR-16485:
Commit 422d6fe8a00e3afefdcc26ceab434cce03b4a048 in solr's branch
refs/heads/main from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=422d6fe8a00 ]
SOLR-16485: Fix NPE in ShardHandlerFactory for standalone (#1100)
> Solr 9 standalone mode nullPointerException when ShardHandlerFactory defined
>
>
> Key: SOLR-16485
> URL: https://issues.apache.org/jira/browse/SOLR-16485
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.0
> Environment: Kubernetes using solr-operator 0.6.0
>Reporter: Nick Vladiceanu
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {color:#00} Solr fails to create cores with a “NullPointerException"
> error when “shardHandlerFactory” is defined for any handlers in the
> solrconfig.xml file.{color}
> *Snippet from solrconfig.xml:*
> {code:java}
> class="HttpShardHandlerFactory">
> ${socketTimeout:800}
> ${connTimeout:500}
>
> {code}
> *Snippet of NullPointerException*{color:#00} (full text here:
> {color}[https://justpaste.it/5lntq]{color:#00} ):{color}
> {color:#00}o{color}
> {code:java}
> lxeu-atlas-web-dist-solr-1 | Caused by: java.lang.NullPointerException
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.handler.component.HttpShardHandlerFactory.setSecurityBuilder(HttpShardHandlerFactory.java:299)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.handler.component.SearchHandler.inform(SearchHandler.java:185)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:722)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrCore.(SolrCore.java:1155) ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrCore.(SolrCore.java:1048) ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1560)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.CoreContainer.lambda$load$10(CoreContainer.java:950)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202)
> ~[metrics-core-4.1.5.jar:4.1.5]{code}
> {*}Steps{*}{color:#00}:{color}
> {color:#00}1. Run library/solr:9.0.0 in docker (default config, no
> tunings); mount a volume with solrconfig.xml that contains
> shardHandlerFactory and schema.xml;{color}
> {color:#00}2. Create a core using the solrconfig.xml:
> {color}[http://localhost:8983/solr/admin/cores?action=CREATE&name=test&instanceDir=/var/solr/data/test&config=solrconfig.xml&dataDir=data/]
> 3. Failure with nullPointerException;
> 4. Remove the shardHandlerFactory block;
> 5. Repeat step 2;
> 6. Success.
>
> Works fine when running Solr in SolrCloud mode.
> Works fine in Solr 8.11 and all older versions in both, standalone and
> SolrCloud.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] HoustonPutman merged pull request #1100: SOLR-16485: Fix NPE in ShardHandlerFactory for standalone
HoustonPutman merged PR #1100: URL: https://github.com/apache/solr/pull/1100 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #585: SOLR-15955: Update Jetty dependency to 10
risdenk commented on code in PR #585: URL: https://github.com/apache/solr/pull/585#discussion_r1002176441 ## gradle/solr/force-versions.gradle: ## @@ -0,0 +1,35 @@ +/* + * 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. + */ + + +// Force slf4j version so that it does not get auto promoted from 1x to 2-alpha due to Jetty dependency. Review Comment: So I know it was added a LONG time ago by dweiss during the initial gradle migration: * https://github.com/apache/solr/commit/ca8661bc3ae4cf5076f5df6412f04f78350e238c * https://github.com/apache/solr/commit/73e8b49f0d077e4c85d3d5c726d1acc0c6d2ac69 It was removed in SOLR-15987 since we were able to get to a consistent slf4j version again: https://github.com/apache/solr/commit/d9373b418474d28676e3812cf42e33d7b7f51c51 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on pull request #585: SOLR-15955: Update Jetty dependency to 10
risdenk commented on PR #585: URL: https://github.com/apache/solr/pull/585#issuecomment-1287418604 > SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions prior to 1.8. Hmmm - thats concerning. we have slf4j 1.7.x in versions.lock and no other slf4j according to versions.lock. So somehow slf4j > 1.7 is getting included. I'll take a closer look and see what is going on. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16188) Antora generates wrong .htaccess file
[
https://issues.apache.org/jira/browse/SOLR-16188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622480#comment-17622480
]
Houston Putman commented on SOLR-16188:
---
Yeah we should delete the "guide" page and link directly to the latest ref
guide version's home page. We should also link the ref guide as a button at the
top of the page Maybe we close this and open another issue.
> Antora generates wrong .htaccess file
> -
>
> Key: SOLR-16188
> URL: https://issues.apache.org/jira/browse/SOLR-16188
> Project: Solr
> Issue Type: Bug
> Components: documentation
>Reporter: Jan Høydahl
>Priority: Major
>
> Spinoff from [https://github.com/apache/solr-site/pull/77]
> When running
> {code:java}
> ./gradlew buildOfficialSite {code}
> there is a {{.htaccess}} file generated in
> {{solr/solr-ref-guide/build/site/.htaccess}} with antora-generated redirects
> for things like "latest" links and page renames. On branch_9_0 antora
> currently generates this file
> {code:java}
> Redirect 302 /guide/solr/latest /guide/solr/9_0
> Redirect 301 /guide/index.html /guide/solr/9_0/index.html {code}
> I believe the first line is ok, but the seconds one is wrong, as the
> {{/guide/index.html}} is managed by our website, not refguide, and there
> should not be a permanent redirect to a specific version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16188) Antora generates wrong .htaccess file
[
https://issues.apache.org/jira/browse/SOLR-16188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622479#comment-17622479
]
Kevin Risden commented on SOLR-16188:
-
[~houston] / [~janhoy] is there more to do here?
> Antora generates wrong .htaccess file
> -
>
> Key: SOLR-16188
> URL: https://issues.apache.org/jira/browse/SOLR-16188
> Project: Solr
> Issue Type: Bug
> Components: documentation
>Reporter: Jan Høydahl
>Priority: Major
>
> Spinoff from [https://github.com/apache/solr-site/pull/77]
> When running
> {code:java}
> ./gradlew buildOfficialSite {code}
> there is a {{.htaccess}} file generated in
> {{solr/solr-ref-guide/build/site/.htaccess}} with antora-generated redirects
> for things like "latest" links and page renames. On branch_9_0 antora
> currently generates this file
> {code:java}
> Redirect 302 /guide/solr/latest /guide/solr/9_0
> Redirect 301 /guide/index.html /guide/solr/9_0/index.html {code}
> I believe the first line is ok, but the seconds one is wrong, as the
> {{/guide/index.html}} is managed by our website, not refguide, and there
> should not be a permanent redirect to a specific version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] epugh opened a new pull request, #1107: SOLR-9775 fixed NPEs
epugh opened a new pull request, #1107: URL: https://github.com/apache/solr/pull/1107 https://issues.apache.org/jira/browse/SOLR-9775 # Description This is brought over from https://github.com/apache/lucene-solr/pull/116/files # Solution I feel like I am pulling a thread on a sweater. It feels odd that we have so much handling around nulls And that this whole thing needs some refactoring so there aren't nulls. In fact, there is kind of a comment about this in `QueryResultKey.unorderedCompare()`: ``` // SOLR-5618: if we had a guarantee that the lists never contained any duplicates, // this logic could be a lot simpler // // (And of course: if the SolrIndexSearcher / QueryCommand was ever changed to // sort the filter query list, then this whole method could be eliminated). ``` It feels like if we simplified the types of objects passed into the `QueryResultKey` this would all be simpler. It's literally just a key! # Tests Existing tests, and then added some to demonstrate the NPE and then the fix... # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [ ] I have developed this patch against the `main` branch. - [ ] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] dsmiley commented on a diff in pull request #585: SOLR-15955: Update Jetty dependency to 10
dsmiley commented on code in PR #585: URL: https://github.com/apache/solr/pull/585#discussion_r1002157652 ## gradle/solr/force-versions.gradle: ## @@ -0,0 +1,35 @@ +/* + * 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. + */ + + +// Force slf4j version so that it does not get auto promoted from 1x to 2-alpha due to Jetty dependency. Review Comment: The technique here is new to me. I see enforcedPlatform documented [here](https://docs.gradle.org/current/userguide/platforms.html#sub:bom_import). Okay I guess. It seems like this is a little-known solution to the problem we are solving. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16368) Refactoring: Use SolrClient type instead of overly specific subclasses
[
https://issues.apache.org/jira/browse/SOLR-16368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622475#comment-17622475
]
Eric Pugh commented on SOLR-16368:
--
I think that this is done as far as can be until we decide how, in our tests,
we want to deal with looking up an HttpClient, as that is why we typically are
using a more specific subclass. I am not sure how to make a decision on
that...
To make this more fun, there are quite a few ways of using the HttpClient
through out the code base:
{{try (HttpSolrClient cl = (HttpSolrClient) j.newClient()) {}}
{{ Utils.executeHttpMethod(cl.getHttpClient(), path, Utils.JSONCONSUMER,
del);}}
{{ }}}
and
{{ ByteBuffer buf =}}
{{ Utils.executeGET(}}
{{ solrClient.getHttpClient(),}}
{{ baseUrl + "/node/files" + path,}}
{{ Utils.newBytesConsumer(Integer.MAX_VALUE));}}
There are some refactorings we could do, for example the method
assertDocExists() and realTimeGetDocId() exists in many test classes. I will
take those refactorings forward
> Refactoring: Use SolrClient type instead of overly specific subclasses
> --
>
> Key: SOLR-16368
> URL: https://issues.apache.org/jira/browse/SOLR-16368
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Assignee: Eric Pugh
>Priority: Minor
> Fix For: main (10.0), 9.2
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> There are many references to a specific SolrClient subclass that could simply
> refer to SolrClient generally, or perhaps CloudSolrClient. This impedes
> switching/migrating to different SolrClient implementations. A similar
> example: we know it's a bad practice to declare a List as ArrayList even when
> it is one; the idea here with SolrClient is the same.
> And furthermore, often times "var solrClient = ..." (or even "var solr =
> ...") is totally adequate in the Solr codebase within a method because the
> variable name adequately communicates the type. These sorts of changes
> should happen first, and then weaken type references in APIs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on pull request #1105: SOLR-13880: Add test that creates/reloads/deletes collections
risdenk commented on PR #1105: URL: https://github.com/apache/solr/pull/1105#issuecomment-1287395562 > there are a MILLION places where we create raw HttpGet in the tests yea more of a we can skip it now but probably has to be fixed at some point :) -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15733) Separate out a solrj-streaming module
[
https://issues.apache.org/jira/browse/SOLR-15733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622473#comment-17622473
]
Houston Putman commented on SOLR-15733:
---
Ok good to know there are actual dependencies that would be separated out. And
I don't really understand the whole sql/jdbc/streaming relationship, but if
splitting out streaming makes splitting out the others easier, then thats a
good reason as well.
> Separate out a solrj-streaming module
> -
>
> Key: SOLR-15733
> URL: https://issues.apache.org/jira/browse/SOLR-15733
> Project: Solr
> Issue Type: Sub-task
>Reporter: Jan Høydahl
>Assignee: Joel Bernstein
>Priority: Major
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> The huge amount of streaming expression code under
> {{org.apache.solr.client.solrj.io}} package can be shipped as an optional
> jar. The {{solrj-jdbc}} (or {{solrj-sql}}) modules would then have a
> dependency on this...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr-site] janhoy merged pull request #79: Announce news about JDK17 JIT bug and new JRE vendor for Solr 8 docker.
janhoy merged PR #79: URL: https://github.com/apache/solr-site/pull/79 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-14410) Switch from SysV init script to systemd service definition
[ https://issues.apache.org/jira/browse/SOLR-14410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622464#comment-17622464 ] Jan Høydahl commented on SOLR-14410: We need help testing the PR for this on more Linux distros. See [Pull Request #428|https://github.com/apache/solr/pull/428] for instructions. > Switch from SysV init script to systemd service definition > -- > > Key: SOLR-14410 > URL: https://issues.apache.org/jira/browse/SOLR-14410 > Project: Solr > Issue Type: Improvement >Reporter: Marius Ghita >Assignee: Jan Høydahl >Priority: Major > Attachments: solr.service > > Time Spent: 4h > Remaining Estimate: 0h > > The proposed change will incorporate the attached service definition file in > the solr installation script. > > More information on the mailinglist > [http://mail-archives.apache.org/mod_mbox/lucene-dev/202004.mbox/%3ccafszzzxs+zh1mrscsjftyxn0kod_+6fjobxd9zhxt66fhaz...@mail.gmail.com%3e] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16309) Upgrade vulnerable jQuery UI to version 1.13.2
[ https://issues.apache.org/jira/browse/SOLR-16309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-16309: Priority: Minor (was: Major) > Upgrade vulnerable jQuery UI to version 1.13.2 > -- > > Key: SOLR-16309 > URL: https://issues.apache.org/jira/browse/SOLR-16309 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 8.8.1 >Reporter: Michael Riedel >Priority: Minor > > The Solr webapp [contains jQuery UI version > 1.12.1|https://github.com/apache/solr/blob/main/solr/webapp/web/libs/jquery-ui.min.js]. > This jQuery UI version is vulnerable to the following vulnerabilities (and > possibly others): > * [CVE-2021-41182|https://nvd.nist.gov/vuln/detail/CVE-2021-41182] > * [CVE-2021-41183|https://nvd.nist.gov/vuln/detail/CVE-2021-41183] > * [CVE-2021-41184|https://nvd.nist.gov/vuln/detail/CVE-2021-41184] > Actually, the first two CVEs may not be relevant, because Solr uses a custom > jQuery UI subset, which currently does not contain the jQuery UI datepicker > component. Solr's custom jQuery UI subset does include the jQuery UI position > utility and might be vulnerable to that last CVE. > I'm working with a dev team who build Solr themselves. Their library > dependency scans constantly complain about all of the above CVEs. I believe > that the actual risk of an exploitable vulnerability stemming from this > jQuery UI version is really small. But an upgrade would shut up such tools. > It's really more a compliance issue rather than a security issue. But > upgrading to latest jQuery UI 1.13.2 or newer, would shut up similar security > scans for other Solr users. And moving to the latest version might make it > easier to upgrade to future jQuery UI versions, when a more impactful > vulnerability becomes known. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16220) Documentation leads to NPE Missing SslContextFactory for SolrJ client
[
https://issues.apache.org/jira/browse/SOLR-16220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-16220:
Labels: newdev (was: )
> Documentation leads to NPE Missing SslContextFactory for SolrJ client
> -
>
> Key: SOLR-16220
> URL: https://issues.apache.org/jira/browse/SOLR-16220
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
>Affects Versions: 9.0
> Environment: JDK used is:
> {noformat}
> openjdk 11.0.14.1 2022-02-08 LTS
> OpenJDK Runtime Environment Zulu11.54+26-SA (build 11.0.14.1+1-LTS)
> OpenJDK 64-Bit Server VM Zulu11.54+26-SA (build 11.0.14.1+1-LTS, mixed
> mode){noformat}
>Reporter: Gunnar Wagenknecht
>Priority: Minor
> Labels: newdev
>
> Following the documentation here:
> [https://solr.apache.org/guide/solr/latest/deployment-guide/solrj.html]
>
> This code leads to an NPE:
> {noformat}
> Http2SolrClient mavenCentralRepo = new
> Http2SolrClient.Builder("https://search.maven.org/solrsearch";).build();
> final SolrQuery query = new SolrQuery("fc:" + className);
> query.setRows(20);
> QueryResponse response = mavenCentralRepo.query(query);{noformat}
> NPE:
> {noformat}
> java.lang.NullPointerException: Missing SslContextFactory
> at java.base/java.util.Objects.requireNonNull(Objects.java:246)
> at
> org.eclipse.jetty.io.ssl.SslClientConnectionFactory.(SslClientConnectionFactory.java:57)
> at
> org.eclipse.jetty.client.HttpClient.newSslClientConnectionFactory(HttpClient.java:1208)
> at
> org.eclipse.jetty.client.HttpClient.newSslClientConnectionFactory(HttpClient.java:1214)
> at
> org.eclipse.jetty.client.HttpDestination.newSslClientConnectionFactory(HttpDestination.java:148)
> at
> org.eclipse.jetty.client.HttpDestination.newSslClientConnectionFactory(HttpDestination.java:154)
> at
> org.eclipse.jetty.client.HttpDestination.(HttpDestination.java:94)
> at
> org.eclipse.jetty.client.MultiplexHttpDestination.(MultiplexHttpDestination.java:25)
> at
> org.eclipse.jetty.http2.client.http.HttpDestinationOverHTTP2.(HttpDestinationOverHTTP2.java:32)
> at
> org.eclipse.jetty.http2.client.http.HttpClientTransportOverHTTP2.newHttpDestination(HttpClientTransportOverHTTP2.java:128)
> at
> org.eclipse.jetty.client.HttpClient.lambda$resolveDestination$0(HttpClient.java:575)
> at
> java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1705)
> at
> org.eclipse.jetty.client.HttpClient.resolveDestination(HttpClient.java:573)
> at
> org.eclipse.jetty.client.HttpClient.resolveDestination(HttpClient.java:551)
> at org.eclipse.jetty.client.HttpClient.send(HttpClient.java:599)
> at org.eclipse.jetty.client.HttpRequest.sendAsync(HttpRequest.java:778)
> at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:765)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:448)
> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:217)
> at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:927)
> at
> org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:940){noformat}
> I think there is a bug in Http2SolrClient somewhere. Such URLs should be
> supported out of the box on a Java 11 JDK without requiring users to provide
> system properties or other custom initialization. Otherwise it should be
> documented but I couldn't find anything related to TLS/SSL configuration in
> the doc mentioned above.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16309) Upgrade vulnerable jQuery UI to version 1.13.2
[ https://issues.apache.org/jira/browse/SOLR-16309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-16309: Component/s: Admin UI > Upgrade vulnerable jQuery UI to version 1.13.2 > -- > > Key: SOLR-16309 > URL: https://issues.apache.org/jira/browse/SOLR-16309 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 8.8.1 >Reporter: Michael Riedel >Priority: Major > > The Solr webapp [contains jQuery UI version > 1.12.1|https://github.com/apache/solr/blob/main/solr/webapp/web/libs/jquery-ui.min.js]. > This jQuery UI version is vulnerable to the following vulnerabilities (and > possibly others): > * [CVE-2021-41182|https://nvd.nist.gov/vuln/detail/CVE-2021-41182] > * [CVE-2021-41183|https://nvd.nist.gov/vuln/detail/CVE-2021-41183] > * [CVE-2021-41184|https://nvd.nist.gov/vuln/detail/CVE-2021-41184] > Actually, the first two CVEs may not be relevant, because Solr uses a custom > jQuery UI subset, which currently does not contain the jQuery UI datepicker > component. Solr's custom jQuery UI subset does include the jQuery UI position > utility and might be vulnerable to that last CVE. > I'm working with a dev team who build Solr themselves. Their library > dependency scans constantly complain about all of the above CVEs. I believe > that the actual risk of an exploitable vulnerability stemming from this > jQuery UI version is really small. But an upgrade would shut up such tools. > It's really more a compliance issue rather than a security issue. But > upgrading to latest jQuery UI 1.13.2 or newer, would shut up similar security > scans for other Solr users. And moving to the latest version might make it > easier to upgrade to future jQuery UI versions, when a more impactful > vulnerability becomes known. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16309) Upgrade vulnerable jQuery UI to version 1.13.2
[ https://issues.apache.org/jira/browse/SOLR-16309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-16309: Issue Type: Task (was: Bug) > Upgrade vulnerable jQuery UI to version 1.13.2 > -- > > Key: SOLR-16309 > URL: https://issues.apache.org/jira/browse/SOLR-16309 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 8.8.1 >Reporter: Michael Riedel >Priority: Major > > The Solr webapp [contains jQuery UI version > 1.12.1|https://github.com/apache/solr/blob/main/solr/webapp/web/libs/jquery-ui.min.js]. > This jQuery UI version is vulnerable to the following vulnerabilities (and > possibly others): > * [CVE-2021-41182|https://nvd.nist.gov/vuln/detail/CVE-2021-41182] > * [CVE-2021-41183|https://nvd.nist.gov/vuln/detail/CVE-2021-41183] > * [CVE-2021-41184|https://nvd.nist.gov/vuln/detail/CVE-2021-41184] > Actually, the first two CVEs may not be relevant, because Solr uses a custom > jQuery UI subset, which currently does not contain the jQuery UI datepicker > component. Solr's custom jQuery UI subset does include the jQuery UI position > utility and might be vulnerable to that last CVE. > I'm working with a dev team who build Solr themselves. Their library > dependency scans constantly complain about all of the above CVEs. I believe > that the actual risk of an exploitable vulnerability stemming from this > jQuery UI version is really small. But an upgrade would shut up such tools. > It's really more a compliance issue rather than a security issue. But > upgrading to latest jQuery UI 1.13.2 or newer, would shut up similar security > scans for other Solr users. And moving to the latest version might make it > easier to upgrade to future jQuery UI versions, when a more impactful > vulnerability becomes known. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16220) Documentation leads to NPE Missing SslContextFactory for SolrJ client
[
https://issues.apache.org/jira/browse/SOLR-16220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-16220:
Component/s: documentation
> Documentation leads to NPE Missing SslContextFactory for SolrJ client
> -
>
> Key: SOLR-16220
> URL: https://issues.apache.org/jira/browse/SOLR-16220
> Project: Solr
> Issue Type: Bug
> Components: documentation, SolrJ
>Affects Versions: 9.0
> Environment: JDK used is:
> {noformat}
> openjdk 11.0.14.1 2022-02-08 LTS
> OpenJDK Runtime Environment Zulu11.54+26-SA (build 11.0.14.1+1-LTS)
> OpenJDK 64-Bit Server VM Zulu11.54+26-SA (build 11.0.14.1+1-LTS, mixed
> mode){noformat}
>Reporter: Gunnar Wagenknecht
>Priority: Minor
> Labels: newdev
>
> Following the documentation here:
> [https://solr.apache.org/guide/solr/latest/deployment-guide/solrj.html]
>
> This code leads to an NPE:
> {noformat}
> Http2SolrClient mavenCentralRepo = new
> Http2SolrClient.Builder("https://search.maven.org/solrsearch";).build();
> final SolrQuery query = new SolrQuery("fc:" + className);
> query.setRows(20);
> QueryResponse response = mavenCentralRepo.query(query);{noformat}
> NPE:
> {noformat}
> java.lang.NullPointerException: Missing SslContextFactory
> at java.base/java.util.Objects.requireNonNull(Objects.java:246)
> at
> org.eclipse.jetty.io.ssl.SslClientConnectionFactory.(SslClientConnectionFactory.java:57)
> at
> org.eclipse.jetty.client.HttpClient.newSslClientConnectionFactory(HttpClient.java:1208)
> at
> org.eclipse.jetty.client.HttpClient.newSslClientConnectionFactory(HttpClient.java:1214)
> at
> org.eclipse.jetty.client.HttpDestination.newSslClientConnectionFactory(HttpDestination.java:148)
> at
> org.eclipse.jetty.client.HttpDestination.newSslClientConnectionFactory(HttpDestination.java:154)
> at
> org.eclipse.jetty.client.HttpDestination.(HttpDestination.java:94)
> at
> org.eclipse.jetty.client.MultiplexHttpDestination.(MultiplexHttpDestination.java:25)
> at
> org.eclipse.jetty.http2.client.http.HttpDestinationOverHTTP2.(HttpDestinationOverHTTP2.java:32)
> at
> org.eclipse.jetty.http2.client.http.HttpClientTransportOverHTTP2.newHttpDestination(HttpClientTransportOverHTTP2.java:128)
> at
> org.eclipse.jetty.client.HttpClient.lambda$resolveDestination$0(HttpClient.java:575)
> at
> java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1705)
> at
> org.eclipse.jetty.client.HttpClient.resolveDestination(HttpClient.java:573)
> at
> org.eclipse.jetty.client.HttpClient.resolveDestination(HttpClient.java:551)
> at org.eclipse.jetty.client.HttpClient.send(HttpClient.java:599)
> at org.eclipse.jetty.client.HttpRequest.sendAsync(HttpRequest.java:778)
> at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:765)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:448)
> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:217)
> at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:927)
> at
> org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:940){noformat}
> I think there is a bug in Http2SolrClient somewhere. Such URLs should be
> supported out of the box on a Java 11 JDK without requiring users to provide
> system properties or other custom initialization. Otherwise it should be
> documented but I couldn't find anything related to TLS/SSL configuration in
> the doc mentioned above.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] janhoy commented on pull request #428: SOLR-14410: switch from SysV to systemd service
janhoy commented on PR #428: URL: https://github.com/apache/solr/pull/428#issuecomment-1287381176 I brought this PR up to date with main, so it can be easily tested. You can check out the PR branch locally, build and then try installing, or you can download a prebuilt tar from http://cominvent.com/pub/solr-10.0.0-SNAPSHOT.tgz -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] epugh commented on pull request #1105: SOLR-13880: Add test that creates/reloads/deletes collections
epugh commented on PR #1105: URL: https://github.com/apache/solr/pull/1105#issuecomment-1287380545 @risdenk there are a MILLION places where we create raw HttpGet in the tests, I saw that when I tried to migrate things to `SolrClient` or `SolrCloudClient`... It would be great if we had a general pattern for I want to just do a HTTP thing and look at the results. As far at not using an API, well, there are two examples, one using the SolrJ, the other with the long string -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-16233) Add HTTP headers support to LogUpdateProcessorFactory
[ https://issues.apache.org/jira/browse/SOLR-16233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden resolved SOLR-16233. - Resolution: Incomplete [~Idjeraoui] there isn't any detail to go on here. > Add HTTP headers support to LogUpdateProcessorFactory > - > > Key: SOLR-16233 > URL: https://issues.apache.org/jira/browse/SOLR-16233 > Project: Solr > Issue Type: New Feature >Reporter: Lamine >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16363) addDoc() in DirectUpdateHandler2 needs additional Exception Handling
[
https://issues.apache.org/jira/browse/SOLR-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622460#comment-17622460
]
Kevin Risden commented on SOLR-16363:
-
This looks valid. need to do something like `.replace("%", "%%");` on the
message string. We should check the rest of the Solr codebase for similar
issues. String.format is used in a bunch of places :/
> addDoc() in DirectUpdateHandler2 needs additional Exception Handling
>
>
> Key: SOLR-16363
> URL: https://issues.apache.org/jira/browse/SOLR-16363
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Affects Versions: 8.11.2, main (10.0)
>Reporter: Aman Verma
>Priority: Minor
>
> In certain situation, to handle IllegalArgumentException while adding doc to
> solr is linked below
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L249|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L250]
> EDIT: Adding Code piece for current main branch:
> [https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L314]
>
> This can be problematic if IllegalArgumentException (of the following format)
> is thrown during processing of docs (in my case it was via Filters to
> URL-Decode a string)
>
> {code:java}
> java.lang.IllegalArgumentException: URLDecoder: Illegal hex characters in
> escape (%) pattern - Error at index 0 in: "sy"{code}
> The _iae.getMessage()_ in this case contains "{*}%){*}" which conflicts with
> String.format which would further throw
> {code:java}
> java.util.UnknownFormatConversionException: Conversion = ')'
> at java.util.Formatter.checkText(Unknown Source) ~[?:?]
> at java.util.Formatter.parse(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.lang.String.format(Unknown Source) ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:249){code}
> This particular exception is not caught and as a result the BAD_REQUEST was
> never returned to the client along with failure point in the chain.
> The ticket is a proposal to make this more robust i.e., in this particular
> situation either getMessage() could replaceAll "%" or perhaps another try?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15733) Separate out a solrj-streaming module
[
https://issues.apache.org/jira/browse/SOLR-15733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622458#comment-17622458
]
Kevin Risden commented on SOLR-15733:
-
{quote}I just don't find it very useful to have an artifact that holds a few
classes and no additional dependencies in our ideal end-state.{quote}
commons-math is at least one dependency already. guava and maybe others in
tests. I think it makes it easier to see what libraries are needed.
also streaming expressions has some interesting dependencies on sql. would be
good to see if we can slim down regular solrj to avoid most of that cross
module dependency.
{quote}overall I think there needs to be a user-centered reason for splitting
out solrj-streaming.{quote}
so we could even just have this internally separated out and always have solrj
have a dependency on it if we want. end user would never know the difference.
It just makes it cleaner to support.
> Separate out a solrj-streaming module
> -
>
> Key: SOLR-15733
> URL: https://issues.apache.org/jira/browse/SOLR-15733
> Project: Solr
> Issue Type: Sub-task
>Reporter: Jan Høydahl
>Assignee: Joel Bernstein
>Priority: Major
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> The huge amount of streaming expression code under
> {{org.apache.solr.client.solrj.io}} package can be shipped as an optional
> jar. The {{solrj-jdbc}} (or {{solrj-sql}}) modules would then have a
> dependency on this...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15733) Separate out a solrj-streaming module
[
https://issues.apache.org/jira/browse/SOLR-15733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622456#comment-17622456
]
Houston Putman commented on SOLR-15733:
---
> we will still include a handful of TupleStream implementations in
> solrj-streaming for backcompat.
I just don't find it very useful to have an artifact that holds a few classes
and no additional dependencies in our ideal end-state.
> There has been enough pushback on this sitting in the main solrj jar that
> I've basically stopped working on it.
So I can think of two reasons for pushback:
* If you want to introduce new mathy libraries that we don't want in SolrJ,
then this is probably a good step.
* If people are complaining about excessive SolrJ work being done then I think
it's just a ridiculous complaint and we can solve the dispute without a code
change. We have a plan to move streaming out of SolrJ near the end of Solr 9,
close to when Solr 10 is cut. As long as we follow through on that plan, I
don't see how people could have any issues with you working on streaming
improvements while its still in SolrJ.
Overall I'm not going to veto this or anything, but overall I think there needs
to be a user-centered reason for splitting out solrj-streaming.
> Separate out a solrj-streaming module
> -
>
> Key: SOLR-15733
> URL: https://issues.apache.org/jira/browse/SOLR-15733
> Project: Solr
> Issue Type: Sub-task
>Reporter: Jan Høydahl
>Assignee: Joel Bernstein
>Priority: Major
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> The huge amount of streaming expression code under
> {{org.apache.solr.client.solrj.io}} package can be shipped as an optional
> jar. The {{solrj-jdbc}} (or {{solrj-sql}}) modules would then have a
> dependency on this...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-9775) NPE in QueryResultKey constructor (when executing a clustering search query?)
[ https://issues.apache.org/jira/browse/SOLR-9775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622455#comment-17622455 ] Eric Pugh commented on SOLR-9775: - There is a QueryResultKeyTest, so I added a test where you have a null, and yeah, it is kind of werid? Should we be making QueryResultKey more robust, or is there anohter bug somewhere? I.e your second point... > NPE in QueryResultKey constructor (when executing a clustering search query?) > - > > Key: SOLR-9775 > URL: https://issues.apache.org/jira/browse/SOLR-9775 > Project: Solr > Issue Type: Bug >Reporter: Christine Poerschke >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > https://github.com/apache/lucene-solr/pull/116 from Roman Kagan yesterday > (November 2016) has a fix. > On the solr-user mailing list (in March) Tim Hearn > [reported|http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201603.mbox/%3CCAFoZJmC87Lbuj%2BaYwcVh%2B5ay_%3Dwi5n8TGs7gBPcF%3Djjo%2BW7vGg%40mail.gmail.com%3E] > encountering what sounds like the same NPE when executing a clustering > search query. > This ticket to tentatively link the two together. Open question: do we want > to include a reproducing test case along with the fix or just commit the fix > alone? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-9775) NPE in QueryResultKey constructor (when executing a clustering search query?)
[
https://issues.apache.org/jira/browse/SOLR-9775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622448#comment-17622448
]
Kevin Risden edited comment on SOLR-9775 at 10/21/22 7:40 PM:
--
https://lists.apache.org/thread/ptdt7joh387610z4lk4jdw581srmwjbh linked in the
description has a query that might be possible to throw in a test somewhere?
A few other things:
* QueryResultKey - probably can create a small unit tests to get this to happen
* I'd be curious if there is another underlying bug somewhere - QueryResultKey
has QueryResultKey(Query query, List filters, Sort sort, int nc_flags)
as the definition. So somewhere QueryResultKey is being called with a non empty
filters list that has null entries... why?
was (Author: risdenk):
https://lists.apache.org/thread/ptdt7joh387610z4lk4jdw581srmwjbh linked in the
description has a query that might be possible to throw in a test somewhere?
A few other things:
* QueryResultKey - probably can create a small unit tests to get this to happen
* I'd be curious if there is another underlying bug somewhere - QueryResultKey
has QueryResultKey(Query query, List filters, Sort sort, int nc_flags) {
as the definition. So somewhere QueryResultKey is being called with a non empty
filters list that has null entries... why?
> NPE in QueryResultKey constructor (when executing a clustering search query?)
> -
>
> Key: SOLR-9775
> URL: https://issues.apache.org/jira/browse/SOLR-9775
> Project: Solr
> Issue Type: Bug
>Reporter: Christine Poerschke
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://github.com/apache/lucene-solr/pull/116 from Roman Kagan yesterday
> (November 2016) has a fix.
> On the solr-user mailing list (in March) Tim Hearn
> [reported|http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201603.mbox/%3CCAFoZJmC87Lbuj%2BaYwcVh%2B5ay_%3Dwi5n8TGs7gBPcF%3Djjo%2BW7vGg%40mail.gmail.com%3E]
> encountering what sounds like the same NPE when executing a clustering
> search query.
> This ticket to tentatively link the two together. Open question: do we want
> to include a reproducing test case along with the fix or just commit the fix
> alone?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-9775) NPE in QueryResultKey constructor (when executing a clustering search query?)
[
https://issues.apache.org/jira/browse/SOLR-9775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622448#comment-17622448
]
Kevin Risden commented on SOLR-9775:
https://lists.apache.org/thread/ptdt7joh387610z4lk4jdw581srmwjbh linked in the
description has a query that might be possible to throw in a test somewhere?
A few other things:
* QueryResultKey - probably can create a small unit tests to get this to happen
* I'd be curious if there is another underlying bug somewhere - QueryResultKey
has QueryResultKey(Query query, List filters, Sort sort, int nc_flags) {
as the definition. So somewhere QueryResultKey is being called with a non empty
filters list that has null entries... why?
> NPE in QueryResultKey constructor (when executing a clustering search query?)
> -
>
> Key: SOLR-9775
> URL: https://issues.apache.org/jira/browse/SOLR-9775
> Project: Solr
> Issue Type: Bug
>Reporter: Christine Poerschke
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://github.com/apache/lucene-solr/pull/116 from Roman Kagan yesterday
> (November 2016) has a fix.
> On the solr-user mailing list (in March) Tim Hearn
> [reported|http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201603.mbox/%3CCAFoZJmC87Lbuj%2BaYwcVh%2B5ay_%3Dwi5n8TGs7gBPcF%3Djjo%2BW7vGg%40mail.gmail.com%3E]
> encountering what sounds like the same NPE when executing a clustering
> search query.
> This ticket to tentatively link the two together. Open question: do we want
> to include a reproducing test case along with the fix or just commit the fix
> alone?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-14410) Switch from SysV init script to systemd service definition
[ https://issues.apache.org/jira/browse/SOLR-14410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622443#comment-17622443 ] Kevin Risden commented on SOLR-14410: - Reported as this causes failures on RHEL 9 - https://lists.apache.org/thread/1prcqjofxx78z2r2wl2dvdyyv61s2f2n > Switch from SysV init script to systemd service definition > -- > > Key: SOLR-14410 > URL: https://issues.apache.org/jira/browse/SOLR-14410 > Project: Solr > Issue Type: Improvement >Reporter: Marius Ghita >Assignee: Jan Høydahl >Priority: Major > Attachments: solr.service > > Time Spent: 3h 50m > Remaining Estimate: 0h > > The proposed change will incorporate the attached service definition file in > the solr installation script. > > More information on the mailinglist > [http://mail-archives.apache.org/mod_mbox/lucene-dev/202004.mbox/%3ccafszzzxs+zh1mrscsjftyxn0kod_+6fjobxd9zhxt66fhaz...@mail.gmail.com%3e] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-15733) Separate out a solrj-streaming module
[
https://issues.apache.org/jira/browse/SOLR-15733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622441#comment-17622441
]
Joel Bernstein edited comment on SOLR-15733 at 10/21/22 7:35 PM:
-
[~houston], the PR is getting closer to completion: code and tests have been
moved, tests are passing and precommit is passing.
There may be some work to get the artifact published to maven and CHANGES.txt
will need to include how and when the new solrj-streaming artifact is used.
>From a customer standpoint this is the only change they are likely to see
>going forward. If we decide to move streaming expressions into core or a
>server module in 10, we will still include a handful of TupleStream
>implementations in solrj-streaming for backcompat.
Let me know if you still have concerns with this ticket.
was (Author: joel.bernstein):
[~houston], the PR is getting closer to completion: code and tests have been
moved, tests are passing and precommit is passing.
There may be some work to get the artifact published to maven and CHANGES.txt
will need to include how and when the new solrj-streaming artifact is used.
>From a customer standpoint this is the only change they are likely to see
>going forward. If we decide to move streaming expressions into core or a
>server module in 10, we will still include handful of TupleStream
>implementations in solrj-streaming for backcompat.
Let me know if you still have concerns with the ticket.
> Separate out a solrj-streaming module
> -
>
> Key: SOLR-15733
> URL: https://issues.apache.org/jira/browse/SOLR-15733
> Project: Solr
> Issue Type: Sub-task
>Reporter: Jan Høydahl
>Assignee: Joel Bernstein
>Priority: Major
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> The huge amount of streaming expression code under
> {{org.apache.solr.client.solrj.io}} package can be shipped as an optional
> jar. The {{solrj-jdbc}} (or {{solrj-sql}}) modules would then have a
> dependency on this...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-15733) Separate out a solrj-streaming module
[
https://issues.apache.org/jira/browse/SOLR-15733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622441#comment-17622441
]
Joel Bernstein edited comment on SOLR-15733 at 10/21/22 7:34 PM:
-
[~houston], the PR is getting closer to completion: code and tests have been
moved, tests are passing and precommit is passing.
There may be some work to get the artifact published to maven and CHANGES.txt
will need to include how and when the new solrj-streaming artifact is used.
>From a customer standpoint this is the only change they are likely to see
>going forward. If we decide to move streaming expressions into core or a
>server module in 10, we will still include handful of TupleStream
>implementations in solrj-streaming for backcompat.
Let me know if you still have concerns with the ticket.
was (Author: joel.bernstein):
[~houston], the PR is getting closer to completion: code and tests have been
moved, tests are passing and precommit is passing.
There may be some work to get the artifact published to maven and CHANGES.txt
will need to include how and when the new solrj-streaming artifact is used.
>From a customer standpoint this is the only change they are likely to see
>going forward. If we decide to move streaming expressions into core or a
>server module in 10, we will still include handful of TupleStream
>implementations in solrj-streaming for backcompat.
Let me know if you still have concerns with ticket.
> Separate out a solrj-streaming module
> -
>
> Key: SOLR-15733
> URL: https://issues.apache.org/jira/browse/SOLR-15733
> Project: Solr
> Issue Type: Sub-task
>Reporter: Jan Høydahl
>Assignee: Joel Bernstein
>Priority: Major
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> The huge amount of streaming expression code under
> {{org.apache.solr.client.solrj.io}} package can be shipped as an optional
> jar. The {{solrj-jdbc}} (or {{solrj-sql}}) modules would then have a
> dependency on this...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-15733) Separate out a solrj-streaming module
[
https://issues.apache.org/jira/browse/SOLR-15733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622441#comment-17622441
]
Joel Bernstein edited comment on SOLR-15733 at 10/21/22 7:33 PM:
-
[~houston], the PR is getting closer to completion: code and tests have been
moved, tests are passing and precommit is passing.
There may be some work to get the artifact published to maven and CHANGES.txt
will need to include how and when the new solrj-streaming artifact is used.
>From a customer standpoint this is the only change they are likely to see
>going forward. If we decide to move streaming expressions into core or a
>server module in 10, we will still include handful of TupleStream
>implementations in solrj-streaming for backcompat.
Let me know if you still have concerns with ticket.
was (Author: joel.bernstein):
[~houston], the PR is getting closer to completion: code and tests have been
moved, tests are passing and precommit is passing.
There may be some work to get the artifact published to maven and CHANGES.txt
will need to include how and when the new solrj-streaming artifact is used.
>From a customer standpoint this is the only change they are likely to see
>going forward. If we decide to move streaming expression into core or a server
>module in 10, we will still include handful of TupleStream implementations in
>solrj-streaming for backcompat.
Let me know if you still have concerns with ticket.
> Separate out a solrj-streaming module
> -
>
> Key: SOLR-15733
> URL: https://issues.apache.org/jira/browse/SOLR-15733
> Project: Solr
> Issue Type: Sub-task
>Reporter: Jan Høydahl
>Assignee: Joel Bernstein
>Priority: Major
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> The huge amount of streaming expression code under
> {{org.apache.solr.client.solrj.io}} package can be shipped as an optional
> jar. The {{solrj-jdbc}} (or {{solrj-sql}}) modules would then have a
> dependency on this...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15733) Separate out a solrj-streaming module
[
https://issues.apache.org/jira/browse/SOLR-15733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622441#comment-17622441
]
Joel Bernstein commented on SOLR-15733:
---
[~houston], the PR is getting closer to completion: code and tests have been
moved, tests are passing and precommit is passing.
There may be some work to get the artifact published to maven and CHANGES.txt
will need to include how and when the new solrj-streaming artifact is used.
>From a customer standpoint this is the only change they are likely to see
>going forward. If we decide to move streaming expression into core or a server
>module in 10, we will still include handful of TupleStream implementations in
>solrj-streaming for backcompat.
Let me know if you still have concerns with ticket.
> Separate out a solrj-streaming module
> -
>
> Key: SOLR-15733
> URL: https://issues.apache.org/jira/browse/SOLR-15733
> Project: Solr
> Issue Type: Sub-task
>Reporter: Jan Høydahl
>Assignee: Joel Bernstein
>Priority: Major
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> The huge amount of streaming expression code under
> {{org.apache.solr.client.solrj.io}} package can be shipped as an optional
> jar. The {{solrj-jdbc}} (or {{solrj-sql}}) modules would then have a
> dependency on this...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16443) Upgrade Jackson bom to 2.13.4.20221013
[ https://issues.apache.org/jira/browse/SOLR-16443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-16443: Status: Patch Available (was: Open) > Upgrade Jackson bom to 2.13.4.20221013 > -- > > Key: SOLR-16443 > URL: https://issues.apache.org/jira/browse/SOLR-16443 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.11.2, 9.1 >Reporter: Nicolò Mendola >Assignee: Kevin Risden >Priority: Minor > > Due to actual jackson-databind cve listing CVE-2022-42004 and CVE-2022-42003 > the Libary should be updated. > [https://nvd.nist.gov/vuln/detail/CVE-2022-42004] > https://nvd.nist.gov/vuln/detail/CVE-2022-42003 > > Perhaps for version 9.1.0 as well as 8.11.2? > Best Regards > h4. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16443) Upgrade Jackson bom to 2.13.4.20221013
[ https://issues.apache.org/jira/browse/SOLR-16443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622439#comment-17622439 ] Kevin Risden commented on SOLR-16443: - Added annotations to compileOnly to work around LOG4J2-3609 it looks like. > Upgrade Jackson bom to 2.13.4.20221013 > -- > > Key: SOLR-16443 > URL: https://issues.apache.org/jira/browse/SOLR-16443 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.11.2, 9.1 >Reporter: Nicolò Mendola >Assignee: Kevin Risden >Priority: Minor > > Due to actual jackson-databind cve listing CVE-2022-42004 and CVE-2022-42003 > the Libary should be updated. > [https://nvd.nist.gov/vuln/detail/CVE-2022-42004] > https://nvd.nist.gov/vuln/detail/CVE-2022-42003 > > Perhaps for version 9.1.0 as well as 8.11.2? > Best Regards > h4. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk opened a new pull request, #1106: SOLR-16433: Upgrade Jackson bom to 2.13.4.20221013
risdenk opened a new pull request, #1106: URL: https://github.com/apache/solr/pull/1106 https://issues.apache.org/jira/browse/SOLR-16433 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-13360) StringIndexOutOfBoundsException: String index out of range: -3
[
https://issues.apache.org/jira/browse/SOLR-13360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622436#comment-17622436
]
Pasupathi Rajamanickam commented on SOLR-13360:
---
I ran into exact same issue. Do we have any plan to fix it? Increasing 500s in
my traffic for simple search terms. I had to remove my synonyms entry, god only
knows how many syn entry I need to remove in future.
> StringIndexOutOfBoundsException: String index out of range: -3
> --
>
> Key: SOLR-13360
> URL: https://issues.apache.org/jira/browse/SOLR-13360
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.2.1
> Environment: Solr 7.2.1 - SAP Hybris 6.7.0.8
>Reporter: Ahmed Ghoneim
>Priority: Critical
> Attachments: managed-schema, managed-schema, resources.json,
> solr-config.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *{color:#ff}I cannot execute the following query:{color}*
> {noformat}
> http://localhost:8983/solr/master_Project_Product_flip/suggest?q=duotop&spellcheck.q=duotop&qt=/suggest&spellcheck.dictionary=de&spellcheck.collate=true{noformat}
> 4/1/2019, 1:16:07 PM ERROR true RequestHandlerBase
> java.lang.StringIndexOutOfBoundsException: String index out of range: -3
> {code:java}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -3
> at
> java.lang.AbstractStringBuilder.replace(AbstractStringBuilder.java:851)
> at java.lang.StringBuilder.replace(StringBuilder.java:262)
> at
> org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:252)
> at
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:94)
> at
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:297)
> at
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:209)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2503)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:710)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:534)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
> at
> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:251)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at
> org.eclipse.jetty.util.thread.strat
[GitHub] [solr] joel-bernstein commented on pull request #1099: SOLR-15733: Migrate streaming
joel-bernstein commented on PR #1099: URL: https://github.com/apache/solr/pull/1099#issuecomment-1287348911 The full test suit is passing except for the following which fails everytime and seems to be unrelated. 2> 32414 INFO (TEST-PerReplicaStatesIntegrationTest.testPerReplicaStateCollection-seed#[D7017DB2FFB75346]) [] o.a.s.SolrTestCaseJ4 ###Ending testPerReplicaStateCollection > org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:65178/solr: Invalid replica : core_node8 in shard/collection : shard1/perReplicaState_test available replicas are core_node2,core_node6,core_node10 > at __randomizedtesting.SeedInfo.seed([D7017DB2FFB75346:FD3CD6F05F17894B]:0) > at app//org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:720) > at app//org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234) > at app//org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:215) > at app//org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:405) > at app//org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:371) > at app//org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1174) > at app//org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:880) > at app//org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807) > at app//org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:234) > at app//org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:249) > at app//org.apache.solr.common.cloud.PerReplicaStatesIntegrationTest.testPerReplicaStateCollection(PerReplicaStatesIntegrationTest.java:91) > at java.base@11.0.9/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base@11.0.9/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base@11.0.9/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base@11.0.9/java.lang.reflect.Method.invoke(Method.java:566) > at app//com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1758) -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] Pasupathi-Rajamanickam commented on pull request #210: SOLR-13360: Collation code fails with non-increasing token order
Pasupathi-Rajamanickam commented on PR #210: URL: https://github.com/apache/solr/pull/210#issuecomment-1287348469 @raveendrabikkina-metcash I ran into same issue because of Synonyms causing issue when char length mismatch. Do you know when this will be merged and moved to production? -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-9775) NPE in QueryResultKey constructor (when executing a clustering search query?)
[ https://issues.apache.org/jira/browse/SOLR-9775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622431#comment-17622431 ] Eric Pugh commented on SOLR-9775: - [~cpoerschke] This showed up on my radar after [~krisden] pointed it out to me. Seems like it is comittable as is.. Do we know how to make it fail in a unit test? > NPE in QueryResultKey constructor (when executing a clustering search query?) > - > > Key: SOLR-9775 > URL: https://issues.apache.org/jira/browse/SOLR-9775 > Project: Solr > Issue Type: Bug >Reporter: Christine Poerschke >Priority: Minor > > https://github.com/apache/lucene-solr/pull/116 from Roman Kagan yesterday > (November 2016) has a fix. > On the solr-user mailing list (in March) Tim Hearn > [reported|http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201603.mbox/%3CCAFoZJmC87Lbuj%2BaYwcVh%2B5ay_%3Dwi5n8TGs7gBPcF%3Djjo%2BW7vGg%40mail.gmail.com%3E] > encountering what sounds like the same NPE when executing a clustering > search query. > This ticket to tentatively link the two together. Open question: do we want > to include a reproducing test case along with the fix or just commit the fix > alone? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16262) Fix Robots headers for old ref guide pages
[ https://issues.apache.org/jira/browse/SOLR-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622430#comment-17622430 ] Houston Putman commented on SOLR-16262: --- Unfortunately not, just a slack discussion that didn't really go anywhere... https://the-asf.slack.com/archives/CBX4TSBQ8/p1656615770850289 I should make one though, it is very very annoying that this doesn't work. > Fix Robots headers for old ref guide pages > -- > > Key: SOLR-16262 > URL: https://issues.apache.org/jira/browse/SOLR-16262 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > We have a htaccess rules generated to make sure that old versions of ref > guide pages are not indexed by search engines, that way users will get the > latest version of the documentation when they search. The syntax is wrong > however and it does work, but only small changes are needed luckily! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #1105: SOLR-13880: Add test that creates/reloads/deletes collections
risdenk commented on code in PR #1105:
URL: https://github.com/apache/solr/pull/1105#discussion_r1002111360
##
solr/core/src/test/org/apache/solr/cloud/api/collections/CollectionReloadTest.java:
##
@@ -86,4 +96,107 @@ public void testReloadedLeaderStateAfterZkSessionLoss()
throws Exception {
log.info("testReloadedLeaderStateAfterZkSessionLoss succeeded ... shutting
down now!");
}
+
+ @Repeat(iterations = 5)
+ public void testCreateReloadDeleteAllNrt() throws Exception {
+testCreateReloadDelete("testCreateReloadDeleteAllNrt", 3, 0, 0);
+ }
+
+ @Repeat(iterations = 5)
+ public void testCreateReloadDeleteAllTlog() throws Exception {
+testCreateReloadDelete("testCreateReloadDeleteAllTlog", 0, 3, 0);
+ }
+
+ @Repeat(iterations = 5)
+ public void testCreateReloadDeletePull() throws Exception {
+testCreateReloadDelete("testCreateReloadDeletePull", 0, 1, 2);
+ }
+
+ private void testCreateReloadDelete(
+ String collectionName, int nrtReplicas, int tlogReplicas, int
pullReplicas) throws Exception {
+int numShards = 3;
+createCollection(numShards, nrtReplicas, tlogReplicas, pullReplicas,
collectionName);
+boolean reloaded = false;
+while (true) {
+ waitForState(
+ "Timeout waiting for collection " + collectionName,
+ collectionName,
+ clusterShape(numShards, numShards * (nrtReplicas + tlogReplicas +
pullReplicas)));
+ if (reloaded) {
+break;
+ } else {
+// reload
+assertSuccessfulAdminRequest(
+CollectionAdminRequest.reloadCollection(collectionName)
+.process(cluster.getSolrClient()));
+reloaded = true;
+ }
+}
+assertSuccessfulAdminRequest(
+
CollectionAdminRequest.deleteCollection(collectionName).process(cluster.getSolrClient()));
+ }
+
+ private void assertSuccessfulAdminRequest(CollectionAdminResponse response) {
+assertEquals("Unexpected response status", 0, response.getStatus());
+assertTrue("Unsuccessful response: " + response, response.isSuccess());
+ }
+
+ private void createCollection(
+ int numShards, int nrtReplicas, int tlogReplicas, int pullReplicas,
String collectionName)
+ throws SolrServerException, IOException {
+switch (random().nextInt(3)) {
+ case 0:
+log.info("Creating collection with SolrJ");
+// Sometimes use SolrJ
+assertSuccessfulAdminRequest(
+CollectionAdminRequest.createCollection(
+collectionName, "conf", numShards, nrtReplicas,
tlogReplicas, pullReplicas)
+.process(cluster.getSolrClient()));
+break;
+ case 1:
+log.info("Creating collection with V1 API");
+// Sometimes use v1 API
+String url =
+String.format(
+Locale.ROOT,
+
"%s/admin/collections?action=CREATE&name=%s&collection.configName=%s&numShards=%s&maxShardsPerNode=%s&nrtReplicas=%s&tlogReplicas=%s&pullReplicas=%s",
+cluster.getRandomJetty(random()).getBaseUrl(),
+collectionName,
+"conf",
+numShards,
+100, // maxShardsPerNode
+nrtReplicas,
+tlogReplicas,
+pullReplicas);
+HttpGet createCollectionGet = new HttpGet(url);
+((CloudLegacySolrClient) cluster.getSolrClient())
Review Comment:
Do we need this to be `CloudLegacySolrClient`?
##
solr/core/src/test/org/apache/solr/cloud/api/collections/CollectionReloadTest.java:
##
@@ -86,4 +96,107 @@ public void testReloadedLeaderStateAfterZkSessionLoss()
throws Exception {
log.info("testReloadedLeaderStateAfterZkSessionLoss succeeded ... shutting
down now!");
}
+
+ @Repeat(iterations = 5)
+ public void testCreateReloadDeleteAllNrt() throws Exception {
+testCreateReloadDelete("testCreateReloadDeleteAllNrt", 3, 0, 0);
+ }
+
+ @Repeat(iterations = 5)
+ public void testCreateReloadDeleteAllTlog() throws Exception {
+testCreateReloadDelete("testCreateReloadDeleteAllTlog", 0, 3, 0);
+ }
+
+ @Repeat(iterations = 5)
+ public void testCreateReloadDeletePull() throws Exception {
+testCreateReloadDelete("testCreateReloadDeletePull", 0, 1, 2);
+ }
+
+ private void testCreateReloadDelete(
+ String collectionName, int nrtReplicas, int tlogReplicas, int
pullReplicas) throws Exception {
+int numShards = 3;
+createCollection(numShards, nrtReplicas, tlogReplicas, pullReplicas,
collectionName);
+boolean reloaded = false;
+while (true) {
+ waitForState(
+ "Timeout waiting for collection " + collectionName,
+ collectionName,
+ clusterShape(numShards, numShards * (nrtReplicas + tlogReplicas +
pullReplicas)));
+ if (reloaded) {
+break;
+ } else {
+// reload
+assertSuccessfulAdminRequest(
+CollectionAdminRequest.reloadCollection(collection
[GitHub] [solr] joel-bernstein commented on a diff in pull request #1099: SOLR-15733: Migrate streaming
joel-bernstein commented on code in PR #1099:
URL: https://github.com/apache/solr/pull/1099#discussion_r1002114271
##
solr/solrj-streaming/build.gradle:
##
@@ -0,0 +1,52 @@
+/*
+ * 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.
+ */
+
+apply plugin: 'java-library'
+
+description = 'Solrj-Streaming - SolrJ requiring Streaming Expressions'
+
+dependencies {
+
+
+implementation project(':solr:solrj')
+
+// declare dependencies we use even though already declared by solrj-core
+implementation 'org.slf4j:slf4j-api'
+implementation 'org.apache.httpcomponents:httpclient'
+implementation 'org.apache.httpcomponents:httpcore'
+implementation 'org.apache.commons:commons-math3'
+
+testImplementation project(':solr:test-framework')
+testImplementation project(':solr:core')
+
+testImplementation 'junit:junit'
+testImplementation 'commons-io:commons-io'
+testImplementation 'com.google.guava:guava'
+testImplementation project(':solr:solrj-zookeeper')
+
+permitTestUsedUndeclared project(':solr:solrj-zookeeper') // duh!
+
+testImplementation('org.apache.zookeeper:zookeeper', {
+exclude group: "org.apache.yetus", module: "audience-annotations"
+})
+
+testRuntimeOnly project(':solr:modules:sql')
Review Comment:
The SQL handler is exercised by the JDBCStream I believe.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16443) Upgrade Jackson bom to 2.13.4.20221013
[
https://issues.apache.org/jira/browse/SOLR-16443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622428#comment-17622428
]
Kevin Risden commented on SOLR-16443:
-
Running into :
{code:java}
> Task :solr:core:compileJava
/Users/risdenk/.gradle/caches/modules-2/files-2.1/com.fasterxml.woodstox/woodstox-core/6.3.1/bf29b07ca4dd81ef3c0bc18c8bd5617510a81c5d/woodstox-core-6.3.1.jar(/com/ctc/wstx/stax/WstxInputFactory.class):
warning: Cannot find annotation method 'value()' in type 'ServiceProvider':
class file for aQute.bnd.annotation.spi.ServiceProvider not found
/Users/risdenk/.gradle/caches/modules-2/files-2.1/com.fasterxml.woodstox/woodstox-core/6.3.1/bf29b07ca4dd81ef3c0bc18c8bd5617510a81c5d/woodstox-core-6.3.1.jar(/com/ctc/wstx/stax/WstxInputFactory.class):
warning: Cannot find annotation method 'resolution()' in type 'ServiceProvider'
warning: unknown enum constant Resolution.OPTIONAL
reason: class file for aQute.bnd.annotation.Resolution not found
error: warnings found and -Werror specified
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error
3 warnings
> Task :solr:core:compileJava FAILED
{code}
> Upgrade Jackson bom to 2.13.4.20221013
> --
>
> Key: SOLR-16443
> URL: https://issues.apache.org/jira/browse/SOLR-16443
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.11.2, 9.1
>Reporter: Nicolò Mendola
>Assignee: Kevin Risden
>Priority: Minor
>
> Due to actual jackson-databind cve listing CVE-2022-42004 and CVE-2022-42003
> the Libary should be updated.
> [https://nvd.nist.gov/vuln/detail/CVE-2022-42004]
> https://nvd.nist.gov/vuln/detail/CVE-2022-42003
>
> Perhaps for version 9.1.0 as well as 8.11.2?
> Best Regards
> h4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] epugh opened a new pull request, #1105: SOLR-13880: Add test that creates/reloads/deletes collections
epugh opened a new pull request, #1105: URL: https://github.com/apache/solr/pull/1105 https://issues.apache.org/jira/browse/SOLR-13880 # Description Migrate test from https://github.com/apache/lucene-solr/pull/986 to current repo. # Solution Additional testing. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16248) equals() & hashCode() impl of DocCollection does not consider PRS
[ https://issues.apache.org/jira/browse/SOLR-16248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-16248: Status: Patch Available (was: Open) > equals() & hashCode() impl of DocCollection does not consider PRS > - > > Key: SOLR-16248 > URL: https://issues.apache.org/jira/browse/SOLR-16248 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16248) equals() & hashCode() impl of DocCollection does not consider PRS
[ https://issues.apache.org/jira/browse/SOLR-16248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622427#comment-17622427 ] Kevin Risden commented on SOLR-16248: - [~noble.paul] looks like there are commits for this. Can this be resolved? > equals() & hashCode() impl of DocCollection does not consider PRS > - > > Key: SOLR-16248 > URL: https://issues.apache.org/jira/browse/SOLR-16248 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16259) installer not properly defining the PID directory -- newline missing at the end of bin/solr.in.sh
[ https://issues.apache.org/jira/browse/SOLR-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-16259: Status: Patch Available (was: Open) > installer not properly defining the PID directory -- newline missing at the > end of bin/solr.in.sh > - > > Key: SOLR-16259 > URL: https://issues.apache.org/jira/browse/SOLR-16259 > Project: Solr > Issue Type: Task > Components: scripts and tools >Affects Versions: 9.0 >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Minor > Labels: newdev > > The file bin/solr.in.sh is missing a newline at the end of the file. When > the service installer script runs, the first line it adds is SOLR_PID_DIR, > which ends up not working because of that missing newline. > The installer script should add a newline before the lines it adds. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16259) installer not properly defining the PID directory -- newline missing at the end of bin/solr.in.sh
[ https://issues.apache.org/jira/browse/SOLR-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622425#comment-17622425 ] Kevin Risden commented on SOLR-16259: - [~elyograg] it looks like this this can be resolved? > installer not properly defining the PID directory -- newline missing at the > end of bin/solr.in.sh > - > > Key: SOLR-16259 > URL: https://issues.apache.org/jira/browse/SOLR-16259 > Project: Solr > Issue Type: Task > Components: scripts and tools >Affects Versions: 9.0 >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Minor > Labels: newdev > > The file bin/solr.in.sh is missing a newline at the end of the file. When > the service installer script runs, the first line it adds is SOLR_PID_DIR, > which ends up not working because of that missing newline. > The installer script should add a newline before the lines it adds. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16262) Fix Robots headers for old ref guide pages
[ https://issues.apache.org/jira/browse/SOLR-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622424#comment-17622424 ] Kevin Risden commented on SOLR-16262: - [~houston] did an INFRA ticket get created for this? I don't see it linked. > Fix Robots headers for old ref guide pages > -- > > Key: SOLR-16262 > URL: https://issues.apache.org/jira/browse/SOLR-16262 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > We have a htaccess rules generated to make sure that old versions of ref > guide pages are not indexed by search engines, that way users will get the > latest version of the documentation when they search. The syntax is wrong > however and it does work, but only small changes are needed luckily! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-13880) Collection creation fails with coreNodeName core_nodeX does not exist in shard
[
https://issues.apache.org/jira/browse/SOLR-13880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh reassigned SOLR-13880:
Assignee: Eric Pugh
> Collection creation fails with coreNodeName core_nodeX does not exist in shard
> --
>
> Key: SOLR-13880
> URL: https://issues.apache.org/jira/browse/SOLR-13880
> Project: Solr
> Issue Type: Bug
> Components: Tests
>Affects Versions: 9.0
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Eric Pugh
>Priority: Minor
> Attachments: TestPullReplica-45-2.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I've seen this when running tests locally. When issuing a collection
> creation, the call fails with:
> {noformat}
> [junit4] 2> 94288 ERROR (qtp149989-237) [n:127.0.0.1:63117_solr
> c:pull_replica_test_create_delete s:shard1 r:core_node9
> x:pull_replica_test_create_delete_shard1_replica_p6 ]
> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Error
> CREATEing SolrCore 'pull_replica_test_create_delete_shard1_replica_p6':
> Unable to create core [pull_replica_test_create_delete_shard1_replica_p6]
> Caused by: coreNodeName core_node9 does not exist in shard shard1, ignore the
> exception if the replica was deleted
>[junit4] 2> at
> org.apache.solr.core.CoreContainer.create(CoreContainer.java:1209)
>[junit4] 2> at
> org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:93)
>[junit4] 2> at
> org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:362)
>[junit4] 2> at
> org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:397)
>[junit4] 2> at
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:181)
>[junit4] 2> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:198)
>[junit4] 2> at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:843)
>[junit4] 2> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:809)
>[junit4] 2> at
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:562)
>[junit4] 2> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:424)
>[junit4] 2> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351)
>[junit4] 2> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
>[junit4] 2> at
> org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:167)
>[junit4] 2> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
>[junit4] 2> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>[junit4] 2> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
>[junit4] 2> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
>[junit4] 2> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>[junit4] 2> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:703)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>[junit4] 2> at
> org.eclipse.jetty.server.Server.handle(Server.java:505)
>[junit4] 2> at
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)
>[junit4] 2> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java
[jira] [Commented] (SOLR-16321) Solr - CSV import - can't read line
[
https://issues.apache.org/jira/browse/SOLR-16321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622422#comment-17622422
]
Kevin Risden commented on SOLR-16321:
-
Jira is not the correct replace for support requests. Those should go to the
mailing list, IRC channel, or slack channel.
https://solr.apache.org/community.html
A reindex is required because you changed the index analysis part of the
fieldType. The existing documents in the index before your schema change went
through a different tokenizer than the new documents, so the query could not
work on them until they were reindexed.
If you need further support on this, please use one of the methods mentioned.
> Solr - CSV import - can't read line
> ---
>
> Key: SOLR-16321
> URL: https://issues.apache.org/jira/browse/SOLR-16321
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Bartłomiej
>Priority: Major
>
> Hello,
>
> I have issue with import CSV. I would like to skip that flauty 116956. Any
> idea how to do this?
>
> Try to use skipLines but its not working for particular line number.
> [https://solr.apache.org/guide/8_1/uploading-data-with-index-handlers.html]
>
> {{shell: curl
> 'localhost:8983/solr/simple/update?commit=true&separator=%09&trim=true'
> --data-binary @/simple.csv -H 'Content-type:application/csv'}}
> {{Bug log:}}
> *13:51:51* "msg": [*13:51:51* "{",*13:51:51* "
> \"responseHeader\":{",*13:51:51* "\"rf\":3,",*13:51:51*
> "\"status\":400,",*13:51:51* "\"QTime\":6317},",*13:51:51*
>" \"error\":{",*13:51:51* "\"metadata\":[",*13:51:51*
> "
> \"error-class\",\"org.apache.solr.common.SolrException\",",*13:51:51*
> " \"root-error-class\",\"java.io.IOException\"],",*13:51:51* "
>\"msg\":\"CSVLoader: input=null, line=116956,can't read line:
> 116956\\n\\tvalues=\{NO LINES AVAILABLE}\",",*13:51:51* "
> \"code\":400}}"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-16321) Solr - CSV import - can't read line
[
https://issues.apache.org/jira/browse/SOLR-16321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden reassigned SOLR-16321:
---
Assignee: Kevin Risden
> Solr - CSV import - can't read line
> ---
>
> Key: SOLR-16321
> URL: https://issues.apache.org/jira/browse/SOLR-16321
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Bartłomiej
>Assignee: Kevin Risden
>Priority: Major
>
> Hello,
>
> I have issue with import CSV. I would like to skip that flauty 116956. Any
> idea how to do this?
>
> Try to use skipLines but its not working for particular line number.
> [https://solr.apache.org/guide/8_1/uploading-data-with-index-handlers.html]
>
> {{shell: curl
> 'localhost:8983/solr/simple/update?commit=true&separator=%09&trim=true'
> --data-binary @/simple.csv -H 'Content-type:application/csv'}}
> {{Bug log:}}
> *13:51:51* "msg": [*13:51:51* "{",*13:51:51* "
> \"responseHeader\":{",*13:51:51* "\"rf\":3,",*13:51:51*
> "\"status\":400,",*13:51:51* "\"QTime\":6317},",*13:51:51*
>" \"error\":{",*13:51:51* "\"metadata\":[",*13:51:51*
> "
> \"error-class\",\"org.apache.solr.common.SolrException\",",*13:51:51*
> " \"root-error-class\",\"java.io.IOException\"],",*13:51:51* "
>\"msg\":\"CSVLoader: input=null, line=116956,can't read line:
> 116956\\n\\tvalues=\{NO LINES AVAILABLE}\",",*13:51:51* "
> \"code\":400}}"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-16321) Solr - CSV import - can't read line
[
https://issues.apache.org/jira/browse/SOLR-16321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden resolved SOLR-16321.
-
Resolution: Invalid
> Solr - CSV import - can't read line
> ---
>
> Key: SOLR-16321
> URL: https://issues.apache.org/jira/browse/SOLR-16321
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Bartłomiej
>Priority: Major
>
> Hello,
>
> I have issue with import CSV. I would like to skip that flauty 116956. Any
> idea how to do this?
>
> Try to use skipLines but its not working for particular line number.
> [https://solr.apache.org/guide/8_1/uploading-data-with-index-handlers.html]
>
> {{shell: curl
> 'localhost:8983/solr/simple/update?commit=true&separator=%09&trim=true'
> --data-binary @/simple.csv -H 'Content-type:application/csv'}}
> {{Bug log:}}
> *13:51:51* "msg": [*13:51:51* "{",*13:51:51* "
> \"responseHeader\":{",*13:51:51* "\"rf\":3,",*13:51:51*
> "\"status\":400,",*13:51:51* "\"QTime\":6317},",*13:51:51*
>" \"error\":{",*13:51:51* "\"metadata\":[",*13:51:51*
> "
> \"error-class\",\"org.apache.solr.common.SolrException\",",*13:51:51*
> " \"root-error-class\",\"java.io.IOException\"],",*13:51:51* "
>\"msg\":\"CSVLoader: input=null, line=116956,can't read line:
> 116956\\n\\tvalues=\{NO LINES AVAILABLE}\",",*13:51:51* "
> \"code\":400}}"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-16330) import csv file scientific notation issue
[ https://issues.apache.org/jira/browse/SOLR-16330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden resolved SOLR-16330. - Resolution: Invalid Not enough detail to go on here. Jira is not the correct replace for support requests. Those should go to the mailing list, IRC channel, or slack channel. https://solr.apache.org/community.html A reindex is required because you changed the index analysis part of the fieldType. The existing documents in the index before your schema change went through a different tokenizer than the new documents, so the query could not work on them until they were reindexed. If you need further support on this, please use one of the methods mentioned. > import csv file scientific notation issue > - > > Key: SOLR-16330 > URL: https://issues.apache.org/jira/browse/SOLR-16330 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Environment: Windows 10 >Reporter: Sridhar >Priority: Major > > Problem encountering is when the csv file is imported using post.jar, it is > truncating some of the numbers into scientific notation even though they are > in a text field. > java -Dc=mycsvData -Dtype=application/csv -jar post.jar "F:\_DATA\Vism > West.csv" -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-16330) import csv file scientific notation issue
[ https://issues.apache.org/jira/browse/SOLR-16330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden reassigned SOLR-16330: --- Assignee: Kevin Risden > import csv file scientific notation issue > - > > Key: SOLR-16330 > URL: https://issues.apache.org/jira/browse/SOLR-16330 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Environment: Windows 10 >Reporter: Sridhar >Assignee: Kevin Risden >Priority: Major > > Problem encountering is when the csv file is imported using post.jar, it is > truncating some of the numbers into scientific notation even though they are > in a text field. > java -Dc=mycsvData -Dtype=application/csv -jar post.jar "F:\_DATA\Vism > West.csv" -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16342) not working
[
https://issues.apache.org/jira/browse/SOLR-16342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622417#comment-17622417
]
Kevin Risden commented on SOLR-16342:
-
[~zaccheob] thanks for the follow up about JsonLayout vs JsonTemplateLayout.
> not working
> --
>
> Key: SOLR-16342
> URL: https://issues.apache.org/jira/browse/SOLR-16342
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Docker
>Affects Versions: 8.11.2
>Reporter: Zaccheo Bagnati
>Priority: Minor
>
> We customized a solr 8.1.2 docker image by adding a custom log4j2
> configuration in order to log in json format.
> The custom configuration is simply replacing the with
> in the main log file:
> {code:java}
> name="MainLogFile"
> fileName="${sys:solr.log.dir}/solr.log"
> filePattern="${sys:solr.log.dir}/solr.log.%i" >
>
>
>
>
>
>
> {code}
> We then set the LOG4J_PROPS variable point to the custom log4j configuration.
> It is not working due to this error:
> {code:java}
> ERROR Could not create plugin of type class
> org.apache.logging.log4j.core.layout.JsonLayout for element JsonLayout:
> java.lang.NoClassDefFoundError:
> com/fasterxml/jackson/databind/ser/FilterProvider
> java.lang.NoClassDefFoundError:
> com/fasterxml/jackson/databind/ser/FilterProvider
> at
> org.apache.logging.log4j.core.layout.JsonLayout.(JsonLayout.java:159)
> at
> org.apache.logging.log4j.core.layout.JsonLayout.(JsonLayout.java:71)
> at
> org.apache.logging.log4j.core.layout.JsonLayout$Builder.build(JsonLayout.java:103)
> at
> org.apache.logging.log4j.core.layout.JsonLayout$Builder.build(JsonLayout.java:79)
> at
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:1120)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:1045)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:1037)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:1037)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:651)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:247)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:293)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:626)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:196)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:137)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:55)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:47)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:33)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
> at org.eclipse.jetty.util.log.Slf4jLog.(Slf4jLog.java:36)
> at org.eclipse.jetty.util.log.Slf4jLog.(Slf4jLog.java:30)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> at org.eclipse.jetty.util.log.Log.initialized(Log.java:158)
> at org.eclipse.jetty.util.log.Log.getLogger(Log.java:278)
> at org.eclipse.jetty.util.log.Log.getLogger(Log.java:267)
> at
> org.eclipse.jetty.xml.XmlConfiguration.(XmlConfiguration.java:88)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
[jira] [Resolved] (SOLR-16342) not working
[
https://issues.apache.org/jira/browse/SOLR-16342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden resolved SOLR-16342.
-
Resolution: Won't Fix
> not working
> --
>
> Key: SOLR-16342
> URL: https://issues.apache.org/jira/browse/SOLR-16342
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Docker
>Affects Versions: 8.11.2
>Reporter: Zaccheo Bagnati
>Priority: Minor
>
> We customized a solr 8.1.2 docker image by adding a custom log4j2
> configuration in order to log in json format.
> The custom configuration is simply replacing the with
> in the main log file:
> {code:java}
> name="MainLogFile"
> fileName="${sys:solr.log.dir}/solr.log"
> filePattern="${sys:solr.log.dir}/solr.log.%i" >
>
>
>
>
>
>
> {code}
> We then set the LOG4J_PROPS variable point to the custom log4j configuration.
> It is not working due to this error:
> {code:java}
> ERROR Could not create plugin of type class
> org.apache.logging.log4j.core.layout.JsonLayout for element JsonLayout:
> java.lang.NoClassDefFoundError:
> com/fasterxml/jackson/databind/ser/FilterProvider
> java.lang.NoClassDefFoundError:
> com/fasterxml/jackson/databind/ser/FilterProvider
> at
> org.apache.logging.log4j.core.layout.JsonLayout.(JsonLayout.java:159)
> at
> org.apache.logging.log4j.core.layout.JsonLayout.(JsonLayout.java:71)
> at
> org.apache.logging.log4j.core.layout.JsonLayout$Builder.build(JsonLayout.java:103)
> at
> org.apache.logging.log4j.core.layout.JsonLayout$Builder.build(JsonLayout.java:79)
> at
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:1120)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:1045)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:1037)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:1037)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:651)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:247)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:293)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:626)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:196)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:137)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:55)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:47)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:33)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
> at org.eclipse.jetty.util.log.Slf4jLog.(Slf4jLog.java:36)
> at org.eclipse.jetty.util.log.Slf4jLog.(Slf4jLog.java:30)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> at org.eclipse.jetty.util.log.Log.initialized(Log.java:158)
> at org.eclipse.jetty.util.log.Log.getLogger(Log.java:278)
> at org.eclipse.jetty.util.log.Log.getLogger(Log.java:267)
> at
> org.eclipse.jetty.xml.XmlConfiguration.(XmlConfiguration.java:88)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorIm
[GitHub] [solr] risdenk commented on a diff in pull request #1099: SOLR-15733: Migrate streaming
risdenk commented on code in PR #1099:
URL: https://github.com/apache/solr/pull/1099#discussion_r1002091268
##
solr/solrj-streaming/build.gradle:
##
@@ -0,0 +1,52 @@
+/*
+ * 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.
+ */
+
+apply plugin: 'java-library'
+
+description = 'Solrj-Streaming - SolrJ requiring Streaming Expressions'
+
+dependencies {
+
+
+implementation project(':solr:solrj')
+
+// declare dependencies we use even though already declared by solrj-core
+implementation 'org.slf4j:slf4j-api'
+implementation 'org.apache.httpcomponents:httpclient'
+implementation 'org.apache.httpcomponents:httpcore'
+implementation 'org.apache.commons:commons-math3'
+
+testImplementation project(':solr:test-framework')
+testImplementation project(':solr:core')
+
+testImplementation 'junit:junit'
+testImplementation 'commons-io:commons-io'
+testImplementation 'com.google.guava:guava'
+testImplementation project(':solr:solrj-zookeeper')
+
+permitTestUsedUndeclared project(':solr:solrj-zookeeper') // duh!
+
+testImplementation('org.apache.zookeeper:zookeeper', {
+exclude group: "org.apache.yetus", module: "audience-annotations"
+})
+
+testRuntimeOnly project(':solr:modules:sql')
Review Comment:
Why is this needed? there are classes in solr/modules/sql that somehow are
needed in these tests?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-16350) http response is delayed when solr is running in slow/restricted network environment
[ https://issues.apache.org/jira/browse/SOLR-16350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden resolved SOLR-16350. - Resolution: Incomplete [~shubanker] have you tried doing what [~gus] said about using 127.0.0.1 or potentially not a DNS entry? It seems like you have DNS resolution being slow and that is causing issues. This is even hinted at in StackOverflow. There aren't any details in the ticket to say what hostname you even tried to hit. > http response is delayed when solr is running in slow/restricted network > environment > > > Key: SOLR-16350 > URL: https://issues.apache.org/jira/browse/SOLR-16350 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 9.0 > Environment: !image-2022-08-23-09-56-45-250.png|width=327,height=170! > restrict/delay internet and DNS resolution time. >Reporter: Shubanker >Priority: Major > Attachments: image-2022-08-23-09-56-45-250.png, > image-2022-08-23-09-59-25-775.png, image-2022-08-23-10-01-40-456.png, > image-2022-08-23-10-03-45-870.png > > > While trying to setup SOLR 9 I noticed the response takes longer to complete > if the internet is slow/restricted. > I tried replicating in local by delaying DNS response and the request started > taking over 4s while the query itself (QTime) is faster. > !image-2022-08-23-10-03-45-870.png|width=429,height=150! > !image-2022-08-23-09-59-25-775.png|width=301,height=188! > even the static files of Admin UI take too long to load. > related StackOverflow > [question|https://stackoverflow.com/questions/73444575/solr-9-http-response-time-is-very-slow-while-query-itself-is-fast]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] joel-bernstein commented on pull request #1099: SOLR-15733: Migrate streaming
joel-bernstein commented on PR #1099: URL: https://github.com/apache/solr/pull/1099#issuecomment-1287318530 solrj-streaming test are passing now. Checking the entire test suite, there will be failures in places that expect to find Streaming Expressions in solrj. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-16358) Can't create SOLR collection using V2 API
[
https://issues.apache.org/jira/browse/SOLR-16358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden resolved SOLR-16358.
-
Resolution: Invalid
Jira is not the correct replace for support requests. Those should go to the
mailing list, IRC channel, or slack channel.
https://solr.apache.org/community.html
> Can't create SOLR collection using V2 API
> -
>
> Key: SOLR-16358
> URL: https://issues.apache.org/jira/browse/SOLR-16358
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: cli
>Affects Versions: 9.0
> Environment: - operating system: RHEL
> - java version: 11.0
>Reporter: sagnik ray choudhury
>Assignee: Eric Pugh
>Priority: Major
> Labels: solrconfig.xml
> Attachments: screenshot-1.png
>
>
> {code:bash}
> curl --netrc-file ~/.netrc -X POST http://localhost:8983/api/cores -H
> 'Content-Type: application/json' -d '
> {
> "create": {
> "name": "test_notes",
> "numShards": 1,
> "replicationFactor": 1}
> }
> '
> {code}
> Produces this error:
> {code:bash}
> {
> "responseHeader":{
> "status":400,
> "QTime":3},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
>
> "root-error-class","org.apache.solr.core.SolrResourceNotFoundException"],
> "msg":"Error CREATEing SolrCore 'test_notes': Unable to create core
> [test_notes] Caused by: Can't find resource 'solrconfig.xml' in classpath or
> '/app/solr/server/solr/test_notes'",
> "code":400}}
> {code}
> I see the same error when I use `config:solrconfig.xml` in the curl call.
> This is the content of my `solr_home/server/solr` folder.
> {code:bash}
> ❯ ls ~/solr/server/solr/configsets/
> _default sample_techproducts_configs
> {code}
> This is the java code that's running solr:
> {code:bash}
> /app/jdk-11.0.1/bin/java -server -Xms512m -Xmx512m -XX:+UseG1GC
> -XX:+PerfDisableSharedMem -XX:+ParallelRefProcEnabled
> -XX:MaxGCPauseMillis=250 -XX:+UseLargePages -XX:+AlwaysPreTouch
> -XX:+ExplicitGCInvokesConcurrent
> -Xlog:gc*:file=/home/linuxuser/solr/server/logs/solr_gc.log:time,uptime:filecount=9,filesize=20M
> -Dsolr.jetty.inetaccess.includes= -Dsolr.jetty.inetaccess.excludes=
> -Dsolr.log.dir=/home/linuxuser/solr/server/logs -Djetty.port=13745
> -DSTOP.PORT=12745 -DSTOP.KEY=solrrocks -Dhost=localhost -Duser.timezone=UTC
> -XX:-OmitStackTraceInFastThrow
> -XX:OnOutOfMemoryError=/home/linuxuser/solr/bin/oom_solr.sh 13745
> /home/linuxuser/solr/server/logs -Djetty.home=/home/linuxuser/solr/server
> -Dsolr.solr.home=/app/solr/server/solr/ -Dsolr.data.home=
> -Dsolr.install.dir=/home/linuxuser/solr
> -Dsolr.default.confdir=/home/linuxuser/solr/server/solr/configsets/_default/conf
> -Xss256k
> -Dsolr.httpclient.builder.factory=org.apache.solr.client.solrj.impl.PreemptiveBasicAuthClientBuilderFactory
> -Dbasicauth=linuxuser:SolrForCedarU54 -Djava.security.manager
> -Djava.security.policy=/home/linuxuser/solr/server/etc/security.policy
> -Djava.security.properties=/home/linuxuser/solr/server/etc/security.properties
> -Dsolr.internal.network.permission=* -DdisableAdminUI=false
> -Dsolr.log.muteconsole -jar start.jar --module=http --module=requestlog
> --module=gzip
> {code}
> My questions are:
> a. What am I doing wrong?
> b. Why is Solr trying to find a solrconfig.xml in a directory that it has not
> yet created (`test_notes`)?
> c. What is this `classpath` Solr is referring to?
> Also, I have symlinked `/app/solr` to `~/solr`. I presume that won't cause a
> problem?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-13626) broken links in solr/solr-ref-guide/src/implicit-requesthandlers.adoc
[ https://issues.apache.org/jira/browse/SOLR-13626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622412#comment-17622412 ] Eric Pugh commented on SOLR-13626: -- I've updated the patch to the latest Github repo. [~tonyc] how would you like to be rererenced? ARe there any changes you'd like to see? > broken links in solr/solr-ref-guide/src/implicit-requesthandlers.adoc > - > > Key: SOLR-13626 > URL: https://issues.apache.org/jira/browse/SOLR-13626 > Project: Solr > Issue Type: Bug > Components: documentation >Affects Versions: 8.1.1 >Reporter: Tony Cook >Assignee: Eric Pugh >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > At line 109 in the source, this page links to > [https://wiki.apache.org/solr/SystemInformationRequestHandlers#SystemInfoHandler] > which no longer exists, if it ever did, I don't see such a page under > [https://cwiki.apache.org/confluence/display/SOLR/Old+Wiki] > It also links to: > line 52: [http://wiki.apache.org/solr/LukeRequestHandler] > line 148: [https://wiki.apache.org/solr/AnalysisRequestHandler] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] epugh commented on pull request #1104: SOLR-13626: document the SystemInfoHandler
epugh commented on PR #1104: URL: https://github.com/apache/solr/pull/1104#issuecomment-1287317048 @tonycoz, how would you like to be reference in the Changelog? -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16486) Pin OS version for base Docker image
[
https://issues.apache.org/jira/browse/SOLR-16486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622410#comment-17622410
]
ASF subversion and git services commented on SOLR-16486:
Commit f6986d1d75434a508b2063184c53461e12e7a7a5 in solr's branch
refs/heads/branch_9_1 from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=f6986d1d754 ]
SOLR-16486: Pin OS Variant for Docker image (#1102)
(cherry picked from commit ed4b3d6f45a5df5e63e25469d96f71f464b46ac5)
> Pin OS version for base Docker image
>
>
> Key: SOLR-16486
> URL: https://issues.apache.org/jira/browse/SOLR-16486
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Docker
>Affects Versions: 9.0
>Reporter: Houston Putman
>Priority: Blocker
> Fix For: 9.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently we have
> [eclipse-temurin:17-jre|https://hub.docker.com/_/eclipse-temurin] set as the
> default base image of our 9.0+ docker images.
> We have had [reports from
> users|https://github.com/apache/solr-docker/pull/13] that the latest OS
> variant of {{eclipse-temurin:17-jre}} does not work for all Docker versions
> (just 20.10.16+). The eclipse temurin project makes no promises that Java
> versions will keep the same OS variant throughout their lifecycles, so we
> should explicitly pin the OS variant in our image name to keep ourselves safe.
> Given that the latest variant (jammy - Ubuntu 22) only supports a 5-month-old
> version of Docker, we should probably pin to the previous OS variant (focal -
> Ubuntu 20) which has Support until April 2025.
> We can upgrade to Ubuntu 22 (Jammy Jellyfish) in a future 9.x minor release,
> which will not affect any of the previous released images.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-16486) Pin OS version for base Docker image
[
https://issues.apache.org/jira/browse/SOLR-16486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman resolved SOLR-16486.
---
Fix Version/s: main (10.0)
Assignee: Houston Putman
Resolution: Fixed
> Pin OS version for base Docker image
>
>
> Key: SOLR-16486
> URL: https://issues.apache.org/jira/browse/SOLR-16486
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Docker
>Affects Versions: 9.0
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Blocker
> Fix For: 9.1, main (10.0)
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently we have
> [eclipse-temurin:17-jre|https://hub.docker.com/_/eclipse-temurin] set as the
> default base image of our 9.0+ docker images.
> We have had [reports from
> users|https://github.com/apache/solr-docker/pull/13] that the latest OS
> variant of {{eclipse-temurin:17-jre}} does not work for all Docker versions
> (just 20.10.16+). The eclipse temurin project makes no promises that Java
> versions will keep the same OS variant throughout their lifecycles, so we
> should explicitly pin the OS variant in our image name to keep ourselves safe.
> Given that the latest variant (jammy - Ubuntu 22) only supports a 5-month-old
> version of Docker, we should probably pin to the previous OS variant (focal -
> Ubuntu 20) which has Support until April 2025.
> We can upgrade to Ubuntu 22 (Jammy Jellyfish) in a future 9.x minor release,
> which will not affect any of the previous released images.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] epugh opened a new pull request, #1104: SOLR-13626: document the SystemInfoHandler
epugh opened a new pull request, #1104: URL: https://github.com/apache/solr/pull/1104 https://issues.apache.org/jira/browse/SOLR-13626 # Description This is work that was done in the old shared lucene-solr repo https://github.com/apache/lucene-solr/pull/802 by @tonycoz. Add missing documentation for /admin/info/system which implicit-requesthandlers currently links to a 404 # Solution Provide some basic documentation. # Tests built ref guide -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16363) addDoc() in DirectUpdateHandler2 needs additional Exception Handling
[
https://issues.apache.org/jira/browse/SOLR-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-16363:
Issue Type: Bug (was: Improvement)
> addDoc() in DirectUpdateHandler2 needs additional Exception Handling
>
>
> Key: SOLR-16363
> URL: https://issues.apache.org/jira/browse/SOLR-16363
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Affects Versions: 8.11.2, main (10.0)
>Reporter: Aman Verma
>Priority: Minor
>
> In certain situation, to handle IllegalArgumentException while adding doc to
> solr is linked below
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L249|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L250]
> EDIT: Adding Code piece for current main branch:
> [https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L314]
>
> This can be problematic if IllegalArgumentException (of the following format)
> is thrown during processing of docs (in my case it was via Filters to
> URL-Decode a string)
>
> {code:java}
> java.lang.IllegalArgumentException: URLDecoder: Illegal hex characters in
> escape (%) pattern - Error at index 0 in: "sy"{code}
> The _iae.getMessage()_ in this case contains "{*}%){*}" which conflicts with
> String.format which would further throw
> {code:java}
> java.util.UnknownFormatConversionException: Conversion = ')'
> at java.util.Formatter.checkText(Unknown Source) ~[?:?]
> at java.util.Formatter.parse(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.lang.String.format(Unknown Source) ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:249){code}
> This particular exception is not caught and as a result the BAD_REQUEST was
> never returned to the client along with failure point in the chain.
> The ticket is a proposal to make this more robust i.e., in this particular
> situation either getMessage() could replaceAll "%" or perhaps another try?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-13626) broken links in solr/solr-ref-guide/src/implicit-requesthandlers.adoc
[ https://issues.apache.org/jira/browse/SOLR-13626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh reassigned SOLR-13626: Assignee: Eric Pugh > broken links in solr/solr-ref-guide/src/implicit-requesthandlers.adoc > - > > Key: SOLR-13626 > URL: https://issues.apache.org/jira/browse/SOLR-13626 > Project: Solr > Issue Type: Bug > Components: documentation >Affects Versions: 8.1.1 >Reporter: Tony Cook >Assignee: Eric Pugh >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > At line 109 in the source, this page links to > [https://wiki.apache.org/solr/SystemInformationRequestHandlers#SystemInfoHandler] > which no longer exists, if it ever did, I don't see such a page under > [https://cwiki.apache.org/confluence/display/SOLR/Old+Wiki] > It also links to: > line 52: [http://wiki.apache.org/solr/LukeRequestHandler] > line 148: [https://wiki.apache.org/solr/AnalysisRequestHandler] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] sonatype-lift[bot] commented on pull request #1103: SOLR-16487: Pull Replica Efficiency Improvements
sonatype-lift[bot] commented on PR #1103: URL: https://github.com/apache/solr/pull/1103#issuecomment-1287314111 :warning: **313 God Classes** were detected by Lift in this project. [Visit the Lift web console](https://lift.sonatype.com/results/github.com/apache/solr/01GFXTMH7FHEGWCXP6WXF2MY64?tab=technical-debt&utm_source=github.com&utm_campaign=lift-comment&utm_content=apache\%20solr) for more details. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-16359) Reindex without delete old index data
[
https://issues.apache.org/jira/browse/SOLR-16359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden resolved SOLR-16359.
-
Resolution: Invalid
> Reindex without delete old index data
> -
>
> Key: SOLR-16359
> URL: https://issues.apache.org/jira/browse/SOLR-16359
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Sridhar
>Priority: Major
>
> In my existing Solr core index. I am trying to get relevant search results
> working with or without the words, hyphens.
> Here is the query example for `like` clause: `q=Address : ( *{*}5-6*{*} {*})
> AND SID : ( *{*}{*}584*{*} *) AND City : ( ** *brentwood ** )`
> In the configuration file `/conf/managed-schema.xml` I changed the tokenizer
> to `solr.KeywordTokenizerFactory` from the default tokenizer
> `solr.StandardTokenizerFactory` on general text filed `text_general`.
> positionIncrementGap="100" multiValued="true">
>
>
> words="stopwords.txt" />
>
>
>
>
> words="stopwords.txt" />
> synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
>
>
>
> The above configuration is working fine for new `core` index data. But it is
> not working on the existing `core` index. I had to delete the old index data
> and reindex from the scratch. *Is there any way to work reindex the data
> without delete the old data?*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16368) Refactoring: Use SolrClient type instead of overly specific subclasses
[ https://issues.apache.org/jira/browse/SOLR-16368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622408#comment-17622408 ] Kevin Risden commented on SOLR-16368: - [~epugh] is there more to do here? I see the PR was merged. > Refactoring: Use SolrClient type instead of overly specific subclasses > -- > > Key: SOLR-16368 > URL: https://issues.apache.org/jira/browse/SOLR-16368 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: David Smiley >Assignee: Eric Pugh >Priority: Minor > Fix For: main (10.0), 9.2 > > Time Spent: 5h 10m > Remaining Estimate: 0h > > There are many references to a specific SolrClient subclass that could simply > refer to SolrClient generally, or perhaps CloudSolrClient. This impedes > switching/migrating to different SolrClient implementations. A similar > example: we know it's a bad practice to declare a List as ArrayList even when > it is one; the idea here with SolrClient is the same. > And furthermore, often times "var solrClient = ..." (or even "var solr = > ...") is totally adequate in the Solr codebase within a method because the > variable name adequately communicates the type. These sorts of changes > should happen first, and then weaken type references in APIs. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16368) Refactoring: Use SolrClient type instead of overly specific subclasses
[ https://issues.apache.org/jira/browse/SOLR-16368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-16368: Fix Version/s: main (10.0) 9.2 > Refactoring: Use SolrClient type instead of overly specific subclasses > -- > > Key: SOLR-16368 > URL: https://issues.apache.org/jira/browse/SOLR-16368 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: David Smiley >Assignee: Eric Pugh >Priority: Minor > Fix For: main (10.0), 9.2 > > Time Spent: 5h 10m > Remaining Estimate: 0h > > There are many references to a specific SolrClient subclass that could simply > refer to SolrClient generally, or perhaps CloudSolrClient. This impedes > switching/migrating to different SolrClient implementations. A similar > example: we know it's a bad practice to declare a List as ArrayList even when > it is one; the idea here with SolrClient is the same. > And furthermore, often times "var solrClient = ..." (or even "var solr = > ...") is totally adequate in the Solr codebase within a method because the > variable name adequately communicates the type. These sorts of changes > should happen first, and then weaken type references in APIs. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16368) Refactoring: Use SolrClient type instead of overly specific subclasses
[ https://issues.apache.org/jira/browse/SOLR-16368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-16368: Status: Patch Available (was: Open) > Refactoring: Use SolrClient type instead of overly specific subclasses > -- > > Key: SOLR-16368 > URL: https://issues.apache.org/jira/browse/SOLR-16368 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: David Smiley >Assignee: Eric Pugh >Priority: Minor > Fix For: main (10.0), 9.2 > > Time Spent: 5h 10m > Remaining Estimate: 0h > > There are many references to a specific SolrClient subclass that could simply > refer to SolrClient generally, or perhaps CloudSolrClient. This impedes > switching/migrating to different SolrClient implementations. A similar > example: we know it's a bad practice to declare a List as ArrayList even when > it is one; the idea here with SolrClient is the same. > And furthermore, often times "var solrClient = ..." (or even "var solr = > ...") is totally adequate in the Solr codebase within a method because the > variable name adequately communicates the type. These sorts of changes > should happen first, and then weaken type references in APIs. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #585: SOLR-15955: Update Jetty dependency to 10
risdenk commented on code in PR #585: URL: https://github.com/apache/solr/pull/585#discussion_r1002079847 ## solr/server/etc/jetty.xml: ## @@ -178,7 +178,7 @@ - + Review Comment: Fixed in 1c9ea3ad9ac98cc133163f3e36c643ca567009a6 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16412) Race condition could trigger error on concurrent SizeLimitedDistributedMap cleanup
[
https://issues.apache.org/jira/browse/SOLR-16412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-16412:
Status: Patch Available (was: Open)
> Race condition could trigger error on concurrent SizeLimitedDistributedMap
> cleanup
> --
>
> Key: SOLR-16412
> URL: https://issues.apache.org/jira/browse/SOLR-16412
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 8.8, main (10.0)
>Reporter: Patson Luk
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> h2. Description
> Exception below is observed while updating the `completedMap` field in
> `OverseerTaskProcessor` :
> {{o.a.s.c.OverseerTaskProcessor
> :org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for
> /overseer/collection-map-completed/mn-736f6c726d616e2d312d3138393038373039383731303932353331}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:118)}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:54)}}
> {{at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:2001)}}
> {{at
> org.apache.solr.common.cloud.SolrZkClient.lambda$delete$1(SolrZkClient.java:264)}}
> {{at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:71)}}
> {{at org.apache.solr.common.cloud.SolrZkClient.delete(SolrZkClient.java:263)}}
> {{at
> org.apache.solr.cloud.SizeLimitedDistributedMap.put(SizeLimitedDistributedMap.java:76)}}
> {{at
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:538)}}
> {{at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:218)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}
> h2. Cause
> Based on the stack trace, `SizeLimitedDistributedMap` had reached the limit
> and attempted to cleanup entries:
> [https://github.com/fullstorydev/lucene-solr/blob/75e89929eb360b513ee864aeb23a80c049747246/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L73-L80]
> However, when it performs the actual deletion, it failed with
> `NoNodeException`
> This is likely caused by race condition as multiple threads can enter the
> same code block and try to delete same list of children which the slower
> threads can delete on child node that no longer exists.
>
> Such condition can be reproduced by unit test case, which will be included in
> the PR
> h2. Solution
> Although we could enforce synchronization to prevent threads from purging the
> same set of child nodes, it might not be desirable to add extra blocking.
> Instead, it's probably safe to ignore the `KeeperException.NoNodeException`
> if such node is no longer there for the purge operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16486) Pin OS version for base Docker image
[
https://issues.apache.org/jira/browse/SOLR-16486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622406#comment-17622406
]
ASF subversion and git services commented on SOLR-16486:
Commit 3ceae7bf85c3aa292930619e0d1527ce174d22e5 in solr's branch
refs/heads/branch_9x from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=3ceae7bf85c ]
SOLR-16486: Pin OS Variant for Docker image (#1102)
(cherry picked from commit ed4b3d6f45a5df5e63e25469d96f71f464b46ac5)
> Pin OS version for base Docker image
>
>
> Key: SOLR-16486
> URL: https://issues.apache.org/jira/browse/SOLR-16486
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Docker
>Affects Versions: 9.0
>Reporter: Houston Putman
>Priority: Blocker
> Fix For: 9.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently we have
> [eclipse-temurin:17-jre|https://hub.docker.com/_/eclipse-temurin] set as the
> default base image of our 9.0+ docker images.
> We have had [reports from
> users|https://github.com/apache/solr-docker/pull/13] that the latest OS
> variant of {{eclipse-temurin:17-jre}} does not work for all Docker versions
> (just 20.10.16+). The eclipse temurin project makes no promises that Java
> versions will keep the same OS variant throughout their lifecycles, so we
> should explicitly pin the OS variant in our image name to keep ourselves safe.
> Given that the latest variant (jammy - Ubuntu 22) only supports a 5-month-old
> version of Docker, we should probably pin to the previous OS variant (focal -
> Ubuntu 20) which has Support until April 2025.
> We can upgrade to Ubuntu 22 (Jammy Jellyfish) in a future 9.x minor release,
> which will not affect any of the previous released images.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on pull request #1039: SOLR-16427: Evaluate and fix errorprone rules - part 2
risdenk commented on PR #1039: URL: https://github.com/apache/solr/pull/1039#issuecomment-1287303290 ``` solr git:(SOLR-16427-part-2) ./gradlew check -Pvalidation.errorprone=true ... BUILD SUCCESSFUL in 21m 31s 586 actionable tasks: 215 executed, 371 up-to-date ``` -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #585: SOLR-15955: Update Jetty dependency to 10
risdenk commented on code in PR #585: URL: https://github.com/apache/solr/pull/585#discussion_r1002074641 ## solr/server/etc/jetty.xml: ## @@ -178,7 +178,7 @@ - + Review Comment: Ugh @epugh found that this is broken - it needs to be `io.dropwizard.metrics.jetty10.InstrumentedHandler` ## versions.props: ## @@ -17,14 +17,13 @@ commons-cli:commons-cli=1.4 commons-codec:commons-codec=1.15 commons-collections:commons-collections=3.2.2 commons-io:commons-io=2.11.0 -io.dropwizard.metrics:*=4.1.5 +io.dropwizard.metrics:*=4.2.12 Review Comment: Needed for metrics-jetty10 ## versions.props: ## @@ -68,5 +68,7 @@ org.openjdk.jmh:*=1.32 org.quicktheories:quicktheories=0.26 org.semver4j:semver4j=2.1.1 org.slf4j:*=1.7.36 +org.springframework.boot:spring-boot*=2.5.14 +org.springframework:spring*=5.3.23 Review Comment: Needed for s3mock? -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16486) Pin OS version for base Docker image
[
https://issues.apache.org/jira/browse/SOLR-16486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622397#comment-17622397
]
ASF subversion and git services commented on SOLR-16486:
Commit ed4b3d6f45a5df5e63e25469d96f71f464b46ac5 in solr's branch
refs/heads/main from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=ed4b3d6f45a ]
SOLR-16486: Pin OS Variant for Docker image (#1102)
> Pin OS version for base Docker image
>
>
> Key: SOLR-16486
> URL: https://issues.apache.org/jira/browse/SOLR-16486
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Docker
>Affects Versions: 9.0
>Reporter: Houston Putman
>Priority: Blocker
> Fix For: 9.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently we have
> [eclipse-temurin:17-jre|https://hub.docker.com/_/eclipse-temurin] set as the
> default base image of our 9.0+ docker images.
> We have had [reports from
> users|https://github.com/apache/solr-docker/pull/13] that the latest OS
> variant of {{eclipse-temurin:17-jre}} does not work for all Docker versions
> (just 20.10.16+). The eclipse temurin project makes no promises that Java
> versions will keep the same OS variant throughout their lifecycles, so we
> should explicitly pin the OS variant in our image name to keep ourselves safe.
> Given that the latest variant (jammy - Ubuntu 22) only supports a 5-month-old
> version of Docker, we should probably pin to the previous OS variant (focal -
> Ubuntu 20) which has Support until April 2025.
> We can upgrade to Ubuntu 22 (Jammy Jellyfish) in a future 9.x minor release,
> which will not affect any of the previous released images.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] HoustonPutman merged pull request #1102: SOLR-16486: Pin OS Variant for Docker image
HoustonPutman merged PR #1102: URL: https://github.com/apache/solr/pull/1102 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16486) Pin OS version for base Docker image
[
https://issues.apache.org/jira/browse/SOLR-16486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-16486:
---
Priority: Blocker (was: Major)
> Pin OS version for base Docker image
>
>
> Key: SOLR-16486
> URL: https://issues.apache.org/jira/browse/SOLR-16486
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Docker
>Affects Versions: 9.0
>Reporter: Houston Putman
>Priority: Blocker
> Fix For: 9.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently we have
> [eclipse-temurin:17-jre|https://hub.docker.com/_/eclipse-temurin] set as the
> default base image of our 9.0+ docker images.
> We have had [reports from
> users|https://github.com/apache/solr-docker/pull/13] that the latest OS
> variant of {{eclipse-temurin:17-jre}} does not work for all Docker versions
> (just 20.10.16+). The eclipse temurin project makes no promises that Java
> versions will keep the same OS variant throughout their lifecycles, so we
> should explicitly pin the OS variant in our image name to keep ourselves safe.
> Given that the latest variant (jammy - Ubuntu 22) only supports a 5-month-old
> version of Docker, we should probably pin to the previous OS variant (focal -
> Ubuntu 20) which has Support until April 2025.
> We can upgrade to Ubuntu 22 (Jammy Jellyfish) in a future 9.x minor release,
> which will not affect any of the previous released images.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16486) Pin OS version for base Docker image
[
https://issues.apache.org/jira/browse/SOLR-16486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-16486:
---
Fix Version/s: 9.1
> Pin OS version for base Docker image
>
>
> Key: SOLR-16486
> URL: https://issues.apache.org/jira/browse/SOLR-16486
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Docker
>Affects Versions: 9.0
>Reporter: Houston Putman
>Priority: Major
> Fix For: 9.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently we have
> [eclipse-temurin:17-jre|https://hub.docker.com/_/eclipse-temurin] set as the
> default base image of our 9.0+ docker images.
> We have had [reports from
> users|https://github.com/apache/solr-docker/pull/13] that the latest OS
> variant of {{eclipse-temurin:17-jre}} does not work for all Docker versions
> (just 20.10.16+). The eclipse temurin project makes no promises that Java
> versions will keep the same OS variant throughout their lifecycles, so we
> should explicitly pin the OS variant in our image name to keep ourselves safe.
> Given that the latest variant (jammy - Ubuntu 22) only supports a 5-month-old
> version of Docker, we should probably pin to the previous OS variant (focal -
> Ubuntu 20) which has Support until April 2025.
> We can upgrade to Ubuntu 22 (Jammy Jellyfish) in a future 9.x minor release,
> which will not affect any of the previous released images.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr-operator] HoustonPutman commented on issue #483: Servicemonitor for prometheus exporter is referring to cluster port instead of metrics pod port
HoustonPutman commented on issue #483: URL: https://github.com/apache/solr-operator/issues/483#issuecomment-1287286797 Are you sure you don't have a podMonitor defined as well? Looks like there might be a bug in the prometheus operator? In the meantime you can use `targetPort` instead to set `8080`. [Here are the available options](https://github.com/prometheus-operator/prometheus-operator/blob/5cfb4da102374d5f0284f463e8f11482705a6651/pkg/apis/monitoring/v1/types.go#L1257) under `endpoints`. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on pull request #1039: SOLR-16427: Evaluate and fix errorprone rules - part 2
risdenk commented on PR #1039: URL: https://github.com/apache/solr/pull/1039#issuecomment-1287278907 I'm not 100% sure I got all the changes from my previous branch - I'm running all the tests now and will potentially force push again to fix any minor things I missed. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on pull request #1039: SOLR-16427: Evaluate and fix errorprone rules - part 2
risdenk commented on PR #1039: URL: https://github.com/apache/solr/pull/1039#issuecomment-1287277826 @dsmiley / @epugh I force pushed this branch to reapply these changes on top of https://github.com/apache/solr/pull/953 and break up each commit into one error-prone rule. Hopefully that makes it easier to review. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr-operator] sanjay3290 commented on issue #483: Servicemonitor for prometheus exporter is referring to cluster port instead of metrics pod port
sanjay3290 commented on issue #483: URL: https://github.com/apache/solr-operator/issues/483#issuecomment-1287275819 you are right, thats how its supposed to work. However the service endpoint in prometheus targets is referencing to http://podIP:90/metrics and due to that, the connection is getting refused. My other default service endpoints for prometheus are working as expected. Prometheus : Chart:prometheus-15.16.1 Version:2.39.1 Kubernetes: AWS EKS, Version:1.22 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
