Re: [PR] SOLR-17556: Examples should run with the standard & recommended Solr home and solr data dir [solr]
epugh merged PR #2861: URL: https://github.com/apache/solr/pull/2861 -- 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-17556) Examples should run with the standard & recommended Solr process
[ https://issues.apache.org/jira/browse/SOLR-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900347#comment-17900347 ] ASF subversion and git services commented on SOLR-17556: Commit 620175a5626e69823b5aec8e20734a6352195000 in solr's branch refs/heads/main from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=solr.git;h=620175a5626 ] SOLR-17556: Examples should run with the standard & recommended Solr home and solr data dir (#2861) * Have techproducts, films, and schemaless all start in the normal solr home. Only -e cloud generates it's individual node files in ./example/cloud/node1, node2 etc... * Update the ref guide to consistently use -Dsolr.modules settings instead of relying on on the declaration. - Co-authored-by: Houston Putman > Examples should run with the standard & recommended Solr process > > > Key: SOLR-17556 > URL: https://issues.apache.org/jira/browse/SOLR-17556 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: examples >Reporter: Houston Putman >Assignee: Eric Pugh >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > Right now, there is a lot of special logic around how examples are started. > However we should get to a place where examples are merely data (+ > configSets) added to the generic Solr install. For the cloud example, it > should still start a number of Solr processes. > Also these examples can use modules via directives in the configSet. We > should move away from this, and have the Solr processes be started with > "-Dsolr.modules", as is recommended in the refGuide. (The directives > will also be removed in 10.0, so this is important to change before that > happens.) -- 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] User Behavior Insights implementation for Apache Solr [solr]
epugh commented on PR #2452: URL: https://github.com/apache/solr/pull/2452#issuecomment-2493648147 Hey, we now have a website! http://ubisearch.dev for more info! -- 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-17570) cursorMark should assume minExactCount=0
[
https://issues.apache.org/jira/browse/SOLR-17570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900460#comment-17900460
]
Chris M. Hostetter commented on SOLR-17570:
---
{quote}Unfortunately I think we have no way to completely disable numFound. if
minExactCount is 0, this is our only way to basically convey that in a
round-about way; do you agree?
{quote}
Agree? ... but your wording has me suspicious that it's a trick question,
because it doesn't even seem that roundabout -- isn't that the exact purpose of
being able to set {{minExactCount=0}} ?
But again: I'm not very familiar with the {{minExactCount}} feature...
>From what you're saying though it sounds like we still always return a
>{{numFound}} no matter what – it's just that that {{numFound}} is no longer
>exact ... which thinking about it more makes me more concerned about the
>backcompat situation (if there is someone out there using {{cursorMark}} that
>*does* care about {{numFound}} i really don't like the idea that on upgrading
>to some future version of Solr their {{numFound}} is now silently "wrong"
>because we changed the default of {{minExactCount}} when using
>{{{}cursorMark{}}}.
Which brings me back to...
{quote}(Although to be really good about backcompat in the same way we have in
the past for changing defaults like this: the default value of
{{minExactCount}} should be based on _both_ {{cursorMark}} being non-null and
luceneMatchVersion < XXX – where XXX is whatever value is in the defualt
configset in the version of solr where you make this change)
{quote}
> cursorMark should assume minExactCount=0
>
>
> Key: SOLR-17570
> URL: https://issues.apache.org/jira/browse/SOLR-17570
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Priority: Major
>
> Claim: Someone using cursorMark (deep paging) probably doesn't care about
> numFound at all, and thus could set minExactCount=0 param. And if they want
> to know, they either find out on the first page straight away (nextCursorMark
> is absent) or failing that, it could send a query purely to ascertain what
> numFound is if it doesn't want to page to the end.
> I see no test with both functionalities together. I think it should work
> this way by default. I tried this with a quick hack using
> DistribCursorPagingTest and it triggered an assertion in
> {{org.apache.solr.search.SolrIndexSearcher#sortDocSet}} that didn't need to
> be there -- it can be removed. The functionality worked.
--
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-17540: Remove Hadoop Auth Module [solr]
epugh commented on PR #2835: URL: https://github.com/apache/solr/pull/2835#issuecomment-2493669806 Would someone be willing to look at what is going on in SolrDispatchFilter? Around https://github.com/apache/solr/blob/620175a5626e69823b5aec8e20734a6352195000/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L336 it appears that MAYBE there is an opportunity for some refactoring to simplify the flow... Especially since we specifically mention the Hadoop Auth as the reason for the extra complexity.. I do not understand this bit and would love another set of eyes I could also see a path to updating the very lengthy comments to say "This has complexity due to hadoop auth partially, and now that it is gone there may be an opportunity for improvement"... -- 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] Support concurrency when reading transaction log encryption header. [solr-sandbox]
bruno-roustant merged PR #112: URL: https://github.com/apache/solr-sandbox/pull/112 -- 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-17569: fix flaky test TestLBHttpSolrClient (9.x) / LBHttp2SolrClientIntegrationTest (main) [solr]
jdyer1 opened a new pull request, #2884: URL: https://github.com/apache/solr/pull/2884 1. Remove "testReliability" because it had no asserts. 2. For "testTwoServers" and "testSimple", wait for the alive check query to be logged after restarting the node. Previously a blind "Thread.sleep" was in use. -- 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-17569) TestLBHttpSolrClient/LBHttp2SolrClientIntegrationTest unreproducible test failures
[
https://issues.apache.org/jira/browse/SOLR-17569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17569:
--
Labels: pull-request-available (was: )
> TestLBHttpSolrClient/LBHttp2SolrClientIntegrationTest unreproducible test
> failures
> ---
>
> Key: SOLR-17569
> URL: https://issues.apache.org/jira/browse/SOLR-17569
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: James Dyer
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *TestLBHttpSolrClient* (branch_9x) was renamed to
> *LBHttp2SolrClientIntegrationTest* and has a high failure rate. These
> failures are not reproducible. Consider altering the test technique to
> eliminate false-positive failures.
> -
> {noformat}
> Build:
> https://ci-builds.apache.org/job/Solr/job/Solr-BadApples-Tests-main/1486/
> 1 tests failed.
> Build:
> https://ci-builds.apache.org/job/Solr/job/Solr-BadApples-Tests-main/1486/
> FAILED: org.apache.solr.client.solrj.TestLBHttp2SolrClient.testSimple
> Error Message:
> java.lang.AssertionError: expected:<3> but was:<2>
> Stack Trace:
> java.lang.AssertionError: expected:<3> but was:<2>
> at
> __randomizedtesting.SeedInfo.seed([3CF24FAC059E0DDC:4416B52226DD90D]:0)
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.solr.client.solrj.TestLBHttp2SolrClient.testSimple(TestLBHttp2SolrClient.java:165)
> Reproduce with: ./gradlew :solr:solrj:test --tests
> "org.apache.solr.client.solrj.TestLBHttp2SolrClient.testSimple"
> -Ptests.jvms=4 -Ptests.haltonfailure=false
> "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:+UseParallelGC
> -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
> -Ptests.seed=3CF24FAC059E0DDC -Ptests.multiplier=2 -Ptests.badapples=true
> -Ptests.file.encoding=US-ASCII
> {noformat}
> -
> {noformat}
> Build: https://ci-builds.apache.org/job/Solr/job/Solr-Test-9.x/6323/
> 1 tests failed.
> FAILED: org.apache.solr.client.solrj.TestLBHttp2SolrClient.testTwoServers
> Error Message:
> org.apache.solr.client.solrj.SolrServerException: Total timeout 2000 ms
> elapsed
> Stack Trace:
> org.apache.solr.client.solrj.SolrServerException: Total timeout 2000 ms
> elapsed
> at
> __randomizedtesting.SeedInfo.seed([C10E68448E178BC0:61E4C6C9555CA5E0]:0)
> at
> app//org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:562)
> at
> app//org.apache.solr.client.solrj.impl.LBSolrClient.lambda$doRequest$0(LBSolrClient.java:558)
> at
> app//org.apache.solr.client.solrj.impl.Http2SolrClient.requestWithBaseUrl(Http2SolrClient.java:604)
> at
> app//org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:558)
> at
> app//org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:809)
> at
> app//org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:753)
> at
> app//org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:279)
> at
> app//org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:927)
> at
> app//org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:940)
> at
> app//org.apache.solr.client.solrj.TestLBHttp2SolrClient.testTwoServers(TestLBHttp2SolrClient.java:202)
> ...etc...
> Caused by: java.util.concurrent.TimeoutException: Total timeout 2000 ms
> elapsed
> at
> org.eclipse.jetty.client.HttpDestination$RequestTimeouts.onExpired(HttpDestination.java:608)
> at
> org.eclipse.jetty.client.HttpDestination$RequestTimeouts.onExpired(HttpDestination.java:591)
> at
> org.eclipse.jetty.io.CyclicTimeouts.onTimeoutExpired(CyclicTimeouts.java:110)
> at
> org.eclipse.jetty.io.CyclicTimeouts$Timeouts.onTimeoutExpired(CyclicTimeouts.java:197)
> at
> org.eclipse.jetty.io.CyclicTimeout$Wakeup.run(CyclicTimeout.java:294)
> Reproduce with: ./gradlew :solr:solrj:test --tests
> "org.apache.solr.client.solrj.TestLBHttp2SolrClient.testTwoServers"
> -Ptests.jvms=4 -Ptests.haltonfailure=false
> "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:+UseParallelGC
> -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
> -Ptests.seed=C10E68448E178BC0 -Ptests.multiplier=2 -Ptests.badapples=false
> -Ptests.file.encoding=ISO-8859-1
> {noformat}
> -
> {noformat}
> Build: https://ci-builds.apache.org/job/Solr/job/Solr-Test-main/9375/
> 1 tests failed.
> FAILED: org.apache.solr.client.solr
[jira] [Commented] (SOLR-17564) Assign.java is unnecessarily complex because of back-compat fixes
[ https://issues.apache.org/jira/browse/SOLR-17564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900488#comment-17900488 ] ASF subversion and git services commented on SOLR-17564: Commit 9ae053218b9398fb5335a9b398cc359ceb10c8f7 in solr's branch refs/heads/main from pjmcarthur [ https://gitbox.apache.org/repos/asf?p=solr.git;h=9ae053218b9 ] SOLR-17564 Assign.java: remove old back-compat logic (#2871) Remove code in Assign.java that was required for compatibility with collections created before 7.0 Assign is part of SolrCloud's replica naming and node assignment logic. Co-authored-by: pmcarthur-apache > Assign.java is unnecessarily complex because of back-compat fixes > - > > Key: SOLR-17564 > URL: https://issues.apache.org/jira/browse/SOLR-17564 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: main (10.0) >Reporter: Paul McArthur >Priority: Minor > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > SOLR-11011 introduced a significant amount of code in the Assign class to > handle backwards compatibility with existing collections and allow upgrades > from 6.x to 7.0. > As long as it is safe to assume that the `counter` node in ZooKeeper to count > replicas and create core node names exists for all collections, this code can > be removed, leading to significant simplification and easier maintenance. -- 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-17564) Assign.java is unnecessarily complex because of back-compat fixes
[ https://issues.apache.org/jira/browse/SOLR-17564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-17564. - Fix Version/s: main (10.0) Resolution: Fixed Merged. SolrCloud is getting a little simpler bit by bit. Thanks Paul! > Assign.java is unnecessarily complex because of back-compat fixes > - > > Key: SOLR-17564 > URL: https://issues.apache.org/jira/browse/SOLR-17564 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: main (10.0) >Reporter: Paul McArthur >Priority: Minor > Labels: pull-request-available > Fix For: main (10.0) > > Time Spent: 20m > Remaining Estimate: 0h > > SOLR-11011 introduced a significant amount of code in the Assign class to > handle backwards compatibility with existing collections and allow upgrades > from 6.x to 7.0. > As long as it is safe to assume that the `counter` node in ZooKeeper to count > replicas and create core node names exists for all collections, this code can > be removed, leading to significant simplification and easier maintenance. -- 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-17564: Remove backwards compatibility code from Assign [solr]
dsmiley merged PR #2871: URL: https://github.com/apache/solr/pull/2871 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-16470) Create V2 equivalent of V1 Replication: Get IndexVersion, Get FileStream, Get File List
[ https://issues.apache.org/jira/browse/SOLR-16470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900449#comment-17900449 ] Jason Gerlowski edited comment on SOLR-16470 at 11/22/24 4:30 PM: -- Alright - here's another v2 ticket closed out. Thanks for all your work on this Matt and Sanjay! was (Author: gerlowskija): Alright - here's another v2 ticket closed out. Thanks for all your work on this Matt! > Create V2 equivalent of V1 Replication: Get IndexVersion, Get FileStream, Get > File List > --- > > Key: SOLR-16470 > URL: https://issues.apache.org/jira/browse/SOLR-16470 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.2 >Reporter: Sanjay Dutt >Assignee: Jason Gerlowski >Priority: Major > Labels: V2, newdev, pull-request-available > Fix For: 9.8 > > Time Spent: 7h 40m > Remaining Estimate: 0h > > Replication Handler has no v2 equivalent. This ticket is covering few > endpoints from ReplicationHandler such as Get IndexVersion, Get FileStream, > Get File List. > Existing V1 > |-GET /solr/collName/replication?command=indexversion-| > |GET /solr/collName/replication?command=filecontent| > |-GET /solr/collName/replication?command=filelist-| > Proposed API design > |-GET /api/cores/coreName/replication/indexversion-| > |GET /api/cores/coreName/replication/files/filePath| > |-GET /api/cores/coreName/replication/files-| > few other pointers that might be helpful, especially for newcomers: > * The v1 logic for this API lives in ReplicationHandler > * [Some discussion of how APIs work in Solr (Particularly the "APIs in Solr" > section.)|https://github.com/apache/solr/blob/main/dev-docs/apis.adoc#apis-in-solr] > * [A step-by-step guide to creating APIs using the preferred v2 API > framework|https://github.com/apache/solr/blob/main/dev-docs/apis.adoc#writing-jax-rs-apis] > * [A recent PR that adds a v2 API, as an > example|https://github.com/apache/solr/pull/2144] > -- 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-16470) Create V2 equivalent of V1 Replication: Get IndexVersion, Get FileStream, Get File List
[ https://issues.apache.org/jira/browse/SOLR-16470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski resolved SOLR-16470. Fix Version/s: 9.8 Assignee: Jason Gerlowski Resolution: Fixed Alright - here's another v2 ticket closed out. Thanks for all your work on this Matt! > Create V2 equivalent of V1 Replication: Get IndexVersion, Get FileStream, Get > File List > --- > > Key: SOLR-16470 > URL: https://issues.apache.org/jira/browse/SOLR-16470 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.2 >Reporter: Sanjay Dutt >Assignee: Jason Gerlowski >Priority: Major > Labels: V2, newdev, pull-request-available > Fix For: 9.8 > > Time Spent: 7h 40m > Remaining Estimate: 0h > > Replication Handler has no v2 equivalent. This ticket is covering few > endpoints from ReplicationHandler such as Get IndexVersion, Get FileStream, > Get File List. > Existing V1 > |-GET /solr/collName/replication?command=indexversion-| > |GET /solr/collName/replication?command=filecontent| > |-GET /solr/collName/replication?command=filelist-| > Proposed API design > |-GET /api/cores/coreName/replication/indexversion-| > |GET /api/cores/coreName/replication/files/filePath| > |-GET /api/cores/coreName/replication/files-| > few other pointers that might be helpful, especially for newcomers: > * The v1 logic for this API lives in ReplicationHandler > * [Some discussion of how APIs work in Solr (Particularly the "APIs in Solr" > section.)|https://github.com/apache/solr/blob/main/dev-docs/apis.adoc#apis-in-solr] > * [A step-by-step guide to creating APIs using the preferred v2 API > framework|https://github.com/apache/solr/blob/main/dev-docs/apis.adoc#writing-jax-rs-apis] > * [A recent PR that adds a v2 API, as an > example|https://github.com/apache/solr/pull/2144] > -- 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] [WIP] Jetty12 + EE8 [solr]
iamsanjay commented on PR #2876: URL: https://github.com/apache/solr/pull/2876#issuecomment-2493848687 For S3Mock, the library is upgraded to support Jetty12. Test cases are running now! For s3mock to deal in separate PR, I tried to maintain two different set of jetty(10 & 12), but there were conflict errors. So for now I just upgraded s3Mock libs to also use Jetty12. Facing some issues with gcs-repository. Running successfully as Intellij test but failing If run via gradlew. ``` ./gradlew :solr:modules:gcs-repository:test --tests "org.apache.solr.gcs.GCSIncrementalBackupTest" -Ptests.jvms=96 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m" -Ptests.seed=90E261AA14A5CB20 -Ptests.timeoutSuite=60! -Ptests.file.encoding=US-ASCII --debug ``` ``` java.lang.IllegalStateException: Unable to locate keystore resource file in classpath: SSLTestConfig.hostname-and-ip-missmatch.keystore at __randomizedtesting.SeedInfo.seed([90E261AA14A5CB20]:0) at org.apache.solr.util.SSLTestConfig.(SSLTestConfig.java:121) at org.apache.solr.util.SSLTestConfig.(SSLTestConfig.java:83) at org.apache.solr.util.RandomizeSSL$SSLRandomizer.createSSLTestConfig(RandomizeSSL.java:129) at org.apache.solr.SolrTestCaseJ4.buildSSLConfig(SolrTestCaseJ4.java:475) at org.apache.solr.SolrTestCaseJ4.setupTestCases(SolrTestCaseJ4.java:298) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) ``` I did changed some code in SSLTestConfig ``` - trustStore = keyStore = Resource.newClassPathResource(resourceName); + trustStore = keyStore = ResourceFactory.root().newSystemResource(resourceName); ``` -- 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: Update CLI tools to use java.nio.file.Path instead of java.io.File [solr]
AndreyBozhko commented on code in PR #2883:
URL: https://github.com/apache/solr/pull/2883#discussion_r1854492803
##
solr/core/src/test/org/apache/solr/cli/PostToolTest.java:
##
@@ -281,15 +281,15 @@ public void testAppendUrlPath() {
@Test
public void testGuessType() {
File f = new File("foo.doc");
Review Comment:
Yes - but I thought it was best to update the test files separately and at a
later point.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-16903: Update CLI tools to use java.nio.file.Path instead of java.io.File [solr]
epugh commented on code in PR #2883:
URL: https://github.com/apache/solr/pull/2883#discussion_r1854635328
##
solr/core/src/test/org/apache/solr/cli/PostToolTest.java:
##
@@ -281,15 +281,15 @@ public void testAppendUrlPath() {
@Test
public void testGuessType() {
File f = new File("foo.doc");
Review Comment:
awesome!
--
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-17540: Remove Hadoop Auth Module [solr]
gus-asf commented on PR #2835:
URL: https://github.com/apache/solr/pull/2835#issuecomment-2494228698
> Would someone be willing to look at what is going on in
SolrDispatchFilter? Around
>
>
https://github.com/apache/solr/blob/620175a5626e69823b5aec8e20734a6352195000/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L336
> it appears that MAYBE there is an opportunity for some refactoring to
simplify the flow... Especially since we specifically mention the Hadoop Auth
as the reason for the extra complexity.. I do not understand this bit and would
love another set of eyes I could also see a path to updating the very
lengthy comments to say "This has complexity due to hadoop auth partially, and
now that it is gone there may be an opportunity for improvement"...
I wrote that comment to memorialize several hours of digging I did back when
I moved startup to a context listener. One of the things I found perplexing
about SolrDispatchFilter when I first tried to understand it for that task was
the lack of a call to doFilter(req,resp,filterchain) ... note that our custom
version with the boolean retry doesn't count, because it doesn't make the
normal call to the method specified by javax.servlet.Filter. Normally filter
implementations look like:
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain)
throws IOException, ServletException {
// Do stuff, that seems important here
if (importantStuffSeemsHappy) {
chain.doFilter(request, response, chain);
} else {
// do unhappy error type stuff.
}
// add try/finally if there is mandatory cleanup.
}
}
So it was very weird not to find a call to doFilter in the doFilter method,
nor in our custom version of it. EVENTUALLY I figured out that that call is
made either in the dispatch method, OR in our auth filter (I haven't tried to
prove it can't get called twice, but with just SolrDispatchFilter in play that
is not currently going to cause a problem since chain.doFilter is a no-op for
the final filter). One of the long term goals I have is to start pulling stuff
that we are doing in this monster filter out int a series of filters, which
will make the individual missions easier to understand and put the cleanup code
near the instantiation code where, again it would be much easier to understand
(and nesting can be easily seen to be correct).
My impulse (not yet informed by actual attempts) is to rework our auth
plugin to be auth filters. The other thing I'm pointing out in that comment is
that the HadoopAuthFilter is what seems to stand in the way of writing an if
block such as:
if (authPlugin.authenticate(req, resp)) {// <<< note the
lack of filterchain arg
// do searchy stuff here
chain.doFilter(request, response, chain);
} else {
// do unhappy 401 error type stuff.
}
// add try/finally for mandatory cleanups.
}
That is of course the first step to breaking auth out to it's own filter
where it becomes
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain)
throws IOException, ServletException {
if (authPlugin.authenticate(req, resp)) {
chain.doFilter(request, response, chain); // <<< dispatch filter
is later in the chain.
} else {
// do unhappy 401 error type stuff.
}
// add try/finally for mandatory cleanups.
}
The particular issue with the hadoop auth plugin that complicates the
transition is that chain.doFilter() comes before a switch statement and other
code...
https://github.com/apache/solr/blob/6f94c505fc923c452c58c2a3946ee4408ea06fac/solr/modules/hadoop-auth/src/java/org/apache/solr/security/hadoop/HadoopAuthPlugin.java#L247
At least at the time of that comment it seemed that all the other plugins
called chain.doFilter() at the end (or possibly in a shortcut followed by an
immediate return statement). Only Hadoop auth seemed to have mandatory actions
AFTER doFilter(). If it disappears, we can possibly remove the filterchain
argument and make a simpler use of the return value from authenticate().
--
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-17556) Examples should run with the standard & recommended Solr process
[ https://issues.apache.org/jira/browse/SOLR-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900360#comment-17900360 ] ASF subversion and git services commented on SOLR-17556: Commit c85c3bed9aa883aa62dc0bdf606f788cfbd75448 in solr's branch refs/heads/branch_9x from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=solr.git;h=c85c3bed9aa ] Support backport of SOLR-17556 > Examples should run with the standard & recommended Solr process > > > Key: SOLR-17556 > URL: https://issues.apache.org/jira/browse/SOLR-17556 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: examples >Reporter: Houston Putman >Assignee: Eric Pugh >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > Right now, there is a lot of special logic around how examples are started. > However we should get to a place where examples are merely data (+ > configSets) added to the generic Solr install. For the cloud example, it > should still start a number of Solr processes. > Also these examples can use modules via directives in the configSet. We > should move away from this, and have the Solr processes be started with > "-Dsolr.modules", as is recommended in the refGuide. (The directives > will also be removed in 10.0, so this is important to change before that > happens.) -- 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-17556) Examples should run with the standard & recommended Solr process
[ https://issues.apache.org/jira/browse/SOLR-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900359#comment-17900359 ] ASF subversion and git services commented on SOLR-17556: Commit 98bf0497efd98e6f1c640173038d635a5f99362e in solr's branch refs/heads/branch_9x from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=solr.git;h=98bf0497efd ] SOLR-17556: Examples should run with the standard & recommended Solr home and solr data dir (#2861) * Have techproducts, films, and schemaless all start in the normal solr home. Only -e cloud generates it's individual node files in ./example/cloud/node1, node2 etc... * Update the ref guide to consistently use -Dsolr.modules settings instead of relying on on the declaration. - Co-authored-by: Houston Putman (cherry picked from commit 620175a5626e69823b5aec8e20734a6352195000) > Examples should run with the standard & recommended Solr process > > > Key: SOLR-17556 > URL: https://issues.apache.org/jira/browse/SOLR-17556 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: examples >Reporter: Houston Putman >Assignee: Eric Pugh >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > Right now, there is a lot of special logic around how examples are started. > However we should get to a place where examples are merely data (+ > configSets) added to the generic Solr install. For the cloud example, it > should still start a number of Solr processes. > Also these examples can use modules via directives in the configSet. We > should move away from this, and have the Solr processes be started with > "-Dsolr.modules", as is recommended in the refGuide. (The directives > will also be removed in 10.0, so this is important to change before that > happens.) -- 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-17556) Examples should run with the standard & recommended Solr process
[ https://issues.apache.org/jira/browse/SOLR-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-17556. -- Fix Version/s: 9.8 Resolution: Fixed > Examples should run with the standard & recommended Solr process > > > Key: SOLR-17556 > URL: https://issues.apache.org/jira/browse/SOLR-17556 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: examples >Reporter: Houston Putman >Assignee: Eric Pugh >Priority: Major > Labels: pull-request-available > Fix For: 9.8 > > Time Spent: 1h > Remaining Estimate: 0h > > Right now, there is a lot of special logic around how examples are started. > However we should get to a place where examples are merely data (+ > configSets) added to the generic Solr install. For the cloud example, it > should still start a number of Solr processes. > Also these examples can use modules via directives in the configSet. We > should move away from this, and have the Solr processes be started with > "-Dsolr.modules", as is recommended in the refGuide. (The directives > will also be removed in 10.0, so this is important to change before that > happens.) -- 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-16470) Create V2 equivalent of V1 Replication: Get IndexVersion, Get FileStream, Get File List
[ https://issues.apache.org/jira/browse/SOLR-16470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900395#comment-17900395 ] ASF subversion and git services commented on SOLR-16470: Commit 6f94c505fc923c452c58c2a3946ee4408ea06fac in solr's branch refs/heads/main from Matthew Biscocho [ https://gitbox.apache.org/repos/asf?p=solr.git;h=6f94c505fc9 ] SOLR-16470: Create v2 replication "fetch file" API (#2734) New v2 API is available at `GET /api/cores/coreName/replication/files/fileName` - Co-authored-by: Matthew Biscocho Co-authored-by: Jason Gerlowski > Create V2 equivalent of V1 Replication: Get IndexVersion, Get FileStream, Get > File List > --- > > Key: SOLR-16470 > URL: https://issues.apache.org/jira/browse/SOLR-16470 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.2 >Reporter: Sanjay Dutt >Priority: Major > Labels: V2, newdev, pull-request-available > Time Spent: 7h 40m > Remaining Estimate: 0h > > Replication Handler has no v2 equivalent. This ticket is covering few > endpoints from ReplicationHandler such as Get IndexVersion, Get FileStream, > Get File List. > Existing V1 > |-GET /solr/collName/replication?command=indexversion-| > |GET /solr/collName/replication?command=filecontent| > |-GET /solr/collName/replication?command=filelist-| > Proposed API design > |-GET /api/cores/coreName/replication/indexversion-| > |GET /api/cores/coreName/replication/files/filePath| > |-GET /api/cores/coreName/replication/files-| > few other pointers that might be helpful, especially for newcomers: > * The v1 logic for this API lives in ReplicationHandler > * [Some discussion of how APIs work in Solr (Particularly the "APIs in Solr" > section.)|https://github.com/apache/solr/blob/main/dev-docs/apis.adoc#apis-in-solr] > * [A step-by-step guide to creating APIs using the preferred v2 API > framework|https://github.com/apache/solr/blob/main/dev-docs/apis.adoc#writing-jax-rs-apis] > * [A recent PR that adds a v2 API, as an > example|https://github.com/apache/solr/pull/2144] > -- 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-16470: Create V2 equivalent of V1 Replication: Get files/{filePath} [solr]
gerlowskija merged PR #2734: URL: https://github.com/apache/solr/pull/2734 -- 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-16781: Remove solrconfig.xml directives [solr]
epugh commented on PR #2875: URL: https://github.com/apache/solr/pull/2875#issuecomment-2493636331 @gerlowskija FYI I merged and backported https://issues.apache.org/jira/browse/SOLR-17556 to clear the decks, but which may impact this a bit. I think you plan for beefing up bin/solr start -e techproducts is a "good 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
Re: [PR] SolrTestCase now supports @LogLevel [solr]
hossman commented on PR #2869: URL: https://github.com/apache/solr/pull/2869#issuecomment-2494322602 I don't know about the `shutdown()` changes, but moving this logic into a `Rule` seems great, and and using that `@Rule` in `SolrTestCase` (instead of `SolrTestCaseJ4`) seems fine... But I'm curious: why not just leave that `@Rule` in `SolrTestCaseJ4` (for backcompat) and let any other `SolrTestCase` subclasses that want to use this functionality add the `@Rule` themselves? ... isn't that the real value of the `Rule` API, that's it's easy to wire in and mix/match? Either way I would suggest updating the `TestLogLevelAnnotations extends ...` declaration to use `SolrTestCase` -- that's the best way to "prove" that making these changes "works".(There are also some comments in that class that probably need updated? ... i think the code they comment is all still true, but they make references to `SolrTestCaseJ4` that should probably now refer to something 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
[jira] [Commented] (SOLR-16470) Create V2 equivalent of V1 Replication: Get IndexVersion, Get FileStream, Get File List
[ https://issues.apache.org/jira/browse/SOLR-16470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900417#comment-17900417 ] ASF subversion and git services commented on SOLR-16470: Commit 0cf4183c48c6e2118e09e733cd2ed8a3817becd6 in solr's branch refs/heads/branch_9x from Matthew Biscocho [ https://gitbox.apache.org/repos/asf?p=solr.git;h=0cf4183c48c ] SOLR-16470: Create v2 replication "fetch file" API (#2734) New v2 API is available at `GET /api/cores/coreName/replication/files/fileName` - Co-authored-by: Matthew Biscocho Co-authored-by: Jason Gerlowski > Create V2 equivalent of V1 Replication: Get IndexVersion, Get FileStream, Get > File List > --- > > Key: SOLR-16470 > URL: https://issues.apache.org/jira/browse/SOLR-16470 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.2 >Reporter: Sanjay Dutt >Priority: Major > Labels: V2, newdev, pull-request-available > Time Spent: 7h 40m > Remaining Estimate: 0h > > Replication Handler has no v2 equivalent. This ticket is covering few > endpoints from ReplicationHandler such as Get IndexVersion, Get FileStream, > Get File List. > Existing V1 > |-GET /solr/collName/replication?command=indexversion-| > |GET /solr/collName/replication?command=filecontent| > |-GET /solr/collName/replication?command=filelist-| > Proposed API design > |-GET /api/cores/coreName/replication/indexversion-| > |GET /api/cores/coreName/replication/files/filePath| > |-GET /api/cores/coreName/replication/files-| > few other pointers that might be helpful, especially for newcomers: > * The v1 logic for this API lives in ReplicationHandler > * [Some discussion of how APIs work in Solr (Particularly the "APIs in Solr" > section.)|https://github.com/apache/solr/blob/main/dev-docs/apis.adoc#apis-in-solr] > * [A step-by-step guide to creating APIs using the preferred v2 API > framework|https://github.com/apache/solr/blob/main/dev-docs/apis.adoc#writing-jax-rs-apis] > * [A recent PR that adds a v2 API, as an > example|https://github.com/apache/solr/pull/2144] > -- 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-16781: Remove solrconfig.xml directives [solr]
gerlowskija commented on PR #2875: URL: https://github.com/apache/solr/pull/2875#issuecomment-2494094532 > how do you want to handle https://github.com/apache/solr/pull/2861? Should it go in first, or after? Sorry - missed this comment the other day. I'm glad I didn't prevent you from merging 2861 - I'm 👍 to incorporate any fallout into 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
[jira] [Commented] (SOLR-17540) Remove hadoop-auth module
[ https://issues.apache.org/jira/browse/SOLR-17540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900437#comment-17900437 ] Eric Pugh commented on SOLR-17540: -- When the PR is merged, we need to go through Jira and update related tickets as either Won't Fix or Abandoned. This query surfaces 35 of them! https://issues.apache.org/jira/browse/SOLR-9496?jql=project%20%3D%20SOLR%20AND%20status%20in%20(Open%2C%20Reopened%2C%20%22Patch%20Available%22)%20AND%20text%20~%20%22kerberos%22 > Remove hadoop-auth module > - > > Key: SOLR-17540 > URL: https://issues.apache.org/jira/browse/SOLR-17540 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: main (10.0) >Reporter: Eric Pugh >Priority: Minor > Labels: pull-request-available > Time Spent: 4h 20m > Remaining Estimate: 0h > > One of the outcomes of the 2024 Community Survey is that we learned (in our > admittedly fairly unscientific) responses that hadoop-auth is not used. > This PR is to understand the impact of removing hadoop-auth in Solr 10. > See [https://lists.apache.org/thread/vnd73j0nq3losfc17lzqp48g10r5tdgg] for > outreach to users mailing list. > See [https://lists.apache.org/thread/lltc0wjdghq18tt37zlrsd8ty35qsytl] for > discussion on Dev. > > I won't merge this PR till we have more consensus. -- 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
