[jira] [Commented] (SOLR-16573) SolrClientTestRule for EmbeddedSolrServer
[ https://issues.apache.org/jira/browse/SOLR-16573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686874#comment-17686874 ] ASF subversion and git services commented on SOLR-16573: Commit 704918b6ccfc2db9a688c1b715438a60ab87e259 in solr's branch refs/heads/main from David Smiley [ https://gitbox.apache.org/repos/asf?p=solr.git;h=704918b6ccf ] SOLR-16573: Fix test Windows path separator (#1347) > SolrClientTestRule for EmbeddedSolrServer > - > > Key: SOLR-16573 > URL: https://issues.apache.org/jira/browse/SOLR-16573 > Project: Solr > Issue Type: Sub-task >Reporter: David Smiley >Priority: Major > Time Spent: 10h 20m > Remaining Estimate: 0h > > See parent issue. Here, create a subclass of ExternalResource (a JUnit > TestRule, FYI compatible with JUnit 5) that provides access to a SolrClient, > or that might even be one itself (delegating the request method). Perhaps > name this "SolrClientTestRule". It will have subclasses for specific types, > initially just one using EmbeddedSolrServer. It should have a builder to > configure it. Some test classes can simply configure at its declaration but > note that others will need to do so afterwards (e.g. in a \@Before or a test > method). This utility should be in the test-framework and be designed to be > useful by external projects who write plugins or that want to test with an > embedded Solr. Therefore it should not contain code that assumes the file > system of the Solr project itself. > Out of scope are other implementations, and thus somehow choosing amongst > them. > Use this mechanism in EmbeddedSolrServerTestBase, ensuring that "TestHarness" > (from SolrTestCaseJ4) isn't used. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] dsmiley merged pull request #1347: SOLR-16573: Fix test Windows path separator
dsmiley merged PR #1347: URL: https://github.com/apache/solr/pull/1347 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] dsmiley opened a new pull request, #1347: SOLR-16573: Fix test Windows path separator
dsmiley opened a new pull request, #1347: URL: https://github.com/apache/solr/pull/1347 https://issues.apache.org/jira/browse/SOLR-16573 Fixing an oversight of mine in the configSet reference that can be a path and thus might be platform specific. Later I want to move this sort of logic to where the value is interpreted (FileSystemConfigSetService) instead of being in the test utility. -- 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-16441) Upgrade Jetty to 11.x
[ https://issues.apache.org/jira/browse/SOLR-16441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686864#comment-17686864 ] Vinod Singh edited comment on SOLR-16441 at 2/10/23 4:21 AM: - [Spring Boot 3|https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Release-Notes] also upgraded to Jetty 11. Until Solr client also upgrades to Jetty 11, any Spring Boot applications using Solr can't upgrade to version 3. was (Author: vi...@vinodsingh.com): [Spring Boot 3|https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Release-Notes] also upgraded to Jetty 11. Until Solr client also upgrades to Jetty 11, any Spring Boot applications using Sole can't upgrade to version 3. > Upgrade Jetty to 11.x > - > > Key: SOLR-16441 > URL: https://issues.apache.org/jira/browse/SOLR-16441 > Project: Solr > Issue Type: Improvement > Components: Server >Reporter: Tomas Eduardo Fernandez Lobbe >Priority: Major > > Solr is currently using Jetty 9.4.x and upgrading to Jetty 10.x in > SOLR-15955, we should look at upgrade to Jetty 11 which moves from javax to > jakarta namespace for servlet. > -- 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-16441) Upgrade Jetty to 11.x
[ https://issues.apache.org/jira/browse/SOLR-16441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686864#comment-17686864 ] Vinod Singh commented on SOLR-16441: [Spring Boot 3|https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Release-Notes] also upgraded to Jetty 11. Until Solr client also upgrades to Jetty 11, any Spring Boot applications using Sole can't upgrade to version 3. > Upgrade Jetty to 11.x > - > > Key: SOLR-16441 > URL: https://issues.apache.org/jira/browse/SOLR-16441 > Project: Solr > Issue Type: Improvement > Components: Server >Reporter: Tomas Eduardo Fernandez Lobbe >Priority: Major > > Solr is currently using Jetty 9.4.x and upgrading to Jetty 10.x in > SOLR-15955, we should look at upgrade to Jetty 11 which moves from javax to > jakarta namespace for servlet. > -- 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-16554) Update docs on filter cache
[ https://issues.apache.org/jira/browse/SOLR-16554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686778#comment-17686778 ] Andy Lester commented on SOLR-16554: Thanks for the interest. I forgot I had this open. I'm waiting until I have the ability to inspect cache contents so that I can write with certainty what's going on. That's dependent on Shawn's cache dumper tool. I'm also expecting to write docs about how to use the cache dumper tool as part of tuning. > Update docs on filter cache > --- > > Key: SOLR-16554 > URL: https://issues.apache.org/jira/browse/SOLR-16554 > Project: Solr > Issue Type: Improvement > Components: documentation, faceting >Reporter: Andy Lester >Priority: Minor > > The docs about the filter cache could use an update, especially more > discussion on how to tune it. > This is something I'm willing to take on, but would welcome help, especially > on delving in to Solr internals. > This ticket is intended as a place to aggregate discussion of the task, and > also notes related to this. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16563) Http2SolrClient should have a defaultCollection setting
[ https://issues.apache.org/jira/browse/SOLR-16563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686753#comment-17686753 ] Eric Pugh commented on SOLR-16563: -- I'd love to see a first draft! > Http2SolrClient should have a defaultCollection setting > --- > > Key: SOLR-16563 > URL: https://issues.apache.org/jira/browse/SOLR-16563 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Reporter: David Smiley >Assignee: Eric Pugh >Priority: Minor > > Similar to CloudSolrClient, Http2SolrClient ought to have a > "defaultCollection" setting. This ought to be used in preference to passing > a "baseUrl" with this collection/core embedded into it. Maybe the builder's > constructor should be overloaded to have a baseUrl + defaultCollection pair > as well. > Doing this would make it easier to issue an admin or any other node level > command using the same SolrClient instance, just as is possible with > CloudSolrClient and EmbeddedSolrServer. -- 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-16563) Http2SolrClient should have a defaultCollection setting
[ https://issues.apache.org/jira/browse/SOLR-16563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686746#comment-17686746 ] David Smiley commented on SOLR-16563: - I looked hard but can't find a recent proposal I did in Jira-- I don't think I proposed it in Slack. But I did find a better synthesis of my proposal in the description of SOLR-12502 This JIRA issue could implement my CollectionSolrClient proposal (a wrapper SolrClient), without having to spread the defaultCollection feature to any existing SolrClient (as that seems controversial maybe). I could do a first-draft if there is doubt on what it'd look like. > Http2SolrClient should have a defaultCollection setting > --- > > Key: SOLR-16563 > URL: https://issues.apache.org/jira/browse/SOLR-16563 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Reporter: David Smiley >Assignee: Eric Pugh >Priority: Minor > > Similar to CloudSolrClient, Http2SolrClient ought to have a > "defaultCollection" setting. This ought to be used in preference to passing > a "baseUrl" with this collection/core embedded into it. Maybe the builder's > constructor should be overloaded to have a baseUrl + defaultCollection pair > as well. > Doing this would make it easier to issue an admin or any other node level > command using the same SolrClient instance, just as is possible with > CloudSolrClient and EmbeddedSolrServer. -- 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-16563) Http2SolrClient should have a defaultCollection setting
[ https://issues.apache.org/jira/browse/SOLR-16563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686718#comment-17686718 ] Jan Høydahl commented on SOLR-16563: The QueryRequest stull is more long term since it will need a different set of method signatures on the clients. I don't know if there will be consensus for removing defaultCollection - we disussed it somewhere else recently, perhaps slack? > Http2SolrClient should have a defaultCollection setting > --- > > Key: SOLR-16563 > URL: https://issues.apache.org/jira/browse/SOLR-16563 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Reporter: David Smiley >Assignee: Eric Pugh >Priority: Minor > > Similar to CloudSolrClient, Http2SolrClient ought to have a > "defaultCollection" setting. This ought to be used in preference to passing > a "baseUrl" with this collection/core embedded into it. Maybe the builder's > constructor should be overloaded to have a baseUrl + defaultCollection pair > as well. > Doing this would make it easier to issue an admin or any other node level > command using the same SolrClient instance, just as is possible with > CloudSolrClient and EmbeddedSolrServer. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] janhoy commented on pull request #1346: SOLR-16457 Add symbolic link version of solr.install.dir to security.policy
janhoy commented on PR #1346: URL: https://github.com/apache/solr/pull/1346#issuecomment-1424675324 Found a bug while testing. Need to resolve `pwd -L` on the original script path, not on the already normalized physical `SOLR_TIP`. After fixing that it woks. I tested with: ```bash cd ~/git/solr/ gw dev cd /tmp/ # Create a symlink to solr to simulate how the installer does it, and the docker image ln -s ~/git/solr/solr/packaging/build/dev symdev cd symdev # add some lib folder to shared lib, using symlink path bin/solr -c -Dsolr.sharedLib=/tmp/symdev/modules/extraction/lib # Create collection with a config that contains /update/extract but no directives (hacked techproducts sample) bin/solr create -c tech -d /path/to/techproducts # Post a PDF, it will fail with classNotFound bin/post -c tech example/exampledocs/solr-word.pdf ``` -- 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-16628) Occasional resource leak around XmlConfigFile parsing
[ https://issues.apache.org/jira/browse/SOLR-16628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Gibney resolved SOLR-16628. --- Fix Version/s: 9.2 Assignee: Michael Gibney Resolution: Fixed > Occasional resource leak around XmlConfigFile parsing > -- > > Key: SOLR-16628 > URL: https://issues.apache.org/jira/browse/SOLR-16628 > Project: Solr > Issue Type: Bug >Affects Versions: 8.9 >Reporter: Michael Gibney >Assignee: Michael Gibney >Priority: Minor > Fix For: 9.2 > > Time Spent: 8h 20m > Remaining Estimate: 0h > > Currently, xml config file parsing can in exceptional circumstances lead to > resource leaks (InputStream not being closed). This has occasionally [shown > up in > tests|https://issues.apache.org/jira/browse/SOLR-16336?focusedCommentId=17678323#comment-17678323] > and presumably could also manifest in the wild. > I suspect (but am not certain) that these changes may have been introduced in > version 8.9 by SOLR-15337 (closing of byte streams in xml parsing is unusual > iiuc in that according to spec, closing is handled internal to the parser, so > it's easy to rely on that behavior and things will usually be ok. But we > should take extra steps to ensure the InputStreams are always closed). -- 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-16628) Occasional resource leak around XmlConfigFile parsing
[ https://issues.apache.org/jira/browse/SOLR-16628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686707#comment-17686707 ] ASF subversion and git services commented on SOLR-16628: Commit aef81de712d717fce3a50dc8b18774405524f8fd in solr's branch refs/heads/branch_9x from Michael Gibney [ https://gitbox.apache.org/repos/asf?p=solr.git;h=aef81de712d ] SOLR-16628: Ensure that InputStreams are closed after Xml parsing (#1302) (cherry picked from commit e20fcf857a32c9c2559ba91cfc68f2ebf5ea09e0) > Occasional resource leak around XmlConfigFile parsing > -- > > Key: SOLR-16628 > URL: https://issues.apache.org/jira/browse/SOLR-16628 > Project: Solr > Issue Type: Bug >Affects Versions: 8.9 >Reporter: Michael Gibney >Priority: Minor > Time Spent: 8h 20m > Remaining Estimate: 0h > > Currently, xml config file parsing can in exceptional circumstances lead to > resource leaks (InputStream not being closed). This has occasionally [shown > up in > tests|https://issues.apache.org/jira/browse/SOLR-16336?focusedCommentId=17678323#comment-17678323] > and presumably could also manifest in the wild. > I suspect (but am not certain) that these changes may have been introduced in > version 8.9 by SOLR-15337 (closing of byte streams in xml parsing is unusual > iiuc in that according to spec, closing is handled internal to the parser, so > it's easy to rely on that behavior and things will usually be ok. But we > should take extra steps to ensure the InputStreams are always closed). -- 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-16628) Occasional resource leak around XmlConfigFile parsing
[ https://issues.apache.org/jira/browse/SOLR-16628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686706#comment-17686706 ] ASF subversion and git services commented on SOLR-16628: Commit e20fcf857a32c9c2559ba91cfc68f2ebf5ea09e0 in solr's branch refs/heads/main from Michael Gibney [ https://gitbox.apache.org/repos/asf?p=solr.git;h=e20fcf857a3 ] SOLR-16628: Ensure that InputStreams are closed after Xml parsing (#1302) > Occasional resource leak around XmlConfigFile parsing > -- > > Key: SOLR-16628 > URL: https://issues.apache.org/jira/browse/SOLR-16628 > Project: Solr > Issue Type: Bug >Affects Versions: 8.9 >Reporter: Michael Gibney >Priority: Minor > Time Spent: 8h 20m > Remaining Estimate: 0h > > Currently, xml config file parsing can in exceptional circumstances lead to > resource leaks (InputStream not being closed). This has occasionally [shown > up in > tests|https://issues.apache.org/jira/browse/SOLR-16336?focusedCommentId=17678323#comment-17678323] > and presumably could also manifest in the wild. > I suspect (but am not certain) that these changes may have been introduced in > version 8.9 by SOLR-15337 (closing of byte streams in xml parsing is unusual > iiuc in that according to spec, closing is handled internal to the parser, so > it's easy to rely on that behavior and things will usually be ok. But we > should take extra steps to ensure the InputStreams are always closed). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] magibney merged pull request #1302: SOLR-16628: Ensure that InputStreams are closed after Xml parsing
magibney merged PR #1302: URL: https://github.com/apache/solr/pull/1302 -- 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-16563) Http2SolrClient should have a defaultCollection setting
[ https://issues.apache.org/jira/browse/SOLR-16563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686700#comment-17686700 ] Eric Pugh commented on SOLR-16563: -- [~janhoy] do you think that as part of THIS jira we should move it to QueryRequest and UpdateRequest? Or do I just deal with the Builder pattern of removing it, and then we create antother JIRA? > Http2SolrClient should have a defaultCollection setting > --- > > Key: SOLR-16563 > URL: https://issues.apache.org/jira/browse/SOLR-16563 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Reporter: David Smiley >Assignee: Eric Pugh >Priority: Minor > > Similar to CloudSolrClient, Http2SolrClient ought to have a > "defaultCollection" setting. This ought to be used in preference to passing > a "baseUrl" with this collection/core embedded into it. Maybe the builder's > constructor should be overloaded to have a baseUrl + defaultCollection pair > as well. > Doing this would make it easier to issue an admin or any other node level > command using the same SolrClient instance, just as is possible with > CloudSolrClient and EmbeddedSolrServer. -- 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-16563) Http2SolrClient should have a defaultCollection setting
[ https://issues.apache.org/jira/browse/SOLR-16563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686693#comment-17686693 ] Jan Høydahl commented on SOLR-16563: I'm OK with nuking defaultCollection. If anywhere I believe it belongs on QueryRequest and UpdateRequest objects rather than on the SolrClient. > Http2SolrClient should have a defaultCollection setting > --- > > Key: SOLR-16563 > URL: https://issues.apache.org/jira/browse/SOLR-16563 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Reporter: David Smiley >Assignee: Eric Pugh >Priority: Minor > > Similar to CloudSolrClient, Http2SolrClient ought to have a > "defaultCollection" setting. This ought to be used in preference to passing > a "baseUrl" with this collection/core embedded into it. Maybe the builder's > constructor should be overloaded to have a baseUrl + defaultCollection pair > as well. > Doing this would make it easier to issue an admin or any other node level > command using the same SolrClient instance, just as is possible with > CloudSolrClient and EmbeddedSolrServer. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #1346: SOLR-16457 Add symbolic link version of solr.install.dir to security.policy
risdenk commented on code in PR #1346: URL: https://github.com/apache/solr/pull/1346#discussion_r1101861421 ## solr/bin/solr.cmd: ## @@ -1397,15 +1397,15 @@ IF "%FG%"=="1" ( "%JAVA%" %SERVEROPT% %SOLR_JAVA_MEM% %START_OPTS% ^ -Dlog4j.configurationFile="%LOG4J_CONFIG%" -DSTOP.PORT=!STOP_PORT! -DSTOP.KEY=%STOP_KEY% ^ -Dsolr.solr.home="%SOLR_HOME%" -Dsolr.install.dir="%SOLR_TIP%" -Dsolr.default.confdir="%DEFAULT_CONFDIR%" ^ --Djetty.port=%SOLR_PORT% -Djetty.home="%SOLR_SERVER_DIR%" ^ +-Djetty.port=%SOLR_PORT% -Djetty.home="%SOLR_SERVER_DIR%" -Dsolr.install.symDir="%SOLR_TIP%" ^ -Djava.io.tmpdir="%SOLR_SERVER_DIR%\tmp" -jar start.jar %SOLR_JETTY_CONFIG% "%SOLR_JETTY_ADDL_CONFIG%" ) ELSE ( START /B "Solr-%SOLR_PORT%" /D "%SOLR_SERVER_DIR%" ^ "%JAVA%" %SERVEROPT% %SOLR_JAVA_MEM% %START_OPTS% ^ -Dlog4j.configurationFile="%LOG4J_CONFIG%" -DSTOP.PORT=!STOP_PORT! -DSTOP.KEY=%STOP_KEY% ^ -Dsolr.log.muteconsole ^ -Dsolr.solr.home="%SOLR_HOME%" -Dsolr.install.dir="%SOLR_TIP%" -Dsolr.default.confdir="%DEFAULT_CONFDIR%" ^ --Djetty.port=%SOLR_PORT% -Djetty.home="%SOLR_SERVER_DIR%" ^ +-Djetty.port=%SOLR_PORT% -Djetty.home="%SOLR_SERVER_DIR%" -Dsolr.install.symDir="%SOLR_TIP%" ^ Review Comment: I think it would make more sense next to `solr.install.dir` on the line above similar to the `bin/solr` script. This goes for line 1400 as well. -- 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-16457) solr.data.home should not be set to empty string in bin/solr
[ https://issues.apache.org/jira/browse/SOLR-16457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686691#comment-17686691 ] Jan Høydahl commented on SOLR-16457: I know, but it will be a temporary fix and has performance implications. I added [https://github.com/apache/solr/pull/1346] and will proceed with testing it.. > solr.data.home should not be set to empty string in bin/solr > > > Key: SOLR-16457 > URL: https://issues.apache.org/jira/browse/SOLR-16457 > Project: Solr > Issue Type: Bug > Components: cli >Affects Versions: 9.0, 9.1 >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: main (10.0), 9.2 > > Attachments: fix_security_symlinks-1.patch, > fix_security_symlinks.patch > > Time Spent: 3h 50m > Remaining Estimate: 0h > > solr.data.home should not be set to empty string in bin/solr since that > causes the security.policy to be more wide open than it should. > solr.cmd does NOT have the same issue since it explicitly checks the case of > empty SOLR_DATA_HOME before adding it. > https://github.com/apache/solr/blob/main/solr/bin/solr.cmd#L1342 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] janhoy opened a new pull request, #1346: SOLR-16457 Add symbolic link version of solr.install.dir to security.policy
janhoy opened a new pull request, #1346: URL: https://github.com/apache/solr/pull/1346 I.e. typically til will allow /opt/solr/... in addition to /opt/solr-X.Y.Z/... I file this PR on https://issues.apache.org/jira/browse/SOLR-16457 since it is related and still un-released. -- 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-16573) SolrClientTestRule for EmbeddedSolrServer
[
https://issues.apache.org/jira/browse/SOLR-16573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686680#comment-17686680
]
Kevin Risden commented on SOLR-16573:
-
I think this commit is potentially causing issues on Windows? Timing lines up
it looks like. I think the error is correct that we shouldn't be writing to
this location:
{code:java}
Unable to create core [collection1] Caused by: access denied
("java.io.FilePermission"
"C:\Users\jenkins\workspace\Solr-main-Windows\solr\server\solr\configsets\sample_techproducts_configs\conf\conf"
"write")
{code}
Full errors from one of the Jenkins runs.
{code:java}
Build: https://jenkins.thetaphi.de/job/Solr-main-Windows/2295/
Java: 64bit/hotspot/jdk-17.0.5 -XX:+UseCompressedOops -XX:+UseSerialGC
7 tests failed.
FAILED: org.apache.solr.client.solrj.GetByIdTest.classMethod
Error Message:
org.apache.solr.common.SolrException: Error CREATEing SolrCore 'collection1':
Unable to create core [collection1] Caused by: access denied
("java.io.FilePermission"
"C:\Users\jenkins\workspace\Solr-main-Windows\solr\server\solr\configsets\sample_techproducts_configs\conf\conf"
"write")
Stack Trace:
org.apache.solr.common.SolrException: Error CREATEing SolrCore 'collection1':
Unable to create core [collection1] Caused by: access denied
("java.io.FilePermission"
"C:\Users\jenkins\workspace\Solr-main-Windows\solr\server\solr\configsets\sample_techproducts_configs\conf\conf"
"write")
at __randomizedtesting.SeedInfo.seed([63E61465D6A66982]:0)
at
app//org.apache.solr.core.CoreContainer.create(CoreContainer.java:1550)
at
app//org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:113)
at
app//org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:409)
at
app//org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:451)
at
app//org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:234)
at
app//org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:224)
at
app//org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:171)
at
app//org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:234)
at
app//org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:249)
at
app//org.apache.solr.util.SolrClientTestRule.create(SolrClientTestRule.java:131)
at
app//org.apache.solr.util.SolrClientTestRule$NewCollectionBuilder.create(SolrClientTestRule.java:109)
at
app//org.apache.solr.client.solrj.GetByIdTest.beforeClass(GetByIdTest.java:39)
at
java.base@17.0.5/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base@17.0.5/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base@17.0.5/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base@17.0.5/java.lang.reflect.Method.invoke(Method.java:568)
at
app//com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1758)
at
app//com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:886)
at
app//com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:902)
at
app//org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at
app//com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
app//com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
app//org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43)
at
app//org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43)
at
app//com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:80)
at app//org.junit.rules.RunRules.evaluate(RunRules.java:20)
at
app//org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43)
at
app//com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
app//org.apache.lucene.tests.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
at
app//com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
app//com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
app//com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State
[jira] [Commented] (SOLR-16563) Http2SolrClient should have a defaultCollection setting
[ https://issues.apache.org/jira/browse/SOLR-16563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686659#comment-17686659 ] Jason Gerlowski commented on SOLR-16563: (Thanks David - INFRA-24180 created.) > Http2SolrClient should have a defaultCollection setting > --- > > Key: SOLR-16563 > URL: https://issues.apache.org/jira/browse/SOLR-16563 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Reporter: David Smiley >Assignee: Eric Pugh >Priority: Minor > > Similar to CloudSolrClient, Http2SolrClient ought to have a > "defaultCollection" setting. This ought to be used in preference to passing > a "baseUrl" with this collection/core embedded into it. Maybe the builder's > constructor should be overloaded to have a baseUrl + defaultCollection pair > as well. > Doing this would make it easier to issue an admin or any other node level > command using the same SolrClient instance, just as is possible with > CloudSolrClient and EmbeddedSolrServer. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-16563) Http2SolrClient should have a defaultCollection setting
[ https://issues.apache.org/jira/browse/SOLR-16563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686649#comment-17686649 ] David Smiley edited comment on SOLR-16563 at 2/9/23 4:59 PM: - This is a request to INFRA. See INFRA-23707 as an example / template. I've done this as well as Bruno. I which more of us here would do this; it's confusing to at-mention people who have duplicates! was (Author: dsmiley): This is a request to INFRA. See INFRA-23707 as an example / template. I've done this as Bruno. I which more of us here would do this; it's confusing to at-mention people who have duplicates! > Http2SolrClient should have a defaultCollection setting > --- > > Key: SOLR-16563 > URL: https://issues.apache.org/jira/browse/SOLR-16563 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Reporter: David Smiley >Assignee: Eric Pugh >Priority: Minor > > Similar to CloudSolrClient, Http2SolrClient ought to have a > "defaultCollection" setting. This ought to be used in preference to passing > a "baseUrl" with this collection/core embedded into it. Maybe the builder's > constructor should be overloaded to have a baseUrl + defaultCollection pair > as well. > Doing this would make it easier to issue an admin or any other node level > command using the same SolrClient instance, just as is possible with > CloudSolrClient and EmbeddedSolrServer. -- 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-16563) Http2SolrClient should have a defaultCollection setting
[ https://issues.apache.org/jira/browse/SOLR-16563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686649#comment-17686649 ] David Smiley commented on SOLR-16563: - This is a request to INFRA. See INFRA-23707 as an example / template. I've done this as Bruno. I which more of us here would do this; it's confusing to at-mention people who have duplicates! > Http2SolrClient should have a defaultCollection setting > --- > > Key: SOLR-16563 > URL: https://issues.apache.org/jira/browse/SOLR-16563 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Reporter: David Smiley >Assignee: Eric Pugh >Priority: Minor > > Similar to CloudSolrClient, Http2SolrClient ought to have a > "defaultCollection" setting. This ought to be used in preference to passing > a "baseUrl" with this collection/core embedded into it. Maybe the builder's > constructor should be overloaded to have a baseUrl + defaultCollection pair > as well. > Doing this would make it easier to issue an admin or any other node level > command using the same SolrClient instance, just as is possible with > CloudSolrClient and EmbeddedSolrServer. -- 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] [Reopened] (SOLR-16636) ZkStateReader.waitForState should not register a watch if state already matches predicate
[ https://issues.apache.org/jira/browse/SOLR-16636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya reopened SOLR-16636: - > ZkStateReader.waitForState should not register a watch if state already > matches predicate > - > > Key: SOLR-16636 > URL: https://issues.apache.org/jira/browse/SOLR-16636 > Project: Solr > Issue Type: Task >Reporter: Noble Paul >Priority: Major > Fix For: 9.2 > > Time Spent: 1h > Remaining Estimate: 0h > > The > [ZkStateReader.waitForState|https://github.com/apache/solr/blob/fae42ec0cf43f288c909cb2e12b4d68e6a409d33/solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L1882] > method registers watches even if the current state matches the predicate. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-16563) Http2SolrClient should have a defaultCollection setting
[
https://issues.apache.org/jira/browse/SOLR-16563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686642#comment-17686642
]
Jason Gerlowski edited comment on SOLR-16563 at 2/9/23 4:44 PM:
(I missed this at the time because Eric used "{{~jegerlow}}" as the tag, which
looks like a login I must've created from a now-defunct work email. Anyone
know of a way to delete that login to avoid this sort of thing going forward?)
I'd be on board with any approach that gets us away from having the collection
sometimes-but-not-always baked into the baseUrl. Anything that moves us away
from that is (y) in my book.
That said - the 'defaultCollection' option has always struck me as a little
odd. I get that it's a convenience thing so folks don't need to specify the
collection on every SolrRequest they construct...but is that really all that
onerous? It's always seemed a bit like a "solution in need of a problem" to
me, albeit a small one. (Though maybe I'm misunderstanding part of the
rationale.)
Personally I'd slightly prefer nuking 'defaultCollection' over spreading it
elsewhere. But if I'm alone in that, I think either approach is a big step in
the right direction of getting collection names out of the baseUrl!
was (Author: gerlowskija):
(I missed this at the time because Eric used "{{~jegerlow}} as the tag, which
looks like a login I must've created from a now-defunct work email. Anyone
know of a way to delete that login to avoid this sort of thing going forward?)
I'd be on board with any approach that gets us away from having the collection
sometimes-but-not-always baked into the baseUrl. Anything that moves us away
from that is (y) in my book.
That said - the 'defaultCollection' option has always struck me as a little
odd. I get that it's a convenience thing so folks don't need to specify the
collection on every SolrRequest they construct...but is that really all that
onerous? It's always seemed a bit like a "solution in need of a problem" to
me, albeit a small one. (Though maybe I'm misunderstanding part of the
rationale.)
Personally I'd slightly prefer nuking 'defaultCollection' over spreading it
elsewhere. But if I'm alone in that, I think either approach is a big step in
the right direction of getting collection names out of the baseUrl!
> Http2SolrClient should have a defaultCollection setting
> ---
>
> Key: SOLR-16563
> URL: https://issues.apache.org/jira/browse/SOLR-16563
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
>Reporter: David Smiley
>Assignee: Eric Pugh
>Priority: Minor
>
> Similar to CloudSolrClient, Http2SolrClient ought to have a
> "defaultCollection" setting. This ought to be used in preference to passing
> a "baseUrl" with this collection/core embedded into it. Maybe the builder's
> constructor should be overloaded to have a baseUrl + defaultCollection pair
> as well.
> Doing this would make it easier to issue an admin or any other node level
> command using the same SolrClient instance, just as is possible with
> CloudSolrClient and EmbeddedSolrServer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-16563) Http2SolrClient should have a defaultCollection setting
[
https://issues.apache.org/jira/browse/SOLR-16563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686642#comment-17686642
]
Jason Gerlowski edited comment on SOLR-16563 at 2/9/23 4:43 PM:
(I missed this at the time because Eric used "{{~jegerlow}} as the tag, which
looks like a login I must've created from a now-defunct work email. Anyone
know of a way to delete that login to avoid this sort of thing going forward?)
I'd be on board with any approach that gets us away from having the collection
sometimes-but-not-always baked into the baseUrl. Anything that moves us away
from that is (y) in my book.
That said - the 'defaultCollection' option has always struck me as a little
odd. I get that it's a convenience thing so folks don't need to specify the
collection on every SolrRequest they construct...but is that really all that
onerous? It's always seemed a bit like a "solution in need of a problem" to
me, albeit a small one. (Though maybe I'm misunderstanding part of the
rationale.)
Personally I'd slightly prefer nuking 'defaultCollection' over spreading it
elsewhere. But if I'm alone in that, I think either approach is a big step in
the right direction of getting collection names out of the baseUrl!
was (Author: gerlowskija):
(I missed this at the time because Eric used "{{[~jegerlow]}} as the tag, which
looks like a login I must've created from a now-defunct work email. Anyone
know of a way to delete that login to avoid this sort of thing going forward?)
I'd be on board with any approach that gets us away from having the collection
sometimes-but-not-always baked into the baseUrl. Anything that moves us away
from that is (y) in my book.
That said - the 'defaultCollection' option has always struck me as a little
odd. I get that it's a convenience thing so folks don't need to specify the
collection on every SolrRequest they construct...but is that really all that
onerous? It's always seemed a bit like a "solution in need of a problem" to
me, albeit a small one. (Though maybe I'm misunderstanding part of the
rationale.)
Personally I'd slightly prefer nuking 'defaultCollection' over spreading it
elsewhere. But if I'm alone in that, I think either approach is a big step in
the right direction of getting collection names out of the baseUrl!
> Http2SolrClient should have a defaultCollection setting
> ---
>
> Key: SOLR-16563
> URL: https://issues.apache.org/jira/browse/SOLR-16563
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
>Reporter: David Smiley
>Assignee: Eric Pugh
>Priority: Minor
>
> Similar to CloudSolrClient, Http2SolrClient ought to have a
> "defaultCollection" setting. This ought to be used in preference to passing
> a "baseUrl" with this collection/core embedded into it. Maybe the builder's
> constructor should be overloaded to have a baseUrl + defaultCollection pair
> as well.
> Doing this would make it easier to issue an admin or any other node level
> command using the same SolrClient instance, just as is possible with
> CloudSolrClient and EmbeddedSolrServer.
--
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-16563) Http2SolrClient should have a defaultCollection setting
[
https://issues.apache.org/jira/browse/SOLR-16563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686642#comment-17686642
]
Jason Gerlowski commented on SOLR-16563:
(I missed this at the time because Eric used "{{[~jegerlow]}} as the tag, which
looks like a login I must've created from a now-defunct work email. Anyone
know of a way to delete that login to avoid this sort of thing going forward?)
I'd be on board with any approach that gets us away from having the collection
sometimes-but-not-always baked into the baseUrl. Anything that moves us away
from that is (y) in my book.
That said - the 'defaultCollection' option has always struck me as a little
odd. I get that it's a convenience thing so folks don't need to specify the
collection on every SolrRequest they construct...but is that really all that
onerous? It's always seemed a bit like a "solution in need of a problem" to
me, albeit a small one. (Though maybe I'm misunderstanding part of the
rationale.)
Personally I'd slightly prefer nuking 'defaultCollection' over spreading it
elsewhere. But if I'm alone in that, I think either approach is a big step in
the right direction of getting collection names out of the baseUrl!
> Http2SolrClient should have a defaultCollection setting
> ---
>
> Key: SOLR-16563
> URL: https://issues.apache.org/jira/browse/SOLR-16563
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
>Reporter: David Smiley
>Assignee: Eric Pugh
>Priority: Minor
>
> Similar to CloudSolrClient, Http2SolrClient ought to have a
> "defaultCollection" setting. This ought to be used in preference to passing
> a "baseUrl" with this collection/core embedded into it. Maybe the builder's
> constructor should be overloaded to have a baseUrl + defaultCollection pair
> as well.
> Doing this would make it easier to issue an admin or any other node level
> command using the same SolrClient instance, just as is possible with
> CloudSolrClient and EmbeddedSolrServer.
--
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-16558) Add Group parameter support for JSON Request API
[
https://issues.apache.org/jira/browse/SOLR-16558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686617#comment-17686617
]
Jason Gerlowski commented on SOLR-16558:
I'd also love to see the JSON Request syntax expanded to cover other features
like grouping or collapse/expand "natively".
That said though - afaik you can still use the JSON Query DSL for everything it
supports, and provide everything else as URI query-params. Solr supports
mixing-and-matching syntaxes that way. So you should still be able to use the
JSON Query DSL to work around the URI-too-long issue you're hitting?
e.g.
{code}
$ curl -k -X POST -H "Content-type: application/json"
"http://localhost:8983/solr/techproducts/select?group=on&group.field=manu_id_s&group.limit=2";
-d '{"query": "cat:electronics"}'
{
"responseHeader":{
"zkConnected":true,
"status":0,
"QTime":1,
"params":{
"group.limit":"2",
"json":"{\"query\": \"cat:electronics\"}",
"group.field":"manu_id_s",
"group":"on"}},
"grouped":{
"manu_id_s":{
"matches":12,
"groups":[{
"groupValue":"corsair",
"doclist":{"numFound":3,"start":0,"numFoundExact":true,"docs":[
{
"id":"TWINX2048-3200PRO",
"name":"CORSAIR XMS 2GB (2 x 1GB) 184-Pin DDR SDRAM Unbuffered
DDR 400 (PC 3200) Dual Channel Kit System Memory - Retail",
"manu":"Corsair Microsystems Inc.",
"manu_id_s":"corsair",
{code}
> Add Group parameter support for JSON Request API
>
>
> Key: SOLR-16558
> URL: https://issues.apache.org/jira/browse/SOLR-16558
> Project: Solr
> Issue Type: New Feature
> Components: JSON Request API, SolrCloud
>Affects Versions: 9.2
>Reporter: Nick Hadder
>Priority: Trivial
> Attachments: image-2022-11-22-10-19-37-615.png
>
>
> Our company would like to see support for the group parameter in JSON API
> Requests. Right now we are limited to using the GET http method where the
> query has to be constructed in the path of the URI of the request. We are
> running into an "Invalid URI: The Uri string is too long." error when
> computing queries to return results for a system we have called keyword
> lists.
>
> This is a sample request that our product was looking to make:
> {code:java}
> Case1004_NewCaseTestWithTopicModeling/select?facet=true&facet.query=money&facet.query=document&facet.query=work&facet.query=play&facet.query=legal&facet.query=globex&facet.query=rachel&facet.query=dejesus&facet.query=ipro&facet.query=trial&facet.query=text&facet.query=dummy&facet.query=fox&facet.query=brown&facet.query=responsive&facet.query=objection&facet.query=privileged&facet.query=credit&facet.query=card&facet.query=number&facet.query=there&facet.query=lived&facet.query=boy&facet.query=named&facet.query=harry&facet.query=wizard&facet.query=amazing&facet.query=grateful&facet.query=magic&facet.query=sue&facet.query=judge&facet.query=judy&fl=_type,_id,field0006,field0005,hit_term7:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=money%7D)),hit_term8:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=document%7D)),hit_term9:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=work%7D)),hit_term10:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=play%7D)),hit_term11:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=legal%7D)),hit_term12:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=globex%7D)),hit_term13:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=rachel%7D)),hit_term14:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=dejesus%7D)),hit_term15:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=ipro%7D)),hit_term16:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=trial%7D)),hit_term17:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=text%7D)),hit_term18:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=dummy%7D)),hit_term19:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=fox%7D)),hit_term20:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=brown%7D)),hit_term21:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=responsive%7D)),hit_term22:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=objection%7D)),hit_term23:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=privileged%7D)),hit_term24:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=credit%7D)),hit_term25:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=card%7D)),hit_term26:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=number%7D)),hit_term27:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=there%7D)),hit_term28:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=lived%7D)),hit_term29:exists(query(%7B!dismax%20qf=_text_%20pf=_text_%20v=boy%7D)),hit_term30:exists(query(%7B!dismax%20qf=_text_%20pf=_text
[jira] [Commented] (SOLR-16457) solr.data.home should not be set to empty string in bin/solr
[ https://issues.apache.org/jira/browse/SOLR-16457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686608#comment-17686608 ] Kevin Risden commented on SOLR-16457: - A workaround might be to use jdk.io.permissionsUseCanonicalPath? > solr.data.home should not be set to empty string in bin/solr > > > Key: SOLR-16457 > URL: https://issues.apache.org/jira/browse/SOLR-16457 > Project: Solr > Issue Type: Bug > Components: cli >Affects Versions: 9.0, 9.1 >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: main (10.0), 9.2 > > Attachments: fix_security_symlinks-1.patch, > fix_security_symlinks.patch > > Time Spent: 3h 40m > Remaining Estimate: 0h > > solr.data.home should not be set to empty string in bin/solr since that > causes the security.policy to be more wide open than it should. > solr.cmd does NOT have the same issue since it explicitly checks the case of > empty SOLR_DATA_HOME before adding it. > https://github.com/apache/solr/blob/main/solr/bin/solr.cmd#L1342 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-16457) solr.data.home should not be set to empty string in bin/solr
[ https://issues.apache.org/jira/browse/SOLR-16457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686604#comment-17686604 ] Kevin Risden edited comment on SOLR-16457 at 2/9/23 3:38 PM: - O interesting - https://mail.openjdk.org/pipermail/jdk9-dev/2016-October/005062.html. FWIW prior to this change on this jira SOLR-16457 everything under `/` was readable. So this just highlighted an underlying issue. Either reopening or opening new works for me. was (Author: risdenk): O interesting - https://mail.openjdk.org/pipermail/jdk9-dev/2016-October/005062.html. FWIW prior to this change everything under `/` was readable. So this just highlighted an underlying issue. Either reopening or opening new works for me. > solr.data.home should not be set to empty string in bin/solr > > > Key: SOLR-16457 > URL: https://issues.apache.org/jira/browse/SOLR-16457 > Project: Solr > Issue Type: Bug > Components: cli >Affects Versions: 9.0, 9.1 >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: main (10.0), 9.2 > > Attachments: fix_security_symlinks-1.patch, > fix_security_symlinks.patch > > Time Spent: 3h 40m > Remaining Estimate: 0h > > solr.data.home should not be set to empty string in bin/solr since that > causes the security.policy to be more wide open than it should. > solr.cmd does NOT have the same issue since it explicitly checks the case of > empty SOLR_DATA_HOME before adding it. > https://github.com/apache/solr/blob/main/solr/bin/solr.cmd#L1342 -- 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-16457) solr.data.home should not be set to empty string in bin/solr
[ https://issues.apache.org/jira/browse/SOLR-16457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686604#comment-17686604 ] Kevin Risden commented on SOLR-16457: - O interesting - https://mail.openjdk.org/pipermail/jdk9-dev/2016-October/005062.html. FWIW prior to this change everything under `/` was readable. So this just highlighted an underlying issue. Either reopening or opening new works for me. > solr.data.home should not be set to empty string in bin/solr > > > Key: SOLR-16457 > URL: https://issues.apache.org/jira/browse/SOLR-16457 > Project: Solr > Issue Type: Bug > Components: cli >Affects Versions: 9.0, 9.1 >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: main (10.0), 9.2 > > Attachments: fix_security_symlinks-1.patch, > fix_security_symlinks.patch > > Time Spent: 3h 40m > Remaining Estimate: 0h > > solr.data.home should not be set to empty string in bin/solr since that > causes the security.policy to be more wide open than it should. > solr.cmd does NOT have the same issue since it explicitly checks the case of > empty SOLR_DATA_HOME before adding it. > https://github.com/apache/solr/blob/main/solr/bin/solr.cmd#L1342 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] tylerbertrand opened a new pull request, #1345: Gradle: Use lazy file types
tylerbertrand opened a new pull request, #1345: URL: https://github.com/apache/solr/pull/1345 # Description Updated inputs defined in `CommandLineArgumentProvider`s to use lazy file types. While usage of "eager" file types is not currently causing issues, it is generally preferred to use lazy file types where possible to defer file evaluation to execution time. # Solution Replaced `File`s with their lazy counterparts: `DirectoryProperty` and `RegularFileProperty` Build scan for these changes: https://scans.gradle.com/s/2rtoy5kx6cipa # Tests N/A - this PR only updates build logic # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `main` branch. - [x] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk opened a new pull request, #1344: Tracking Field usage with DirectoryReader
risdenk opened a new pull request, #1344: URL: https://github.com/apache/solr/pull/1344 https://issues.apache.org/jira/browse/SOLR-X -- 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-16554) Update docs on filter cache
[ https://issues.apache.org/jira/browse/SOLR-16554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686584#comment-17686584 ] Jason Gerlowski commented on SOLR-16554: bq. This is something I'm willing to take on, but would welcome help, especially on delving in to Solr internals. Hey [~petdance] - is there something in particular others can do to help? More than happy to review whatever changes or language if you've got some drafted? > Update docs on filter cache > --- > > Key: SOLR-16554 > URL: https://issues.apache.org/jira/browse/SOLR-16554 > Project: Solr > Issue Type: Improvement > Components: documentation, faceting >Reporter: Andy Lester >Priority: Minor > > The docs about the filter cache could use an update, especially more > discussion on how to tune it. > This is something I'm willing to take on, but would welcome help, especially > on delving in to Solr internals. > This ticket is intended as a place to aggregate discussion of the task, and > also notes related to this. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] epugh commented on pull request #1014: Refactor SolrZkclient to use a Builder pattern
epugh commented on PR #1014: URL: https://github.com/apache/solr/pull/1014#issuecomment-1424338918 Could we follow the same pattern defined in SOLR-16595 and SOLR-16590 of using `with` instead of bare property names, and using `TimeUnit`? Have some consistency in how we create our builders! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] epugh commented on pull request #1338: SOLR-16595: Standardize Solr Client Builders handling of times
epugh commented on PR #1338: URL: https://github.com/apache/solr/pull/1338#issuecomment-1424332956 I broke the ConncurrentUpdateSolrClient unit test.. sigh First pass thorugh, no luck on why setting the timeout isn't working. -- 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-16457) solr.data.home should not be set to empty string in bin/solr
[ https://issues.apache.org/jira/browse/SOLR-16457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686484#comment-17686484 ] Jan Høydahl commented on SOLR-16457: There was a change in JDK9 in how FilePermission is resolved. Earlier it would resolve symlinks, but now it won't, so if we need both we need to add them explicitly. Should I re-open this Jira since it is related or open a new? > solr.data.home should not be set to empty string in bin/solr > > > Key: SOLR-16457 > URL: https://issues.apache.org/jira/browse/SOLR-16457 > Project: Solr > Issue Type: Bug > Components: cli >Affects Versions: 9.0, 9.1 >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: main (10.0), 9.2 > > Attachments: fix_security_symlinks-1.patch, > fix_security_symlinks.patch > > Time Spent: 3h 40m > Remaining Estimate: 0h > > solr.data.home should not be set to empty string in bin/solr since that > causes the security.policy to be more wide open than it should. > solr.cmd does NOT have the same issue since it explicitly checks the case of > empty SOLR_DATA_HOME before adding it. > https://github.com/apache/solr/blob/main/solr/bin/solr.cmd#L1342 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] janhoy commented on pull request #1342: SOLR-16650, SOLR-16532: OTEL tracer additional tags
janhoy commented on PR #1342: URL: https://github.com/apache/solr/pull/1342#issuecomment-1424094122 Removed the `net.*` tags, and instead added a static `host.name` tag with solr's host name (as defined in `host` sysprop). All changes are now in OTEL module only so no need for extra CHANGES entry. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] janhoy commented on a diff in pull request #1342: SOLR-16650, SOLR-16532: OTEL tracer additional tags
janhoy commented on code in PR #1342:
URL: https://github.com/apache/solr/pull/1342#discussion_r1101340577
##
solr/core/src/java/org/apache/solr/servlet/ServletUtils.java:
##
@@ -310,7 +310,11 @@ protected static Span buildSpan(Tracer tracer,
HttpServletRequest request) {
.asChildOf(tracer.extract(Format.Builtin.HTTP_HEADERS, new
HttpServletCarrier(request)))
.withTag(Tags.SPAN_KIND, Tags.SPAN_KIND_SERVER)
.withTag(Tags.HTTP_METHOD, request.getMethod())
-.withTag(Tags.HTTP_URL, request.getRequestURL().toString());
+.withTag(Tags.HTTP_URL, request.getRequestURL().toString())
+.withTag("net.host.name", request.getServerName())
+.withTag("net.host.port", request.getServerPort())
+.withTag("net.peer.name", request.getRemoteHost())
+.withTag("net.peer.port", request.getRemotePort());
Review Comment:
Hmm, I wonder if I'll skip these four tags in this PR, and just do the
refGuide change to keep it contained.
What I initially planned was to add the solr host name in the trace, not the
http request host name (which could be an alias, and is also part of the URL).
It could be possible to add the `host.name` tag in a static way as part of the
Otel configurator and avoid touching this common part for now.
Once we replace OT instrumentation with OTEL instrumentation, we can revisit
what tags to set by default.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] janhoy commented on a diff in pull request #1342: SOLR-16650, SOLR-16532: OTEL tracer additional tags
janhoy commented on code in PR #1342:
URL: https://github.com/apache/solr/pull/1342#discussion_r1101290759
##
solr/core/src/java/org/apache/solr/servlet/ServletUtils.java:
##
@@ -310,7 +310,11 @@ protected static Span buildSpan(Tracer tracer,
HttpServletRequest request) {
.asChildOf(tracer.extract(Format.Builtin.HTTP_HEADERS, new
HttpServletCarrier(request)))
.withTag(Tags.SPAN_KIND, Tags.SPAN_KIND_SERVER)
.withTag(Tags.HTTP_METHOD, request.getMethod())
-.withTag(Tags.HTTP_URL, request.getRequestURL().toString());
+.withTag(Tags.HTTP_URL, request.getRequestURL().toString())
+.withTag("net.host.name", request.getServerName())
+.withTag("net.host.port", request.getServerPort())
+.withTag("net.peer.name", request.getRemoteHost())
+.withTag("net.peer.port", request.getRemotePort());
Review Comment:
I'm no expert here, but the opentelemetry semantic conventions seem to have
evolved and differ from what OpenTracing used. I don't know the history here,
but OT is now part of OTEL, so I interpreted that `peer.hostname` is the old OT
tag name while `net.peer.name` is the new OTEL name. Thus there was no constant
available.
The `opentelemetry-semconv` dependency which we currently do not pull in,
contains such constants in
[SemanticAttributes.java](https://github.com/open-telemetry/opentelemetry-java/blob/main/semconv/src/main/java/io/opentelemetry/semconv/trace/attributes/SemanticAttributes.java).
A bit overkill to pull that in for four string constants though.
The question then is - since this is shared code between Jaeger and OTEL,
and they both expect different tag names (the others, SPAN_KIND, HTTP_METHOD,
HTTP_URL are the same), if we should tag both variants, or find some way to
choose tags based on active module. Trick is that in `ServletUtils` class we
only have a tracer instance and don't know the active module. Only way I can
think of is to do `tracer instanceof
io.opentelemetry.opentracingshim.TracerShim`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] janhoy commented on pull request #1342: SOLR-16650, SOLR-16532: OTEL tracer additional tags
janhoy commented on PR #1342: URL: https://github.com/apache/solr/pull/1342#issuecomment-1423997100 > > Not adding CHANGES line since none of this is yet released. > > But this change isn't restricted to OTEL; any tracer plugin would get these new tags. Any way, it's fine with me. Yes, since this is on the OT Tracer level, that is true, so perhaps it deserves a line. -- 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
