Re: [PR] Add ability to schedule recurring incremental backups [solr-operator]
killdash9 commented on PR #359: URL: https://github.com/apache/solr-operator/pull/359#issuecomment-2711215072 > @gerlowskija, given that https://issues.apache.org/jira/browse/SOLR-15706 is not released yet, maybe we just wait to add in the `purge` call until the next Solr Operator release. That issue has been fixed. Should we add purgeUnused to the solr operator's backup functionality? -- 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-17702) ZkController should own its own reconnect logic
[ https://issues.apache.org/jira/browse/SOLR-17702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935403#comment-17935403 ] David Smiley commented on SOLR-17702: - Nice Houston! I suppose this addresses my few comments on our Curator issue? Ideally you'd comment there. > ZkController should own its own reconnect logic > --- > > Key: SOLR-17702 > URL: https://issues.apache.org/jira/browse/SOLR-17702 > Project: Solr > Issue Type: Improvement >Affects Versions: main (10.0) >Reporter: Houston Putman >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Since we use Curator now, the SolrZkClient is no longer in charge of > maintaining onDisconnect and onReconnect listeners, Curator does. This means > that SolrZkClient doesn't need to own their execution either. > ZkController is the main usage of this logic, with big "onDisconnect" and > "onReconnect" methods. However, when onReconnect is called just before a > server is taken down, the ZkController does not own the executor for this > reconnect logic, so we have to wait until the SolrZkClient is shut down (one > of the last steps of shutting down a solr node). > Instead, we can have the ZkController take control of the executor, so that > we can ensure that reconnect and disconnect logic is stopped once "close()" > is called. > There are a few other places that use the SolrZkClient onReconnect() > listener, but those can be transitioned to call Curator to add them. > (ZkStateReader being the main one). And this is only going to go to main > (10.0) since it requires Curator, so we don't need to worry about changing > class/method signatures or back-compatibility. > And one extra benefit is that we are slimming down one more thing from > SolrZkClient (and maybe we can actually retire it one day)! -- 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-17703) BinaryResponseParser and BinaryRequestWriter rename to "JavaBin..."
David Smiley created SOLR-17703: --- Summary: BinaryResponseParser and BinaryRequestWriter rename to "JavaBin..." Key: SOLR-17703 URL: https://issues.apache.org/jira/browse/SOLR-17703 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: David Smiley SolrJ BinaryRequestWriter and BinaryResponseParser should be renamed to replace "Binary" with "JavaBin". Same with StreamingBinaryResponseParser. This clarifies that they are for "JavaBin" specifically, and not binary generically, and it's also more consistent with the other uses of "JavaBin" named things. The poor naming has led to accidental misuse of these. Separately in another issue, the Solr side JavaBinResponseWriter was renamed from a worse name. 10.0 only, obviously. -- 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-10998: Obey 'Accept' header in v2 APIs [solr]
epugh commented on PR #3262: URL: https://github.com/apache/solr/pull/3262#issuecomment-2720940030 This is some nice alignment with normal web expectations.. -- 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-17700) CoreContainer does not obtain a lock when unloading cores
[
https://issues.apache.org/jira/browse/SOLR-17700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935218#comment-17935218
]
ASF subversion and git services commented on SOLR-17700:
Commit 7725ac3245927ee667c5eed6f1eaaaef184ba3ff in solr's branch
refs/heads/main from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=7725ac32459 ]
SOLR-17700: Use core operation lock when unloading core (#3260)
> CoreContainer does not obtain a lock when unloading cores
> -
>
> Key: SOLR-17700
> URL: https://issues.apache.org/jira/browse/SOLR-17700
> Project: Solr
> Issue Type: Bug
>Reporter: Houston Putman
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CoreContainer uses {{solrCores.waitAddPendingCoreOps(name)}} when doing an
> operation on a core. And the documentation for
> {{SolrCores.waitAddPendingCoreOps(name)}} mentions that:
> bq. // Wait here until any pending operations (load, unload or reload) are
> completed on this core.
> However, CoreContainer does not use this locking when unloading a core. This
> is the reason why we are seeing race condition issues when deleting and
> reloading a collection at the same time.
> Loading a core can possibly require unloading said core, when
> "deleteUnknownCoresOnStartup" is used, thus we need a way of unloading
> without a lock. But other than this edge case, locking the unload operation
> should only improve stability in Solr.
--
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-17700: Use core operation lock when unloading core [solr]
HoustonPutman merged PR #3260: URL: https://github.com/apache/solr/pull/3260 -- 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-17607: Http ClusterStateProvider, lazy connect [solr]
HoustonPutman commented on PR #3249: URL: https://github.com/apache/solr/pull/3249#issuecomment-2721420292 I think this is breaking an integration test, namely: "export fails on non cloud mode" in `test_export.bats`. It gives the following error on Jenkins: https://ci-builds.apache.org/job/Solr/job/Solr-Smoketest-9.x/642/ ``` not ok 36 export fails on non cloud mode # in 11026 ms # (from function `assert_output' in file .gradle/node/node_modules/bats-assert/src/assert.bash, line 247, # in test file test/test_export.bats, line 69) # `assert_output --partial "ERROR: Couldn't initialize a HttpClusterStateProvider"' failed # # -- output does not contain substring -- # substring (1 lines): # ERROR: Couldn't initialize a HttpClusterStateProvider # output (36 lines): # Option '-url','--solr-collection-url': Deprecated for removal since 9.8: Use --solr-url and -c / --name instead # Option '-url','--solr-collection-url': Deprecated for removal since 9.8: Use --solr-url and -c / --name instead # # ERROR: Failed fetching live_nodes from [http://localhost:40197/solr]. If you think your Solr cluster is up and is accessible, you could try re-creating a new CloudSolrClient using working solr URLs. ``` https://ci-builds.apache.org/job/Solr/job/Solr-TestIntegration-main/123/ ``` not ok 35 export fails on non cloud mode # in 11893 ms # (from function `assert_output' in file .gradle/node/node_modules/bats-assert/src/assert.bash, line 247, # in test file test/test_export.bats, line 69) # `assert_output --partial "ERROR: Couldn't initialize a HttpClusterStateProvider"' failed # # -- output does not contain substring -- # substring (1 lines): # ERROR: Couldn't initialize a HttpClusterStateProvider # output (2 lines): # # ERROR: Failed fetching live_nodes from [http://localhost:37591/solr]. If you think your Solr cluster is up and is accessible, you could try re-creating a new CloudSolrClient using working solr URLs. ``` -- 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-17700) CoreContainer does not obtain a lock when unloading cores
[
https://issues.apache.org/jira/browse/SOLR-17700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935237#comment-17935237
]
ASF subversion and git services commented on SOLR-17700:
Commit cc6ea87d4755ee42ec5e742873907eaa368f0cb5 in solr's branch
refs/heads/branch_9x from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=cc6ea87d475 ]
SOLR-17700: Use core operation lock when unloading core (#3260)
(cherry picked from commit 7725ac3245927ee667c5eed6f1eaaaef184ba3ff)
> CoreContainer does not obtain a lock when unloading cores
> -
>
> Key: SOLR-17700
> URL: https://issues.apache.org/jira/browse/SOLR-17700
> Project: Solr
> Issue Type: Bug
>Reporter: Houston Putman
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CoreContainer uses {{solrCores.waitAddPendingCoreOps(name)}} when doing an
> operation on a core. And the documentation for
> {{SolrCores.waitAddPendingCoreOps(name)}} mentions that:
> bq. // Wait here until any pending operations (load, unload or reload) are
> completed on this core.
> However, CoreContainer does not use this locking when unloading a core. This
> is the reason why we are seeing race condition issues when deleting and
> reloading a collection at the same time.
> Loading a core can possibly require unloading said core, when
> "deleteUnknownCoresOnStartup" is used, thus we need a way of unloading
> without a lock. But other than this edge case, locking the unload operation
> should only improve stability in Solr.
--
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-17700) CoreContainer does not obtain a lock when unloading cores
[
https://issues.apache.org/jira/browse/SOLR-17700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman resolved SOLR-17700.
---
Fix Version/s: 9.9
Assignee: Houston Putman
Resolution: Fixed
> CoreContainer does not obtain a lock when unloading cores
> -
>
> Key: SOLR-17700
> URL: https://issues.apache.org/jira/browse/SOLR-17700
> Project: Solr
> Issue Type: Bug
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Labels: pull-request-available
> Fix For: 9.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CoreContainer uses {{solrCores.waitAddPendingCoreOps(name)}} when doing an
> operation on a core. And the documentation for
> {{SolrCores.waitAddPendingCoreOps(name)}} mentions that:
> bq. // Wait here until any pending operations (load, unload or reload) are
> completed on this core.
> However, CoreContainer does not use this locking when unloading a core. This
> is the reason why we are seeing race condition issues when deleting and
> reloading a collection at the same time.
> Loading a core can possibly require unloading said core, when
> "deleteUnknownCoresOnStartup" is used, thus we need a way of unloading
> without a lock. But other than this edge case, locking the unload operation
> should only improve stability in Solr.
--
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-16305) MODIFYCOLLECTION with 'property.*' changes can't change values used in config file variables (even though they can be set during collection CREATE)
[
https://issues.apache.org/jira/browse/SOLR-16305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935255#comment-17935255
]
Jason Gerlowski commented on SOLR-16305:
bq. so whatever approach is taken to rectify/unify the various types of
"property apis" needs to ensure that the ref-guide is updated to either remove
all references to core.properties (or mention it only in the context of being
an implementation detail)
Good call out! We probably can't remove all mention of "core.properties"; I
imagine it'll continue to be relevant for "standalone" users who might want to
set props in a "CREATECORE" call? But we'll need to excise it from all of our
SolrCloud-specific docs on collections operations, collection properties, etc.
bq. one thing that isn't in your table but deserves equal consideration is
ADDREPLICAPROP
Agreed - will cover that in an upcoming writeup!
> MODIFYCOLLECTION with 'property.*' changes can't change values used in config
> file variables (even though they can be set during collection CREATE)
> ---
>
> Key: SOLR-16305
> URL: https://issues.apache.org/jira/browse/SOLR-16305
> Project: Solr
> Issue Type: Bug
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-16305_test.patch
>
>
> Consider a configset with a {{solrconfig.xml}} that includes a snippet like
> this...
> {code:java}
> ${custom.prop:customDefVal}
> {code}
> ...this {{custom.prop}} can be set when doing a {{CREATE}} command for a
> collection that uses this configset, using the {{property.*}} prefix as noted
> in the reg-guide...
> {quote}{{property.{_}name{_}={_}value{_}}}
> |Optional|Default: none|
> Set core property _name_ to {_}value{_}. See the section [Core
> Discovery|https://solr.apache.org/guide/solr/latest/configuration-guide/core-discovery.html]
> for details on supported properties and values.
> {quote}
> ...BUT
> These values can *not* be changed by using the {{MODIFYCOLLECTION}} command,
> in spite of the ref-guide indicating that it can be used to modify custom
> {{property.*}} attributes...
> {quote}The attributes that can be modified are:
> * {{replicationFactor}}
> * {{collection.configName}}
> * {{readOnly}}
> * other custom properties that use a {{property.}} prefix
> See the [CREATE
> action|https://solr.apache.org/guide/solr/latest/deployment-guide/collection-management.html#create]
> section above for details on these attributes.
> {quote}
--
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-17656) Add expert level option to allowe PULL replicas to go ACTIVE w/o RECOVERING
[
https://issues.apache.org/jira/browse/SOLR-17656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935318#comment-17935318
]
Chris M. Hostetter commented on SOLR-17656:
---
{quote} So that made me eventually think that it was a client problem and not
actually a problem with the node.
...
I added the state wait at the beginning because I wasn't entirely sure this was
the issue at the time, but now I know that part is useless, it can be removed.
{quote}
Ha ha ... ok ... my confusion was thinking the "state wait" was the
*_important_* part of your fix, and that the client changes were just you doing
a little refactoring/cleanup of duplicated code in the same commit.
Now that i understand that your changes to what {{SolrClient}} gets used in the
test are what *REALLY* made the failures stop, that makes things (a little)
less confusing ... maybe the underling issue relates to connection caching in
the low level {{org.apache.http.client.HttpClient}} , and the jetty restarts
breaking those connections in a way that the client doesn't notice until it
tries to send a request?
(but i don't really understand the retry weirdness you mentioned)
> Add expert level option to allowe PULL replicas to go ACTIVE w/o RECOVERING
> ---
>
> Key: SOLR-17656
> URL: https://issues.apache.org/jira/browse/SOLR-17656
> Project: Solr
> Issue Type: New Feature
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Fix For: main (10.0), 9.9
>
> Attachments: SOLR-17656-1.patch, SOLR-17656.patch
>
>
> In situations where a Solr cluster undergoes a rolling restart (or some other
> "catastrophic" failure situations requiring/causing solr node restarts) there
> can be a snowball effect of poor performance (or even solr node crashing) due
> to fewer then normal replicas serving query requests while replicas on
> restarting nodes are DOWN or RECOVERING – especially if shard leaders are
> also affected, and (restarting) replicas first must wait for a leader
> election before they can recover (or wait to finish recovery from an
> over-worked leader).
> For NRT type usecases, RECOVERING is really a necessary evil to ensure every
> replicas is up to date before handling NRT requests – but in the case of PULL
> replicas, which are expected to routinely "lag" behind their leader, I've
> talked to a lot of Solr users w/usecases where they would be happy to have
> PULL replicas back online serving "stale" data ASAP, and let normal
> IndexFetching "catchup" with the leader later.
> I propose we support a new "advanced" replica property that can be set on
> PULL replicas by expert level users, to indicate: on (re)init, these replicas
> may skip RECOVERING and go directly to ACTIVE.
--
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] Prevent RAW_GINKGO unset error in e2e tests [solr-operator]
gerlowskija commented on PR #767: URL: https://github.com/apache/solr-operator/pull/767#issuecomment-2722526123 I swear a different dev brought this up at some point in either an Issue or PR (though I can't find that comment now). In any case, I've hit this a number of times across different machines, so seems worth fixing. -- 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-17685) Can't pass in -z connection parameter to bin/solr auth
[
https://issues.apache.org/jira/browse/SOLR-17685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935348#comment-17935348
]
ASF subversion and git services commented on SOLR-17685:
Commit 1bcbcbb587bb4599a7abc1f8e2f52dcf7f899c41 in solr's branch
refs/heads/main from Eric Pugh
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=1bcbcbb587b ]
SOLR-17685: Remove script creation of solr url based on SOLR_TOOL_HOST in
favour of java code in CLI tools (#3223)
* Add test to demonstrate conflict with -z, and the fix.
* Remove solr.tool.host and SOLR_TOOL_HOST
* Preserve legacy AUTH_PORT usage, with a bats test
> Can't pass in -z connection parameter to bin/solr auth
> --
>
> Key: SOLR-17685
> URL: https://issues.apache.org/jira/browse/SOLR-17685
> Project: Solr
> Issue Type: Bug
> Components: cli
>Affects Versions: main (10.0)
>Reporter: Eric Pugh
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> I noticed that the Security page in Solr for a not secured Solr gives you a
> default command to run:
>
> bin/solr auth enable --type basicAuth --prompt true -z 127.0.0.1:9983
>
> However, that fails with the error "Failed to parse command-line arguments
> due to: The option 's' was specified but an option from this group has
> already been selected: ‘z’”.
>
> I dug in a bit and the bin/solr command to run the auth tool tries to be
> smart about your Solr URL:
>
> run_tool auth $@ --solr-url
> "$SOLR_URL_SCHEME://$SOLR_TOOL_HOST:${AUTH_PORT:-8983}”
>
> Right now, we actually have a method INSIDE of the Java process that looks up
> a default Solr URL if you don’t pass in a —Solr-url or -z one and that uses
> the SOLR_TOOL_HOST environment variable.
>
> I believe this gives everyone what they want….?
>
--
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-17685: Remove script creation of solr url based on SOLR_TOOL_HOST in favour of java code in CLI tools [solr]
epugh merged PR #3223: URL: https://github.com/apache/solr/pull/3223 -- 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] Prevent RAW_GINKGO unset error in e2e tests [solr-operator]
gerlowskija opened a new pull request, #767: URL: https://github.com/apache/solr-operator/pull/767 Not all environments set particular `RAW_GINKGO` args, causing `make e2e-tests` to fail with an "unset variable" related error. This commit tweaks our `manage_e2e_tests.sh` script to guard against this case. -- 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-17043: Remove SolrClient path pattern matching [solr]
dsmiley commented on code in PR #3238:
URL: https://github.com/apache/solr/pull/3238#discussion_r1994348390
##
solr/solrj/src/java/org/apache/solr/client/solrj/request/DirectXmlRequest.java:
##
@@ -55,8 +55,13 @@ public SolrParams getParams() {
}
@Override
- public String getRequestType() {
-return SolrRequestType.UPDATE.toString();
+ protected SolrRequestType getBaseRequestType() {
Review Comment:
IMO we should deprecate `DirectXmlRequest`. It's unused, untested, and not
needed. I'll do so in my deprecation branch/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] SOLR-17043: Remove SolrClient path pattern matching [solr]
dsmiley commented on code in PR #3238:
URL: https://github.com/apache/solr/pull/3238#discussion_r1994346969
##
solr/solrj/src/java/org/apache/solr/client/solrj/request/DelegationTokenRequest.java:
##
@@ -84,8 +84,8 @@ public DelegationTokenResponse.Get createResponse(SolrClient
client) {
}
@Override
-public String getRequestType() {
- return SolrRequestType.ADMIN.toString();
+protected SolrRequestType getBaseRequestType() {
Review Comment:
@risdenk I also at-mentioned you on that point on the related Hadoop removal
PR since you are the SME on this (not 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-17043: Remove SolrClient path pattern matching [solr]
dsmiley commented on code in PR #3238:
URL: https://github.com/apache/solr/pull/3238#discussion_r1994350312
##
solr/solrj/src/java/org/apache/solr/client/solrj/request/DirectXmlRequest.java:
##
@@ -55,8 +55,13 @@ public SolrParams getParams() {
}
@Override
- public String getRequestType() {
-return SolrRequestType.UPDATE.toString();
+ protected SolrRequestType getBaseRequestType() {
Review Comment:
I already did that:
https://github.com/apache/solr/blob/cbc2321598f30066dab4ba396e6c593577f9d8f4/solr/solrj/src/java/org/apache/solr/client/solrj/request/DirectXmlRequest.java#L33
I should merge that PR so we can more easily communicate to even each other
what things are going away so we shouldn't spend attention on
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17632: Text to Vector Update Request Processor [solr]
alessandrobenedetti merged PR #3151: URL: https://github.com/apache/solr/pull/3151 -- 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-17632) Text to Vector Update Request Processor
[ https://issues.apache.org/jira/browse/SOLR-17632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935267#comment-17935267 ] ASF subversion and git services commented on SOLR-17632: Commit 35a9b975ecaa83b2d4bd571d05d427f305af0f16 in solr's branch refs/heads/main from Alessandro Benedetti [ https://gitbox.apache.org/repos/asf?p=solr.git;h=35a9b975eca ] SOLR-17632: Text to Vector Update Request Processor (#3151) * SOLR-17632: introducing update request processor + tests - Co-authored-by: Christine Poerschke > Text to Vector Update Request Processor > --- > > Key: SOLR-17632 > URL: https://issues.apache.org/jira/browse/SOLR-17632 > Project: Solr > Issue Type: New Feature > Components: UpdateRequestProcessors >Reporter: Alessandro Benedetti >Assignee: Alessandro Benedetti >Priority: Major > Labels: pull-request-available, vector-based-search > Time Spent: 6h 10m > Remaining Estimate: 0h > > Scope of this issue is to introduce support for automatic text vectorisation > in Apache Solr, directly in a update request processor. > A LLM fine-tuned for sentence similarity will be accessed to embed the text. > Apache Solr will host the configuration parameters to access embedding > services and the update request processor will use such services to directly > encode the document field as a vector. -- 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-17632: Text to Vector Update Request Processor [solr]
alessandrobenedetti commented on PR #3151: URL: https://github.com/apache/solr/pull/3151#issuecomment-2721866606 Merged! Thanks, everybody, for the help! -- 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] Solr 9.8.0 pods do not become ready [solr-operator]
aloosnetmatch commented on issue #761: URL: https://github.com/apache/solr-operator/issues/761#issuecomment-2721872746 We had our initial issues with the "nonp" cluster. Here we "manually" configure the readinessGates I took the time to spin up a new "test" cluster. A similar cluster without the affinity rules When i do a "kubectl get pod" on one of the nodes in both namespaces and compare the results I spot this interesting part . Under status I see the type: Ready status: 'False' message: >- corresponding condition of pod readiness gate "solr.apache.org/isNotStopped" does not exist.** ```status: phase: Running conditions: - type: PodReadyToStartContainers status: 'True' lastProbeTime: null lastTransitionTime: '2025-03-13T14:57:53Z' - type: Initialized status: 'True' lastProbeTime: null lastTransitionTime: '2025-03-13T14:57:55Z' - type: Ready status: 'False' lastProbeTime: null lastTransitionTime: '2025-03-13T14:57:38Z' **reason: ReadinessGatesNotReady message: >- corresponding condition of pod readiness gate "solr.apache.org/isNotStopped" does not exist.** - type: ContainersReady status: 'True' lastProbeTime: null lastTransitionTime: '2025-03-13T15:00:32Z' - type: PodScheduled status: 'True' lastProbeTime: null lastTransitionTime: '2025-03-13T14:57:38Z'``` Here are the files that i used to compare: [nonp-cluster.txt](https://github.com/user-attachments/files/19232472/nonp-cluster.txt) [test-cluster.txt](https://github.com/user-attachments/files/19232471/test-cluster.txt) -- 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] Solr registers with incorrect port 80 in Zookeeper [solr-operator]
edaemon commented on issue #84: URL: https://github.com/apache/solr-operator/issues/84#issuecomment-2722486500 @HoustonPutman, thanks for the feedback. I had recreated the cloud many times without the custom `podPort` and saw the same behavior. I did see the `SOLR_PORT_ADVERTISE=8983` envvar but for some reason it was not effective. I'll try again sometime soon and open an issue if I see the same problem. -- 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] Add ability to schedule recurring incremental backups [solr-operator]
HoustonPutman commented on PR #359: URL: https://github.com/apache/solr-operator/pull/359#issuecomment-2722405375 Absolutely, you should create a new issue for that @killdash9 ! -- 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-17043: Remove SolrClient path pattern matching [solr]
dsmiley commented on code in PR #3238:
URL: https://github.com/apache/solr/pull/3238#discussion_r1994305927
##
solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java:
##
@@ -210,6 +236,16 @@ public boolean requiresCollection() {
return false;
}
+ /**
+ * Indicates if clients should make attempts to route this request to a
shard leader, overriding
+ * typical client routing preferences for requests. Defaults to true.
+ *
+ * @see CloudSolrClient#isUpdatesToLeaders
+ */
+ public boolean shouldSendToLeaders() {
Review Comment:
I should have clarified that my comment wasn't a critique of this PR. The
presence of this boolean seemed to somewhat get in the way of this PR (?) so I
chose this moment to share my thoughts. Feel free to ignore!
--
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-16903: Migrate all tests using File to NIO Path [solr]
epugh commented on code in PR #3263:
URL: https://github.com/apache/solr/pull/3263#discussion_r1994355061
##
solr/core/src/test/org/apache/solr/SolrInfoBeanTest.java:
##
@@ -88,30 +90,37 @@ public void testCallMBeanInfo() throws Exception {
}
private static List> getClassesForPackage(String pckgname) throws
Exception {
-ArrayList directories = new ArrayList<>();
+ArrayList directories = new ArrayList<>();
ClassLoader cld = h.getCore().getResourceLoader().getClassLoader();
String path = pckgname.replace('.', '/');
Enumeration resources = cld.getResources(path);
while (resources.hasMoreElements()) {
final URI uri = resources.nextElement().toURI();
if (!"file".equalsIgnoreCase(uri.getScheme())) continue;
- final File f = new File(uri);
+ final Path f = Path.of(uri);
directories.add(f);
}
ArrayList> classes = new ArrayList<>();
-for (File directory : directories) {
- if (directory.exists()) {
-String[] files = directory.list();
-for (String file : files) {
- if (file.endsWith(".class")) {
-String clazzName = file.substring(0, file.length() - 6);
-// exclude Test classes that happen to be in these packages.
-// class.ForName'ing some of them can cause trouble.
-if (!clazzName.endsWith("Test") && !clazzName.startsWith("Test")) {
- classes.add(Class.forName(pckgname + '.' + clazzName));
-}
- }
+for (Path directory : directories) {
+ if (Files.exists(directory)) {
+try (Stream files = Files.list(directory)) {
Review Comment:
Is the try helping? Is this a try-with-resources pattern?
##
solr/core/src/test/org/apache/solr/cli/TestSolrCLIRunExample.java:
##
@@ -558,32 +555,34 @@ public void testInteractiveSolrCloudExample() throws
Exception {
@Test
public void testFailExecuteScript() throws Exception {
-File solrHomeDir = new File(ExternalPaths.SERVER_HOME);
-if (!solrHomeDir.isDirectory())
- fail(solrHomeDir.getAbsolutePath() + " not found and is required to run
this test!");
+Path solrHomeDir = Path.of(ExternalPaths.SERVER_HOME);
+if (!Files.isDirectory(solrHomeDir))
+ fail(solrHomeDir.toAbsolutePath() + " not found and is required to run
this test!");
-Path tmpDir = createTempDir();
-File solrExampleDir = tmpDir.toFile();
-File solrServerDir = solrHomeDir.getParentFile();
+Path solrExampleDir = createTempDir();
+Path solrServerDir = solrHomeDir.getParent();
// need a port to start the example server on
int bindPort = -1;
try (ServerSocket socket = new ServerSocket(0)) {
bindPort = socket.getLocalPort();
}
-File toExecute = new File(tmpDir.toString(), "failExecuteScript");
-assertTrue(
-"Should have been able to create file '" + toExecute.getAbsolutePath()
+ "' ",
-toExecute.createNewFile());
+Path toExecute = Path.of(solrExampleDir.toString(), "failExecuteScript");
+try {
+ Files.createFile(toExecute);
+} catch (IOException e) {
+ throw new IOException(
+ "Should have been able to create file '" +
toExecute.toAbsolutePath() + "' ");
+}
String[] toolArgs =
new String[] {
"-e", "techproducts",
- "--server-dir", solrServerDir.getAbsolutePath(),
- "--example-dir", solrExampleDir.getAbsolutePath(),
+ "--server-dir", solrServerDir.toAbsolutePath().toString(),
Review Comment:
Shame that this requires all these `.toString`.. Is there a smarter way of
handling this toolArgs? `var toolArgs`? And then internally we call
.toString on anything passed in?
##
solr/core/src/test/org/apache/solr/cli/StreamToolTest.java:
##
@@ -185,11 +183,11 @@ public void testReadStream() throws Exception {
@Test
@SuppressWarnings({"unchecked", "rawtypes"})
public void testLocalCatStream() throws Exception {
-File localFile = File.createTempFile("topLevel1", ".txt");
-populateFileWithData(localFile.toPath());
+Path localFile = Files.createTempFile("topLevel1", ".txt");
+populateFileWithData(localFile);
StreamTool.LocalCatStream catStream =
-new StreamTool.LocalCatStream(localFile.getAbsolutePath(), -1);
+new StreamTool.LocalCatStream(localFile.toAbsolutePath().toString(),
-1);
Review Comment:
Should we just pass in a path here?
##
solr/core/src/test/org/apache/solr/SolrInfoBeanTest.java:
##
@@ -88,30 +90,37 @@ public void testCallMBeanInfo() throws Exception {
}
private static List> getClassesForPackage(String pckgname) throws
Exception {
-ArrayList directories = new ArrayList<>();
+ArrayList directories = new ArrayList<>();
ClassLoader cld = h.getCore().getResourceLoader().getClassLoader();
String path = pckgname.replace('.', '/');
Enumeration resources = c
[jira] [Commented] (SOLR-17607) HTTP ClusterStateProvider should defer talking to Solr until first use
[ https://issues.apache.org/jira/browse/SOLR-17607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935364#comment-17935364 ] ASF subversion and git services commented on SOLR-17607: Commit 3b0ce26df120459b81355d2b10218b8fd7c0d54c in solr's branch refs/heads/main from David Smiley [ https://gitbox.apache.org/repos/asf?p=solr.git;h=3b0ce26df12 ] SOLR-17607: bats: remove looking for specific error Looking for a specific error message doesn't seem worthwhile. It became out-of-date. > HTTP ClusterStateProvider should defer talking to Solr until first use > -- > > Key: SOLR-17607 > URL: https://issues.apache.org/jira/browse/SOLR-17607 > Project: Solr > Issue Type: Improvement > Components: SolrCloud, SolrJ >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Labels: pull-request-available > Fix For: 9.9 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > When using CloudSolrClient with HTTP URLs to get the ClusterState (HTTP > ClusterStateProvider), it will talk to Solr when the client is created to > fetch the live nodes. But maybe Solr isn't available at this time; it's > annoying to require that Solr is available at the time that the > CloudSolrClient is constructed. The ZK one is deferred till first use; I > propose the same behavior for HTTP. -- 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-17607) HTTP ClusterStateProvider should defer talking to Solr until first use
[ https://issues.apache.org/jira/browse/SOLR-17607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935368#comment-17935368 ] ASF subversion and git services commented on SOLR-17607: Commit 00b16b165259e786bc506a15c727f5a6032318d1 in solr's branch refs/heads/branch_9x from David Smiley [ https://gitbox.apache.org/repos/asf?p=solr.git;h=00b16b16525 ] SOLR-17607: bats: remove looking for specific error Looking for a specific error message doesn't seem worthwhile. It became out-of-date. (cherry picked from commit 3b0ce26df120459b81355d2b10218b8fd7c0d54c) > HTTP ClusterStateProvider should defer talking to Solr until first use > -- > > Key: SOLR-17607 > URL: https://issues.apache.org/jira/browse/SOLR-17607 > Project: Solr > Issue Type: Improvement > Components: SolrCloud, SolrJ >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Labels: pull-request-available > Fix For: 9.9 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > When using CloudSolrClient with HTTP URLs to get the ClusterState (HTTP > ClusterStateProvider), it will talk to Solr when the client is created to > fetch the live nodes. But maybe Solr isn't available at this time; it's > annoying to require that Solr is available at the time that the > CloudSolrClient is constructed. The ZK one is deferred till first use; I > propose the same behavior for HTTP. -- 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-17685: Change fix version to 10x [solr]
epugh opened a new pull request, #3264: URL: https://github.com/apache/solr/pull/3264 https://issues.apache.org/jira/browse/SOLR-17685 # Description Change to 10x # Solution Backporting looked tough, and I don't want to inject new bugs into 9x... -- 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-17701) Remove AUTH_PORT in bin/solr scripts
Eric Pugh created SOLR-17701: Summary: Remove AUTH_PORT in bin/solr scripts Key: SOLR-17701 URL: https://issues.apache.org/jira/browse/SOLR-17701 Project: Solr Issue Type: Task Components: cli Affects Versions: 9.8.1 Reporter: Eric Pugh Assignee: Eric Pugh AUTH_PORT is no longer needed, so let's strip it out of 10. -- 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-17701: Strip out AUTH_PORT in favour of SOLR_PORT [solr]
epugh opened a new pull request, #3265: URL: https://github.com/apache/solr/pull/3265 https://issues.apache.org/jira/browse/SOLR-17701 # Description AUTH_PORT no longer used. # Solution Remove AUTH_PORT export as we set it to SOLR_PORT and use that. # Tests Existing tests, except I removed a AUTH_PORT specific bats test. -- 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-17701: Strip out AUTH_PORT in favour of SOLR_PORT [solr]
epugh commented on PR #3265: URL: https://github.com/apache/solr/pull/3265#issuecomment-2722829023 Changelog will say something like "AUTH_PORT export removed in favour of more commonly used SOLR_PORT export"? -- 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-17638 Some CLI errors not logged when starting prometheus exporter [solr]
epugh commented on code in PR #3236:
URL: https://github.com/apache/solr/pull/3236#discussion_r1994384208
##
solr/prometheus-exporter/src/java/org/apache/solr/prometheus/exporter/SolrExporter.java:
##
@@ -349,4 +361,31 @@ private static MetricsConfiguration
loadMetricsConfiguration(String configPath)
private static String getSystemVariable(String name) {
return System.getProperty(name, System.getenv(name));
}
+
+ // copied over from CLIUtils
+ public static void exit(int exitStatus) {
+try {
+ System.exit(exitStatus);
+} catch (java.lang.SecurityException secExc) {
+ if (exitStatus != 0)
+throw new RuntimeException("SolrExporter failed to exit with status "
+ exitStatus);
+}
+ }
+
+ // copied over from CLIUtils
+ private static String getDefaultSolrUrl() {
+// note that ENV_VAR syntax (and the env vars too) are mapped to env.var
sys props
+String scheme = EnvUtils.getProperty("solr.url.scheme", "http");
+String host = EnvUtils.getProperty("solr.tool.host", "localhost");
Review Comment:
I just commited to 10x (only) the change to remove solr.tool.host.
backporting to 9x was tough.
--
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] Solr -operator and prometheus-exporter [solr-operator]
HoustonPutman commented on issue #760: URL: https://github.com/apache/solr-operator/issues/760#issuecomment-2722006358 Yeah, the only way for `ZK_HOST` to not actually have a value is to do some really weird stuff, so it would be necessary to see what your `solrcloud` and `solrprometheusexporter` specs look like -- 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] Solr 9.8.0 pods do not become ready [solr-operator]
HoustonPutman commented on issue #761: URL: https://github.com/apache/solr-operator/issues/761#issuecomment-2722079878 Thanks for all the info here @aloosnetmatch , it is an easy fix and hopefully should be released soon! -- 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-17632) Text to Vector Update Request Processor
[ https://issues.apache.org/jira/browse/SOLR-17632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessandro Benedetti resolved SOLR-17632. - Resolution: Fixed > Text to Vector Update Request Processor > --- > > Key: SOLR-17632 > URL: https://issues.apache.org/jira/browse/SOLR-17632 > Project: Solr > Issue Type: New Feature > Components: UpdateRequestProcessors >Reporter: Alessandro Benedetti >Assignee: Alessandro Benedetti >Priority: Major > Labels: pull-request-available, vector-based-search > Fix For: 9.9 > > Time Spent: 6h 20m > Remaining Estimate: 0h > > Scope of this issue is to introduce support for automatic text vectorisation > in Apache Solr, directly in a update request processor. > A LLM fine-tuned for sentence similarity will be accessed to embed the text. > Apache Solr will host the configuration parameters to access embedding > services and the update request processor will use such services to directly > encode the document field as a vector. -- 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-17638 Some CLI errors not logged when starting prometheus exporter [solr]
HoustonPutman commented on code in PR #3236:
URL: https://github.com/apache/solr/pull/3236#discussion_r1993942563
##
solr/prometheus-exporter/src/java/org/apache/solr/prometheus/exporter/SolrExporter.java:
##
@@ -349,4 +361,31 @@ private static MetricsConfiguration
loadMetricsConfiguration(String configPath)
private static String getSystemVariable(String name) {
return System.getProperty(name, System.getenv(name));
}
+
+ // copied over from CLIUtils
+ public static void exit(int exitStatus) {
+try {
+ System.exit(exitStatus);
+} catch (java.lang.SecurityException secExc) {
+ if (exitStatus != 0)
+throw new RuntimeException("SolrExporter failed to exit with status "
+ exitStatus);
+}
+ }
+
+ // copied over from CLIUtils
+ private static String getDefaultSolrUrl() {
+// note that ENV_VAR syntax (and the env vars too) are mapped to env.var
sys props
+String scheme = EnvUtils.getProperty("solr.url.scheme", "http");
+String host = EnvUtils.getProperty("solr.tool.host", "localhost");
Review Comment:
We shouldn't use "solr.tool.host" here IMO, since that variable is going to
go away, and I don't think it was ever used with the prometheus exporter.
--
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-17632) Text to Vector Update Request Processor
[ https://issues.apache.org/jira/browse/SOLR-17632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessandro Benedetti updated SOLR-17632: Fix Version/s: 9.9 > Text to Vector Update Request Processor > --- > > Key: SOLR-17632 > URL: https://issues.apache.org/jira/browse/SOLR-17632 > Project: Solr > Issue Type: New Feature > Components: UpdateRequestProcessors >Reporter: Alessandro Benedetti >Assignee: Alessandro Benedetti >Priority: Major > Labels: pull-request-available, vector-based-search > Fix For: 9.9 > > Time Spent: 6h 20m > Remaining Estimate: 0h > > Scope of this issue is to introduce support for automatic text vectorisation > in Apache Solr, directly in a update request processor. > A LLM fine-tuned for sentence similarity will be accessed to embed the text. > Apache Solr will host the configuration parameters to access embedding > services and the update request processor will use such services to directly > encode the document field as a vector. -- 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-17656) Add expert level option to allowe PULL replicas to go ACTIVE w/o RECOVERING
[
https://issues.apache.org/jira/browse/SOLR-17656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935274#comment-17935274
]
Houston Putman commented on SOLR-17656:
---
[~hossman] I could never reproduce locally either, but the smoking gun for me
was that the node was available (the logs said it was fine, and the collection
creation command worked without issue) but the actual client request got the
IOException. So that made me eventually think that it was a client problem and
not actually a problem with the node.
If you look at the logs of the failing tests, they include many of these:
{quote} o.a.h.i.e.RetryExec I/O exception
(org.apache.http.NoHttpResponseException) caught when processing request to
\{s}->https://127.0.0.1:38235: The target server failed to respond
o.a.h.i.e.RetryExec Retrying request to
\{s}->[https://127.0.0.1:38235|https://127.0.0.1:38235/]
{quote}
The weird thing here, is that the bad requests are only supposed to be retried
if the request is non-admin, but all of these requests being retried seem to be
Collections API calls. The weirder thing, is that this same retry logic is not
used when the same exception happens during the "/get" call in
{{testRealTimeGet()}} , so it fails in the way described above. These
NoHttpResponseExceptions happen all over the test, probably because of the
amount of restarts being done, but because they get retried almost every time
it's not a big deal.
I don't know why it's not being retried for the "/get" request, but all I do
know is that creating a new client is a safe way to see the test pass, and
ultimately the client is not what is being tested here.
I added the state wait at the beginning because I wasn't entirely sure this was
the issue at the time, but now I know that part is useless, it can be removed.
> Add expert level option to allowe PULL replicas to go ACTIVE w/o RECOVERING
> ---
>
> Key: SOLR-17656
> URL: https://issues.apache.org/jira/browse/SOLR-17656
> Project: Solr
> Issue Type: New Feature
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Fix For: main (10.0), 9.9
>
> Attachments: SOLR-17656-1.patch, SOLR-17656.patch
>
>
> In situations where a Solr cluster undergoes a rolling restart (or some other
> "catastrophic" failure situations requiring/causing solr node restarts) there
> can be a snowball effect of poor performance (or even solr node crashing) due
> to fewer then normal replicas serving query requests while replicas on
> restarting nodes are DOWN or RECOVERING – especially if shard leaders are
> also affected, and (restarting) replicas first must wait for a leader
> election before they can recover (or wait to finish recovery from an
> over-worked leader).
> For NRT type usecases, RECOVERING is really a necessary evil to ensure every
> replicas is up to date before handling NRT requests – but in the case of PULL
> replicas, which are expected to routinely "lag" behind their leader, I've
> talked to a lot of Solr users w/usecases where they would be happy to have
> PULL replicas back online serving "stale" data ASAP, and let normal
> IndexFetching "catchup" with the leader later.
> I propose we support a new "advanced" replica property that can be set on
> PULL replicas by expert level users, to indicate: on (re)init, these replicas
> may skip RECOVERING and go directly to ACTIVE.
--
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-17632) Text to Vector Update Request Processor
[ https://issues.apache.org/jira/browse/SOLR-17632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935286#comment-17935286 ] ASF subversion and git services commented on SOLR-17632: Commit cca9a7ac630b4df98dbc9381446af896434f88f9 in solr's branch refs/heads/branch_9x from Alessandro Benedetti [ https://gitbox.apache.org/repos/asf?p=solr.git;h=cca9a7ac630 ] SOLR-17632: minors > Text to Vector Update Request Processor > --- > > Key: SOLR-17632 > URL: https://issues.apache.org/jira/browse/SOLR-17632 > Project: Solr > Issue Type: New Feature > Components: UpdateRequestProcessors >Reporter: Alessandro Benedetti >Assignee: Alessandro Benedetti >Priority: Major > Labels: pull-request-available, vector-based-search > Fix For: 9.9 > > Time Spent: 6h 20m > Remaining Estimate: 0h > > Scope of this issue is to introduce support for automatic text vectorisation > in Apache Solr, directly in a update request processor. > A LLM fine-tuned for sentence similarity will be accessed to embed the text. > Apache Solr will host the configuration parameters to access embedding > services and the update request processor will use such services to directly > encode the document field as a vector. -- 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: [I] Basic Auth Bootstrap Not Working In 0.9.0 [solr-operator]
HoustonPutman closed issue #755: Basic Auth Bootstrap Not Working In 0.9.0 URL: https://github.com/apache/solr-operator/issues/755 -- 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-17632) Text to Vector Update Request Processor
[ https://issues.apache.org/jira/browse/SOLR-17632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935285#comment-17935285 ] ASF subversion and git services commented on SOLR-17632: Commit ffd10423ae17b11ed0d9609145e83ad6e6312b9d in solr's branch refs/heads/branch_9x from Alessandro Benedetti [ https://gitbox.apache.org/repos/asf?p=solr.git;h=ffd10423ae1 ] SOLR-17632: Text to Vector Update Request Processor (#3151) * SOLR-17632: introducing update request processor + tests - Co-authored-by: Christine Poerschke (cherry picked from commit 35a9b975ecaa83b2d4bd571d05d427f305af0f16) > Text to Vector Update Request Processor > --- > > Key: SOLR-17632 > URL: https://issues.apache.org/jira/browse/SOLR-17632 > Project: Solr > Issue Type: New Feature > Components: UpdateRequestProcessors >Reporter: Alessandro Benedetti >Assignee: Alessandro Benedetti >Priority: Major > Labels: pull-request-available, vector-based-search > Fix For: 9.9 > > Time Spent: 6h 20m > Remaining Estimate: 0h > > Scope of this issue is to introduce support for automatic text vectorisation > in Apache Solr, directly in a update request processor. > A LLM fine-tuned for sentence similarity will be accessed to embed the text. > Apache Solr will host the configuration parameters to access embedding > services and the update request processor will use such services to directly > encode the document field as a vector. -- 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] Allow disabling new UI module during builds [solr]
uschindler commented on PR #3261:
URL: https://github.com/apache/solr/pull/3261#issuecomment-2722212518
> > Could we also disable it by default in the OS/Arch values we know are
unsupported, as well as the ALT JDK option?
>
> This can be done by checking the values set in
`System.getProperty("os.name")` and `System.getenv("RUNTIME_JAVA_HOME")` (or is
it also just a property?) I believe? The main challenge is to disable the
module during the initialization phase, which has not loaded any gradle script
like `alternative-jdk-support.gradle`.
It is not only the env var. You can also set an alternative JDK with a
sysprop or project property. I am not sure if you can check all this duing
early setup.
Basically I don't like this at all. Can we not just move away from Kotlin? I
am not happy that we have a mixed build. Either all in Kotlin or nothing.
> Which operating systems are not supported besides s390x? If we get a more
complex logic, I would extract it to a separate script and apply it like we do
with `gradle/lucene-dev/lucene-dev-repo-composite.gradle`.
>
> It also seems that it works well and does not complain about invalid lock
state, which I was expecting at first when disabling the module.
Uwe
--
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] BalanceReplicas called even when PopulatePodsOnScaleUp and VacatePodsOnScaleDown are false [solr-operator]
HoustonPutman commented on issue #724: URL: https://github.com/apache/solr-operator/issues/724#issuecomment-2722373055 Hmmm I've looked into this again and I'm not sure anymore. It only queues a Balancing operation if a Scaling Operation is already queued. And the scaling operation is only queued if the `vacatePodsOnScaleDown` is set to true, or not set at all (the default is false). -- 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] Allow disabling new UI module during builds [solr]
dsmiley commented on PR #3261: URL: https://github.com/apache/solr/pull/3261#issuecomment-2722364171 We're sticking with Kotlin for the UI module, and Java for everything else. -- 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-17607: Http ClusterStateProvider, lazy connect [solr]
dsmiley commented on PR #3249: URL: https://github.com/apache/solr/pull/3249#issuecomment-2722399761 ouch; I'll fix today. Pierre told me too. Sorry about this. I really wish that I got an email that I failed the build -- a basic software engineering practice I use elsewhere for a long time. -- 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] Solr registers with incorrect port 80 in Zookeeper [solr-operator]
HoustonPutman commented on issue #84: URL: https://github.com/apache/solr-operator/issues/84#issuecomment-2722403088 @edaemon I think there was an issue when you had `podPort=80`, and created replicas. Those now see themselves as living on that port, which you are no longer using. I would recommend re-creating your cloud and removing the custom "solr.port.advertise" (which the operator does set through the `SOLR_PORT_ADVERTISE` envVar). If it still doesn't work after starting from scratch, create a new issue. -- 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] Use supported Solr version in examples [solr-operator]
gerlowskija merged PR #768: URL: https://github.com/apache/solr-operator/pull/768 -- 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-17682) Refactor QueryResponseWriter hierarchy to put binary at the base and add TextQueryResponseWriter sub
[ https://issues.apache.org/jira/browse/SOLR-17682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935377#comment-17935377 ] ASF subversion and git services commented on SOLR-17682: Commit b4ee7fc8333b5bba48b85e680f6dae6e45cd651b in solr's branch refs/heads/main from David Smiley [ https://gitbox.apache.org/repos/asf?p=solr.git;h=b4ee7fc8333 ] SOLR-17682: QueryResponseWriter hierarchy refactor (#3209) Base abstraction is now byte oriented, thus BinaryQueryResponseWriter is gone. Added TextQueryResponseWriter for the text ones. Stopped using RawResponseWriter when not needed. Added writeToString QueryResponseWriterUtil is removed Declare throw IOException from write(...) > Refactor QueryResponseWriter hierarchy to put binary at the base and add > TextQueryResponseWriter sub > > > Key: SOLR-17682 > URL: https://issues.apache.org/jira/browse/SOLR-17682 > Project: Solr > Issue Type: Improvement >Reporter: David Smiley >Priority: Major > Labels: pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > The QueryResponseWriter hierarchy should be inverted. Instead of Writer/Text > being at the base with a subclass (BinaryResponseWriter) doing > OutputStream/Binary, it should be inverted. QueryResponseWriter should have > write(OutputStream,...) and there should be a subclass/interface > TextResponseWriter for the textual formats. Once this is done, there are > some awkward methods that do casting (a code smell) that will instead be > simplified. There will be no use for QueryResponseWriterUtil. This is all > best shown in a PR to see why it's better. -- 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-17702) ZkController should own its own reconnect logic
Houston Putman created SOLR-17702: - Summary: ZkController should own its own reconnect logic Key: SOLR-17702 URL: https://issues.apache.org/jira/browse/SOLR-17702 Project: Solr Issue Type: Improvement Affects Versions: main (10.0) Reporter: Houston Putman Since we use Curator now, the SolrZkClient is no longer in charge of maintaining onDisconnect and onReconnect listeners, Curator does. This means that SolrZkClient doesn't need to own their execution either. ZkController is the main usage of this logic, with big "onDisconnect" and "onReconnect" methods. However, when onReconnect is called just before a server is taken down, the ZkController does not own the executor for this reconnect logic, so we have to wait until the SolrZkClient is shut down (one of the last steps of shutting down a solr node). Instead, we can have the ZkController take control of the executor, so that we can ensure that reconnect and disconnect logic is stopped once "close()" is called. There are a few other places that use the SolrZkClient onReconnect() listener, but those can be transitioned to call Curator to add them. (ZkStateReader being the main one). And this is only going to go to main (10.0) since it requires Curator, so we don't need to worry about changing class/method signatures or back-compatibility. And one extra benefit is that we are slimming down one more thing from SolrZkClient (and maybe we can actually retire it one day)! -- 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-16903: Migrate all tests using File to NIO Path [solr]
mlbiscoc opened a new pull request, #3263: URL: https://github.com/apache/solr/pull/3263 https://issues.apache.org/jira/browse/SOLR-16903 # Description WIP - Leaving in draft state for now as there is still more work from refactor needed but most tests pass so can be semi-reviewed. Migrate all imports using `File` to `Path`. There should be no more imports using `File` in the project. We are close to making `File` a forbidden API after this but still more work needed. # 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, not available for branches on forks living under an organisation) - [ ] 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] [Resolved] (SOLR-17685) Can't pass in -z connection parameter to bin/solr auth
[
https://issues.apache.org/jira/browse/SOLR-17685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh resolved SOLR-17685.
--
Fix Version/s: main (10.0)
Assignee: Eric Pugh
Resolution: Fixed
> Can't pass in -z connection parameter to bin/solr auth
> --
>
> Key: SOLR-17685
> URL: https://issues.apache.org/jira/browse/SOLR-17685
> Project: Solr
> Issue Type: Bug
> Components: cli
>Affects Versions: main (10.0)
>Reporter: Eric Pugh
>Assignee: Eric Pugh
>Priority: Major
> Labels: pull-request-available
> Fix For: main (10.0)
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> I noticed that the Security page in Solr for a not secured Solr gives you a
> default command to run:
>
> bin/solr auth enable --type basicAuth --prompt true -z 127.0.0.1:9983
>
> However, that fails with the error "Failed to parse command-line arguments
> due to: The option 's' was specified but an option from this group has
> already been selected: ‘z’”.
>
> I dug in a bit and the bin/solr command to run the auth tool tries to be
> smart about your Solr URL:
>
> run_tool auth $@ --solr-url
> "$SOLR_URL_SCHEME://$SOLR_TOOL_HOST:${AUTH_PORT:-8983}”
>
> Right now, we actually have a method INSIDE of the Java process that looks up
> a default Solr URL if you don’t pass in a —Solr-url or -z one and that uses
> the SOLR_TOOL_HOST environment variable.
>
> I believe this gives everyone what they want….?
>
--
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-17702) ZkController should own its own reconnect logic
[ https://issues.apache.org/jira/browse/SOLR-17702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17702: -- Labels: pull-request-available (was: ) > ZkController should own its own reconnect logic > --- > > Key: SOLR-17702 > URL: https://issues.apache.org/jira/browse/SOLR-17702 > Project: Solr > Issue Type: Improvement >Affects Versions: main (10.0) >Reporter: Houston Putman >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Since we use Curator now, the SolrZkClient is no longer in charge of > maintaining onDisconnect and onReconnect listeners, Curator does. This means > that SolrZkClient doesn't need to own their execution either. > ZkController is the main usage of this logic, with big "onDisconnect" and > "onReconnect" methods. However, when onReconnect is called just before a > server is taken down, the ZkController does not own the executor for this > reconnect logic, so we have to wait until the SolrZkClient is shut down (one > of the last steps of shutting down a solr node). > Instead, we can have the ZkController take control of the executor, so that > we can ensure that reconnect and disconnect logic is stopped once "close()" > is called. > There are a few other places that use the SolrZkClient onReconnect() > listener, but those can be transitioned to call Curator to add them. > (ZkStateReader being the main one). And this is only going to go to main > (10.0) since it requires Curator, so we don't need to worry about changing > class/method signatures or back-compatibility. > And one extra benefit is that we are slimming down one more thing from > SolrZkClient (and maybe we can actually retire it one day)! -- 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-17518) Refactor out a XmlRequestWriter so that RequestWriter is abstract
[
https://issues.apache.org/jira/browse/SOLR-17518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935379#comment-17935379
]
David Smiley commented on SOLR-17518:
-
As I now look in branch_9x, this was a non-backwards-compatible change. A
SolrJ user wanting to send as XML would create a new RequestWriter but now it's
abstract; that won't work. Also the CHANGES.txt entry isn't indicative of the
magnitude of the change:
{quote} SOLR-17518: Deprecate UpdateRequest.getXml() and replace it with
XMLRequestWriter. (Pierre Salagnac){quote}
Back-compat is a pain; I question if attempting to bother to try to uphold it
is worth it for a refactoring like this.
> Refactor out a XmlRequestWriter so that RequestWriter is abstract
> -
>
> Key: SOLR-17518
> URL: https://issues.apache.org/jira/browse/SOLR-17518
> Project: Solr
> Issue Type: Task
> Components: SolrJ
>Reporter: David Smiley
>Assignee: Pierre Salagnac
>Priority: Minor
> Labels: newdev, pull-request-available
> Fix For: main (10.0), 9.9
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> RequestWriter writes XML; some subclasses write other things. This is
> terrible API design; the XML choice should be a subclass, RequestWriter
> should be abstract (or an interface).
> While we're at this, the XML generation is kind of split into multiple
> places; it should be consolidated: UpdateRequest & ClientUtils have XML
> generation methods. Those methods should move to the new XmlRequestWriter.
> BinaryRequestWriter should probably be final and/or ensure the CBOR one does
> not subclass it, which is weird since CBOR != "javabin".
> Be sure to note this refactoring in the update notes since SolrJ users will
> be impacted.
--
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-17702: Move ZK ConnectionListener logic out of SolrZkClient [solr]
HoustonPutman opened a new pull request, #3266: URL: https://github.com/apache/solr/pull/3266 https://issues.apache.org/jira/browse/SOLR-17702 This will fix the flaky `org.apache.solr.cloud.BasicDistributedZk2Test` (class method) failures. But in general this is a better way of taking down Solr. There's no reason for SolrZkClient to own this logic anymore. The classes that want to watch on connection state can decide if they want to be async or sync, and how to handle closing the executor themselves. -- 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-17701) Remove AUTH_PORT in bin/solr scripts
[ https://issues.apache.org/jira/browse/SOLR-17701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17701: -- Labels: pull-request-available (was: ) > Remove AUTH_PORT in bin/solr scripts > > > Key: SOLR-17701 > URL: https://issues.apache.org/jira/browse/SOLR-17701 > Project: Solr > Issue Type: Task > Components: cli >Affects Versions: 9.8.1 >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > AUTH_PORT is no longer needed, so let's strip it out of 10. -- 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-16903: Migrate all tests using File to NIO Path [solr]
epugh commented on code in PR #3263:
URL: https://github.com/apache/solr/pull/3263#discussion_r1994352934
##
solr/core/src/java/org/apache/solr/blockcache/BlockDirectory.java:
##
@@ -289,12 +290,12 @@ String getFileCacheName(String name) throws IOException {
private long getFileModified(String name) throws IOException {
if (in instanceof FSDirectory) {
- File directory = ((FSDirectory) in).getDirectory().toFile();
- File file = new File(directory, name);
- if (!file.exists()) {
+ Path directory = ((FSDirectory) in).getDirectory();
+ Path file = directory.resolve(name);
Review Comment:
Maybe just purely cosmentic, but should this really be `path` instead of
`file`? In all the places?
--
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-17682: QueryResponseWriter hierarchy refactor [solr]
dsmiley merged PR #3209: URL: https://github.com/apache/solr/pull/3209 -- 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-17682: Rename BinaryResponseWriter to JavaBinResponseWriter [solr]
dsmiley opened a new pull request, #3267: URL: https://github.com/apache/solr/pull/3267 https://issues.apache.org/jira/browse/SOLR-17682 2nd PR for this JIRA; I wanted to do this separately. -- 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-16903: Migrate all tests using File to NIO Path [solr]
dsmiley commented on code in PR #3263:
URL: https://github.com/apache/solr/pull/3263#discussion_r1994576108
##
solr/core/src/java/org/apache/solr/blockcache/BlockDirectory.java:
##
@@ -289,12 +290,12 @@ String getFileCacheName(String name) throws IOException {
private long getFileModified(String name) throws IOException {
if (in instanceof FSDirectory) {
- File directory = ((FSDirectory) in).getDirectory().toFile();
- File file = new File(directory, name);
- if (!file.exists()) {
+ Path directory = ((FSDirectory) in).getDirectory();
+ Path file = directory.resolve(name);
Review Comment:
No. I like 'file' to differentiate from a 'dir'. 'path' is generic if
could be either.
--
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-16903: Migrate all tests using File to NIO Path [solr]
dsmiley commented on code in PR #3263:
URL: https://github.com/apache/solr/pull/3263#discussion_r1994581560
##
solr/core/src/test/org/apache/solr/cli/SolrCLIZkToolsTest.java:
##
@@ -265,7 +275,10 @@ public void testCp() throws Exception {
new String[] {
"--zk-host",
zkAddr,
- "file:" + srcPathCheck.normalize().toAbsolutePath() + File.separator
+ "solrconfig.xml",
+ "file:"
+ + srcPathCheck.normalize().toAbsolutePath()
+ + FileSystems.getDefault().getSeparator()
Review Comment:
shouldn't we use resolve instead? And everywhere else in this source file
probably.
##
solr/core/src/test/org/apache/solr/cli/SolrCLIZkToolsTest.java:
##
@@ -417,7 +434,7 @@ public void testCp() throws Exception {
res = cpTool.runTool(SolrCLI.processCommandLineArgs(cpTool, args));
assertEquals("Copy should have succeeded.", 0, res);
-Path locEmpty = Paths.get(tmp2.toAbsolutePath().toString(), "stopwords",
"emptyfile");
+Path locEmpty = Path.of(tmp2.toAbsolutePath().toString(), "stopwords",
"emptyfile");
Review Comment:
Use resolve here instead? and in many other places similarly
##
solr/core/src/test/org/apache/solr/cli/SolrCLIZkToolsTest.java:
##
@@ -279,12 +292,16 @@ public void testCp() throws Exception {
// src and cp3 are valid
String localNamed =
-tmp.normalize() + File.separator + "localnamed" + File.separator +
"renamed.txt";
+tmp.normalize()
Review Comment:
shouldn't we use resolve() instead?
--
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-10998: Obey 'Accept' header in v2 APIs [solr]
gerlowskija opened a new pull request, #3262: URL: https://github.com/apache/solr/pull/3262 'wt' takes precedence if specified for now, if not provided Solr (through our use of Jersey) will pick a response format in keeping with the specified 'Accept' header. JSON responses remains the "default" if neither 'wt' nor an "Accept" header are specified. Still needed: - tests - CHANGES.txt entry https://issues.apache.org/jira/browse/SOLR-10998 # Description The HTTP spec defines an ["Accept" header](https://httpwg.org/specs/rfc7231.html#header.accept) that users can provide to specify the response format (or formats, plural) that they're willing to "accept" in a response. This is part of the HTTP specs support for "content negotiation" more generally. Solr today doesn't support this, and opts to have users specify their response format in a "wt" (i.e. "writer type") query-parameter. We should obey "Accept" headers, when they are provided. # Solution This PR modifies Solr to obey "Accept" headers on v2 API requests, unless an overriding "wt" parameter is also provided. Jersey (which is used for v2 requests) actually obeys the "Accept" header out of the box, but a bug in our `MediaTypeOverridingFilter` (which implements the 'wt' override) was causing the value of "Accept" to be ignored altogether. With this change, the order of precedence for v2 APIs is: `wt` parameter, then `Accept` header, and lastly "JSON" is used as a fallback/default. # Tests TBD - still need tests here to ensure that v2 APIs obey common 'wt' and Accept header values. # 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. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation) - [x] 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] [Commented] (SOLR-10998) Support "Accept" request header as alternative to "wt" parameter
[
https://issues.apache.org/jira/browse/SOLR-10998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935152#comment-17935152
]
Jason Gerlowski commented on SOLR-10998:
Jersey obeys "Accept" headers out of the box, so we largely already support
this in our Jersey-based v2 APIs. (Though our support of 'wt' as an override
introduced a small bug.) I've opened a [PR
here|https://github.com/apache/solr/pull/3262] to fix this bug and add better
tests around v2's support for "content negotiation".
> Support "Accept" request header as alternative to "wt" parameter
>
>
> Key: SOLR-10998
> URL: https://issues.apache.org/jira/browse/SOLR-10998
> Project: Solr
> Issue Type: Improvement
> Components: Server
>Reporter: Jan Høydahl
>Priority: Major
> Labels: http-headers, pull-request-available, standards
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Spinoff from
> [email|https://lists.apache.org/thread.html/b4ec90b01bc075a98947e77b0a683308f760221dccb11be5819d1601@%3Cdev.lucene.apache.org%3E]
> Advertises which content types, expressed as MIME types, the client is able
> to understand
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept]
> Could replace or at least be an alternative to “wt”. Examples:
> Accept: application/xml
> Accept: text/csv
> Issue: Most browsers sends a long accept header, typically
> application/xml,text/html, {{\*/\*}} , and now that json is default for Solr,
> we’d need to serve JSON if the accept header includes “\*/\*"
--
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-10998) Support "Accept" request header as alternative to "wt" parameter
[
https://issues.apache.org/jira/browse/SOLR-10998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-10998:
--
Labels: http-headers pull-request-available standards (was: http-headers
standards)
> Support "Accept" request header as alternative to "wt" parameter
>
>
> Key: SOLR-10998
> URL: https://issues.apache.org/jira/browse/SOLR-10998
> Project: Solr
> Issue Type: Improvement
> Components: Server
>Reporter: Jan Høydahl
>Priority: Major
> Labels: http-headers, pull-request-available, standards
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Spinoff from
> [email|https://lists.apache.org/thread.html/b4ec90b01bc075a98947e77b0a683308f760221dccb11be5819d1601@%3Cdev.lucene.apache.org%3E]
> Advertises which content types, expressed as MIME types, the client is able
> to understand
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept]
> Could replace or at least be an alternative to “wt”. Examples:
> Accept: application/xml
> Accept: text/csv
> Issue: Most browsers sends a long accept header, typically
> application/xml,text/html, {{\*/\*}} , and now that json is default for Solr,
> we’d need to serve JSON if the accept header includes “\*/\*"
--
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
