Re: [PR] SOLR-17623: Simple ordered map should implement map [solr]
dsmiley commented on PR #3048: URL: https://github.com/apache/solr/pull/3048#issuecomment-2621748542 > Wouldn't it be a better approach just to override asShallowMap in SimpleOrderedMap and return itself? :face-palm: of course; wow I have no excuse for myself. Not enough coffee maybe. > Additionally,I have noticed that org.apache.solr.common.util.NamedList#asShallowMap(boolean) is not called outside NamedList, do we want to set it to private? **Separately** in another issue/pr, NamedList needs some more attention around this and toMap. Definitely deprecating that 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-17438) releaseWizard: remove refs to people.apache.org/home.apache.org
[ https://issues.apache.org/jira/browse/SOLR-17438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17922089#comment-17922089 ] Jan Høydahl commented on SOLR-17438: [~dsmiley] I know ASF have disabled personal home folders and ssh login to the home.apache.org server. However, I cannot find a reference to any decommission of the entire server. The wizard uses it to lookup gpg key be committer id, and that still works, and the entire "phonebook" is still there. Do you have a link to more information about decommissioning of this server? > releaseWizard: remove refs to people.apache.org/home.apache.org > --- > > Key: SOLR-17438 > URL: https://issues.apache.org/jira/browse/SOLR-17438 > Project: Solr > Issue Type: Task > Components: release-scripts >Reporter: David Smiley >Assignee: Jan Høydahl >Priority: Blocker > > The ASF is turning off home.apache.org on September 12th for good. Thus the > release wizard should stop using it to get your key in configure_pgp() -- > https://home.apache.org/keys/committer/%s.asc > FYI see the Lucene [issue|https://github.com/apache/lucene/issues/13647] -- 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] Fix TestReplicationHandler [solr]
HoustonPutman commented on PR #3142: URL: https://github.com/apache/solr/pull/3142#issuecomment-2622059853 @dsmiley do you have any opinion on adding the snapshot directories to the filter? -- 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] chore(deps): update dependency com.google.code.gson:gson to v2.12.0 [solr]
solrbot opened a new pull request, #3143: URL: https://github.com/apache/solr/pull/3143 This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [com.google.code.gson:gson](https://redirect.github.com/google/gson) | dependencies | minor | `2.11.0` -> `2.12.0` | --- ### Configuration 📅 **Schedule**: Branch creation - "* * * * *" (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 this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://redirect.github.com/solrbot/renovate-github-action) -- 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-17504) CoreContainer calls UpdateHandler.commit
[ https://issues.apache.org/jira/browse/SOLR-17504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17922006#comment-17922006 ] Bruno Roustant commented on SOLR-17504: --- Thanks Houston > CoreContainer calls UpdateHandler.commit > > > Key: SOLR-17504 > URL: https://issues.apache.org/jira/browse/SOLR-17504 > Project: Solr > Issue Type: Improvement >Reporter: Bruno Roustant >Assignee: Bruno Roustant >Priority: Major > Labels: pull-request-available > Fix For: 9.8 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > ... and DirectUpdateHandler2.closeWriter supports commit metadata. > This proposal is about unifying calls to UpdateHandler.commit. > CoreContainer.reload may call directly IndexWriter.commit if the core to > reload is readonly (property of the Collection). This is an issue because it > bypasses some logic in UpdateHandler.commit. In addition, the current code > commits without taking the commit lock. > DirectUpdateHandler2.closeWriter may commit if the update log is not empty > (not committed yet). But it does not call DirectUpdateHandler2.commit(), it > copies commit() code instead for some reasons (comments in the code mention > test failures). The proposal is to add the same call to > DirectUpdateHandler2.shouldCommit() as in the commit() method, otherwise > commit metadata are lost. In addition shouldCommit() can be extended > correctly, for example in the solr-sandbox encryption module which needs to > intercept calls to shouldCommit(). -- 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-17623: Simple ordered map should implement map [solr]
renatoh commented on PR #3048: URL: https://github.com/apache/solr/pull/3048#issuecomment-2620972046 > As part of this PR, let's have NamedList.asShallowMap do an instanceof check for Map and return it if so. That will lead to real usage / code coverage of the changes you've done. Wouldn't it be a better approach just to override asShallowMap in SimpleOrderedMap and return itself? Additionally,I have noticed that org.apache.solr.common.util.NamedList#asShallowMap(boolean) is not called outside NamedList, do we want to set it to private? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. 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: [I] Use custom name for the ServiceAccount of Zookeeper operator [solr-operator]
vesk0win closed issue #750: Use custom name for the ServiceAccount of Zookeeper operator URL: https://github.com/apache/solr-operator/issues/750 -- 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: [I] Use custom name for the ServiceAccount of Zookeeper operator [solr-operator]
vesk0win commented on issue #750: URL: https://github.com/apache/solr-operator/issues/750#issuecomment-2621005805 thanks, i tried it out and it works! -- 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-17637: Fix LBHttpSolrClient & HttpShardHandler bug [solr]
markrmiller commented on PR #3147: URL: https://github.com/apache/solr/pull/3147#issuecomment-2623245074 Nice catch. Patch looks good. -- 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] SolrRequest.getParams never null; and clarify mutability [solr]
dsmiley commented on code in PR #3140: URL: https://github.com/apache/solr/pull/3140#discussion_r1934921025 ## solr/solrj/src/java/org/apache/solr/client/solrj/request/DirectXmlRequest.java: ## @@ -20,13 +20,15 @@ import org.apache.solr.client.solrj.request.RequestWriter.StringPayloadContentWriter; import org.apache.solr.client.solrj.response.UpdateResponse; import org.apache.solr.client.solrj.util.ClientUtils; +import org.apache.solr.common.params.ModifiableSolrParams; import org.apache.solr.common.params.SolrParams; /** * Send arbitrary XML to a request handler * * @since solr 1.3 */ +@Deprecated Review Comment: I want to consolidate deprecations elsewhere so I will remove this change from the PR. We can discuss when I post that. -- 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] SolrRequest.getParams never null; and clarify mutability [solr]
dsmiley commented on code in PR #3140:
URL: https://github.com/apache/solr/pull/3140#discussion_r1934927357
##
solr/solrj/src/java/org/apache/solr/common/params/SolrParams.java:
##
@@ -526,4 +526,9 @@ public String toString() {
}
return sb.toString();
}
+
+ /** An empty, immutable SolrParams. */
+ public static SolrParams of() {
Review Comment:
Coincidentally I recently had the same conversation for the new
SimpleOrderedMap.of.It's modelled off JDK data structure utilities using
this name, thus its consistent. Once we see additional overloads, I think
you'll like it better. I could add one or two in this PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
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] SolrRequest.getParams never null; and clarify mutability [solr]
dsmiley commented on code in PR #3140:
URL: https://github.com/apache/solr/pull/3140#discussion_r1934925281
##
solr/modules/cross-dc/src/java/org/apache/solr/crossdc/common/MirroredSolrRequest.java:
##
@@ -247,10 +246,10 @@ public boolean equals(final Object o) {
}
public static void setParams(SolrRequest request, ModifiableSolrParams
params) {
-if (request instanceof MirroredAdminRequest) {
- ((MirroredAdminRequest) request).setParams(params);
-} else if (request instanceof UpdateRequest) {
- ((UpdateRequest) request).setParams(params);
+if (request instanceof MirroredAdminRequest mReq) {
Review Comment:
yeah it's a very nice Java 16 thing
--
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-17306) Solr Repeater or Slave loses data after restart when replication is not enabled on leader
[
https://issues.apache.org/jira/browse/SOLR-17306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17922202#comment-17922202
]
ASF subversion and git services commented on SOLR-17306:
Commit 22706cd3d9da0f6a73a3d6004f583add5a5e1992 in solr's branch
refs/heads/branch_9x from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=22706cd3d9d ]
Fix TestReplicationHandler (#3142)
Addresses a combination of SOLR-17306 and SOLR-17548.
(cherry picked from commit a5b0b98a79559021e44d00b43fff6c020c54f829)
> Solr Repeater or Slave loses data after restart when replication is not
> enabled on leader
> -
>
> Key: SOLR-17306
> URL: https://issues.apache.org/jira/browse/SOLR-17306
> Project: Solr
> Issue Type: Bug
>Affects Versions: 9.2, 9.3, 9.4, 9.5, 9.6
>Reporter: Peter Kroiss
>Assignee: Eric Pugh
>Priority: Major
> Labels: pull-request-available
> Fix For: 9.8
>
> Attachments: solr-replication-test.txt
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> We are testing Solr 9.6.2 in a leader - repeater - follower configuration. We
> have times where we write the leader heavily, in that time replication is
> disabled to save bandwidth.
> In the time, when replication is disabled on leader, the repeater restarts
> for some reason, the repeater loses all documents and doesn't recover when
> the leader is opened for replication.
> The documents are deleted but indexVersion and generation properties are set
> to the value of the leader, so the repeater or follower doesn't recover when
> the leader is opened for replication again.
> It recovers only when there are commits on the leader after opening the
> replication.
> Log:
> 2024-05-22 06:18:42.186 INFO (qtp16373883-27-null-23) [c: s: r: x:mycore
> t:null-23] o.a.s.c.S.Request webapp=/solr path=/replication
> params=\{wt=json&command=details} status=0 QTime=10
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Leader's generation: 0
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Leader's version: 0
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Follower's generation: 2913
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Follower's version: 1716300697144
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher New index in Leader. Deleting mine...
>
> --> there is no new Index in Leader it is only closed for replication
>
>
> We think the problem is in IndexFetcher
> old: if (IndexDeletionPolicyWrapper.getCommitTimestamp(commit) != 0L) {
> forceReplication - will probably fix the problem
> new : if (forceReplication &&
> IndexDeletionPolicyWrapper.getCommitTimestamp(commit) != 0L) {
>
>
>
>
> When investigation the problem we also found some inconsistencies in the
> details request. There are two fragments leader. When the leader is closed
> for replication the property leader. replicationEnabled is set to true, the
> property follower. leaderDetails. Leader. replicationEnabled is correct.
>
> Example
> curl -s
> "https://solr9-repeater:8983/solr/mycore/replication?wt=json&command=details";
> | jq '.details |
> { indexSize: .indexSize, indexVersion: .indexVersion, generation:
> .generation, indexPath: .indexPath, leader: \\{ replicableVersion:
> .leader.replicableVersion, replicableGeneration:
> .leader.replicableGeneration, replicationEnabled: .leader.replicationEnabled }
> ,
> follower: { leaderDetails: { indexSize: .follower.leaderDetails.indexSize,
> generation: .follower.leaderDetails.generation,
> indexVersion: .follower.leaderDetails.indexVersion, indexPath:
> .follower.leaderDetails.indexPath,
> leader:
> { replicableVersion: .follower.leaderDetails.leader.replicableVersion ,
> replicableGeneration: .follower.leaderDetails.leader.replicableGeneration,
> replicationEnabled: .follower.leaderDetails.leader.replicationEnabled }
> }}
> }'
>
> {
> "indexSize": "10.34 GB",
> "indexVersion": 1716358708159,
> "generation": 2913,
> "indexPath": "/var/solr/data/mycore/data/index.20240522061946262",
> "leader":
> { "replicableVersion": 1716358708159, "replicableGeneration": 2913,
> "replicationEnabled": "true" }
> ,
> "follower": {
> "leaderDetails": {
> "indexSize": "10.34 GB",
> "generation": 2913,
> "indexVersion": 1716358708159,
> "indexPath": "/var/solr/data/mycore/data/restore.20240508131046932",
> "leader":
> { "replicableVersion": 1716
[jira] [Commented] (SOLR-17548) Switch all public Java APIs from File to Path
[ https://issues.apache.org/jira/browse/SOLR-17548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17922203#comment-17922203 ] ASF subversion and git services commented on SOLR-17548: Commit 22706cd3d9da0f6a73a3d6004f583add5a5e1992 in solr's branch refs/heads/branch_9x from Houston Putman [ https://gitbox.apache.org/repos/asf?p=solr.git;h=22706cd3d9d ] Fix TestReplicationHandler (#3142) Addresses a combination of SOLR-17306 and SOLR-17548. (cherry picked from commit a5b0b98a79559021e44d00b43fff6c020c54f829) > Switch all public Java APIs from File to Path > - > > Key: SOLR-17548 > URL: https://issues.apache.org/jira/browse/SOLR-17548 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: David Smiley >Priority: Major > Labels: newdev, pull-request-available > Fix For: main (10.0) > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Change all java.io.File parameters (and return types) of publicly visible > methods/constructors to java.nio.file.Path. > It's acceptable to simply do type conversion back/forth; the conversion could > happen whenever. And it's also acceptable to only do non-tests. The scope > is limited here so as to make this achievable for Solr 10 without much work. -- 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-XXXXX: Support different filesystem implementations with EmbeddedSolrServer [solr]
AndreyBozhko commented on code in PR #3146:
URL: https://github.com/apache/solr/pull/3146#discussion_r1934788370
##
solr/core/src/test/org/apache/solr/client/solrj/embedded/TestEmbeddedSolrServerConstructors.java:
##
@@ -58,4 +63,63 @@ public void testNodeConfigConstructor() throws Exception {
assertEquals(1, server.query("newcore", new
SolrQuery("*:*")).getResults().getNumFound());
}
}
+
+ @SuppressWarnings("removal")
+ @Test
+ public void testPathConstructorZipFS() throws Exception {
+assumeTrue(
+"""
+Test only works without Security Manager due to
SecurityConfHandlerLocal
+missing permission to read /1/2/3/4/security.json file""",
+System.getSecurityManager() == null);
Review Comment:
To make the test work regardless of the security manager, this line
https://github.com/apache/solr/blob/a5b0b98a79559021e44d00b43fff6c020c54f829/solr/core/src/java/org/apache/solr/handler/admin/SecurityConfHandlerLocal.java#L43
needs to be updated to handle Path in a more idiomatic way.
However, that requires updating CoreContainer#getSolrHome to return a Path
instead of a String - so it looks like a much bigger change.
--
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-17151) Review current usage of QueryLimits to ensure complete coverage
[
https://issues.apache.org/jira/browse/SOLR-17151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17922240#comment-17922240
]
Houston Putman commented on SOLR-17151:
---
I think a small here opened up a pretty big error in the LBSolrClient, that
propagates to the HttpShardHandler.
In this ticket, when checking the previous exception,
{{previousEx.getMessage().contains("Limits exceeded!")}} is used to check
something. If the previousEx doesn't have a message, this throws a
NullPointerException.
In {{LBHttp2SolrClient}}, when choosing the next server to try, only
{{SolrServerException}} is caught and used to complete the future. Since
{{NullPointerException}} is not a {{SolrServerException}}, the exception
finished the listener callback, but doesn't complete the {{apiFuture}}. This
means that {{HttpShardHandler}} will wait infinitely for a completion that it
will never receive.
I will file another JIRA, and we should probably do a release to fix this bug.
> Review current usage of QueryLimits to ensure complete coverage
> ---
>
> Key: SOLR-17151
> URL: https://issues.apache.org/jira/browse/SOLR-17151
> Project: Solr
> Issue Type: Sub-task
> Components: Query Limits
>Reporter: Andrzej Bialecki
>Assignee: Gus Heck
>Priority: Major
> Labels: pull-request-available
> Fix For: main (10.0), 9.8
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Resource usage by a query is not limited to the actual search within
> {{QueryComponent}}. Other components invoked by {{SearchHandler}} may
> significantly contribute to this usage, either before or after the
> {{QueryComponent}}.
> Those components that already use {{QueryTimeout}} either directly or
> indirectly will properly observe the limits and terminate if needed. However,
> other components may be expensive or misbehaving but fail to observe the
> limits imposed on the end-to-end query processing.
> One such obvious place where we could add this check is where the
> {{SearchHandler}} loops over {{SearchComponent}-s - it should call explicitly
> {{QueryLimits.shouldExit()}} to ensure that even if previously executed
> component ignored the limits they will be still enforced at the
> {{SearchHandler}} level. There may be other places like this, too.
--
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-17637) HttpShardHandler can wait indefinitely when retrying after certain failures
Houston Putman created SOLR-17637: - Summary: HttpShardHandler can wait indefinitely when retrying after certain failures Key: SOLR-17637 URL: https://issues.apache.org/jira/browse/SOLR-17637 Project: Solr Issue Type: Bug Affects Versions: 9.8 Reporter: Houston Putman If a The LBHttp2SolrClient is used to do an asynchronous request, then any error that has a null message can result in that request not having its future completed. The HttpShardHandler loops indefinitely until all responses have been processed. So if a future is not completed, then its response will not be added to the list. -- 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-17637: Fix LBHttpSolrClient & HttpShardHandler bug [solr]
dsmiley commented on PR #3147: URL: https://github.com/apache/solr/pull/3147#issuecomment-2623522751 Just curious; I suppose this bug might show as an NPE? -- 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] SolrRequest.getParams never null; and clarify mutability [solr]
dsmiley commented on code in PR #3140:
URL: https://github.com/apache/solr/pull/3140#discussion_r1935063818
##
solr/solrj/src/java/org/apache/solr/client/solrj/request/AbstractUpdateRequest.java:
##
@@ -21,10 +21,9 @@
import org.apache.solr.common.params.ModifiableSolrParams;
import org.apache.solr.common.params.UpdateParams;
-/** */
public abstract class AbstractUpdateRequest extends
CollectionRequiringSolrRequest
implements IsUpdateRequest {
- protected ModifiableSolrParams params;
+ protected ModifiableSolrParams params = new ModifiableSolrParams(); // TODO
make final
Review Comment:
It's easy for me to enforce that setParams arg isn't null. I'll do that.
setParams is called kinda a lot BTW, although I feel it's usually not needed.
I can do a follow-up draft PR to show you what it looks like if *nobody* calls
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
Re: [PR] SOLR-17637: Fix LBHttpSolrClient & HttpShardHandler bug [solr]
HoustonPutman commented on PR #3147: URL: https://github.com/apache/solr/pull/3147#issuecomment-2623621771 > Just curious; I suppose this bug might show as an NPE? It doesnt show at all. The thread thats running the async request fails, and since its not in the catch, it doesnt pass the exception to the completion step. So the thread just goes away without logging anything. Took a while to pin it down because of 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
Re: [PR] SolrRequest.getParams never null; and clarify mutability [solr]
gerlowskija commented on code in PR #3140:
URL: https://github.com/apache/solr/pull/3140#discussion_r1934494649
##
solr/solrj/src/java/org/apache/solr/client/solrj/request/AbstractUpdateRequest.java:
##
@@ -21,10 +21,9 @@
import org.apache.solr.common.params.ModifiableSolrParams;
import org.apache.solr.common.params.UpdateParams;
-/** */
public abstract class AbstractUpdateRequest extends
CollectionRequiringSolrRequest
implements IsUpdateRequest {
- protected ModifiableSolrParams params;
+ protected ModifiableSolrParams params = new ModifiableSolrParams(); // TODO
make final
Review Comment:
+1 to make this `final`. Otherwise it's tough to rely on the field being
non-null, since the signature/contract lets folks set it to null.
That's my main concern about this PR in general - I love that we're saying
that `SolrRequest.getParams()` always returns non-null. But I'm unsure how
much confidence we can have in that guarantee while some SolrRequest
implementations offer a `setParams(...)` method that would allow any SolrJ user
to break that promise (in their client side code at least). Maybe javadocs on
the `setParams(...)` methods is enough to address that? Or maybe something
else in this PR already addresses that and I've just missed it?
##
solr/core/src/java/org/apache/solr/handler/api/V2ApiUtils.java:
##
@@ -91,9 +91,6 @@ public static void squashIntoNamedListWithoutHeader(
}
public static String getMediaTypeFromWtParam(SolrParams params, String
defaultMediaType) {
-if (params == null) {
Review Comment:
The null-check is still needed here, I think. Some callers of this method
(e.g. MediaTypeOverridingFilter) may not have a SolrParams to pass in (because
they don't have a SolrQueryRequest at all).
If we really want to remove the null-check here, we can, but we'd need to
also go into some of those call-sites and ensure they're passing in an empty
SolrParams where necessary.
I guess those call-sites could check for that case and pass in a
`SolrParams.of()`, but we can't remove the null check here without that.
##
solr/modules/cross-dc/src/java/org/apache/solr/crossdc/common/MirroredSolrRequest.java:
##
@@ -247,10 +246,10 @@ public boolean equals(final Object o) {
}
public static void setParams(SolrRequest request, ModifiableSolrParams
params) {
-if (request instanceof MirroredAdminRequest) {
- ((MirroredAdminRequest) request).setParams(params);
-} else if (request instanceof UpdateRequest) {
- ((UpdateRequest) request).setParams(params);
+if (request instanceof MirroredAdminRequest mReq) {
Review Comment:
[+1] I haven't seen this instanceof-and-declare-variable syntax before -
very cool!
##
solr/solrj/src/java/org/apache/solr/common/params/SolrParams.java:
##
@@ -526,4 +526,9 @@ public String toString() {
}
return sb.toString();
}
+
+ /** An empty, immutable SolrParams. */
+ public static SolrParams of() {
Review Comment:
[0] When I see `of()` it reminds me of the various var-arg methods with the
same name that Java's "Collections" classes offer
([List.of](https://docs.oracle.com/javase/9/docs/api/java/util/List.html#of--)).
It's a little jarring to see that we don't accept any args here, and that
this is only for creating empty param-sets. Maybe a name like `emptyParams()`
or `empty()` would convey things more accurately?
##
solr/solrj/src/java/org/apache/solr/client/solrj/request/DirectXmlRequest.java:
##
@@ -20,13 +20,15 @@
import
org.apache.solr.client.solrj.request.RequestWriter.StringPayloadContentWriter;
import org.apache.solr.client.solrj.response.UpdateResponse;
import org.apache.solr.client.solrj.util.ClientUtils;
+import org.apache.solr.common.params.ModifiableSolrParams;
import org.apache.solr.common.params.SolrParams;
/**
* Send arbitrary XML to a request handler
*
* @since solr 1.3
*/
+@Deprecated
Review Comment:
Happy to look the other way in terms of you sneaking a tiny deprecation into
this PR.
But if we're deprecating we should probably also put a user-friendly note
somewhere so that folks have a sense why this went away, and what they should
use instead.
(Not sure where that note should go: in CHANGES.txt's deprecation section?
as a PR comment? in the code itself near this annotation?)
--
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-17438 Resolve committer GPG key from other source [solr]
madrob commented on PR #3145: URL: https://github.com/apache/solr/pull/3145#issuecomment-2622778263 I've heard rumblings that this data is going to move away from whimsy and onto infra-reports.a.o, so it may behoove us to wait a bit instead of switching now and then switching again. @dfoulks1 is working on that, he said he can follow up with us about it next week. -- 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-17623: Simple ordered map should implement map [solr]
renatoh commented on PR #3048: URL: https://github.com/apache/solr/pull/3048#issuecomment-2622942999 > have a slight concern if there's existing code relying on quirky sad behaviors of NamedList.asShallowMap having weird/sad implementations of `keySet`, `values`, `entrySet` because it calls `asMap(1)` on them. Had it been `asMap(0)`, probably lower/no concern. _Maybe_ this change should be in Solr 10 only. On the other hand... maybe it's an unlikely impact? Hard to say... right away I see SolrXmlConfig calling `.asShallowMap().entrySet()`. Isn't SolrXmlConfig always calling .asShallowMap on a NamedList, which is create org.apache.solr.common.ConfigNode#forEachChild? So the changes do not make a difference here, or do they? -- 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-17637) HttpShardHandler can wait indefinitely when retrying after certain failures
[
https://issues.apache.org/jira/browse/SOLR-17637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17922242#comment-17922242
]
Houston Putman commented on SOLR-17637:
---
I believe this will fix a lot of the {{TestCoordinatorRole.testNRTRestart}}
failures, but we will have to see after merging.
> HttpShardHandler can wait indefinitely when retrying after certain failures
> ---
>
> Key: SOLR-17637
> URL: https://issues.apache.org/jira/browse/SOLR-17637
> Project: Solr
> Issue Type: Bug
>Affects Versions: 9.8
>Reporter: Houston Putman
>Priority: Critical
>
> If a The LBHttp2SolrClient is used to do an asynchronous request, then any
> error that has a null message can result in that request not having its
> future completed. The HttpShardHandler loops indefinitely until all responses
> have been processed. So if a future is not completed, then its response will
> not be added to the list.
--
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-17637) HttpShardHandler can wait indefinitely when retrying after certain failures
[ https://issues.apache.org/jira/browse/SOLR-17637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17637: -- Labels: pull-request-available (was: ) > HttpShardHandler can wait indefinitely when retrying after certain failures > --- > > Key: SOLR-17637 > URL: https://issues.apache.org/jira/browse/SOLR-17637 > Project: Solr > Issue Type: Bug >Affects Versions: 9.8 >Reporter: Houston Putman >Priority: Critical > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > If a The LBHttp2SolrClient is used to do an asynchronous request, then any > error that has a null message can result in that request not having its > future completed. The HttpShardHandler loops indefinitely until all responses > have been processed. So if a future is not completed, then its response will > not be added to the list. -- 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
[PR] SOLR-17637: Fix LBHttpSolrClient & HttpShardHandler bug [solr]
HoustonPutman opened a new pull request, #3147: URL: https://github.com/apache/solr/pull/3147 https://issues.apache.org/jira/browse/SOLR-17637 -- 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] SOLR-XXXXX: Support different filesystem implementations with EmbeddedSolrServer [solr]
AndreyBozhko opened a new pull request, #3146: URL: https://github.com/apache/solr/pull/3146 https://issues.apache.org/jira/browse/SOLR-X # Description EmbeddedSolrServer has a public constructor `EmbeddedSolrServer(Path solrHome, String defaultCoreName)` - which suggests that any Path implementation is acceptable (e.g., ZipPath, S3Path, and not just UnixPath/WindowsPath). # Solution Updated ManagedIndexSchemaFactory code that deals with schema paths to be more idiomatic. # Tests Added a test for instantiating EmbeddedSolrServer using a ZipPath instance. # Checklist Please review the following and check all that apply: - [x] 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. - [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, not available for branches on forks living under an organisation) - [x] I have developed this patch against the `main` branch. - [x] I have run `./gradlew check`. - [x] 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
Re: [PR] SOLR-17492: Introduce recommendations of WAYS of running Solr from small to massive [solr]
github-actions[bot] commented on PR #2783: URL: https://github.com/apache/solr/pull/2783#issuecomment-2623202990 This PR has had no activity for 60 days and is now labeled as stale. Any new activity will remove the stale label. To attract more reviewers, please tag people who might be familiar with the code area and/or notify the d...@solr.apache.org mailing list. To exempt this PR from being marked as stale, make it a draft PR or add the label "exempt-stale". If left unattended, this PR will be closed after another 60 days of inactivity. Thank you for your contribution! -- 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-XXXXX: Support different filesystem implementations with EmbeddedSolrServer [solr]
madrob commented on code in PR #3146:
URL: https://github.com/apache/solr/pull/3146#discussion_r1934824591
##
solr/core/src/java/org/apache/solr/schema/ManagedIndexSchemaFactory.java:
##
@@ -148,12 +147,11 @@ public String lookupZKManagedSchemaPath() {
*/
public Path lookupLocalManagedSchemaPath() {
final Path legacyManagedSchemaPath =
-Paths.get(
Review Comment:
We should try to remove usages of Paths.get generally, I remember it having
some wonky behaviour in the past. Happy to see this coming in.
--
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 TestReplicationHandler [solr]
mlbiscoc commented on PR #3142: URL: https://github.com/apache/solr/pull/3142#issuecomment-2623119702 > @mlbiscoc I should have reminded/and or run the nightly tests when I was reviewing the path stuff.. Let's remember to do that as we continue! Got it. Thanks @HoustonPutman for fixing the regression! -- 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-17548) Switch all public Java APIs from File to Path
[ https://issues.apache.org/jira/browse/SOLR-17548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17922210#comment-17922210 ] ASF subversion and git services commented on SOLR-17548: Commit b2cf5abf13f303d0e16df05b06e00ceed3828a98 in solr's branch refs/heads/branch_9_8 from Houston Putman [ https://gitbox.apache.org/repos/asf?p=solr.git;h=b2cf5abf13f ] Fix TestReplicationHandler (#3142) Addresses a combination of SOLR-17306 and SOLR-17548. (cherry picked from commit a5b0b98a79559021e44d00b43fff6c020c54f829) > Switch all public Java APIs from File to Path > - > > Key: SOLR-17548 > URL: https://issues.apache.org/jira/browse/SOLR-17548 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: David Smiley >Priority: Major > Labels: newdev, pull-request-available > Fix For: main (10.0) > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Change all java.io.File parameters (and return types) of publicly visible > methods/constructors to java.nio.file.Path. > It's acceptable to simply do type conversion back/forth; the conversion could > happen whenever. And it's also acceptable to only do non-tests. The scope > is limited here so as to make this achievable for Solr 10 without much work. -- 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-17306) Solr Repeater or Slave loses data after restart when replication is not enabled on leader
[
https://issues.apache.org/jira/browse/SOLR-17306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17922209#comment-17922209
]
ASF subversion and git services commented on SOLR-17306:
Commit b2cf5abf13f303d0e16df05b06e00ceed3828a98 in solr's branch
refs/heads/branch_9_8 from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=b2cf5abf13f ]
Fix TestReplicationHandler (#3142)
Addresses a combination of SOLR-17306 and SOLR-17548.
(cherry picked from commit a5b0b98a79559021e44d00b43fff6c020c54f829)
> Solr Repeater or Slave loses data after restart when replication is not
> enabled on leader
> -
>
> Key: SOLR-17306
> URL: https://issues.apache.org/jira/browse/SOLR-17306
> Project: Solr
> Issue Type: Bug
>Affects Versions: 9.2, 9.3, 9.4, 9.5, 9.6
>Reporter: Peter Kroiss
>Assignee: Eric Pugh
>Priority: Major
> Labels: pull-request-available
> Fix For: 9.8
>
> Attachments: solr-replication-test.txt
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> We are testing Solr 9.6.2 in a leader - repeater - follower configuration. We
> have times where we write the leader heavily, in that time replication is
> disabled to save bandwidth.
> In the time, when replication is disabled on leader, the repeater restarts
> for some reason, the repeater loses all documents and doesn't recover when
> the leader is opened for replication.
> The documents are deleted but indexVersion and generation properties are set
> to the value of the leader, so the repeater or follower doesn't recover when
> the leader is opened for replication again.
> It recovers only when there are commits on the leader after opening the
> replication.
> Log:
> 2024-05-22 06:18:42.186 INFO (qtp16373883-27-null-23) [c: s: r: x:mycore
> t:null-23] o.a.s.c.S.Request webapp=/solr path=/replication
> params=\{wt=json&command=details} status=0 QTime=10
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Leader's generation: 0
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Leader's version: 0
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Follower's generation: 2913
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Follower's version: 1716300697144
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher New index in Leader. Deleting mine...
>
> --> there is no new Index in Leader it is only closed for replication
>
>
> We think the problem is in IndexFetcher
> old: if (IndexDeletionPolicyWrapper.getCommitTimestamp(commit) != 0L) {
> forceReplication - will probably fix the problem
> new : if (forceReplication &&
> IndexDeletionPolicyWrapper.getCommitTimestamp(commit) != 0L) {
>
>
>
>
> When investigation the problem we also found some inconsistencies in the
> details request. There are two fragments leader. When the leader is closed
> for replication the property leader. replicationEnabled is set to true, the
> property follower. leaderDetails. Leader. replicationEnabled is correct.
>
> Example
> curl -s
> "https://solr9-repeater:8983/solr/mycore/replication?wt=json&command=details";
> | jq '.details |
> { indexSize: .indexSize, indexVersion: .indexVersion, generation:
> .generation, indexPath: .indexPath, leader: \\{ replicableVersion:
> .leader.replicableVersion, replicableGeneration:
> .leader.replicableGeneration, replicationEnabled: .leader.replicationEnabled }
> ,
> follower: { leaderDetails: { indexSize: .follower.leaderDetails.indexSize,
> generation: .follower.leaderDetails.generation,
> indexVersion: .follower.leaderDetails.indexVersion, indexPath:
> .follower.leaderDetails.indexPath,
> leader:
> { replicableVersion: .follower.leaderDetails.leader.replicableVersion ,
> replicableGeneration: .follower.leaderDetails.leader.replicableGeneration,
> replicationEnabled: .follower.leaderDetails.leader.replicationEnabled }
> }}
> }'
>
> {
> "indexSize": "10.34 GB",
> "indexVersion": 1716358708159,
> "generation": 2913,
> "indexPath": "/var/solr/data/mycore/data/index.20240522061946262",
> "leader":
> { "replicableVersion": 1716358708159, "replicableGeneration": 2913,
> "replicationEnabled": "true" }
> ,
> "follower": {
> "leaderDetails": {
> "indexSize": "10.34 GB",
> "generation": 2913,
> "indexVersion": 1716358708159,
> "indexPath": "/var/solr/data/mycore/data/restore.20240508131046932",
> "leader":
> { "replicableVersion": 171
Re: [PR] SolrRequest.getParams never null; and clarify mutability [solr]
dsmiley commented on code in PR #3140:
URL: https://github.com/apache/solr/pull/3140#discussion_r1934914237
##
solr/core/src/java/org/apache/solr/handler/api/V2ApiUtils.java:
##
@@ -91,9 +91,6 @@ public static void squashIntoNamedListWithoutHeader(
}
public static String getMediaTypeFromWtParam(SolrParams params, String
defaultMediaType) {
-if (params == null) {
Review Comment:
Okay I'll remove. I suppose the scope of this PR should be more focused on
SolrJ QueryRequest not server side SolrQueryRequest. Granted, I'd wish for the
same for SolrQueryRequest.getParams; same rationale for doing it in SolrJ. I
_could_ increase the scope to that but maybe too much in one PR; not sure.
--
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] SOLR-17187: make replica poll interval configurable [solr]
cpoerschke opened a new pull request, #3144: URL: https://github.com/apache/solr/pull/3144 Continuation of @tboeghk's #2316 as a new pull request since pushing to the PR's branch is not possible (due to org vs. individual repo fork). * [X] merged in latest `origin/main` * [X] added (minimal) Solr Ref Guide update * [ ] added solr/CHANGES.txt entry https://issues.apache.org/jira/browse/SOLR-17187 -- 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-17187] Add possibility to supply a custom commitPollInterval for TLOG/PULL replicas [solr]
cpoerschke commented on PR #2316: URL: https://github.com/apache/solr/pull/2316#issuecomment-2622171632 Opened #3144 as a continuation of this pull request here since pushing to this PR's branch is not possible (due to org vs. individual repo fork). -- 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-17187) Make replica poll interval configurable
[ https://issues.apache.org/jira/browse/SOLR-17187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17922161#comment-17922161 ] Christine Poerschke commented on SOLR-17187: https://github.com/apache/solr/pull/3144 opened as a continuation of https://github.com/apache/solr/pull/2316 since pushing to the PR's branch is not possible (due to org vs. individual repo fork). > Make replica poll interval configurable > --- > > Key: SOLR-17187 > URL: https://issues.apache.org/jira/browse/SOLR-17187 > Project: Solr > Issue Type: Improvement > Components: replication (java), SolrCloud >Reporter: Torsten Bøgh Köster >Priority: Major > Labels: pull-request-available > Time Spent: 6h 10m > Remaining Estimate: 0h > > In TLOG/PULL replica setups with longer commit intervals it would be great to > configure the interval to check for new commits manually to tune to your > setup. > Currently on the PULL replica the interval to check for new commits is > computed using the commit / soft commit settings [1] > [1] > https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/cloud/ReplicateFromLeader.java#L83-L87 -- 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-17187: make replica poll interval configurable [solr]
epugh commented on code in PR #3144:
URL: https://github.com/apache/solr/pull/3144#discussion_r1934338854
##
solr/core/src/java/org/apache/solr/cloud/ReplicateFromLeader.java:
##
@@ -75,16 +75,9 @@ public void startReplication(boolean switchTransactionLog) {
"SolrCore not found:" + coreName + " in " +
CloudUtil.getLoadedCoreNamesAsString(cc));
}
}
- SolrConfig.UpdateHandlerInfo uinfo =
core.getSolrConfig().getUpdateHandlerInfo();
- String pollIntervalStr = "00:00:03";
- if (System.getProperty("jetty.testMode") != null) {
-pollIntervalStr = "00:00:01";
- }
- String calculatedPollIntervalString = determinePollInterval(uinfo);
- if (calculatedPollIntervalString != null) {
-pollIntervalStr = calculatedPollIntervalString;
- }
+ final SolrConfig.UpdateHandlerInfo uinfo =
core.getSolrConfig().getUpdateHandlerInfo();
+ final String pollIntervalStr = determinePollInterval(uinfo);
Review Comment:
this is nicer.
##
solr/core/src/java/org/apache/solr/cloud/ReplicateFromLeader.java:
##
@@ -134,18 +127,25 @@ public static String getCommitVersion(SolrCore solrCore) {
}
/**
- * Determine the poll interval for replicas based on the auto soft/hard
commit schedule
+ * Determine the poll interval for replicas based on the auto soft/hard
commit schedule or
+ * configured commit poll interval
*
* @param uinfo the update handler info containing soft/hard commit
configuration
* @return a poll interval string representing a cadence of polling
frequency in the form of
- * hh:mm:ss
+ * hh:mm:ss, never null
*/
public static String determinePollInterval(SolrConfig.UpdateHandlerInfo
uinfo) {
int hardCommitMaxTime = uinfo.autoCommmitMaxTime;
int softCommitMaxTime = uinfo.autoSoftCommmitMaxTime;
boolean hardCommitNewSearcher = uinfo.openSearcher;
-String pollIntervalStr = null;
-if (hardCommitMaxTime != -1) {
+String customCommitPollInterval = uinfo.commitPollInterval;
Review Comment:
with the comment about the never null, do we need some sort of `assert` in
here?
##
solr/core/src/java/org/apache/solr/cloud/ReplicateFromLeader.java:
##
@@ -134,18 +127,25 @@ public static String getCommitVersion(SolrCore solrCore) {
}
/**
- * Determine the poll interval for replicas based on the auto soft/hard
commit schedule
+ * Determine the poll interval for replicas based on the auto soft/hard
commit schedule or
+ * configured commit poll interval
*
* @param uinfo the update handler info containing soft/hard commit
configuration
* @return a poll interval string representing a cadence of polling
frequency in the form of
- * hh:mm:ss
+ * hh:mm:ss, never null
*/
public static String determinePollInterval(SolrConfig.UpdateHandlerInfo
uinfo) {
int hardCommitMaxTime = uinfo.autoCommmitMaxTime;
int softCommitMaxTime = uinfo.autoSoftCommmitMaxTime;
boolean hardCommitNewSearcher = uinfo.openSearcher;
-String pollIntervalStr = null;
-if (hardCommitMaxTime != -1) {
+String customCommitPollInterval = uinfo.commitPollInterval;
+String pollIntervalStr = "00:00:03";
+
+if (System.getProperty("jetty.testMode") != null) {
Review Comment:
are we still doing System.getProperty? I thought we had something else that
abstracted this away? So you could use a system property or a config file?
Maybe my imagination!
##
solr/core/src/test/org/apache/solr/cloud/ReplicateFromLeaderTest.java:
##
@@ -18,54 +18,105 @@
package org.apache.solr.cloud;
import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertThrows;
+import org.apache.solr.common.SolrException;
import org.apache.solr.core.SolrConfig;
+import org.junit.After;
+import org.junit.Before;
import org.junit.Test;
public class ReplicateFromLeaderTest {
+ private String jettyTestMode;
+
+ @Before
+ public void setUp() {
Review Comment:
don't we have some sort of Rule thing these days for this? @dsmiley ???
##
solr/core/src/java/org/apache/solr/handler/ReplicationHandler.java:
##
@@ -1485,7 +1486,8 @@ private Long readIntervalMs(String interval) {
return TimeUnit.MILLISECONDS.convert(readIntervalNs(interval),
TimeUnit.NANOSECONDS);
}
- private Long readIntervalNs(String interval) {
+ @VisibleForTesting
+ public static Long readIntervalNs(String interval) {
Review Comment:
do you need the `public` if you have `@VisibleForTesting`, or is that just
to remind us why it's public?
--
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
---
Re: [PR] SOLR-17623: Simple ordered map should implement map [solr]
renatoh commented on PR #3048: URL: https://github.com/apache/solr/pull/3048#issuecomment-2622011097 > **Separately** in another issue/pr, NamedList needs some more attention around this and toMap. Definitely deprecating that one. I interpreted you thumbs up on my comment early as OK for both of the issue mentioned, hence I committed and pushed it, was too quick:). Shall I revert 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-17379) ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
[
https://issues.apache.org/jira/browse/SOLR-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17922130#comment-17922130
]
Houston Putman commented on SOLR-17379:
---
I will add, the French date test only fails with the TestSecurityManager. With
the default security manager, we get the error logs printed above, but the
tests pass. Very strange. I even made a new SolrTestSecurityManager that does
nothing but extend java.lang.SecurityManager, and it swallows the errors and
fails, just like the Lucene TestSecurityManager. very very strange. There must
be some code somewhere that is looking for just the default SecurityManager.
The TestSecurityManager/SecurityManager differnce is strange and really makes
no sense, but the CLDR issue has been reported, and the openjdk maintainers see
no real reason to fix it since the security manager is being removed in Java
24. So there is no real way to fix this issue deep down without removing the
URLPermissions from our test security.policy, which doesn't seem realistic.
[https://bugs.openjdk.org/browse/JDK-8305346|https://bugs.openjdk.org/browse/JDK-8305346?attachmentOrder=desc]
Overall I think we should either disable the security manager for Solr 10,
because it's being removed in Java 24, or we should just use the default
SecurityMnaager for tests and try to swallow the errors so that we aren't
spammed with this unfixable bug.
> ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
>
>
> Key: SOLR-17379
> URL: https://issues.apache.org/jira/browse/SOLR-17379
> Project: Solr
> Issue Type: Test
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-17379.test-1.patch, SOLR-17379.test.patch
>
>
> Background: https://lists.apache.org/thread/o7xwz8df6j0bx7w2m3w8ptrp4r7q957n
> Test failures from {{ParsingFieldUpdateProcessorsTest.testAKSTZone}} and
> {{ParsingFieldUpdateProcessorsTest.testParseFrenchDate}} are seemingly
> guaranteed on JDK23, due to the removal of the {{COMPAT}} local provider
> option.
> On (some) earlier JDKs, these failures can be reproduced using...
> {noformat}
> ./gradlew test --tests ParsingFieldUpdateProcessorsTest
> -Ptests.jvmargs="-Djava.locale.providers=CLDR -XX:TieredStopAtLevel=1
> -XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
> {noformat}
> ...to force the use off {{CLDR}} and exclude the use of {{COMPAT}}
--
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-17623: Simple ordered map should implement map [solr]
dsmiley commented on code in PR #3048:
URL: https://github.com/apache/solr/pull/3048#discussion_r1934300672
##
solr/solrj/src/java/org/apache/solr/common/util/NamedList.java:
##
@@ -238,6 +238,14 @@ public int indexOf(String name, int start) {
return -1;
}
+ /***
+ * Scans the list sequentially beginning at index 0
Review Comment:
nitpick: javadoc should include clarity that it's the index of the name.
It's not great to require looking at a parameter's name to disambiguate the
meaning of a method.
##
solr/solrj/src/java/org/apache/solr/common/util/NamedList.java:
##
@@ -403,8 +411,8 @@ public Map asShallowMap() {
return asShallowMap(false);
}
- public Map asShallowMap(boolean allowDps) {
-return new Map() {
+ private Map asShallowMap(boolean allowDps) {
Review Comment:
now's not the time to make private but feel free to deprecate.
##
solr/solrj/src/java/org/apache/solr/common/util/NamedList.java:
##
@@ -845,7 +853,7 @@ public void forEachKey(Consumer fun) {
}
}
- public void forEach(BiConsumer action) {
+ public void forEach(BiConsumer action) {
Review Comment:
did doing this fix something? it's weird.
##
solr/solrj/src/java/org/apache/solr/common/util/SimpleOrderedMap.java:
##
@@ -68,24 +75,123 @@ public SimpleOrderedMap(Map.Entry[]
nameValuePairs) {
public SimpleOrderedMap clone() {
ArrayList newList = new ArrayList<>(nvPairs.size());
newList.addAll(nvPairs);
-return new SimpleOrderedMap<>(newList);
+return new SimpleOrderedMap(newList);
+ }
+
+ @Override
+ public boolean isEmpty() {
+return nvPairs.isEmpty();
+ }
+
+ @Override
+ public boolean containsKey(final Object key) {
+return this.indexOf((String) key) >= 0;
+ }
+
+ @Override
+ public boolean containsValue(final Object value) {
+return values().contains(value);
}
/**
- * Returns a shared, empty, and immutable instance of SimpleOrderedMap.
+ * {@inheritDoc}
+ *
+ * Has linear lookup time O(N)
*
- * @return Empty SimpleOrderedMap (immutable)
+ * @see NamedList#get(String)
*/
- public static SimpleOrderedMap of() {
-return EMPTY;
+ @Override
+ public T get(final Object key) {
+return super.get((String) key);
+ }
+
+ @Override
+ public T put(String key, T value) {
+int idx = indexOf(key);
+if (idx == -1) {
+ add(key, value);
+ return null;
+} else {
+ T t = get(key);
+ setVal(idx, value);
+ return t;
+}
}
/**
- * Returns an immutable instance of SimpleOrderedMap with a single key-value
pair.
+ * @see NamedList#remove(String)
+ */
+ @Override
+ public T remove(final Object key) {
+return super.remove((String) key);
+ }
+
+ @Override
+ public void putAll(final Map m) {
+if (isEmpty()) {
+ m.forEach(this::add);
+} else {
+ m.forEach(this::put);
+}
+ }
+
+ @Override
+ public Map asShallowMap() {
Review Comment:
nitpick but place this up above implementing Map interfaces rather than
arbitrarily somewhere in the middle.
--
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-17438) releaseWizard: remove refs to people.apache.org/home.apache.org
[ https://issues.apache.org/jira/browse/SOLR-17438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17438: -- Labels: pull-request-available (was: ) > releaseWizard: remove refs to people.apache.org/home.apache.org > --- > > Key: SOLR-17438 > URL: https://issues.apache.org/jira/browse/SOLR-17438 > Project: Solr > Issue Type: Task > Components: release-scripts >Reporter: David Smiley >Assignee: Jan Høydahl >Priority: Blocker > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The ASF is turning off home.apache.org on September 12th for good. Thus the > release wizard should stop using it to get your key in configure_pgp() -- > https://home.apache.org/keys/committer/%s.asc > FYI see the Lucene [issue|https://github.com/apache/lucene/issues/13647] -- 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
[PR] SOLR-17438 Resolve committer GPG key from other source [solr]
janhoy opened a new pull request, #3145: URL: https://github.com/apache/solr/pull/3145 https://issues.apache.org/jira/browse/SOLR-17438 -- 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-17379) ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
[
https://issues.apache.org/jira/browse/SOLR-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17922155#comment-17922155
]
David Smiley commented on SOLR-17379:
-
I didn't know Lucene had a special TestSecurityManager. Looking at its
javadocs, it exists only to prevent a test calling System.exit. Wow; what a
heavy-handed solution to a non-problem in practice (I say naively without
looking deeper at the situation that led to this). +1 to use the standard one
in tests.
We can discuss non-test in the existing thread(s) on the dev list about the
SecurityManager.
> ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
>
>
> Key: SOLR-17379
> URL: https://issues.apache.org/jira/browse/SOLR-17379
> Project: Solr
> Issue Type: Test
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-17379.test-1.patch, SOLR-17379.test.patch
>
>
> Background: https://lists.apache.org/thread/o7xwz8df6j0bx7w2m3w8ptrp4r7q957n
> Test failures from {{ParsingFieldUpdateProcessorsTest.testAKSTZone}} and
> {{ParsingFieldUpdateProcessorsTest.testParseFrenchDate}} are seemingly
> guaranteed on JDK23, due to the removal of the {{COMPAT}} local provider
> option.
> On (some) earlier JDKs, these failures can be reproduced using...
> {noformat}
> ./gradlew test --tests ParsingFieldUpdateProcessorsTest
> -Ptests.jvmargs="-Djava.locale.providers=CLDR -XX:TieredStopAtLevel=1
> -XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
> {noformat}
> ...to force the use off {{CLDR}} and exclude the use of {{COMPAT}}
--
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
[PR] SOLR-?????: make Lucene's BPReorderingMergePolicy configurable in Solr [solr]
cpoerschke opened a new pull request, #2641: URL: https://github.com/apache/solr/pull/2641 https://github.com/apache/lucene/pull/12622 in Lucene 9.9 added a `BPReorderingMergePolicy` and the changes in this PR are to make it configurable in Solr. TODO list: - [ ] create JIRA issue if this is interesting, useful, etc. - [ ] add solr/CHANGES.txt entry (new feature?) - [ ] ??? related issues: - https://github.com/apache/lucene/issues/12665 - https://github.com/apache/lucene/issues/13565 -- 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] [Created] (SOLR-17636) add BPReorderingMergePolicyFactory class
Christine Poerschke created SOLR-17636:
--
Summary: add BPReorderingMergePolicyFactory class
Key: SOLR-17636
URL: https://issues.apache.org/jira/browse/SOLR-17636
Project: Solr
Issue Type: Task
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Factory class for the {{BPReorderingMergePolicy}} added in Lucene 9.9 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-17548) Switch all public Java APIs from File to Path
[ https://issues.apache.org/jira/browse/SOLR-17548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17922183#comment-17922183 ] ASF subversion and git services commented on SOLR-17548: Commit a5b0b98a79559021e44d00b43fff6c020c54f829 in solr's branch refs/heads/main from Houston Putman [ https://gitbox.apache.org/repos/asf?p=solr.git;h=a5b0b98a795 ] Fix TestReplicationHandler (#3142) Addresses a combination of SOLR-17306 and SOLR-17548. > Switch all public Java APIs from File to Path > - > > Key: SOLR-17548 > URL: https://issues.apache.org/jira/browse/SOLR-17548 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: David Smiley >Priority: Major > Labels: newdev, pull-request-available > Fix For: main (10.0) > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Change all java.io.File parameters (and return types) of publicly visible > methods/constructors to java.nio.file.Path. > It's acceptable to simply do type conversion back/forth; the conversion could > happen whenever. And it's also acceptable to only do non-tests. The scope > is limited here so as to make this achievable for Solr 10 without much work. -- 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-17306) Solr Repeater or Slave loses data after restart when replication is not enabled on leader
[
https://issues.apache.org/jira/browse/SOLR-17306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17922182#comment-17922182
]
ASF subversion and git services commented on SOLR-17306:
Commit a5b0b98a79559021e44d00b43fff6c020c54f829 in solr's branch
refs/heads/main from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=a5b0b98a795 ]
Fix TestReplicationHandler (#3142)
Addresses a combination of SOLR-17306 and SOLR-17548.
> Solr Repeater or Slave loses data after restart when replication is not
> enabled on leader
> -
>
> Key: SOLR-17306
> URL: https://issues.apache.org/jira/browse/SOLR-17306
> Project: Solr
> Issue Type: Bug
>Affects Versions: 9.2, 9.3, 9.4, 9.5, 9.6
>Reporter: Peter Kroiss
>Assignee: Eric Pugh
>Priority: Major
> Labels: pull-request-available
> Fix For: 9.8
>
> Attachments: solr-replication-test.txt
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> We are testing Solr 9.6.2 in a leader - repeater - follower configuration. We
> have times where we write the leader heavily, in that time replication is
> disabled to save bandwidth.
> In the time, when replication is disabled on leader, the repeater restarts
> for some reason, the repeater loses all documents and doesn't recover when
> the leader is opened for replication.
> The documents are deleted but indexVersion and generation properties are set
> to the value of the leader, so the repeater or follower doesn't recover when
> the leader is opened for replication again.
> It recovers only when there are commits on the leader after opening the
> replication.
> Log:
> 2024-05-22 06:18:42.186 INFO (qtp16373883-27-null-23) [c: s: r: x:mycore
> t:null-23] o.a.s.c.S.Request webapp=/solr path=/replication
> params=\{wt=json&command=details} status=0 QTime=10
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Leader's generation: 0
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Leader's version: 0
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Follower's generation: 2913
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Follower's version: 1716300697144
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher New index in Leader. Deleting mine...
>
> --> there is no new Index in Leader it is only closed for replication
>
>
> We think the problem is in IndexFetcher
> old: if (IndexDeletionPolicyWrapper.getCommitTimestamp(commit) != 0L) {
> forceReplication - will probably fix the problem
> new : if (forceReplication &&
> IndexDeletionPolicyWrapper.getCommitTimestamp(commit) != 0L) {
>
>
>
>
> When investigation the problem we also found some inconsistencies in the
> details request. There are two fragments leader. When the leader is closed
> for replication the property leader. replicationEnabled is set to true, the
> property follower. leaderDetails. Leader. replicationEnabled is correct.
>
> Example
> curl -s
> "https://solr9-repeater:8983/solr/mycore/replication?wt=json&command=details";
> | jq '.details |
> { indexSize: .indexSize, indexVersion: .indexVersion, generation:
> .generation, indexPath: .indexPath, leader: \\{ replicableVersion:
> .leader.replicableVersion, replicableGeneration:
> .leader.replicableGeneration, replicationEnabled: .leader.replicationEnabled }
> ,
> follower: { leaderDetails: { indexSize: .follower.leaderDetails.indexSize,
> generation: .follower.leaderDetails.generation,
> indexVersion: .follower.leaderDetails.indexVersion, indexPath:
> .follower.leaderDetails.indexPath,
> leader:
> { replicableVersion: .follower.leaderDetails.leader.replicableVersion ,
> replicableGeneration: .follower.leaderDetails.leader.replicableGeneration,
> replicationEnabled: .follower.leaderDetails.leader.replicationEnabled }
> }}
> }'
>
> {
> "indexSize": "10.34 GB",
> "indexVersion": 1716358708159,
> "generation": 2913,
> "indexPath": "/var/solr/data/mycore/data/index.20240522061946262",
> "leader":
> { "replicableVersion": 1716358708159, "replicableGeneration": 2913,
> "replicationEnabled": "true" }
> ,
> "follower": {
> "leaderDetails": {
> "indexSize": "10.34 GB",
> "generation": 2913,
> "indexVersion": 1716358708159,
> "indexPath": "/var/solr/data/mycore/data/restore.20240508131046932",
> "leader":
> { "replicableVersion": 1716358708159, "replicableGeneration":
> 2913, "replicationEnab
Re: [PR] Fix TestReplicationHandler [solr]
HoustonPutman merged PR #3142: URL: https://github.com/apache/solr/pull/3142 -- 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-17623: Simple ordered map should implement map [solr]
renatoh commented on PR #3048: URL: https://github.com/apache/solr/pull/3048#issuecomment-2622728797 > Just needs a CHANGES.txt entry. I've added that under Solr 9.9.0, is that correct? -- 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
