Re: [PR] SOLR-17269: Do not publish synthetic solr core (of Coordinator node) to ZK [solr]
dsmiley commented on PR #2438: URL: https://github.com/apache/solr/pull/2438#issuecomment-2143261736 I noticed you tagged nobody for review; it's good to think of one two pertinent people. -- 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
Re: [PR] SOLR-17269: Do not publish synthetic solr core (of Coordinator node) to ZK [solr]
dsmiley commented on code in PR #2438:
URL: https://github.com/apache/solr/pull/2438#discussion_r1623133317
##
solr/core/src/java/org/apache/solr/core/ConfigSetService.java:
##
@@ -391,6 +402,21 @@ protected NamedList
loadConfigSetFlags(SolrResourceLoader loader) throws
*/
protected abstract SolrResourceLoader
createCoreResourceLoader(CoreDescriptor cd);
+ /**
+ * Create a SolrResourceLoader for a core with the provided configSetName.
+ *
+ * By default, this will just call {@link
+ * ConfigSetService#createConfigSetService(CoreContainer)}. Child
implementation might override
+ * this to make use of the configSetName directly
+ *
+ * @param cd the core's CoreDescriptor
+ * @param configSetName an optional config set name
+ * @return a SolrResourceLoader
+ */
+ protected SolrResourceLoader createCoreResourceLoader(CoreDescriptor cd,
String configSetName) {
Review Comment:
Since the configSetName is also on the CoreDescriptor, isn't this API
needless? Same elsewhere (loadConfigSet)
##
solr/core/src/java/org/apache/solr/servlet/CoordinatorHttpSolrCall.java:
##
@@ -314,6 +182,19 @@ public CloudDescriptor getCloudDescriptor() {
};
}
+ /**
+ * Overrides the MDC context as the core set was synthetic core, which does
not reflect the
+ * collection being operated on
+ */
+ private static void setMDCLoggingContext(String collectionName) {
Review Comment:
We use Google Java code standards, thus use "Mdc" capitalization. Plenty of
old code did a mis-mash of things, MDCLoggingContext being one.
--
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-15715) Dedicated query coordinator nodes in the solr cluster
[ https://issues.apache.org/jira/browse/SOLR-15715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851243#comment-17851243 ] David Smiley commented on SOLR-15715: - Gus, without this feature, how does one get a core/replica onto a coordinator node that has no data? Normally a core is part of a shard and that shard has data like all the others. This only partially addresses your questions; I don't have all the answers. I think I would have rather seen a special shard; maybe having no range and/or having a special state. But I think an aspect of the solution here is to have an approach that scales to many collections, thus don't want many empty cores. So instead I could imagine a collection that is able to query any other collection. I noticed an interesting new issue & PR on this feature recently SOLR-17118. > Dedicated query coordinator nodes in the solr cluster > - > > Key: SOLR-15715 > URL: https://issues.apache.org/jira/browse/SOLR-15715 > Project: Solr > Issue Type: New Feature > Components: SearchComponents - other >Affects Versions: 8.10.1 >Reporter: Hitesh Khamesra >Assignee: Noble Paul >Priority: Major > Fix For: 9.1 > > Attachments: coordinator-poc.jpg, coordinator-poc.pdf, > coordinator-vs-data-nodes.jpg, regular-node.jpg, regular-node.pdf > > Time Spent: 3h 40m > Remaining Estimate: 0h > > We have a large collection with 1000s of shards in the solr cluster. We have > observed that distributed solr query takes many resources(thread, memory, > etc.) on the solr data node(node which contains indexes). Thus we need > dedicated query nodes to execute distributed queries on large solr > collection. That would reduce the memory/cpu pressure from solr data nodes. > Elastis search has similar functionality > [here|https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html#coordinating-node] > > [~noble.paul] [~ichattopadhyaya] -- 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
Re: [PR] SOLR-17301: Support all types of requests in rate limiting [solr]
dsmiley commented on code in PR #2469:
URL: https://github.com/apache/solr/pull/2469#discussion_r1623101435
##
solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java:
##
@@ -58,7 +59,21 @@ public enum SolrRequestType {
SECURITY,
ADMIN,
STREAMING,
-UNSPECIFIED
+UNSPECIFIED;
+
+public static SolrRequestType parse(String s) {
+ if (s == null) return QUERY;
+
+ s = s.toUpperCase(Locale.ROOT);
+ if (QUERY.toString().equals(s)) return QUERY;
+ if (UPDATE.toString().equals(s)) return UPDATE;
+ if (ADMIN.toString().equals(s)) return ADMIN;
+ if (STREAMING.toString().equals(s)) return STREAMING;
+ if (UNSPECIFIED.toString().equals(s)) return UNSPECIFIED;
Review Comment:
See `Enum.valueOf(...)`
--
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-17118) Solr deadlock during servlet container start
[
https://issues.apache.org/jira/browse/SOLR-17118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851239#comment-17851239
]
ASF subversion and git services commented on SOLR-17118:
Commit 1177796e32631c62d8f00e7df4341c92b75e1617 in solr's branch
refs/heads/main from David Smiley
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=1177796e326 ]
SOLR-17118: Simplify/fix CoreContainerProvider initialization (#2474)
Thereby fixing a rare occurrence of Solr hanging on startup.
CoreContainerProvider: Don't need any CountDownLatch (x2), the synchronized
WeakHashMap of "services", the ServiceHolder, the ContextInitializationKey. No
looping to wait for initialization.
JettySolrRunner: incorporate the CoreContainerProvider and various servlet
filters in a normal way -- add all this before starting, not after. Thus Jetty
will shut them down properly so we don't have to. Removed some needless
synchronized wait/notify and other needless stuff.
HealthCheckHandlerTest was shutting down CoreContainer improperly; this subset
of the test was removed.
> Solr deadlock during servlet container start
>
>
> Key: SOLR-17118
> URL: https://issues.apache.org/jira/browse/SOLR-17118
> Project: Solr
> Issue Type: Bug
> Components: Server
>Affects Versions: 9.2.1
>Reporter: Andreas Hubold
>Assignee: David Smiley
>Priority: Major
> Labels: deadlock, servlet-context
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> In rare cases, Solr can run into a deadlock when started. The servlet
> container startup thread gets blocked and there's no other thread that could
> unblock it:
> {noformat}
> "main" #1 prio=5 os_prio=0 cpu=5922.39ms elapsed=7490.27s
> tid=0x7f637402ae70 nid=0x47 waiting on condition [0x7f6379488000]
>java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@17.0.9/Native Method)
> - parking to wait for <0x81da8000> (a
> java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(java.base@17.0.9/Unknown
> Source)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@17.0.9/Unknown
> Source)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(java.base@17.0.9/Unknown
> Source)
> at java.util.concurrent.CountDownLatch.await(java.base@17.0.9/Unknown
> Source)
> at
> org.apache.solr.servlet.CoreContainerProvider$ContextInitializationKey.waitForReadyService(CoreContainerProvider.java:523)
> at
> org.apache.solr.servlet.CoreContainerProvider$ServiceHolder.getService(CoreContainerProvider.java:562)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:148)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:133)
> at
> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$2(ServletHandler.java:725)
> at
> org.eclipse.jetty.servlet.ServletHandler$$Lambda$315/0x7f62fc2674b8.accept(Unknown
> Source)
> at
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(java.base@17.0.9/Unknown
> Source)
> at
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(java.base@17.0.9/Unknown
> Source)
> at
> java.util.stream.ReferencePipeline$Head.forEach(java.base@17.0.9/Unknown
> Source)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:749)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:392)
>
> {noformat}
> ContextInitializationKey.waitForReadyService should have been unblocked by
> CoreContainerProvider#init, which is calling ServiceHolder#setService. This
> should work because CoreContainerProvider#init is always called before
> SolrDispatchFilter#init (ServletContextListeners are initialized before
> Filters).
> But there's a problem: CoreContainerProvider#init stores the
> ContextInitializationKey and the mapped ServiceHolder in
> CoreContainerProvider#services, and that's a *WeakHashMap*:
> {code:java}
> services
> .computeIfAbsent(new ContextInitializationKey(servletContext),
> ServiceHolder::new)
> .setService(this);
> {code}
> The key is not referenced anywhere else, which makes the mapping a candidate
> for garbage collection. The ServiceHolder value also does not reference the
> key anymore, because #setService cleared the reference.
> With bad luck, the mapping is already gone from the WeakHashMap before
> SolrDispatchFilter#init tries to retrieve it with
> CoreContainerProvider#serviceForContext. And that method will then create a
> new ContextInitializationKey and ServiceHolder, which is then used for
> #waitForReadyServic
Re: [PR] SOLR-17118: Simplify CoreContainerProvider initialization [solr]
dsmiley merged PR #2474: URL: https://github.com/apache/solr/pull/2474 -- 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
Re: [PR] fix Lucene[95-->99] typo in SchemaCodecFactory javadocs [solr]
dsmiley commented on code in PR #2478:
URL: https://github.com/apache/solr/pull/2478#discussion_r1623083017
##
solr/core/src/java/org/apache/solr/core/SchemaCodecFactory.java:
##
@@ -151,7 +151,7 @@ public Codec getCodec() {
}
/**
- * This class exists because Lucene95HnswVectorsFormat's getMaxDimensions
method is final and we
+ * This class exists because Lucene99HnswVectorsFormat's getMaxDimensions
method is final and we
Review Comment:
why not directly reference it using `{@link ...}`. It's take less chars
overall! (no need to refer to "method")
--
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-16093) Tests should not require a working IPv6 networking stack
[
https://issues.apache.org/jira/browse/SOLR-16093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-16093.
-
Fix Version/s: 9.7
Resolution: Fixed
> Tests should not require a working IPv6 networking stack
>
>
> Key: SOLR-16093
> URL: https://issues.apache.org/jira/browse/SOLR-16093
> Project: Solr
> Issue Type: Test
> Components: Tests
>Reporter: Mike Drob
>Assignee: David Smiley
>Priority: Minor
> Fix For: 9.7
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I was running tests inside of a docker container (trying to parallelize some
> stuff in a different way) and likely had my networking set up incorrectly.
> This was with JDK17.
> I'm not sure how the IPv6 shard addresses got in there, maybe that what Solr
> decided to register in zookeeper, or maybe it was an artifact of my docker
> container doing some weird translation.
> {{shards=http://127.0.0.1:41629/x_bm/lr/collection1|[::1]:4/x_bm/lr|[::1]:6/x_bm/lr,http://127.0.0.1:44693/x_bm/lr/collection1,[::1]:4/x_bm/lr|http://127.0.0.1:44741/x_bm/lr/collection1}}
> {noformat}
> 2> 88712 INFO (qtp1293439783-64) [ x:collection1] o.a.s.c.S.Request
> webapp=/x_bm/lr path=/select
> params={q=id:42&shards=http://127.0.0.1:41629/x_bm/lr/collection1|[::1]:4/x_bm/lr|[::1]:6/x_bm/lr,http://127.0.0.1:44693/x_bm/lr/collection1,[::1]:4/x_bm/lr|http://127.0.0.1:44741/x_bm/lr/collection1&rows=0&wt=javabin&version=2}
> status=500 QTime=252
> 2> 88716 ERROR (qtp1293439783-64) [ x:collection1] o.a.s.s.HttpSolrCall
> org.apache.solr.common.SolrException:
> org.apache.solr.client.solrj.SolrServerException: Unsupported address type
> 2> => org.apache.solr.common.SolrException:
> org.apache.solr.client.solrj.SolrServerException: Unsupported address type
> 2>at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:504)
> 2> org.apache.solr.common.SolrException:
> org.apache.solr.client.solrj.SolrServerException: Unsupported address type
> 2>at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:504)
> ~[main/:?]
> 2>at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:230)
> ~[main/:?]
> 2>at org.apache.solr.core.SolrCore.execute(SolrCore.java:2866)
> ~[main/:?]
> 2>at
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:881) [main/:?]
> 2>at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:600)
> [main/:?]
> 2>at
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:234)
> [main/:?]
> 2>at
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:202)
> [main/:?]
> 2>at
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:257)
> [main/:?]
> 2>at
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:227)
> [main/:?]
> 2>at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:197)
> [main/:?]
> 2>at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> [main/:?]
> 2>at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
> [jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601)
> [jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:187)
> [main/:?]
> 2>at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
> [jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601)
> [jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:548)
> [jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> [jetty-server-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
> [jetty-server-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> [jetty-server-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1434)
> [jetty-server-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHand
[PR] Update org.mockito:mockito* to v5.12.0 [solr]
solrbot opened a new pull request, #2490: URL: https://github.com/apache/solr/pull/2490 This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [org.mockito:mockito-subclass](https://togithub.com/mockito/mockito) | test | minor | `5.11.0` -> `5.12.0` | | [org.mockito:mockito-core](https://togithub.com/mockito/mockito) | test | minor | `5.11.0` -> `5.12.0` | --- ### Release Notes mockito/mockito (org.mockito:mockito-subclass) ### [`v5.12.0`](https://togithub.com/mockito/mockito/releases/tag/v5.12.0) *Changelog generated by [Shipkit Changelog Gradle Plugin](https://togithub.com/shipkit/shipkit-changelog)* # 5.12.0 - 2024-05-11 - [25 commit(s)](https://togithub.com/mockito/mockito/compare/v5.11.0...v5.12.0) by Piotr Przybylak, Stefano Cordio, Tim van der Lippe, dependabot\[bot], jonghoonpark - Bump com.gradle.enterprise from 3.17.2 to 3.17.3 [(#3341)](https://togithub.com/mockito/mockito/pull/3341) - Bump org.jetbrains.kotlin:kotlin-stdlib from 1.9.23 to 1.9.24 [(#3339)](https://togithub.com/mockito/mockito/pull/3339) - Bump versions.bytebuddy from 1.14.14 to 1.14.15 [(#3338)](https://togithub.com/mockito/mockito/pull/3338) - Bump org.shipkit:shipkit-auto-version from 2.0.6 to 2.0.7 [(#3337)](https://togithub.com/mockito/mockito/pull/3337) - Bump org.jetbrains.kotlin:kotlin-gradle-plugin from 1.9.23 to 1.9.24 [(#3336)](https://togithub.com/mockito/mockito/pull/3336) - Fixes [#3331](https://togithub.com/mockito/mockito/issues/3331) : Fix `AdditionalMatchers.and()` and `AdditionalMatchers.or()` not to swap the order of matchers [(#3335)](https://togithub.com/mockito/mockito/pull/3335) - AdditionalMatchers.and() and or() swap matcher order [(#3331)](https://togithub.com/mockito/mockito/issues/3331) - Bump gradle/wrapper-validation-action from 3.3.1 to 3.3.2 [(#3327)](https://togithub.com/mockito/mockito/pull/3327) - Bump versions.bytebuddy from 1.14.13 to 1.14.14 [(#3324)](https://togithub.com/mockito/mockito/pull/3324) - Bump org.shipkit:shipkit-auto-version from 2.0.5 to 2.0.6 [(#3322)](https://togithub.com/mockito/mockito/pull/3322) - Bump gradle/wrapper-validation-action from 3.3.0 to 3.3.1 [(#3320)](https://togithub.com/mockito/mockito/pull/3320) - Bump com.gradle.enterprise from 3.17 to 3.17.2 [(#3318)](https://togithub.com/mockito/mockito/pull/3318) - Bump gradle/wrapper-validation-action from 2.1.2 to 3.3.0 [(#3317)](https://togithub.com/mockito/mockito/pull/3317) - Update codecov-action version [(#3316)](https://togithub.com/mockito/mockito/pull/3316) - Bump com.google.googlejavaformat:google-java-format from 1.21.0 to 1.22.0 [(#3312)](https://togithub.com/mockito/mockito/pull/3312) - Bump com.gradle.enterprise from 3.16.2 to 3.17 [(#3311)](https://togithub.com/mockito/mockito/pull/3311) - Bump versions.bytebuddy from 1.14.12 to 1.14.13 [(#3308)](https://togithub.com/mockito/mockito/pull/3308) - Fix README logo [(#3305)](https://togithub.com/mockito/mockito/pull/3305) - Bump gradle/wrapper-validation-action from 2.1.1 to 2.1.2 [(#3303)](https://togithub.com/mockito/mockito/pull/3303) - Bump org.shipkit:shipkit-auto-version from 2.0.4 to 2.0.5 [(#3298)](https://togithub.com/mockito/mockito/pull/3298) - Bump org.jetbrains.kotlin:kotlin-gradle-plugin from 1.9.22 to 1.9.23 [(#3296)](https://togithub.com/mockito/mockito/pull/3296) - Bump org.eclipse.platform:org.eclipse.osgi from 3.18.600 to 3.19.0 [(#3295)](https://togithub.com/mockito/mockito/pull/3295) - Bump org.jetbrains.kotlin:kotlin-stdlib from 1.9.22 to 1.9.23 [(#3292)](https://togithub.com/mockito/mockito/pull/3292) - Bump com.google.googlejavaformat:google-java-format from 1.20.0 to 1.21.0 [(#3291)](https://togithub.com/mockito/mockito/pull/3291) - Fixes [#3286](https://togithub.com/mockito/mockito/issues/3286) : Mockito.only() points to the wanted call as unwanted if it is the first being calledIssue3286 [(#3287)](https://togithub.com/mockito/mockito/pull/3287) - Mockito.only() points to the wanted call as unwanted if it is the first being called. [(#3286)](https://togithub.com/mockito/mockito/issues/3286) - Bump org.codehaus.groovy:groovy from 3.0.20 to 3.0.21 [(#3284)](https://togithub.com/mockito/mockito/pull/3284) --- ### Configuration 📅 **Schedule**: Branch creation - "before 9am on the first day of the month" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about these updates again. --- - [ ] If you want to rebase/retry this PR
[jira] [Commented] (SOLR-17271) PerReplicaState: Shard leader elections still impact state.json
[ https://issues.apache.org/jira/browse/SOLR-17271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851235#comment-17851235 ] ASF subversion and git services commented on SOLR-17271: Commit c5913f6b06629f6015a2b6fb2b28b1fd03489f34 in solr's branch refs/heads/branch_9x from Noble Paul [ https://gitbox.apache.org/repos/asf?p=solr.git;h=c5913f6b066 ] SOLR-17271: PerReplicaState: Shard leader elections still impact state.json (#2443) > PerReplicaState: Shard leader elections still impact state.json > --- > > Key: SOLR-17271 > URL: https://issues.apache.org/jira/browse/SOLR-17271 > Project: Solr > Issue Type: Bug >Reporter: Justin Sweeney >Assignee: Noble Paul >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > From testing it has been found that shard leader elections when there are > multiple replicas still touches state.json, even when PerReplicaState (PRS) > is enabled. With PRS, leader should be contained in the per replica state so > we should not have to modify state.json. -- 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-17271) PerReplicaState: Shard leader elections still impact state.json
[ https://issues.apache.org/jira/browse/SOLR-17271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851233#comment-17851233 ] ASF subversion and git services commented on SOLR-17271: Commit bc7fceeb7d7dc6e75b9e79ddf8cddb57eb8f452f in solr's branch refs/heads/main from Noble Paul [ https://gitbox.apache.org/repos/asf?p=solr.git;h=bc7fceeb7d7 ] SOLR-17271: PerReplicaState: Shard leader elections still impact state.json (#2443) > PerReplicaState: Shard leader elections still impact state.json > --- > > Key: SOLR-17271 > URL: https://issues.apache.org/jira/browse/SOLR-17271 > Project: Solr > Issue Type: Bug >Reporter: Justin Sweeney >Assignee: Noble Paul >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > From testing it has been found that shard leader elections when there are > multiple replicas still touches state.json, even when PerReplicaState (PRS) > is enabled. With PRS, leader should be contained in the per replica state so > we should not have to modify state.json. -- 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
Re: [PR] SOLR-17271: PerReplicaState: Shard leader elections still impact state.json [solr]
noblepaul merged PR #2443: URL: https://github.com/apache/solr/pull/2443 -- 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-16093) Tests should not require a working IPv6 networking stack
[
https://issues.apache.org/jira/browse/SOLR-16093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851231#comment-17851231
]
ASF subversion and git services commented on SOLR-16093:
Commit 8c15fd632a4a8a26b015aee45ea998a80880eddc in solr's branch
refs/heads/branch_9x from David Smiley
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=8c15fd632a4 ]
SOLR-16093: Tests: don't require IPv6 (#2484)
The Java VM/host, doesn't always support IPv6, our tests shouldn't require it.
security.policy: Removed 3 lines that were only for tests.
(cherry picked from commit 52042187f7645b578aedad27c4bf58b5110ddc65)
> Tests should not require a working IPv6 networking stack
>
>
> Key: SOLR-16093
> URL: https://issues.apache.org/jira/browse/SOLR-16093
> Project: Solr
> Issue Type: Test
> Components: Tests
>Reporter: Mike Drob
>Assignee: David Smiley
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I was running tests inside of a docker container (trying to parallelize some
> stuff in a different way) and likely had my networking set up incorrectly.
> This was with JDK17.
> I'm not sure how the IPv6 shard addresses got in there, maybe that what Solr
> decided to register in zookeeper, or maybe it was an artifact of my docker
> container doing some weird translation.
> {{shards=http://127.0.0.1:41629/x_bm/lr/collection1|[::1]:4/x_bm/lr|[::1]:6/x_bm/lr,http://127.0.0.1:44693/x_bm/lr/collection1,[::1]:4/x_bm/lr|http://127.0.0.1:44741/x_bm/lr/collection1}}
> {noformat}
> 2> 88712 INFO (qtp1293439783-64) [ x:collection1] o.a.s.c.S.Request
> webapp=/x_bm/lr path=/select
> params={q=id:42&shards=http://127.0.0.1:41629/x_bm/lr/collection1|[::1]:4/x_bm/lr|[::1]:6/x_bm/lr,http://127.0.0.1:44693/x_bm/lr/collection1,[::1]:4/x_bm/lr|http://127.0.0.1:44741/x_bm/lr/collection1&rows=0&wt=javabin&version=2}
> status=500 QTime=252
> 2> 88716 ERROR (qtp1293439783-64) [ x:collection1] o.a.s.s.HttpSolrCall
> org.apache.solr.common.SolrException:
> org.apache.solr.client.solrj.SolrServerException: Unsupported address type
> 2> => org.apache.solr.common.SolrException:
> org.apache.solr.client.solrj.SolrServerException: Unsupported address type
> 2>at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:504)
> 2> org.apache.solr.common.SolrException:
> org.apache.solr.client.solrj.SolrServerException: Unsupported address type
> 2>at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:504)
> ~[main/:?]
> 2>at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:230)
> ~[main/:?]
> 2>at org.apache.solr.core.SolrCore.execute(SolrCore.java:2866)
> ~[main/:?]
> 2>at
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:881) [main/:?]
> 2>at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:600)
> [main/:?]
> 2>at
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:234)
> [main/:?]
> 2>at
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:202)
> [main/:?]
> 2>at
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:257)
> [main/:?]
> 2>at
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:227)
> [main/:?]
> 2>at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:197)
> [main/:?]
> 2>at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> [main/:?]
> 2>at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
> [jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601)
> [jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:187)
> [main/:?]
> 2>at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
> [jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601)
> [jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:548)
> [jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> [jetty-server-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
> [
[jira] [Commented] (SOLR-16093) Tests should not require a working IPv6 networking stack
[
https://issues.apache.org/jira/browse/SOLR-16093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851193#comment-17851193
]
ASF subversion and git services commented on SOLR-16093:
Commit 52042187f7645b578aedad27c4bf58b5110ddc65 in solr's branch
refs/heads/main from David Smiley
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=52042187f76 ]
SOLR-16093: Tests: don't require IPv6 (#2484)
The Java VM/host, doesn't always support IPv6, our tests shouldn't require it.
security.policy: Removed 3 lines that were only for tests.
> Tests should not require a working IPv6 networking stack
>
>
> Key: SOLR-16093
> URL: https://issues.apache.org/jira/browse/SOLR-16093
> Project: Solr
> Issue Type: Test
> Components: Tests
>Reporter: Mike Drob
>Assignee: David Smiley
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I was running tests inside of a docker container (trying to parallelize some
> stuff in a different way) and likely had my networking set up incorrectly.
> This was with JDK17.
> I'm not sure how the IPv6 shard addresses got in there, maybe that what Solr
> decided to register in zookeeper, or maybe it was an artifact of my docker
> container doing some weird translation.
> {{shards=http://127.0.0.1:41629/x_bm/lr/collection1|[::1]:4/x_bm/lr|[::1]:6/x_bm/lr,http://127.0.0.1:44693/x_bm/lr/collection1,[::1]:4/x_bm/lr|http://127.0.0.1:44741/x_bm/lr/collection1}}
> {noformat}
> 2> 88712 INFO (qtp1293439783-64) [ x:collection1] o.a.s.c.S.Request
> webapp=/x_bm/lr path=/select
> params={q=id:42&shards=http://127.0.0.1:41629/x_bm/lr/collection1|[::1]:4/x_bm/lr|[::1]:6/x_bm/lr,http://127.0.0.1:44693/x_bm/lr/collection1,[::1]:4/x_bm/lr|http://127.0.0.1:44741/x_bm/lr/collection1&rows=0&wt=javabin&version=2}
> status=500 QTime=252
> 2> 88716 ERROR (qtp1293439783-64) [ x:collection1] o.a.s.s.HttpSolrCall
> org.apache.solr.common.SolrException:
> org.apache.solr.client.solrj.SolrServerException: Unsupported address type
> 2> => org.apache.solr.common.SolrException:
> org.apache.solr.client.solrj.SolrServerException: Unsupported address type
> 2>at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:504)
> 2> org.apache.solr.common.SolrException:
> org.apache.solr.client.solrj.SolrServerException: Unsupported address type
> 2>at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:504)
> ~[main/:?]
> 2>at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:230)
> ~[main/:?]
> 2>at org.apache.solr.core.SolrCore.execute(SolrCore.java:2866)
> ~[main/:?]
> 2>at
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:881) [main/:?]
> 2>at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:600)
> [main/:?]
> 2>at
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:234)
> [main/:?]
> 2>at
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:202)
> [main/:?]
> 2>at
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:257)
> [main/:?]
> 2>at
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:227)
> [main/:?]
> 2>at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:197)
> [main/:?]
> 2>at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> [main/:?]
> 2>at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
> [jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601)
> [jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:187)
> [main/:?]
> 2>at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
> [jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601)
> [jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:548)
> [jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> [jetty-server-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
> [jetty-server-9.4.44.v20210927.jar:9.4.44.v20210927]
> 2>at
> org.ecli
Re: [PR] SOLR-16093: Tests: don't require IPv6 [solr]
dsmiley merged PR #2484: URL: https://github.com/apache/solr/pull/2484 -- 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
Re: [PR] Move setShardAttributesToParams [solr]
dsmiley merged PR #2486: URL: https://github.com/apache/solr/pull/2486 -- 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
Re: [PR] Correct command to reproduce test with a failure in classMethod [solr]
AndreyBozhko closed pull request #2483: Correct command to reproduce test with a failure in classMethod URL: https://github.com/apache/solr/pull/2483 -- 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
Re: [PR] Build: report test history via GE [solr]
AndreyBozhko commented on PR #2487: URL: https://github.com/apache/solr/pull/2487#issuecomment-2142819005 LGTM - just echoing the comment from @gus-asf: https://github.com/apache/solr/pull/2483#issuecomment-2138043439 > if we are touching this lets add a ./ on the front of the command so one can actually cut and paste it :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. 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-17137) Prometheus-exporter support SSL on Solr standalone
[ https://issues.apache.org/jira/browse/SOLR-17137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851176#comment-17851176 ] ASF subversion and git services commented on SOLR-17137: Commit 3d268bc57d7be84dc1198324955ec152601ad133 in solr's branch refs/heads/branch_9x from Eivind Bergstøl [ https://gitbox.apache.org/repos/asf?p=solr.git;h=3d268bc57d7 ] SOLR-17137 - Add configuration for SSL between Solr and Prometheus exporter. (#2232) When running Solr with mTLS the exporter also needs to use mTLS to be able to talk to Solr api. This commit also adds a bats test that verifies that solr exporter actually scrape the running solr instance by verifying information about a newly made core is present. > Prometheus-exporter support SSL on Solr standalone > -- > > Key: SOLR-17137 > URL: https://issues.apache.org/jira/browse/SOLR-17137 > Project: Solr > Issue Type: Improvement > Components: contrib - prometheus-exporter >Affects Versions: 9.4.1 >Reporter: Eivind Bergtøl >Priority: Major > Time Spent: 3h 20m > Remaining Estimate: 0h > > If you enable TLS on Solr, the promethes-exporter cannot fetch metrics. It > should be configured with SSLContext in Http2SolrClient builder -- 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-17137) Prometheus-exporter support SSL on Solr standalone
[ https://issues.apache.org/jira/browse/SOLR-17137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-17137. -- Fix Version/s: 9.7 Assignee: Eric Pugh Resolution: Fixed > Prometheus-exporter support SSL on Solr standalone > -- > > Key: SOLR-17137 > URL: https://issues.apache.org/jira/browse/SOLR-17137 > Project: Solr > Issue Type: Improvement > Components: contrib - prometheus-exporter >Affects Versions: 9.4.1 >Reporter: Eivind Bergtøl >Assignee: Eric Pugh >Priority: Major > Fix For: 9.7 > > Time Spent: 3.5h > Remaining Estimate: 0h > > If you enable TLS on Solr, the promethes-exporter cannot fetch metrics. It > should be configured with SSLContext in Http2SolrClient builder -- 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
Re: [PR] SOLR-17137 Add configuration for SSL between Solr and Prometheus exporter. [solr]
epugh commented on PR #2232: URL: https://github.com/apache/solr/pull/2232#issuecomment-2142792815 thank you fro this! -- 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-17137) Prometheus-exporter support SSL on Solr standalone
[ https://issues.apache.org/jira/browse/SOLR-17137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851173#comment-17851173 ] ASF subversion and git services commented on SOLR-17137: Commit 5bee23c9dea32f9262a6d8cf279a03b141636ee1 in solr's branch refs/heads/main from Eivind Bergstøl [ https://gitbox.apache.org/repos/asf?p=solr.git;h=5bee23c9dea ] SOLR-17137 - Add configuration for SSL between Solr and Prometheus exporter. (#2232) When running Solr with mTLS the exporter also needs to use mTLS to be able to talk to Solr api. This commit also adds a bats test that verifies that solr exporter actually scrape the running solr instance by verifying information about a newly made core is present. > Prometheus-exporter support SSL on Solr standalone > -- > > Key: SOLR-17137 > URL: https://issues.apache.org/jira/browse/SOLR-17137 > Project: Solr > Issue Type: Improvement > Components: contrib - prometheus-exporter >Affects Versions: 9.4.1 >Reporter: Eivind Bergtøl >Priority: Major > Time Spent: 3h 20m > Remaining Estimate: 0h > > If you enable TLS on Solr, the promethes-exporter cannot fetch metrics. It > should be configured with SSLContext in Http2SolrClient builder -- 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
Re: [PR] SOLR-17137 Add configuration for SSL between Solr and Prometheus exporter. [solr]
epugh merged PR #2232: URL: https://github.com/apache/solr/pull/2232 -- 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
Re: [PR] Correct command to reproduce test with a failure in classMethod [solr]
dsmiley commented on PR #2483: URL: https://github.com/apache/solr/pull/2483#issuecomment-2142758098 Yes I think this should be closed as incorporated by #2487 . Feel free to provide any further feedback there! -- 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-15447) Reproduce with line inaccurate for class methods
[
https://issues.apache.org/jira/browse/SOLR-15447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851168#comment-17851168
]
David Smiley commented on SOLR-15447:
-
Will be fixed by the linked PR https://github.com/apache/solr/pull/2487
> Reproduce with line inaccurate for class methods
>
>
> Key: SOLR-15447
> URL: https://issues.apache.org/jira/browse/SOLR-15447
> Project: Solr
> Issue Type: Test
> Components: Tests
>Reporter: Mike Drob
>Priority: Major
> Attachments: SOLR-15447.patch
>
>
> I had this failure running tests recently:
> {noformat}
> - org.apache.solr.cloud.api.collections.ShardSplitTest.classMethod
> (:solr:core)
> Test output:
> /Users/mdrob/code/solr/solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.cloud.api.collections.ShardSplitTest.txt
> Reproduce with: gradlew :solr:core:test --tests
> "org.apache.solr.cloud.api.collections.ShardSplitTest.classMethod"
> -Ptests.jvms=16 -Ptests.jvmargs=-XX:TieredStopAtLevel=1
> -Ptests.seed=40D22CF6F9086FB4 -Ptests.file.encoding=UTF-8 {noformat}
> There is no "classMethod" method, so the given command line fails to
> reproduce the failure. Unfortunately, I do not have the logs anymore, but I
> strongly expect this was a failure either in the test setup, teardown, or
> possibly something like the thread leak detector.
>
> We should figure out how we can provide a better reproduce with line for this
> type of failure.
--
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
Re: [PR] Correct command to reproduce test with a failure in classMethod [solr]
AndreyBozhko commented on PR #2483: URL: https://github.com/apache/solr/pull/2483#issuecomment-2142615599 Looks like this may be superseded by https://github.com/apache/solr/pull/2487 -- 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
Re: [PR] SOLR-10654: Introduce output of Prometheus metrics for Solr Core registry [solr]
dsmiley commented on PR #2405: URL: https://github.com/apache/solr/pull/2405#issuecomment-2142527945 It doesn't feel right to merge this PR right now. Needs docs. Also the choice of what metrics are done so far is inverted from the value that would make most sense for this whole approach -- OS/JVM/node issues are highest value. -- 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
Re: [PR] Introduce support for Reciprocal Rank Fusion (combining queries) [solr]
alessandrobenedetti commented on PR #2489: URL: https://github.com/apache/solr/pull/2489#issuecomment-2142359815 As of today the solution is clean enough to be reviewed and tests are green. The usage is intuitive and it should cover many use cases. Pending activities: - add a new documentation page - add tests for the distributed scenario -- 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
[PR] Introduce support for Reciprocal Rank Fusion (combining queries) [solr]
alessandrobenedetti opened a new pull request, #2489:
URL: https://github.com/apache/solr/pull/2489
https://issues.apache.org/jira/browse/SOLR-17319
# Description
Reciprocal Rank Fusion (RRF) is an algorithm that takes in input multiple
ranked lists to produce a unified result set.
Examples of use cases where RRF can be used include hybrid search and
multiple Knn vector queries executed concurrently.
RRF is based on the concept of reciprocal rank, which is the inverse of the
rank of a document in a ranked list of search results.
The combination of search results happens taking into account the position of
the items in the original rankings, and giving higher score to items that
are ranked higher in multiple lists. RRF was introduced the first time by
Cormack et al. in [1].
The syntax proposed:
JSON Request
```
{
"queries": {
"lexical1": {
"lucene": {
"query": "id:(10^=2 OR 2^=1 OR 4^=0.5)"
}
},
"lexical2": {
"lucene": {
"query": "id:(2^=2 OR 4^=1 OR 3^=0.5)"
}
}
},
"limit": 10,
"fields": "[id,score]",
"params": {
"combiner": true,
"combiner.upTo": 5,
"facet": true,
"facet.field": "id",
"facet.mincount": 1
}
}
```
[1] Cormack, Gordon V. et al. “Reciprocal rank fusion outperforms condorcet
and individual rank learning methods.” Proceedings of the 32nd international
ACM SIGIR conference on Research and development in information retrieval (2009)
# Solution
The support has been introduced leveraging the "queries" support in the JSON
request syntax.
The combination of results happen at QueryComponent, processing level.
The debug component has the responsibility of managing the explainability
part.
Limitations:
- grouping/field collapsing won't be supported in a first version
- the distributed support is present but not super advanced: query
combination happens at node level and then results are combined at shard level.
# Tests
Tests have been added to cover the main use cases
# Checklist
Please review the following and check all that apply:
- [ ] I have reviewed the guidelines for [How to
Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) 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
[jira] [Comment Edited] (SOLR-17319) Introduce support for Reciprocal Rank Fusion (combining queries)
[
https://issues.apache.org/jira/browse/SOLR-17319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851114#comment-17851114
]
Alessandro Benedetti edited comment on SOLR-17319 at 5/31/24 2:12 PM:
--
This issue solve an outstanding problem raised many time by [~dep4b] od having
the possibility of running interleaving with any kind of queries (not only
Learning To Rank).
Progress updates and discussions will happen on the related Pull
Request(opening soon)
was (Author: alessandro.benedetti):
This issue solve an outstanding problem raised many time by [~dep4b] od having
the possibility of running interleaving with any kind of queries (not only
Learning To Rank)
> Introduce support for Reciprocal Rank Fusion (combining queries)
>
>
> Key: SOLR-17319
> URL: https://issues.apache.org/jira/browse/SOLR-17319
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query
>Affects Versions: 9.6.1
>Reporter: Alessandro Benedetti
>Assignee: Alessandro Benedetti
>Priority: Major
>
> Reciprocal Rank Fusion (RRF) is an algorithm that takes in input multiple
> ranked lists to produce a unified result set.
> Examples of use cases where RRF can be used include hybrid search and
> multiple Knn vector queries executed concurrently.
> RRF is based on the concept of reciprocal rank, which is the inverse of the
> rank of a document in a ranked list of search results.
> The combination of search results happens taking into account the position of
> the items in the original rankings, and giving higher score to items that
> are ranked higher in multiple lists. RRF was introduced the first time by
> Cormack et al. in [1].
> The syntax proposed:
> JSON Request
> {code:json}
> {
> "queries": {
> "lexical1": {
> "lucene": {
> "query": "id:(10^=2 OR 2^=1 OR 4^=0.5)"
> }
> },
> "lexical2": {
> "lucene": {
> "query": "id:(2^=2 OR 4^=1 OR 3^=0.5)"
> }
> }
> },
> "limit": 10,
> "fields": "[id,score]",
> "params": {
> "combiner": true,
> "combiner.upTo": 5,
> "facet": true,
> "facet.field": "id",
> "facet.mincount": 1
> }
> }
> {code}
> [1] Cormack, Gordon V. et al. “Reciprocal rank fusion outperforms condorcet
> and individual rank learning methods.” Proceedings of the 32nd international
> ACM SIGIR conference on Research and development in information retrieval
> (2009)
--
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-17319) Introduce support for Reciprocal Rank Fusion (combining queries)
[
https://issues.apache.org/jira/browse/SOLR-17319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alessandro Benedetti updated SOLR-17319:
Description:
Reciprocal Rank Fusion (RRF) is an algorithm that takes in input multiple
ranked lists to produce a unified result set.
Examples of use cases where RRF can be used include hybrid search and multiple
Knn vector queries executed concurrently.
RRF is based on the concept of reciprocal rank, which is the inverse of the
rank of a document in a ranked list of search results.
The combination of search results happens taking into account the position of
the items in the original rankings, and giving higher score to items that are
ranked higher in multiple lists. RRF was introduced the first time by Cormack
et al. in [1].
The syntax proposed:
JSON Request
{code:json}
{
"queries": {
"lexical1": {
"lucene": {
"query": "id:(10^=2 OR 2^=1 OR 4^=0.5)"
}
},
"lexical2": {
"lucene": {
"query": "id:(2^=2 OR 4^=1 OR 3^=0.5)"
}
}
},
"limit": 10,
"fields": "[id,score]",
"params": {
"combiner": true,
"combiner.upTo": 5,
"facet": true,
"facet.field": "id",
"facet.mincount": 1
}
}
{code}
[1] Cormack, Gordon V. et al. “Reciprocal rank fusion outperforms condorcet and
individual rank learning methods.” Proceedings of the 32nd international ACM
SIGIR conference on Research and development in information retrieval (2009)
was:
Reciprocal Rank Fusion (RRF) is an algorithm that takes in input multiple
ranked lists to produce a unified result set.
Examples of use cases where RRF can be used include hybrid search and multiple
Knn vector queries executed concurrently.
RRF is based on the concept of reciprocal rank, which is the inverse of the
rank of a document in a ranked list of search results.
The combination of search results happens taking into account the position of
the items in the original rankings, and giving higher score to items that are
ranked higher in multiple lists. RRF was introduced the first time by Cormack
et al. in [1].
The syntax proposed:
{code:json}
{
"queries": {
"lexical1": {
"lucene": {
"query": "id:(10^=2 OR 2^=1 OR 4^=0.5)"
}
},
"lexical2": {
"lucene": {
"query": "id:(2^=2 OR 4^=1 OR 3^=0.5)"
}
}
},
"limit": 10,
"fields": "[id,score]",
"params": {
"combiner": true,
"combiner.upTo": 5,
"facet": true,
"facet.field": "id",
"facet.mincount": 1
}
}
{code}
[1] Cormack, Gordon V. et al. “Reciprocal rank fusion outperforms condorcet and
individual rank learning methods.” Proceedings of the 32nd international ACM
SIGIR conference on Research and development in information retrieval (2009)
> Introduce support for Reciprocal Rank Fusion (combining queries)
>
>
> Key: SOLR-17319
> URL: https://issues.apache.org/jira/browse/SOLR-17319
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query
>Affects Versions: 9.6.1
>Reporter: Alessandro Benedetti
>Assignee: Alessandro Benedetti
>Priority: Major
>
> Reciprocal Rank Fusion (RRF) is an algorithm that takes in input multiple
> ranked lists to produce a unified result set.
> Examples of use cases where RRF can be used include hybrid search and
> multiple Knn vector queries executed concurrently.
> RRF is based on the concept of reciprocal rank, which is the inverse of the
> rank of a document in a ranked list of search results.
> The combination of search results happens taking into account the position of
> the items in the original rankings, and giving higher score to items that
> are ranked higher in multiple lists. RRF was introduced the first time by
> Cormack et al. in [1].
> The syntax proposed:
> JSON Request
> {code:json}
> {
> "queries": {
> "lexical1": {
> "lucene": {
> "query": "id:(10^=2 OR 2^=1 OR 4^=0.5)"
> }
> },
> "lexical2": {
> "lucene": {
> "query": "id:(2^=2 OR 4^=1 OR 3^=0.5)"
> }
> }
> },
> "limit": 10,
> "fields": "[id,score]",
> "params": {
> "combiner": true,
> "combiner.upTo": 5,
> "facet": true,
> "facet.field": "id",
> "facet.mincount": 1
> }
> }
> {code}
> [1] Cormack, Gordon V. et al. “Reciprocal rank fusion outperforms condorcet
> and individual rank learning methods.” Proceedings of the 32nd international
> ACM SI
Re: [PR] SOLR-16824: Adopt Linux Command line tool pattern of -- for long option commands [solr]
epugh commented on PR #1768: URL: https://github.com/apache/solr/pull/1768#issuecomment-2142295192 thanks for tackling those.. I would love to get more of the string parsing out of the scripts for solr.. I went back and looked at them, and I think that for the various commands not related to "start", "stop", and "status", I can actually slim down a lot what is in the scripts. However, looking at "start", "stop", and "status" they have a lot of environment specific logic that I don't feel confident porting over to Java code ;-). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. 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-17319) Introduce support for Reciprocal Rank Fusion (combining queries)
[
https://issues.apache.org/jira/browse/SOLR-17319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alessandro Benedetti updated SOLR-17319:
Description:
Reciprocal Rank Fusion (RRF) is an algorithm that takes in input multiple
ranked lists to produce a unified result set.
Examples of use cases where RRF can be used include hybrid search and multiple
Knn vector queries executed concurrently.
RRF is based on the concept of reciprocal rank, which is the inverse of the
rank of a document in a ranked list of search results.
The combination of search results happens taking into account the position of
the items in the original rankings, and giving higher score to items that are
ranked higher in multiple lists. RRF was introduced the first time by Cormack
et al. in [1].
The syntax proposed:
{code:json}
{
"queries": {
"lexical1": {
"lucene": {
"query": "id:(10^=2 OR 2^=1 OR 4^=0.5)"
}
},
"lexical2": {
"lucene": {
"query": "id:(2^=2 OR 4^=1 OR 3^=0.5)"
}
}
},
"limit": 10,
"fields": "[id,score]",
"params": {
"combiner": true,
"combiner.upTo": 5,
"facet": true,
"facet.field": "id",
"facet.mincount": 1
}
}
{code}
[1] Cormack, Gordon V. et al. “Reciprocal rank fusion outperforms condorcet and
individual rank learning methods.” Proceedings of the 32nd international ACM
SIGIR conference on Research and development in information retrieval (2009)
was:
Reciprocal Rank Fusion (RRF) is an algorithm that takes in input multiple
ranked lists to produce a unified result set.
Examples of use cases where RRF can be used include hybrid search and multiple
Knn vector queries executed concurrently.
RRF is based on the concept of reciprocal rank, which is the inverse of the
rank of a document in a ranked list of search results.
The combination of search results happens taking into account the position of
the items in the original rankings, and giving higher score to items that are
ranked higher in multiple lists. RRF was introduced the first time by Cormack
et al. in [1].
[1] Cormack, Gordon V. et al. “Reciprocal rank fusion outperforms condorcet and
individual rank learning methods.” Proceedings of the 32nd international ACM
SIGIR conference on Research and development in information retrieval (2009)
> Introduce support for Reciprocal Rank Fusion (combining queries)
>
>
> Key: SOLR-17319
> URL: https://issues.apache.org/jira/browse/SOLR-17319
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query
>Affects Versions: 9.6.1
>Reporter: Alessandro Benedetti
>Assignee: Alessandro Benedetti
>Priority: Major
>
> Reciprocal Rank Fusion (RRF) is an algorithm that takes in input multiple
> ranked lists to produce a unified result set.
> Examples of use cases where RRF can be used include hybrid search and
> multiple Knn vector queries executed concurrently.
> RRF is based on the concept of reciprocal rank, which is the inverse of the
> rank of a document in a ranked list of search results.
> The combination of search results happens taking into account the position of
> the items in the original rankings, and giving higher score to items that
> are ranked higher in multiple lists. RRF was introduced the first time by
> Cormack et al. in [1].
> The syntax proposed:
> {code:json}
> {
> "queries": {
> "lexical1": {
> "lucene": {
> "query": "id:(10^=2 OR 2^=1 OR 4^=0.5)"
> }
> },
> "lexical2": {
> "lucene": {
> "query": "id:(2^=2 OR 4^=1 OR 3^=0.5)"
> }
> }
> },
> "limit": 10,
> "fields": "[id,score]",
> "params": {
> "combiner": true,
> "combiner.upTo": 5,
> "facet": true,
> "facet.field": "id",
> "facet.mincount": 1
> }
> }
> {code}
> [1] Cormack, Gordon V. et al. “Reciprocal rank fusion outperforms condorcet
> and individual rank learning methods.” Proceedings of the 32nd international
> ACM SIGIR conference on Research and development in information retrieval
> (2009)
--
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
Re: [PR] SOLR-16824: Adopt Linux Command line tool pattern of -- for long option commands [solr]
janhoy commented on PR #1768: URL: https://github.com/apache/solr/pull/1768#issuecomment-2142276698 Did a few low hanging ones -- 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] [Assigned] (SOLR-17319) Introduce support for Reciprocal Rank Fusion (combining queries)
[ https://issues.apache.org/jira/browse/SOLR-17319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessandro Benedetti reassigned SOLR-17319: --- Assignee: Alessandro Benedetti > Introduce support for Reciprocal Rank Fusion (combining queries) > > > Key: SOLR-17319 > URL: https://issues.apache.org/jira/browse/SOLR-17319 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: query >Affects Versions: 9.6.1 >Reporter: Alessandro Benedetti >Assignee: Alessandro Benedetti >Priority: Major > > Reciprocal Rank Fusion (RRF) is an algorithm that takes in input multiple > ranked lists to produce a unified result set. > Examples of use cases where RRF can be used include hybrid search and > multiple Knn vector queries executed concurrently. > RRF is based on the concept of reciprocal rank, which is the inverse of the > rank of a document in a ranked list of search results. > The combination of search results happens taking into account the position of > the items in the original rankings, and giving higher score to items that > are ranked higher in multiple lists. RRF was introduced the first time by > Cormack et al. in [1]. > [1] Cormack, Gordon V. et al. “Reciprocal rank fusion outperforms condorcet > and individual rank learning methods.” Proceedings of the 32nd international > ACM SIGIR conference on Research and development in information retrieval > (2009) -- 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-17319) Introduce support for Reciprocal Rank Fusion (combining queries)
[ https://issues.apache.org/jira/browse/SOLR-17319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851114#comment-17851114 ] Alessandro Benedetti commented on SOLR-17319: - This issue solve an outstanding problem raised many time by [~dep4b] od having the possibility of running interleaving with any kind of queries (not only Learning To Rank) > Introduce support for Reciprocal Rank Fusion (combining queries) > > > Key: SOLR-17319 > URL: https://issues.apache.org/jira/browse/SOLR-17319 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: query >Affects Versions: 9.6.1 >Reporter: Alessandro Benedetti >Assignee: Alessandro Benedetti >Priority: Major > > Reciprocal Rank Fusion (RRF) is an algorithm that takes in input multiple > ranked lists to produce a unified result set. > Examples of use cases where RRF can be used include hybrid search and > multiple Knn vector queries executed concurrently. > RRF is based on the concept of reciprocal rank, which is the inverse of the > rank of a document in a ranked list of search results. > The combination of search results happens taking into account the position of > the items in the original rankings, and giving higher score to items that > are ranked higher in multiple lists. RRF was introduced the first time by > Cormack et al. in [1]. > [1] Cormack, Gordon V. et al. “Reciprocal rank fusion outperforms condorcet > and individual rank learning methods.” Proceedings of the 32nd international > ACM SIGIR conference on Research and development in information retrieval > (2009) -- 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] [Created] (SOLR-17319) Introduce support for Reciprocal Rank Fusion (combining queries)
Alessandro Benedetti created SOLR-17319: --- Summary: Introduce support for Reciprocal Rank Fusion (combining queries) Key: SOLR-17319 URL: https://issues.apache.org/jira/browse/SOLR-17319 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Components: query Affects Versions: 9.6.1 Reporter: Alessandro Benedetti Reciprocal Rank Fusion (RRF) is an algorithm that takes in input multiple ranked lists to produce a unified result set. Examples of use cases where RRF can be used include hybrid search and multiple Knn vector queries executed concurrently. RRF is based on the concept of reciprocal rank, which is the inverse of the rank of a document in a ranked list of search results. The combination of search results happens taking into account the position of the items in the original rankings, and giving higher score to items that are ranked higher in multiple lists. RRF was introduced the first time by Cormack et al. in [1]. [1] Cormack, Gordon V. et al. “Reciprocal rank fusion outperforms condorcet and individual rank learning methods.” Proceedings of the 32nd international ACM SIGIR conference on Research and development in information retrieval (2009) -- 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] [Created] (SOLR-17318) bin/solr version should take a -z or -s and return actual version.
Eric Pugh created SOLR-17318:
Summary: bin/solr version should take a -z or -s and return actual
version.
Key: SOLR-17318
URL: https://issues.apache.org/jira/browse/SOLR-17318
Project: Solr
Issue Type: Sub-task
Components: cli
Reporter: Eric Pugh
Sourced from [https://github.com/apache/solr/pull/1768#issuecomment-2142193420]
Now that {{bin/solr}} supports a remote Solr cluster with {{{}--solr-url{}}}.
We currently support {{solr version}} which prints the version from
{{{}SolrVersion.java{}}}, i.e. the client version. However, if you run the tool
towards a remote solr with a different version, you won't see that.
So I wonder if {{solr --version}} should be the tool version, but {{solr
version --solr-url http://foo.bar/solr/}} should call the backend to ask for
its version.
Maybe have solr/version ALSO report the version of Solr the CLI was built with.
--
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
Re: [PR] SOLR-16824: Adopt Linux Command line tool pattern of -- for long option commands [solr]
epugh commented on PR #1768: URL: https://github.com/apache/solr/pull/1768#issuecomment-2142200406 > I had a thought now that `bin/solr` supports a remote Solr cluster with `--solr-url`. We currently support `solr version` which prints the version from `SolrVersion.java`, i.e. the client version. However, if you run the tool towards a remote solr with a different version, you won't see that. > > So I wonder if `solr --version` should be the tool version, but `solr version --solr-url http://foo.bar/solr/` should call the backend to ask for its version. > > Probably scope creep for this PR though. i love it...https://issues.apache.org/jira/browse/SOLR-17318 -- 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
Re: [PR] SOLR-16824: Adopt Linux Command line tool pattern of -- for long option commands [solr]
janhoy commented on PR #1768: URL: https://github.com/apache/solr/pull/1768#issuecomment-2142193420 I had a thought now that `bin/solr` supports a remote Solr cluster with `--solr-url`. We currently support `solr version` which prints the version from `SolrVersion.java`, i.e. the client version. However, if you run the tool towards a remote solr with a different version, you won't see that. So I wonder if `solr --version` should be the tool version, but `solr version --solr-url http://foo.bar/solr/` should call the backend to ask for its version. Probably scope creep for this PR though. -- 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
Re: [PR] SOLR-16824: Adopt Linux Command line tool pattern of -- for long option commands [solr]
epugh commented on PR #1768: URL: https://github.com/apache/solr/pull/1768#issuecomment-2142189297 @janhoy I ran a bit out of steam while waiting for 1.8.0, please do feel free to continue to push this PR along ;-). -- 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
Re: [PR] SOLR-10654: Introduce output of Prometheus metrics for Solr Core registry [solr]
mlbiscoc commented on PR #2405: URL: https://github.com/apache/solr/pull/2405#issuecomment-2142176578 > What's here looks good to me. Just need to add more; lots more metrics. Maybe it'll evolve a little once you add another category. My interest on this at-work is not the core metrics but all the other ones (Solr, JVM, Jetty). I'd then be inclined to take this to our Solr fork to kick the tires for real world usage. Thanks. I've been caught up in some other things recently but plan on continuing on the other registries somewhat soon and it shouldn't be as bad to export. Would it be better for me to continue and commit them to this branch, or was this planned to be merged and export the other 3 registries in a separate PR? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. 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
[PR] Build site with github action [solr-site]
janhoy opened a new pull request, #99: URL: https://github.com/apache/solr-site/pull/99 Ref email to PMC and instructions at https://cwiki.apache.org/confluence/display/INFRA/Moving+from+Infrastructure-pelican+to+GitHub+Actions -- 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
Re: [PR] SOLR-17137 Add configuration for SSL between Solr and Prometheus exporter. [solr]
eivinhb commented on PR #2232: URL: https://github.com/apache/solr/pull/2232#issuecomment-2142115625 Since I forked this under an organisation there is no way to give you the permission to the PR. Should I edit the file in a separate commit or the same one? -- 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
Re: [PR] SOLR-16824: Adopt Linux Command line tool pattern of -- for long option commands [solr]
janhoy commented on code in PR #1768:
URL: https://github.com/apache/solr/pull/1768#discussion_r1622383331
##
solr/core/src/java/org/apache/solr/cli/SolrCLI.java:
##
@@ -80,30 +83,72 @@ public class SolrCLI implements CLIO {
public static final String ZK_HOST = "localhost:9983";
+ public static final Option OPTION_ZKHOST_DEPRECATED =
+ Option.builder("zkHost")
+ .longOpt("zkHost")
+ .deprecated(
+ DeprecatedAttributes.builder()
+ .setForRemoval(true)
+ .setSince("9.6")
+ .setDescription("Use --zk-host instead")
+ .get())
+ .argName("HOST")
+ .hasArg()
+ .required(false)
+ .desc(
+ "Zookeeper connection string; unnecessary if ZK_HOST is defined
in solr.in.sh; otherwise, defaults to "
+ + ZK_HOST
+ + '.')
+ .build();
+
public static final Option OPTION_ZKHOST =
Option.builder("z")
- .longOpt("zkHost")
+ .longOpt("zk-host")
.argName("HOST")
.hasArg()
.required(false)
.desc(
"Zookeeper connection string; unnecessary if ZK_HOST is defined
in solr.in.sh; otherwise, defaults to "
+ ZK_HOST
+ '.')
- .longOpt("zkHost")
.build();
- public static final Option OPTION_SOLRURL =
+ public static final Option OPTION_SOLRURL_DEPRECATED =
Option.builder("solrUrl")
+ .longOpt("solrUrl")
+ .deprecated(
+ DeprecatedAttributes.builder()
+ .setForRemoval(true)
+ .setSince("9.6")
Review Comment:
```suggestion
.setSince("9.7")
```
##
solr/core/src/java/org/apache/solr/cli/SolrCLI.java:
##
@@ -80,30 +83,72 @@ public class SolrCLI implements CLIO {
public static final String ZK_HOST = "localhost:9983";
+ public static final Option OPTION_ZKHOST_DEPRECATED =
+ Option.builder("zkHost")
+ .longOpt("zkHost")
+ .deprecated(
+ DeprecatedAttributes.builder()
+ .setForRemoval(true)
+ .setSince("9.6")
Review Comment:
```suggestion
.setSince("9.7")
```
--
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
Re: [PR] Update dependency commons-cli:commons-cli to v1.8.0 [solr]
janhoy merged PR #2481: URL: https://github.com/apache/solr/pull/2481 -- 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
Re: [PR] SOLR-16824: Adopt Linux Command line tool pattern of -- for long option commands [solr]
janhoy commented on PR #1768: URL: https://github.com/apache/solr/pull/1768#issuecomment-2142070166 1.8.0 is out, will merge the renovate PR https://github.com/apache/solr/pull/2481 -- 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
Re: [PR] SOLR-17137 Add configuration for SSL between Solr and Prometheus exporter. [solr]
epugh commented on PR #2232: URL: https://github.com/apache/solr/pull/2232#issuecomment-2142048792 I like your edit! Can you confirm I can push to your branch? alternatively, can you add to improvemetns for solr 9.7: ``` * SOLR-17137: Enable Prometheus exporter to communicate with SSL protected Solr. (Eivind Bergstøl via Eric Pugh) ``` -- 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
Re: [PR] SOLR-17137 Add configuration for SSL between Solr and Prometheus exporter. [solr]
eivinhb commented on PR #2232: URL: https://github.com/apache/solr/pull/2232#issuecomment-2142021688 Great! My name is "Eivind Bergstøl". I think that what you suggest is nice. :) I might argue that it is the other way around: `Enable Prometheus exporter to communicate with SSL protected Solr. (Eivind Bergstøl via Eric Pugh)` -- 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
Re: [PR] SOLR-17137 Add configuration for SSL between Solr and Prometheus exporter. [solr]
epugh commented on PR #2232: URL: https://github.com/apache/solr/pull/2232#issuecomment-2141971072 @eivinhb this looks great. How do you want to be credited in `solr/CHANGES.txt`. I'm thinking this is an improvement under 9.7... "Enable SSL protected Solr to communicate with Prometheus exporter. (Your name via Eric Pugh)". -- 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
[PR] Add `alwaysStopwords` option to `edismax` so its "all stopwords" behaviour can be controlled [solr]
andywebb1975 opened a new pull request, #2488:
URL: https://github.com/apache/solr/pull/2488
_work in progress!_ If anyone sees this and has thoughts on it, please
comment below :-)
# Description
We were surprised by `edismax`'s behaviour for pure-stopword queries, having
expected that these would return zero results. Its _'If a query consists of all
stopwords, such as "to be or not to be", then all words are required.'_
behaviour is the opposite to what we want as we're using query-time stopwords
to prevent particular query terms matching, but there's no way to disable the
behaviour other than using `dismax` instead, which may have other impacts.
# Solution
This PR adds an `alwaysStopwords` option that disables the default
behaviour. Its name is TBD.
I've noticed that the query plan becomes `+()` rather than
`MatchNoDocsQuery("")` for pure-stopword queries, also when the query contains
only tokenising characters (e.g. punctuation). Does this make any difference?
# Tests
_TO DO!_
# Checklist
Please review the following and check all that apply:
- [ ] I have reviewed the guidelines for [How to
Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) 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
