[GitHub] [lucene-solr] dweiss commented on a change in pull request #1905: LUCENE-9488 Release with Gradle Part 2
dweiss commented on a change in pull request #1905:
URL: https://github.com/apache/lucene-solr/pull/1905#discussion_r492507019
##
File path: lucene/build.gradle
##
@@ -15,8 +15,56 @@
* limitations under the License.
*/
+// Should we do this as :lucene:packaging similar to how Solr does it?
Review comment:
Yes, please move it to :lucene:packaging. It makes things much cleaner
in the long run.
##
File path: lucene/build.gradle
##
@@ -15,8 +15,56 @@
* limitations under the License.
*/
+// Should we do this as :lucene:packaging similar to how Solr does it?
+// Or is this fine here?
+
+plugins {
+ id 'distribution'
+}
+
description = 'Parent project for Apache Lucene Core'
subprojects {
group "org.apache.lucene"
-}
\ No newline at end of file
+}
+
+distributions {
+ main {
+ // This is empirically wrong, but it is mostly a copy from `ant
package-zip`
Review comment:
This is wrong. It should rely on published artifacts from other
subprojects (set up proper dependencies) and assemble them in the right way
into the distribution layout.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9528) Clean up obsolete and commented-out cruft from StandardSyntaxParser.jj
[ https://issues.apache.org/jira/browse/LUCENE-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199871#comment-17199871 ] Dawid Weiss commented on LUCENE-9528: - I think this query parser is great, really! It does have some things that could be cleaned up but it is the only query parser that is externally extensible and usable for me. It supports multifield expansion for unqualified terms and it is *very* flexible - the parse tree resulting from query parsing can be adjusted and enhanced in multiple ways without touching the parser code (you only touch the post processing tree pipeline and/or the builders). We have been using it with success in both our in-house projects (Lingo4G) and in combination with Solr. I don't see the reason to remove it. In fact, I think the approach this query parser takes (intermediate representation) is much superior to the "classic" query parser which creates intermediate Query instances right away. And the span query parser... eh. This isn't usable at all - the syntax is too strange - it was difficult to use even for me as a developer. > Clean up obsolete and commented-out cruft from StandardSyntaxParser.jj > -- > > Key: LUCENE-9528 > URL: https://issues.apache.org/jira/browse/LUCENE-9528 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: master (9.0) > > Time Spent: 20m > Remaining Estimate: 0h > > The indentation in that file is crazy. So are micro-optimizations which make > reading the syntax parser much more difficult than it actually is. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dweiss commented on pull request #1836: LUCENE-9317: Clean up split package in analyzers-common
dweiss commented on pull request #1836: URL: https://github.com/apache/lucene-solr/pull/1836#issuecomment-696537432 In general, I like it. I wondered whether it'd make sense to create a separate package (subproject) for those classes moved to the core - this would make the core really separate from analysis. If somebody is using dependency systems with transitive dependencies, they wouldn't feel the difference (the analysis-util/ analysis-base?) subprojects would be sucked in automatically. What do you think? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] tflobbe merged pull request #1892: Improve TestConfigSetsAPI
tflobbe merged pull request #1892: URL: https://github.com/apache/lucene-solr/pull/1892 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta commented on pull request #1836: LUCENE-9317: Clean up split package in analyzers-common
mocobeta commented on pull request #1836: URL: https://github.com/apache/lucene-solr/pull/1836#issuecomment-696524047 This branch has been a bit stale (I just merged recent master and resolved some conflicts). @uschindler do you have time to review this, or would it be better that I close it for the moment? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14883) Add a Muse (CI) configuration file
[
https://issues.apache.org/jira/browse/SOLR-14883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199812#comment-17199812
]
Thomas DuBuisson commented on SOLR-14883:
-
[~dsmiley] Gladly, though I have no links that address this topic.
I work for Muse Dev, a company focused on bringing static analysis closer to
the developer ("shift left" as they say these days). We have been talking with
Apache both in developer to developer engagements and through the foundation at
more of an organizational level. This organization level discussion has
resulted is us getting in touch with the infrastructure team and getting the
GitHub app (also called Muse, often "MuseBot") installed. Though we are small,
we are looking to support Apache and join the community.
The current aim is to run a bug bash at the Apache conference, thus motivating
people to put some elbow grease in as well as a create an atmosphere for
mentoring or pulling in new contributors to the participating Apache projects.
This issue (and the matching PR on github) is part of getting ready for the
bash - regardless of having the app installed we can and certainly will provide
links to the analysis results to the bash participants. However, that's a
misuse of the analysis, which is best used during PRs to surface new issues
when the relevant code is already paged in mentally. Less critically, for the
duration of the bash we will run a leaderboard tallying fixed bugs - earning
precious internet points is easier when the leaderboard updates automatically
via hooks we have in the app.
As for our relation with GitHub, we are separate companies. Our app is
available on GitHub cloud and enterprise as well as on the enterprise version
of GitHub competitors. Certainly we have a symbiotic relationship and contacts
within these companies but it's all pretty cut and dry.
> Add a Muse (CI) configuration file
> --
>
> Key: SOLR-14883
> URL: https://issues.apache.org/jira/browse/SOLR-14883
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Thomas DuBuisson
>Priority: Trivial
> Time Spent: 1h
> Remaining Estimate: 0h
>
> This ticket is a continuation of conversation that started
> https://issues.apache.org/jira/browse/SOLR-14819?filter=-2 and was also on
> the mailing list.
>
> The Apache infrastructure team has installed the Muse GitHub application. In
> order for Lucene-Solr to benefit the application must understand how to build
> the project. While it has build heuristics, it does not guess between JDK8
> or JDK11 (two JDKs most supported by several static analysis tools). Thus,
> this configuration explicitly instructs use of JDK11.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson commented on pull request #1881: SOLR-14876: Upgrade to zookeeper 3.6.2
ErickErickson commented on pull request #1881: URL: https://github.com/apache/lucene-solr/pull/1881#issuecomment-695867035 This has been fixed in Solr 8.7... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on pull request #5: SOLR-8639 replace static SimpleDateFormat with threadsafe jodatimeDateFormatter
madrob commented on pull request #5: URL: https://github.com/apache/lucene-solr/pull/5#issuecomment-696234934 DIH has been moved out to an external package, please consider submitting your patch to https://github.com/rohitbemax/dataimporthandler - thank you! 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley closed pull request #1875: SOLR-14802: Allow LLPSF fields as geodist argument
dsmiley closed pull request #1875: URL: https://github.com/apache/lucene-solr/pull/1875 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] tflobbe commented on a change in pull request #1861: SOLR-10391: Add overwrite option to UPLOAD ConfigSet action
tflobbe commented on a change in pull request #1861:
URL: https://github.com/apache/lucene-solr/pull/1861#discussion_r492423507
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/ConfigSetsHandler.java
##
@@ -170,21 +176,90 @@ private void handleConfigUploadRequest(SolrQueryRequest
req, SolrQueryResponse r
// Create a node for the configuration in zookeeper
boolean trusted = getTrusted(req);
-zkClient.makePath(configPathInZk, ("{\"trusted\": " +
Boolean.toString(trusted) + "}").
-getBytes(StandardCharsets.UTF_8), true);
+Set filesToDelete = Collections.emptySet();
+if (overwritesExisting) {
+ if (!trusted) {
+ensureOverwritingUntrustedConfigSet(zkClient, configPathInZk);
+ }
+ if (req.getParams().getBool(ConfigSetParams.CLEANUP, false)) {
+filesToDelete = getAllConfigsetFiles(zkClient, configPathInZk);
+ }
+} else {
+ zkClient.makePath(configPathInZk, ("{\"trusted\": " +
Boolean.toString(trusted) + "}").
+ getBytes(StandardCharsets.UTF_8), true);
+}
ZipInputStream zis = new ZipInputStream(inputStream,
StandardCharsets.UTF_8);
ZipEntry zipEntry = null;
while ((zipEntry = zis.getNextEntry()) != null) {
String filePathInZk = configPathInZk + "/" + zipEntry.getName();
+ if (filePathInZk.endsWith("/")) {
+filesToDelete.remove(filePathInZk.substring(0, filePathInZk.length()
-1));
+ } else {
+filesToDelete.remove(filePathInZk);
+ }
if (zipEntry.isDirectory()) {
-zkClient.makePath(filePathInZk, true);
+zkClient.makePath(filePathInZk, false, true);
Review comment:
Yes, I don't think this would be needed at this point. No API would set
this, and no Solr component would read it. I guess the only case would be a
custom component that writes and reads directly to ZooKeeper.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on a change in pull request #1891: SOLR-14877: Add github action for running SolrJ tests.
madrob commented on a change in pull request #1891: URL: https://github.com/apache/lucene-solr/pull/1891#discussion_r492179162 ## File path: .github/workflows/solrj-test.yml ## @@ -0,0 +1,27 @@ +name: SolrJ Tests + +on: + pull_request: +branches: + - 'master' +paths: + - '.github/workflows/solrj-test.yml' + - 'solr/solrj/**' + +jobs: + test: +name: Run SolrJ Tests + +runs-on: ubuntu-latest + +steps: +# Setup +- uses: actions/checkout@v2 +- name: Set up JDK 11 + uses: actions/setup-java@v1 + with: +java-version: 11 +- name: Grant execute permission for gradlew + run: chmod +x gradlew +- name: Test the SolrJ Package + run: ./gradlew solr:solrj:test Review comment: Do we need to consider that this test run won't have our generated gradle properties? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] TomMD commented on a change in pull request #1901: SOLR-14883 Add a Muse (Continuous assurance platform) configuration
TomMD commented on a change in pull request #1901: URL: https://github.com/apache/lucene-solr/pull/1901#discussion_r492311229 ## File path: .muse/config.toml ## @@ -0,0 +1 @@ +jdk11 = true Review comment: @tflobbe Sure, I'll put that here and amend the commit. The full documentation is docs.muse.dev. Most interesting is the repository configuration reference https://docs.muse.dev/docs/repository-configuration/ which details how to change which tools runs, add custom tools (other than those built into the platform by default), filter for or against certain bug types, etc. For example, an explicit `.muse/config.toml` file might be: ``` jdk11 = true build = "./gradlew assemble" tools = [ "infer", "errorprone", "findsecbugs" ] customTools = [ ] ``` 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mayya-sharipova commented on pull request #1903: Fix bug in sort optimization
mayya-sharipova commented on pull request #1903: URL: https://github.com/apache/lucene-solr/pull/1903#issuecomment-696373592 @jimczi I could not reproduce an issue of duplicate documents in Lucene, and I am still not sure how it actually happens. Even as we were [incorrectly advancing](https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/search/Weight.java#L216) only `scorerIterator`, as `filteredIterator` is an intersection of `collectorIterator` and `scorerIterator`, a next document from `filteredIterator` must be a document > the current document of `scorerIterator`? No? There was also a question why we did not detect duplicate documents in the tests. First, they don't happen in the tests, and before I was not using `AssertingIndexSearcher`. I've changed the tests on _doc sort to use `AssertingIndexSearcher` 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on pull request #1740: LUCENE-9458: WDGF and WDF should tie-break by endOffset
dsmiley commented on pull request #1740: URL: https://github.com/apache/lucene-solr/pull/1740#issuecomment-696351031 Sorry for the delay; I have had a solution for over a month locally but didn't share it yet. I'm pretty comfortable with what I just pushed. I did some "fuzz testing" to determine if there was a token ordering difference given the same input but varying the `compare` logic. It revealed that I could simplify WDGF's `compare` logic to only look at the start and end offset. However, WDF's `compare` failed this exercise; my change introduced a new position in some cases, although not the ones I explicitly tested for. WDF is more complicated (to me any way), and furthermore WDF is deprecated so I'm not motivated to disturb the logic there. I added the fuzz testing here as a comment. It's not really committable live because it's requires modifying WDGF's `compare` to actually do two compares and assert the same result. Without that, there is no assertion being checked -- no comparison. Suggested CHANGES.txt would be improvement: "WordDelimiterGraphFilter should tie-break by endOffset to emit longer tokens first. The same graph is produced." 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1896: SOLR-14880: Support coreRootDirectory setting when create new cores from command line, in standalone mode
dsmiley commented on a change in pull request #1896:
URL: https://github.com/apache/lucene-solr/pull/1896#discussion_r492238398
##
File path: solr/core/src/java/org/apache/solr/util/SolrCLI.java
##
@@ -1675,9 +1675,9 @@ protected void runImpl(CommandLine cli) throws Exception {
}
// convert raw JSON into user-friendly output
-solrHome = (String)systemInfo.get("solr_home");
-if (solrHome == null)
- solrHome = configsetsDir.getParentFile().getAbsolutePath();
+coreRootDirectory = (String)systemInfo.get("solr_core_root");
Review comment:
Can you help my understand where exactly solr_core_root is populated? I
don't see it in SystemInfoHandler which I presume populates the response for
this.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] arafalov commented on a change in pull request #1894: SOLR-14878: Expose solr.xml's coreRootDirectory property via the System Settings API
arafalov commented on a change in pull request #1894:
URL: https://github.com/apache/lucene-solr/pull/1894#discussion_r492270332
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/SystemInfoHandler.java
##
@@ -139,8 +140,19 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
if (solrCloudMode) {
rsp.add("zkHost", getCoreContainer(req,
core).getZkController().getZkServerAddress());
}
-if (cc != null)
- rsp.add( "solr_home", cc.getSolrHome());
+if (cc != null) {
+ String solrHome = cc.getSolrHome();
+ rsp.add("solr_home", solrHome);
+
+ Path coreRootDirectory = cc.getCoreRootDirectory();
+ if (coreRootDirectory != null) {
+String coreRootDirectoryString = coreRootDirectory.toString();
+if (!coreRootDirectoryString.equals(solrHome)) {
Review comment:
Ok, I was on borderline myself. I felt that because this option is
barely used, having the same long string sent twice was bit of a waste of
bandwidth. But, I guess it does not happen too often.
I can correct both generation and invocation of this option to make it a
guaranteed setup. Let's just hope they don't run version 9 tool against version
8 core.
Also, if you don't like the name (the other open point), this is a good time
to mention it.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] HoustonPutman merged pull request #1899: Adding dev-docs around the use of Git Worktree.
HoustonPutman merged pull request #1899: URL: https://github.com/apache/lucene-solr/pull/1899 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] arafalov commented on pull request #1898: SOLR-14882
arafalov commented on pull request #1898: URL: https://github.com/apache/lucene-solr/pull/1898#issuecomment-696160912 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] sigram commented on pull request #1758: SOLR-14749: Provide a clean API for cluster-level event processing, Initial draft.
sigram commented on pull request #1758: URL: https://github.com/apache/lucene-solr/pull/1758#issuecomment-696057300 @murblanc See `CollectionsRepairEventListener` for an example. Also the `ClusterEventProducerTest` unit test. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] arafalov merged pull request #1897: SOLR-9607: Finalize move of Terms component and request handler into the implicit definitions
arafalov merged pull request #1897: URL: https://github.com/apache/lucene-solr/pull/1897 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] tflobbe commented on a change in pull request #1901: SOLR-14883 Add a Muse (Continuous assurance platform) configuration
tflobbe commented on a change in pull request #1901: URL: https://github.com/apache/lucene-solr/pull/1901#discussion_r492252479 ## File path: .muse/config.toml ## @@ -0,0 +1 @@ +jdk11 = true Review comment: Could you add a comment or two pointing to the documentation how to add/change/skip checks? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson closed pull request #1881: SOLR-14876: Upgrade to zookeeper 3.6.2
ErickErickson closed pull request #1881: URL: https://github.com/apache/lucene-solr/pull/1881 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1894: SOLR-14878: Expose solr.xml's coreRootDirectory property via the System Settings API
dsmiley commented on a change in pull request #1894:
URL: https://github.com/apache/lucene-solr/pull/1894#discussion_r492252261
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/SystemInfoHandler.java
##
@@ -139,8 +140,19 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
if (solrCloudMode) {
rsp.add("zkHost", getCoreContainer(req,
core).getZkController().getZkServerAddress());
}
-if (cc != null)
- rsp.add( "solr_home", cc.getSolrHome());
+if (cc != null) {
+ String solrHome = cc.getSolrHome();
+ rsp.add("solr_home", solrHome);
+
+ Path coreRootDirectory = cc.getCoreRootDirectory();
+ if (coreRootDirectory != null) {
+String coreRootDirectoryString = coreRootDirectory.toString();
+if (!coreRootDirectoryString.equals(solrHome)) {
Review comment:
I disagree with this condition. I think this should always emitted no
matter where it is. It's more helpful on consumers to depend on its existence
rather than having it vary in some cases but not others.
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/SystemInfoHandler.java
##
@@ -139,8 +140,19 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
if (solrCloudMode) {
rsp.add("zkHost", getCoreContainer(req,
core).getZkController().getZkServerAddress());
}
-if (cc != null)
- rsp.add( "solr_home", cc.getSolrHome());
+if (cc != null) {
+ String solrHome = cc.getSolrHome();
+ rsp.add("solr_home", solrHome);
+
+ Path coreRootDirectory = cc.getCoreRootDirectory();
+ if (coreRootDirectory != null) {
Review comment:
coreRootDirectory is always non-null. I don't like null checks that are
unnecessary; it may feel "safe" but slightly obscures code clarity and suggests
possibilities that are impossibilities.
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/SystemInfoHandler.java
##
@@ -139,8 +140,19 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
if (solrCloudMode) {
rsp.add("zkHost", getCoreContainer(req,
core).getZkController().getZkServerAddress());
}
-if (cc != null)
- rsp.add( "solr_home", cc.getSolrHome());
+if (cc != null) {
+ String solrHome = cc.getSolrHome();
+ rsp.add("solr_home", solrHome);
+
+ Path coreRootDirectory = cc.getCoreRootDirectory();
+ if (coreRootDirectory != null) {
+String coreRootDirectoryString = coreRootDirectory.toString();
+if (!coreRootDirectoryString.equals(solrHome)) {
Review comment:
The "solr_" part should be skipped IMO. Everything here is Solr :-)
> Let's just hope they don't run version 9 tool against version 8 core.
Well it's up to them to have a tolerant client. For the SolrCLI I think it
makes sense to check for null in case of a cross-version situation.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] sigram commented on a change in pull request #1758: SOLR-14749: Provide a clean API for cluster-level event processing, Initial draft.
sigram commented on a change in pull request #1758:
URL: https://github.com/apache/lucene-solr/pull/1758#discussion_r491867642
##
File path:
solr/core/src/java/org/apache/solr/cluster/events/CollectionsAddedEvent.java
##
@@ -0,0 +1,32 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.cluster.events;
+
+import java.util.Collection;
+
+/**
+ * Event generated when some collections have been added.
+ */
+public interface CollectionsAddedEvent extends ClusterEvent {
+
+ @Override
+ default EventType getType() {
+return EventType.COLLECTIONS_ADDED;
+ }
+
+ Collection getCollectionNames();
Review comment:
Ok.
##
File path:
solr/core/src/java/org/apache/solr/cluster/events/ClusterEventListener.java
##
@@ -0,0 +1,41 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.cluster.events;
+
+import java.util.Set;
+
+/**
+ * Components that want to be notified of cluster-wide events should use this.
+ *
+ * XXX should this work only for ClusterSingleton-s? some types of events may
be
+ * XXX difficult (or pointless) to propagate to every node.
+ */
+public interface ClusterEventListener {
+
+ /**
+ * The types of events that this listener can process.
+ */
+ Set getEventTypes();
Review comment:
Ok.
##
File path:
solr/core/src/java/org/apache/solr/cluster/events/ClusterEventProducer.java
##
@@ -0,0 +1,71 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.cluster.events;
+
+import org.apache.solr.cloud.ClusterSingleton;
+
+import java.util.Collections;
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.ConcurrentHashMap;
+
+/**
+ * Component that produces {@link ClusterEvent} instances.
+ */
+public interface ClusterEventProducer extends ClusterSingleton {
+
+ String PLUGIN_NAME = "clusterEventProducer";
+
+ /**
+ * Returns a modifiable map of event types and listeners to process events
+ * of a given type.
+ */
+ Map> getEventListeners();
Review comment:
`EnumMap` is a concrete class, if we specify just a `Map` here then
implementations are free to use whatever impl they want.
##
File path:
solr/core/src/java/org/apache/solr/cluster/events/ClusterPropertiesChangedEvent.java
##
@@ -0,0 +1,35 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except
[GitHub] [lucene-solr] goankur commented on pull request #1733: LUCENE-9450 Use BinaryDocValues in the taxonomy writer
goankur commented on pull request #1733: URL: https://github.com/apache/lucene-solr/pull/1733#issuecomment-696420384 Thanks @gautamworah96 for this impactful change and @mikemccand for reviewing it. A few thoughts 1. This change disables STORED fields part but keeps the POSTINGS part here `fullPathField = new StringField(Consts.FULL, "", Field.Store.NO); ` which is unnecessary as postings are already enabled for facet labels in [FacetsConfig#L364-L399](https://github.com/apache/lucene-solr/blob/master/lucene/facet/src/java/org/apache/lucene/facet/FacetsConfig.java#L364-L366) including [dimension drill-down](https://github.com/apache/lucene-solr/blob/master/lucene/facet/src/java/org/apache/lucene/facet/FacetsConfig.java#L88). So I propose we get rid of the `fullPathField` altogether. 2. For maintaining backwards compatibility, we can read facet labels from new BinaryDocValues field, falling back to old StoredField if BinaryDocValues field does not exist or has no value for the docId. The performance penalty of doing so should be acceptable. Alternatively we can implement a special merge policy that takes care of moving data from old Stored field to BinaryDocValues field at the time of merge but that might be tricky to implement. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on pull request #1897: SOLR-9607: Finalize move of Terms component and request handler into the implicit definitions
noblepaul commented on pull request #1897: URL: https://github.com/apache/lucene-solr/pull/1897#issuecomment-696079153 👍 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob closed pull request #5: SOLR-8639 replace static SimpleDateFormat with threadsafe jodatimeDateFormatter
madrob closed pull request #5: URL: https://github.com/apache/lucene-solr/pull/5 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] HoustonPutman commented on a change in pull request #1891: SOLR-14877: Add github action for running SolrJ tests.
HoustonPutman commented on a change in pull request #1891: URL: https://github.com/apache/lucene-solr/pull/1891#discussion_r492184982 ## File path: .github/workflows/solrj-test.yml ## @@ -0,0 +1,27 @@ +name: SolrJ Tests + +on: + pull_request: +branches: + - 'master' +paths: + - '.github/workflows/solrj-test.yml' + - 'solr/solrj/**' + +jobs: + test: +name: Run SolrJ Tests + +runs-on: ubuntu-latest + +steps: +# Setup +- uses: actions/checkout@v2 +- name: Set up JDK 11 + uses: actions/setup-java@v1 + with: +java-version: 11 +- name: Grant execute permission for gradlew + run: chmod +x gradlew +- name: Test the SolrJ Package + run: ./gradlew solr:solrj:test Review comment: I copied the same format as the precommit action, is there something we need to add to use the right properties? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] munendrasn commented on pull request #1900: [SSK-14036]: Remove explicit distrib=false from /terms handler
munendrasn commented on pull request #1900: URL: https://github.com/apache/lucene-solr/pull/1900#issuecomment-696242179 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1877: SOLR-13181: param macro expansion could throw
dsmiley commented on a change in pull request #1877:
URL: https://github.com/apache/lucene-solr/pull/1877#discussion_r492226769
##
File path:
solr/core/src/test/org/apache/solr/request/macro/TestMacroExpander.java
##
@@ -143,15 +142,31 @@ public void testMapExprExpandOn() {
String oldVal = System.getProperty("StreamingExpressionMacros","false");
System.setProperty("StreamingExpressionMacros", "true");
try {
- @SuppressWarnings({"rawtypes"})
- Map expanded = MacroExpander.expand(request);
- assertEquals("zero", ((String[])expanded.get("fq"))[0]);
- assertEquals("one", ((String[])expanded.get("fq"))[1]);
- assertEquals("two", ((String[]) expanded.get("fq"))[2]);
- assertEquals("three", ((String[]) expanded.get("fq"))[3]);
- assertEquals("one", ((String[])expanded.get("expr"))[0]);
+ Map expanded = MacroExpander.expand(request);
+ assertEquals("zero", expanded.get("fq")[0]);
+ assertEquals("one", expanded.get("fq")[1]);
+ assertEquals("two", expanded.get("fq")[2]);
+ assertEquals("three", expanded.get("fq")[3]);
+ assertEquals("one", expanded.get("expr")[0]);
} finally {
System.setProperty("StreamingExpressionMacros", oldVal);
}
}
+
+ @Test
+ public void testUnbalanced() { // SOLR-13181
+final MacroExpander meSkipOnMissingParams = new
MacroExpander(Collections.emptyMap());
+final MacroExpander meFailOnMissingParams = new
MacroExpander(Collections.emptyMap(), true);
+assertEquals("${noClose", meSkipOnMissingParams.expand("${noClose"));
Review comment:
I'm not 100% clear what you suggest; let me try to guess. Let's say the
parameter map has exactly one param == goodAnswer with value 42.
assertEquals("42", meSkipOnMissingParams.expand("${goodAnswer}"));
assertEquals("42", meFailOnMissingParams.expand("${goodAnswer}"));
Is that what you suggest?
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] Hronom commented on a change in pull request #1864: SOLR-14850 ExactStatsCache NullPointerException when shards.tolerant=true
Hronom commented on a change in pull request #1864:
URL: https://github.com/apache/lucene-solr/pull/1864#discussion_r492247322
##
File path: solr/core/src/java/org/apache/solr/search/stats/ExactStatsCache.java
##
@@ -94,6 +94,12 @@ protected ShardRequest
doRetrieveStatsRequest(ResponseBuilder rb) {
protected void doMergeToGlobalStats(SolrQueryRequest req,
List responses) {
Set allTerms = new HashSet<>();
for (ShardResponse r : responses) {
+ if
("true".equalsIgnoreCase(req.getParams().get(ShardParams.SHARDS_TOLERANT)) &&
r.getException() != null) {
Review comment:
No, `SHARDS_TOLERANT` can have third parameter
https://lucene.apache.org/solr/guide/8_6/solrcloud-query-routing-and-read-tolerance.html#shards-tolerant-parameter
```
In addition to true and false, shards.tolerant may also be set to
requireZkConnected - see below.
```
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on pull request #1875: SOLR-14802: Allow LLPSF fields as geodist argument
dsmiley commented on pull request #1875: URL: https://github.com/apache/lucene-solr/pull/1875#issuecomment-695886358 I made some tweaks and committed to master & branch_8x 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] arafalov commented on a change in pull request #1896: SOLR-14880: Support coreRootDirectory setting when create new cores from command line, in standalone mode
arafalov commented on a change in pull request #1896:
URL: https://github.com/apache/lucene-solr/pull/1896#discussion_r492241814
##
File path: solr/core/src/java/org/apache/solr/util/SolrCLI.java
##
@@ -1675,9 +1675,9 @@ protected void runImpl(CommandLine cli) throws Exception {
}
// convert raw JSON into user-friendly output
-solrHome = (String)systemInfo.get("solr_home");
-if (solrHome == null)
- solrHome = configsetsDir.getParentFile().getAbsolutePath();
+coreRootDirectory = (String)systemInfo.get("solr_core_root");
Review comment:
It also had to be introduced, check SOLR-14878
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] arafalov commented on pull request #1900: SOLR-14036: Remove explicit distrib=false from /terms handler
arafalov commented on pull request #1900: URL: https://github.com/apache/lucene-solr/pull/1900#issuecomment-696269537 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] arafalov merged pull request #1904: SOLR-14878: Expose solr.xml's coreRootDirectory property via the System Settings API (part 2)
arafalov merged pull request #1904: URL: https://github.com/apache/lucene-solr/pull/1904 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] cpoerschke commented on a change in pull request #1877: SOLR-13181: param macro expansion could throw
cpoerschke commented on a change in pull request #1877:
URL: https://github.com/apache/lucene-solr/pull/1877#discussion_r492216575
##
File path:
solr/core/src/test/org/apache/solr/request/macro/TestMacroExpander.java
##
@@ -143,15 +142,31 @@ public void testMapExprExpandOn() {
String oldVal = System.getProperty("StreamingExpressionMacros","false");
System.setProperty("StreamingExpressionMacros", "true");
try {
- @SuppressWarnings({"rawtypes"})
- Map expanded = MacroExpander.expand(request);
- assertEquals("zero", ((String[])expanded.get("fq"))[0]);
- assertEquals("one", ((String[])expanded.get("fq"))[1]);
- assertEquals("two", ((String[]) expanded.get("fq"))[2]);
- assertEquals("three", ((String[]) expanded.get("fq"))[3]);
- assertEquals("one", ((String[])expanded.get("expr"))[0]);
+ Map expanded = MacroExpander.expand(request);
+ assertEquals("zero", expanded.get("fq")[0]);
+ assertEquals("one", expanded.get("fq")[1]);
+ assertEquals("two", expanded.get("fq")[2]);
+ assertEquals("three", expanded.get("fq")[3]);
+ assertEquals("one", expanded.get("expr")[0]);
} finally {
System.setProperty("StreamingExpressionMacros", oldVal);
}
}
+
+ @Test
+ public void testUnbalanced() { // SOLR-13181
+final MacroExpander meSkipOnMissingParams = new
MacroExpander(Collections.emptyMap());
+final MacroExpander meFailOnMissingParams = new
MacroExpander(Collections.emptyMap(), true);
+assertEquals("${noClose", meSkipOnMissingParams.expand("${noClose"));
Review comment:
How about adding (say) `${goodAnswer} ${noClose` as another case and it
turning into `42 ${noClose` if there is a `goodAnswer=42` mapping i.e. to
demonstrate that absence of closing curly bracket partially affects expansion
(as opposed to no expansion at all happening)?
##
File path: solr/core/src/java/org/apache/solr/request/macro/MacroExpander.java
##
@@ -135,33 +135,34 @@ private String _expand(String val) {
}
}
else if (idx < 0) {
-if (sb == null) return val;
-sb.append(val.substring(start));
-return sb.toString();
+break;
}
// found unescaped "${"
- idx += macroStart.length();
+ final int matchedStart = idx;
- int rbrace = val.indexOf('}', idx);
+ int rbrace = val.indexOf('}', matchedStart + macroStart.length());
if (rbrace == -1) {
// no matching close brace...
-continue;
Review comment:
> ... fix infinite loop when no close ...
Ah, yes, good catch!
And since the logic in the loop is quite complex the "infinite loop" wording
inspired me to go lookup again about the _loop invariants_ and _loop variants_
concepts and work it through here:
* `val.size() - idx` looks like the loops variant and to ensure loop
termination it must decrease i.e. `idx` must advance (or we must break or
return out of the loop)
* `idx > 0` leads to advancing
* `idx < 0` previously returned and now it breaks i.e. either gets us out of
the loop
* `idx == 0` if combined with `rbrace == -1` i.e. no closing would get us
stuck in the loop if `continue` is used but both `return null` or `break` get
us out of the loop
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] epugh commented on pull request #1898: SOLR-14882
epugh commented on pull request #1898: URL: https://github.com/apache/lucene-solr/pull/1898#issuecomment-696166997 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on a change in pull request #1758: SOLR-14749: Provide a clean API for cluster-level event processing, Initial draft.
murblanc commented on a change in pull request #1758:
URL: https://github.com/apache/lucene-solr/pull/1758#discussion_r491887454
##
File path:
solr/core/src/java/org/apache/solr/cluster/events/ClusterEventProducer.java
##
@@ -0,0 +1,71 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.cluster.events;
+
+import org.apache.solr.cloud.ClusterSingleton;
+
+import java.util.Collections;
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.ConcurrentHashMap;
+
+/**
+ * Component that produces {@link ClusterEvent} instances.
+ */
+public interface ClusterEventProducer extends ClusterSingleton {
+
+ String PLUGIN_NAME = "clusterEventProducer";
+
+ /**
+ * Returns a modifiable map of event types and listeners to process events
+ * of a given type.
+ */
+ Map> getEventListeners();
Review comment:
These implementations will be internal (the `ClusterEvent` values are a
finite defined set so any new events imply changes to internal implementation),
so we likely can accept to use `EnumMap` in these.
Potential efficiency gain vs. flexibility?
I would have used `EnumMap` but ok to keep `Map`.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on pull request #1638: SOLR-14066: Deprecate DIH
madrob commented on pull request #1638: URL: https://github.com/apache/lucene-solr/pull/1638#issuecomment-696235285 @chatman Can we close this? It looks like DIH has already been removed in master branch. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on pull request #1898: SOLR-14882
madrob commented on pull request #1898: URL: https://github.com/apache/lucene-solr/pull/1898#issuecomment-696213908 Please add a 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on a change in pull request #1864: SOLR-14850 ExactStatsCache NullPointerException when shards.tolerant=true
madrob commented on a change in pull request #1864:
URL: https://github.com/apache/lucene-solr/pull/1864#discussion_r492181202
##
File path: solr/core/src/java/org/apache/solr/search/stats/ExactStatsCache.java
##
@@ -94,6 +94,12 @@ protected ShardRequest
doRetrieveStatsRequest(ResponseBuilder rb) {
protected void doMergeToGlobalStats(SolrQueryRequest req,
List responses) {
Set allTerms = new HashSet<>();
for (ShardResponse r : responses) {
+ if
("true".equalsIgnoreCase(req.getParams().get(ShardParams.SHARDS_TOLERANT)) &&
r.getException() != null) {
Review comment:
Should we use `getBool` here instead?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] tflobbe commented on pull request #1861: SOLR-10391: Add overwrite option to UPLOAD ConfigSet action
tflobbe commented on pull request #1861: URL: https://github.com/apache/lucene-solr/pull/1861#issuecomment-696456676 I plan to merge this tomorrow 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on pull request #1900: SOLR-14036: Remove explicit distrib=false from /terms handler
dsmiley commented on pull request #1900: URL: https://github.com/apache/lucene-solr/pull/1900#issuecomment-696260676 I'm glad to see this :-) I think the change of default behavior for users using /terms should be master-only and have a note in `solr-upgrade-notes.adoc`. If you like, you could backport the underlying fix but not the change in 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ctargett commented on pull request #1869: SOLR-14866 autowidth tables in ref guide
ctargett commented on pull request #1869: URL: https://github.com/apache/lucene-solr/pull/1869#issuecomment-696366569 I'm a little confused what's going on here at this point. It seems the latest commits increase the mixing of styles, which as I said is fine with me in general, but sort of counter to what you said you wanted to do. There are 3 tables in `charfilterfactories.adoc` for example, and two are now changed to remove the `[options="header"]` and add a blank line between header row and data rows, but the header param remains on the 3rd table which also includes the `%autowidth.spread,width="100%"` parameters which I thought I showed aren't necessary and are already the default. Despite all that, the `asciidoc-syntax.adoc` is updated to imply the best practice is defining the autospread, width, and header params explicitly, even though other tables in this PR were changed to definitely not do that. It stops short of saying it's a best practice, though, it just points out that one might see it (when before it was more direct in what it recommended writers to do). So, I'm no longer sure what's really being achieved here. Removing TODOs that aren't needed anymore because they're holdovers from PDF days is a laudable goal and helpful cleanup, but is it any more clear now what both the internal docs and examples within the content would recommend someone do to define tables? I know that wasn't the original intent, but it got turned into a goal and now it's not doing that. At this point I'm not sure if I should approve the PR (since I don't think it's ultimately that big a deal) or if I should look to hold the PR to some level of internal consistency? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14878) SystemInfoHandler need to expose coreRootDirectory
[ https://issues.apache.org/jira/browse/SOLR-14878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199741#comment-17199741 ] ASF subversion and git services commented on SOLR-14878: Commit 91b6223f380dbf26d2e7748f6df7f7a6de3aacfa in lucene-solr's branch refs/heads/master from Alexandre Rafalovitch [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=91b6223 ] SOLR-14878: Expose coreRootDirectory via API (Correction to make name shorter and always return value) > SystemInfoHandler need to expose coreRootDirectory > -- > > Key: SOLR-14878 > URL: https://issues.apache.org/jira/browse/SOLR-14878 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Fix For: master (9.0) > > Time Spent: 1h 10m > Remaining Estimate: 0h > > solr.xml allows to define *coreRootDirectory* but it is currently impossible > to get this value through API, which makes external commands (like /bin/solr > create_core) fail when this parameter is set. > Expose this property if it is set to a value different from solr_home. > It will be accessible under the name *solr_core_root* and accessible from > both System Settings API end-points > * /solr/admin/info/system > * /api/node/system -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] arafalov merged pull request #1904: SOLR-14878: Expose solr.xml's coreRootDirectory property via the System Settings API (part 2)
arafalov merged pull request #1904: URL: https://github.com/apache/lucene-solr/pull/1904 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9537) Add Indri Search Engine Functionality to Lucene
Cameron VandenBerg created LUCENE-9537: -- Summary: Add Indri Search Engine Functionality to Lucene Key: LUCENE-9537 URL: https://issues.apache.org/jira/browse/LUCENE-9537 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Cameron VandenBerg Attachments: LUCENE-INDRI.patch Indri ([http://lemurproject.org/indri.php]) is an academic search engine developed by The University of Massachusetts and Carnegie Mellon University. The major difference between Lucene and Indri is that Indri will give a document a "smoothing score" to a document that does not contain the search term, which has improved the search ranking accuracy in our experiments. I have created an Indri patch, which adds the search code needed to implement the Indri AND logic as well as Indri's implementation of Dirichlet Smoothing. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9528) Clean up obsolete and commented-out cruft from StandardSyntaxParser.jj
[ https://issues.apache.org/jira/browse/LUCENE-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199740#comment-17199740 ] David Smiley commented on LUCENE-9528: -- Just curious; are you (Dawid) improving the flexible query parser because you are using it, or ... ? I've been procrastinating proposing it's removal from Lucene. I've been on a couple big search projects where we took a look at it and chose not to use it, and I don't recommend to most people who need a query parser either. > Clean up obsolete and commented-out cruft from StandardSyntaxParser.jj > -- > > Key: LUCENE-9528 > URL: https://issues.apache.org/jira/browse/LUCENE-9528 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: master (9.0) > > Time Spent: 20m > Remaining Estimate: 0h > > The indentation in that file is crazy. So are micro-optimizations which make > reading the syntax parser much more difficult than it actually is. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14884) TestContainerPlugin.testApiFromPackage jenkins failures
[ https://issues.apache.org/jira/browse/SOLR-14884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199733#comment-17199733 ] ASF subversion and git services commented on SOLR-14884: Commit 1a018105b41e260bc3aaaf760fb9f2dab98ff53c in lucene-solr's branch refs/heads/branch_8x from noblepaul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1a01810 ] SOLR-14884: TestContainerPlugin.testApiFromPackage jenkins failures > TestContainerPlugin.testApiFromPackage jenkins failures > --- > > Key: SOLR-14884 > URL: https://issues.apache.org/jira/browse/SOLR-14884 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14884) TestContainerPlugin.testApiFromPackage jenkins failures
[ https://issues.apache.org/jira/browse/SOLR-14884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199732#comment-17199732 ] ASF subversion and git services commented on SOLR-14884: Commit 3d03a1b88c88aa5664499b59a59c477f7ff5c3e7 in lucene-solr's branch refs/heads/branch_8x from noblepaul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3d03a1b ] SOLR-14884: TestContainerPlugin.testApiFromPackage jenkins failures > TestContainerPlugin.testApiFromPackage jenkins failures > --- > > Key: SOLR-14884 > URL: https://issues.apache.org/jira/browse/SOLR-14884 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14884) TestContainerPlugin.testApiFromPackage jenkins failures
[ https://issues.apache.org/jira/browse/SOLR-14884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199729#comment-17199729 ] ASF subversion and git services commented on SOLR-14884: Commit 4087958d31829ee36ddda0bd884ea303ae9a1a61 in lucene-solr's branch refs/heads/master from noblepaul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4087958 ] SOLR-14884: TestContainerPlugin.testApiFromPackage jenkins failures > TestContainerPlugin.testApiFromPackage jenkins failures > --- > > Key: SOLR-14884 > URL: https://issues.apache.org/jira/browse/SOLR-14884 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14884) TestContainerPlugin.testApiFromPackage jenkins failures
[ https://issues.apache.org/jira/browse/SOLR-14884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199728#comment-17199728 ] ASF subversion and git services commented on SOLR-14884: Commit 4087958d31829ee36ddda0bd884ea303ae9a1a61 in lucene-solr's branch refs/heads/master from noblepaul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4087958 ] SOLR-14884: TestContainerPlugin.testApiFromPackage jenkins failures > TestContainerPlugin.testApiFromPackage jenkins failures > --- > > Key: SOLR-14884 > URL: https://issues.apache.org/jira/browse/SOLR-14884 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14597) Advanced Query Parser
[
https://issues.apache.org/jira/browse/SOLR-14597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199726#comment-17199726
]
Gus Heck commented on SOLR-14597:
-
looks like LUCENE-9531 has caused a conflict with the patch, and there have
been some changes to the gradle files running javacc so I'm working on updating
to work with that and I'll publish the fix as a pull-request for easier review.
Now that there is code to look at some responses:
[~arafalov]: Point noted about TypeTokenFilter, there is similarity though
filtering on flags instead of types. It would be attractive to also inherit
from FilteringTokenFilter but It looks like one edge case I ran into isn't
handled by the super class. (and makes me wonder if there's a lurking issue
with other FilteringTokenFilter sub classes. The case I ran into is thus: The
first token in the stream gets assigned a synonym, then in a subsequent step
the first token is dropped (this is quite intentional in some use cases we had
where the intent was to entirely prevent matches on the original token, but
still match on the synonym). When this happens it causes
{{java.lang.IllegalArgumentException: first position increment must be > 0 (got
0)}} despite the fact that this scenario is not actually an error in terms of
which tokens we want. Unfortunately there's no good way to know what's going to
happen to the next token (which may not have the flags in question) so I came
up with a workaround that I'm not very pleased with dropping in a placeholder
token that is unlikely to match anything. Open to suggestions for better
options there, and interested in whether or not other filters that drop tokens
can hit the same issue, or if they've handled it in some graceful way I'm not
appreciating.
Also, now that the code is available, let me know if you still see similarity
between PatternTypingFilterFactory and KeywordMarkerFilterFactory... I think
they are quite different.
[~ichattopadhyaya], [~dsmiley] While some of this could potentially be broken
out into a package, there are also some changes to core and some lucene level
classes that probably wouldn't want to be in a package, so feel free to put
some eyes on it and suggest what the dividing line is (more eyes == better).
I'm not against the idea of a 1st party package, but the question is will this
be popular enough to merit default inclusion? Another breaking new ground sort
of question is "Is it easier to pull it in later or push it out to a package
later if we change our minds?" Maybe neither is harder...
Changes to note to classes outside the new org.apache.solr.aqp package (where
the meat of the new parser and it's .jj file lives):
# TypeAsSynonymFilter is gaining the ability to manage what flags are
transmitted from the original token to the synonym when it is created
# BaseTokenStreamTestCase is gaining the ability to verify the flags on the
tokens produced.
# access org.apache.solr.cloud.AbstractDistribZkTestBase#copyConfigUp is
opened up so that it can be used in a wider array of tests.
# Solr gains TokenAnalyzerFilter which applies the Analyzer from a specified
field type to the individual tokens of the current stream (see javadoc for more
detail)
# Operator and SynonymQueryStyle are extracted from the standard parser's base
class so they can be re-used. Reuse is is necessary because TextField
references SynonymQueryStyle directly.
# The above change forces an compile time API change in TextField, which might
force this to not be available till 9.x (though the desire to make AQP
available in 8.x is there).
# The change to TextField then failed TestPackages which failed with a
ClassNotFound when it went looking for the old SynonymeQueryStyle inner class
that had been promoted to a separate class. This forced me to decompile and
provide classes and build/rebuild support for the binary jars checked in for
TestPackages (as *.jar.bin). (the .java files for the classes loaded by this
test had not been checked in). This is the genesis of the o.a.smy.pkg package
namespace.
Some of the above (especially #7) might want to be broken into related or
sub-tickets.
> Advanced Query Parser
> -
>
> Key: SOLR-14597
> URL: https://issues.apache.org/jira/browse/SOLR-14597
> Project: Solr
> Issue Type: New Feature
> Components: query parsers
>Reporter: Mike Nibeck
>Assignee: Gus Heck
>Priority: Major
> Attachments: aqp_patch.patch
>
>
> This JIRA ticket tracks the progress of SIP-9, the Advanced Query Parser that
> is being donated by the Library of Congress. Full description of the feature
> can be found on the SIP Page.
> [https://cwiki.apache.org/confluence/display/SOLR/SIP-9+Advanced+Query+Parser]
> Briefly, this parser provides a comprehensive syntax for users t
[GitHub] [lucene-solr] tflobbe commented on pull request #1861: SOLR-10391: Add overwrite option to UPLOAD ConfigSet action
tflobbe commented on pull request #1861: URL: https://github.com/apache/lucene-solr/pull/1861#issuecomment-696456676 I plan to merge this tomorrow 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] tflobbe commented on a change in pull request #1861: SOLR-10391: Add overwrite option to UPLOAD ConfigSet action
tflobbe commented on a change in pull request #1861:
URL: https://github.com/apache/lucene-solr/pull/1861#discussion_r492423507
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/ConfigSetsHandler.java
##
@@ -170,21 +176,90 @@ private void handleConfigUploadRequest(SolrQueryRequest
req, SolrQueryResponse r
// Create a node for the configuration in zookeeper
boolean trusted = getTrusted(req);
-zkClient.makePath(configPathInZk, ("{\"trusted\": " +
Boolean.toString(trusted) + "}").
-getBytes(StandardCharsets.UTF_8), true);
+Set filesToDelete = Collections.emptySet();
+if (overwritesExisting) {
+ if (!trusted) {
+ensureOverwritingUntrustedConfigSet(zkClient, configPathInZk);
+ }
+ if (req.getParams().getBool(ConfigSetParams.CLEANUP, false)) {
+filesToDelete = getAllConfigsetFiles(zkClient, configPathInZk);
+ }
+} else {
+ zkClient.makePath(configPathInZk, ("{\"trusted\": " +
Boolean.toString(trusted) + "}").
+ getBytes(StandardCharsets.UTF_8), true);
+}
ZipInputStream zis = new ZipInputStream(inputStream,
StandardCharsets.UTF_8);
ZipEntry zipEntry = null;
while ((zipEntry = zis.getNextEntry()) != null) {
String filePathInZk = configPathInZk + "/" + zipEntry.getName();
+ if (filePathInZk.endsWith("/")) {
+filesToDelete.remove(filePathInZk.substring(0, filePathInZk.length()
-1));
+ } else {
+filesToDelete.remove(filePathInZk);
+ }
if (zipEntry.isDirectory()) {
-zkClient.makePath(filePathInZk, true);
+zkClient.makePath(filePathInZk, false, true);
Review comment:
Yes, I don't think this would be needed at this point. No API would set
this, and no Solr component would read it. I guess the only case would be a
custom component that writes and reads directly to ZooKeeper.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14884) TestContainerPlugin.testApiFromPackage jenkins failures
Noble Paul created SOLR-14884: - Summary: TestContainerPlugin.testApiFromPackage jenkins failures Key: SOLR-14884 URL: https://issues.apache.org/jira/browse/SOLR-14884 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob opened a new pull request #1905: LUCENE-9488 Release with Gradle Part 2
madrob opened a new pull request #1905: URL: https://github.com/apache/lucene-solr/pull/1905 Deleted lucene/version.properties again 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] goankur commented on pull request #1733: LUCENE-9450 Use BinaryDocValues in the taxonomy writer
goankur commented on pull request #1733: URL: https://github.com/apache/lucene-solr/pull/1733#issuecomment-696420384 Thanks @gautamworah96 for this impactful change and @mikemccand for reviewing it. A few thoughts 1. This change disables STORED fields part but keeps the POSTINGS part here `fullPathField = new StringField(Consts.FULL, "", Field.Store.NO); ` which is unnecessary as postings are already enabled for facet labels in [FacetsConfig#L364-L399](https://github.com/apache/lucene-solr/blob/master/lucene/facet/src/java/org/apache/lucene/facet/FacetsConfig.java#L364-L366) including [dimension drill-down](https://github.com/apache/lucene-solr/blob/master/lucene/facet/src/java/org/apache/lucene/facet/FacetsConfig.java#L88). So I propose we get rid of the `fullPathField` altogether. 2. For maintaining backwards compatibility, we can read facet labels from new BinaryDocValues field, falling back to old StoredField if BinaryDocValues field does not exist or has no value for the docId. The performance penalty of doing so should be acceptable. Alternatively we can implement a special merge policy that takes care of moving data from old Stored field to BinaryDocValues field at the time of merge but that might be tricky to implement. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] arafalov opened a new pull request #1904: SOLR-14878: Expose solr.xml's coreRootDirectory property via the System Settings API (part 2)
arafalov opened a new pull request #1904: URL: https://github.com/apache/lucene-solr/pull/1904 # Description Adjustment based on comments in - merged - #1894 # Solution 1. Shorten the name solr_core_root->core_root 2. Always return the value, even if not explicitly defined 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14883) Add a Muse (CI) configuration file
[ https://issues.apache.org/jira/browse/SOLR-14883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199686#comment-17199686 ] David Smiley commented on SOLR-14883: - Can you please add some links here on ASF infra's / GitHub's relationship to Muse? I'm not familiar. > Add a Muse (CI) configuration file > -- > > Key: SOLR-14883 > URL: https://issues.apache.org/jira/browse/SOLR-14883 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Thomas DuBuisson >Priority: Trivial > Time Spent: 0.5h > Remaining Estimate: 0h > > This ticket is a continuation of conversation that started > https://issues.apache.org/jira/browse/SOLR-14819?filter=-2 and was also on > the mailing list. > > The Apache infrastructure team has installed the Muse GitHub application. In > order for Lucene-Solr to benefit the application must understand how to build > the project. While it has build heuristics, it does not guess between JDK8 > or JDK11 (two JDKs most supported by several static analysis tools). Thus, > this configuration explicitly instructs use of JDK11. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] arafalov commented on pull request #1900: SOLR-14036: Remove explicit distrib=false from /terms handler
arafalov commented on pull request #1900: URL: https://github.com/apache/lucene-solr/pull/1900#issuecomment-696402318 > @arafalov > There is one already which I have modified(DistributedTermsComponentTest) - https://github.com/apache/lucene-solr/pull/1900/files#diff-9b9ccbcf271c6320902d92479615f4fbR73 Thank you for clarification. I saw that code change, but did not realize it answered my question. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9536) Optimize OrdinalMap when one segment contains all distinct values?
Julie Tibshirani created LUCENE-9536: Summary: Optimize OrdinalMap when one segment contains all distinct values? Key: LUCENE-9536 URL: https://issues.apache.org/jira/browse/LUCENE-9536 Project: Lucene - Core Issue Type: Improvement Reporter: Julie Tibshirani For doc values that are not too high cardinality, it seems common to have some large segments that contain all distinct values (plus many small segments who are missing some values). In this case, we could check if the first segment ords map perfectly to global ords and if so store `globalOrdDeltas` and `firstSegments` as `LongValues.ZEROES`. This could save a small amount of space. I don’t think it would help a huge amount, especially since the optimization might only kick in with small/ medium cardinalities, which don’t create huge `OrdinalMap` instances anyways? But it is simple and seemed worth mentioning. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-10305) uniqueKey field store=false will throw null NullPointerException
[ https://issues.apache.org/jira/browse/SOLR-10305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199665#comment-17199665 ] David Smiley commented on SOLR-10305: - For awhile now, uniqueKey supports docValues=true stored=false. Jan Hacker, if you can get an exception in this scenario (help explain how to reproduce) then I'll take a closer look. uniqueKey is almost always "required" -- must be defined in the schema. Stored/DocValues is a different matter than having your schema identify which field is the unique key. > uniqueKey field store=false will throw null NullPointerException > > > Key: SOLR-10305 > URL: https://issues.apache.org/jira/browse/SOLR-10305 > Project: Solr > Issue Type: Bug >Affects Versions: 5.3.1 >Reporter: jin jing >Priority: Major > > i found if set uniqueKey store=false ,when insert some index,and query as *:* > will throw nullPointer: > java.lang.NullPointerException > at > org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:1095) > at > org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:754) > at > org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:733) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mayya-sharipova commented on pull request #1903: Fix bug in sort optimization
mayya-sharipova commented on pull request #1903: URL: https://github.com/apache/lucene-solr/pull/1903#issuecomment-696373592 @jimczi I could not reproduce an issue of duplicate documents in Lucene, and I am still not sure how it actually happens. Even as we were [incorrectly advancing](https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/search/Weight.java#L216) only `scorerIterator`, as `filteredIterator` is an intersection of `collectorIterator` and `scorerIterator`, a next document from `filteredIterator` must be a document > the current document of `scorerIterator`? No? There was also a question why we did not detect duplicate documents in the tests. First, they don't happen in the tests, and before I was not using `AssertingIndexSearcher`. I've changed the tests on _doc sort to use `AssertingIndexSearcher` 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mayya-sharipova opened a new pull request #1903: Fix bug in sort optimization
mayya-sharipova opened a new pull request #1903: URL: https://github.com/apache/lucene-solr/pull/1903 Fix bug how iterator with skipping functionality advances and produces docs Relates to #1725 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ctargett commented on pull request #1869: SOLR-14866 autowidth tables in ref guide
ctargett commented on pull request #1869: URL: https://github.com/apache/lucene-solr/pull/1869#issuecomment-696366569 I'm a little confused what's going on here at this point. It seems the latest commits increase the mixing of styles, which as I said is fine with me in general, but sort of counter to what you said you wanted to do. There are 3 tables in `charfilterfactories.adoc` for example, and two are now changed to remove the `[options="header"]` and add a blank line between header row and data rows, but the header param remains on the 3rd table which also includes the `%autowidth.spread,width="100%"` parameters which I thought I showed aren't necessary and are already the default. Despite all that, the `asciidoc-syntax.adoc` is updated to imply the best practice is defining the autospread, width, and header params explicitly, even though other tables in this PR were changed to definitely not do that. It stops short of saying it's a best practice, though, it just points out that one might see it (when before it was more direct in what it recommended writers to do). So, I'm no longer sure what's really being achieved here. Removing TODOs that aren't needed anymore because they're holdovers from PDF days is a laudable goal and helpful cleanup, but is it any more clear now what both the internal docs and examples within the content would recommend someone do to define tables? I know that wasn't the original intent, but it got turned into a goal and now it's not doing that. At this point I'm not sure if I should approve the PR (since I don't think it's ultimately that big a deal) or if I should look to hold the PR to some level of internal consistency? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on pull request #1740: LUCENE-9458: WDGF and WDF should tie-break by endOffset
dsmiley commented on pull request #1740: URL: https://github.com/apache/lucene-solr/pull/1740#issuecomment-696351031 Sorry for the delay; I have had a solution for over a month locally but didn't share it yet. I'm pretty comfortable with what I just pushed. I did some "fuzz testing" to determine if there was a token ordering difference given the same input but varying the `compare` logic. It revealed that I could simplify WDGF's `compare` logic to only look at the start and end offset. However, WDF's `compare` failed this exercise; my change introduced a new position in some cases, although not the ones I explicitly tested for. WDF is more complicated (to me any way), and furthermore WDF is deprecated so I'm not motivated to disturb the logic there. I added the fuzz testing here as a comment. It's not really committable live because it's requires modifying WDGF's `compare` to actually do two compares and assert the same result. Without that, there is no assertion being checked -- no comparison. Suggested CHANGES.txt would be improvement: "WordDelimiterGraphFilter should tie-break by endOffset to emit longer tokens first. The same graph is produced." 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] TomMD commented on a change in pull request #1901: SOLR-14883 Add a Muse (Continuous assurance platform) configuration
TomMD commented on a change in pull request #1901: URL: https://github.com/apache/lucene-solr/pull/1901#discussion_r492311229 ## File path: .muse/config.toml ## @@ -0,0 +1 @@ +jdk11 = true Review comment: @tflobbe Sure, I'll put that here and amend the commit. The full documentation is docs.muse.dev. Most interesting is the repository configuration reference https://docs.muse.dev/docs/repository-configuration/ which details how to change which tools runs, add custom tools (other than those built into the platform by default), filter for or against certain bug types, etc. For example, an explicit `.muse/config.toml` file might be: ``` jdk11 = true build = "./gradlew assemble" tools = [ "infer", "errorprone", "findsecbugs" ] customTools = [ ] ``` 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9464) Add high(er)-level hit highlighter example that demonstrates and uses low-level components
[ https://issues.apache.org/jira/browse/LUCENE-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199621#comment-17199621 ] David Smiley commented on LUCENE-9464: -- Yes, "lucene.experimental" is mostly about API stability within a minor release, not really other stability. It does tend to get over-used just in case but this here is fresh code that advertises itself as an example. As a project we don't remove it when we should probably. The other highlighters have very stable APIs. > Add high(er)-level hit highlighter example that demonstrates and uses > low-level components > -- > > Key: LUCENE-9464 > URL: https://issues.apache.org/jira/browse/LUCENE-9464 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Fix For: master (9.0) > > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3550) Create example code for core
[ https://issues.apache.org/jira/browse/LUCENE-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199616#comment-17199616 ] Animesh Pandey commented on LUCENE-3550: Hi, This is a pretty old Jira but I see that it is still open. I wanted to confirm if the work was completed and if not, I'd like to take a look at this. Regards, Animesh > Create example code for core > > > Key: LUCENE-3550 > URL: https://issues.apache.org/jira/browse/LUCENE-3550 > Project: Lucene - Core > Issue Type: New Feature > Components: core/other >Reporter: Shai Erera >Priority: Major > Labels: newdev > Attachments: LUCENE-3550-sort.patch, LUCENE-3550.patch > > > Trunk has gone under lots of API changes. Some of which are not trivial, and > the migration path from 3.x to 4.0 seems hard. I'd like to propose some way > to tackle this, by means of live example code. > The facet module implements this approach. There is live Java code under > src/examples that demonstrate some well documented scenarios. The code itself > is documented, in addition to javadoc. Also, the code itself is being unit > tested regularly. > We found it very difficult to keep documentation up-to-date -- javadocs > always lag behind, Wiki pages get old etc. However, when you have live Java > code, you're *forced* to keep it up-to-date. It doesn't compile if you break > the API, it fails to run if you change internal impl behavior. If you keep it > simple enough, its documentation stays simple to. > And if we are successful at maintaining it (which we must be, otherwise the > build should fail), then people should have an easy experience migrating > between releases. So say you take the simple scenario "I'd like to index > documents which have the fields ID, date and body". Then you create an > example class/method that accomplishes that. And between releases, this code > gets updated, and people can follow the changes required to implement that > scenario. > I'm not saying the examples code should always stay optimized. We can aim at > that, but I don't try to fool myself thinking that we'll succeed. But at > least we can get it compiled and regularly unit tested. > I think that it would be good if we introduce the concept of examples such > that if a module (core, contrib, modules) have an src/examples, we package it > in a .jar and include it with the binary distribution. That's for a first > step. We can also have meta examples, under their own module/contrib, that > show how to combine several modules together (this might even uncover API > problems), but that's definitely a second phase. > At first, let's do the "unit examples" (ala unit tests) and better start with > core. Whatever we succeed at writing for 4.0 will only help users. So let's > use this issue to: > # List example scenarios that we want to demonstrate for core > # Building the infrastructure in our build system to package and distribute a > module's examples. > Please feel free to list here example scenarios that come to mind. We can > then track what's been done and what's not. The more we do the better. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1894: SOLR-14878: Expose solr.xml's coreRootDirectory property via the System Settings API
dsmiley commented on a change in pull request #1894:
URL: https://github.com/apache/lucene-solr/pull/1894#discussion_r492274546
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/SystemInfoHandler.java
##
@@ -139,8 +140,19 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
if (solrCloudMode) {
rsp.add("zkHost", getCoreContainer(req,
core).getZkController().getZkServerAddress());
}
-if (cc != null)
- rsp.add( "solr_home", cc.getSolrHome());
+if (cc != null) {
+ String solrHome = cc.getSolrHome();
+ rsp.add("solr_home", solrHome);
+
+ Path coreRootDirectory = cc.getCoreRootDirectory();
+ if (coreRootDirectory != null) {
+String coreRootDirectoryString = coreRootDirectory.toString();
+if (!coreRootDirectoryString.equals(solrHome)) {
Review comment:
The "solr_" part should be skipped IMO. Everything here is Solr :-)
> Let's just hope they don't run version 9 tool against version 8 core.
Well it's up to them to have a tolerant client. For the SolrCLI I think it
makes sense to check for null in case of a cross-version situation.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] epugh commented on pull request #1898: SOLR-14882
epugh commented on pull request #1898: URL: https://github.com/apache/lucene-solr/pull/1898#issuecomment-696301654 This is why we need a full overhaul of the SolrCLI, get all this logic out of the solr shell and cmd files, and into Java, and have one way of doing everything! 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] epugh commented on pull request #1898: SOLR-14882
epugh commented on pull request #1898: URL: https://github.com/apache/lucene-solr/pull/1898#issuecomment-696299309 Okay, turns out my not loading json was due to something odd in the sample data I exported (sigh)... However, the more_books.jsonl works just fine. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] arafalov commented on a change in pull request #1894: SOLR-14878: Expose solr.xml's coreRootDirectory property via the System Settings API
arafalov commented on a change in pull request #1894:
URL: https://github.com/apache/lucene-solr/pull/1894#discussion_r492270332
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/SystemInfoHandler.java
##
@@ -139,8 +140,19 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
if (solrCloudMode) {
rsp.add("zkHost", getCoreContainer(req,
core).getZkController().getZkServerAddress());
}
-if (cc != null)
- rsp.add( "solr_home", cc.getSolrHome());
+if (cc != null) {
+ String solrHome = cc.getSolrHome();
+ rsp.add("solr_home", solrHome);
+
+ Path coreRootDirectory = cc.getCoreRootDirectory();
+ if (coreRootDirectory != null) {
+String coreRootDirectoryString = coreRootDirectory.toString();
+if (!coreRootDirectoryString.equals(solrHome)) {
Review comment:
Ok, I was on borderline myself. I felt that because this option is
barely used, having the same long string sent twice was bit of a waste of
bandwidth. But, I guess it does not happen too often.
I can correct both generation and invocation of this option to make it a
guaranteed setup. Let's just hope they don't run version 9 tool against version
8 core.
Also, if you don't like the name (the other open point), this is a good time
to mention it.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] arafalov commented on pull request #1898: SOLR-14882
arafalov commented on pull request #1898:
URL: https://github.com/apache/lucene-solr/pull/1898#issuecomment-696296773
> Okay, so @arafalov I am having NO luck in finding the text `usage:` or
where it is comiong from... I can live with it...
It helps to see where other invocations do it. So, it seems to be something
about:
```
if (cli.getOptions().length == 0 || cli.getArgs().length > 0 ||
cli.hasOption("h")) {
new HelpFormatter().printHelp("bin/solr utils [OPTIONS]",
getToolOptions(this));
return 1;
}
```
This tool does not have it, so probably falls back to default implementation
that constructs default message with getOptions() instead. Not the end of the
world, but would have been nice to fix.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] epugh commented on pull request #1898: SOLR-14882
epugh commented on pull request #1898: URL: https://github.com/apache/lucene-solr/pull/1898#issuecomment-696292278 Okay, working on testing the CURL commands in the solr-control-script-reference.adoc...I am not able to do this: ``` curl -X POST -d @big.jsonl http://localhost:8983/solr/dude2/update/json/docs?commit=true ``` So, did I miss soemthing, maybe we aren't doing JSONL... 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] HoustonPutman merged pull request #1899: Adding dev-docs around the use of Git Worktree.
HoustonPutman merged pull request #1899: URL: https://github.com/apache/lucene-solr/pull/1899 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] epugh commented on pull request #1898: SOLR-14882
epugh commented on pull request #1898: URL: https://github.com/apache/lucene-solr/pull/1898#issuecomment-696284466 Okay, so @arafalov I am having NO luck in finding the text `usage:` or where it is comiong from... I can live with it... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-9607) Finalize /terms implicit definition and remove explicit one from configsets
[ https://issues.apache.org/jira/browse/SOLR-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199566#comment-17199566 ] David Smiley commented on SOLR-9607: Oops; I was confused with SOLR-14036; nevermind. > Finalize /terms implicit definition and remove explicit one from configsets > --- > > Key: SOLR-9607 > URL: https://issues.apache.org/jira/browse/SOLR-9607 > Project: Solr > Issue Type: Improvement >Affects Versions: 6.2 >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Minor > Fix For: master (9.0) > > Time Spent: 0.5h > Remaining Estimate: 0h > > SOLR-9193 has created implicit definitions for terms SearchComponent and > /terms RequestHandler. The RequestHandler definition is missing a couple of > parameters to match current explicit definitions (terms=true, distrib=false). > Once those parameters are added, both SearchComponent and RequestHandler > sections can be removed from example configuration files, making them a bit > easier to read. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-9607) Finalize /terms implicit definition and remove explicit one from configsets
[
https://issues.apache.org/jira/browse/SOLR-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199564#comment-17199564
]
David Smiley commented on SOLR-9607:
My code review indicated that you should update {{solr-upgrade-notes.adoc}} for
9.0. Do you disagree with my suggestion?
> Finalize /terms implicit definition and remove explicit one from configsets
> ---
>
> Key: SOLR-9607
> URL: https://issues.apache.org/jira/browse/SOLR-9607
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 6.2
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Fix For: master (9.0)
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> SOLR-9193 has created implicit definitions for terms SearchComponent and
> /terms RequestHandler. The RequestHandler definition is missing a couple of
> parameters to match current explicit definitions (terms=true, distrib=false).
> Once those parameters are added, both SearchComponent and RequestHandler
> sections can be removed from example configuration files, making them a bit
> easier to read.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] tflobbe commented on a change in pull request #1901: SOLR-14883 Add a Muse (Continuous assurance platform) configuration
tflobbe commented on a change in pull request #1901: URL: https://github.com/apache/lucene-solr/pull/1901#discussion_r492252479 ## File path: .muse/config.toml ## @@ -0,0 +1 @@ +jdk11 = true Review comment: Could you add a comment or two pointing to the documentation how to add/change/skip checks? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1894: SOLR-14878: Expose solr.xml's coreRootDirectory property via the System Settings API
dsmiley commented on a change in pull request #1894:
URL: https://github.com/apache/lucene-solr/pull/1894#discussion_r492252261
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/SystemInfoHandler.java
##
@@ -139,8 +140,19 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
if (solrCloudMode) {
rsp.add("zkHost", getCoreContainer(req,
core).getZkController().getZkServerAddress());
}
-if (cc != null)
- rsp.add( "solr_home", cc.getSolrHome());
+if (cc != null) {
+ String solrHome = cc.getSolrHome();
+ rsp.add("solr_home", solrHome);
+
+ Path coreRootDirectory = cc.getCoreRootDirectory();
+ if (coreRootDirectory != null) {
+String coreRootDirectoryString = coreRootDirectory.toString();
+if (!coreRootDirectoryString.equals(solrHome)) {
Review comment:
I disagree with this condition. I think this should always emitted no
matter where it is. It's more helpful on consumers to depend on its existence
rather than having it vary in some cases but not others.
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/SystemInfoHandler.java
##
@@ -139,8 +140,19 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
if (solrCloudMode) {
rsp.add("zkHost", getCoreContainer(req,
core).getZkController().getZkServerAddress());
}
-if (cc != null)
- rsp.add( "solr_home", cc.getSolrHome());
+if (cc != null) {
+ String solrHome = cc.getSolrHome();
+ rsp.add("solr_home", solrHome);
+
+ Path coreRootDirectory = cc.getCoreRootDirectory();
+ if (coreRootDirectory != null) {
Review comment:
coreRootDirectory is always non-null. I don't like null checks that are
unnecessary; it may feel "safe" but slightly obscures code clarity and suggests
possibilities that are impossibilities.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] Hronom commented on a change in pull request #1864: SOLR-14850 ExactStatsCache NullPointerException when shards.tolerant=true
Hronom commented on a change in pull request #1864:
URL: https://github.com/apache/lucene-solr/pull/1864#discussion_r492247322
##
File path: solr/core/src/java/org/apache/solr/search/stats/ExactStatsCache.java
##
@@ -94,6 +94,12 @@ protected ShardRequest
doRetrieveStatsRequest(ResponseBuilder rb) {
protected void doMergeToGlobalStats(SolrQueryRequest req,
List responses) {
Set allTerms = new HashSet<>();
for (ShardResponse r : responses) {
+ if
("true".equalsIgnoreCase(req.getParams().get(ShardParams.SHARDS_TOLERANT)) &&
r.getException() != null) {
Review comment:
No, `SHARDS_TOLERANT` can have third parameter
https://lucene.apache.org/solr/guide/8_6/solrcloud-query-routing-and-read-tolerance.html#shards-tolerant-parameter
```
In addition to true and false, shards.tolerant may also be set to
requireZkConnected - see below.
```
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14354) HttpShardHandler send requests in async
[
https://issues.apache.org/jira/browse/SOLR-14354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199558#comment-17199558
]
David Smiley commented on SOLR-14354:
-
It's nice to see you participating in other issues, Mark ;-)
Would you recommend reverting from 8x? I'm not sure; it hasn't been shown to
cause test failures that we can attribute here so seems safe from that end. At
least where I work, it's something we'll use in our 8x fork and can serve as a
canary.
> HttpShardHandler send requests in async
> ---
>
> Key: SOLR-14354
> URL: https://issues.apache.org/jira/browse/SOLR-14354
> Project: Solr
> Issue Type: Improvement
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Blocker
> Fix For: master (9.0), 8.7
>
> Attachments: image-2020-03-23-10-04-08-399.png,
> image-2020-03-23-10-09-10-221.png, image-2020-03-23-10-12-00-661.png
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> h2. 1. Current approach (problem) of Solr
> Below is the diagram describe the model on how currently handling a request.
> !image-2020-03-23-10-04-08-399.png!
> The main-thread that handles the search requests, will submit n requests (n
> equals to number of shards) to an executor. So each request will correspond
> to a thread, after sending a request that thread basically do nothing just
> waiting for response from other side. That thread will be swapped out and CPU
> will try to handle another thread (this is called context switch, CPU will
> save the context of the current thread and switch to another one). When some
> data (not all) come back, that thread will be called to parsing these data,
> then it will wait until more data come back. So there will be lots of context
> switching in CPU. That is quite inefficient on using threads.Basically we
> want less threads and most of them must busy all the time, because threads
> are not free as well as context switching. That is the main idea behind
> everything, like executor
> h2. 2. Async call of Jetty HttpClient
> Jetty HttpClient offers async API like this.
> {code:java}
> httpClient.newRequest("http://domain.com/path";)
> // Add request hooks
> .onRequestQueued(request -> { ... })
> .onRequestBegin(request -> { ... })
> // Add response hooks
> .onResponseBegin(response -> { ... })
> .onResponseHeaders(response -> { ... })
> .onResponseContent((response, buffer) -> { ... })
> .send(result -> { ... }); {code}
> Therefore after calling {{send()}} the thread will return immediately without
> any block. Then when the client received the header from other side, it will
> call {{onHeaders()}} listeners. When the client received some {{byte[]}} (not
> all response) from the data it will call {{onContent(buffer)}} listeners.
> When everything finished it will call {{onComplete}} listeners. One main
> thing that will must notice here is all listeners should finish quick, if the
> listener block, all further data of that request won’t be handled until the
> listener finish.
> h2. 3. Solution 1: Sending requests async but spin one thread per response
> Jetty HttpClient already provides several listeners, one of them is
> InputStreamResponseListener. This is how it is get used
> {code:java}
> InputStreamResponseListener listener = new InputStreamResponseListener();
> client.newRequest(...).send(listener);
> // Wait for the response headers to arrive
> Response response = listener.get(5, TimeUnit.SECONDS);
> if (response.getStatus() == 200) {
> // Obtain the input stream on the response content
> try (InputStream input = listener.getInputStream()) {
> // Read the response content
> }
> } {code}
> In this case, there will be 2 thread
> * one thread trying to read the response content from InputStream
> * one thread (this is a short-live task) feeding content to above
> InputStream whenever some byte[] is available. Note that if this thread
> unable to feed data into InputStream, this thread will wait.
> By using this one, the model of HttpShardHandler can be written into
> something like this
> {code:java}
> handler.sendReq(req, (is) -> {
> executor.submit(() ->
> try (is) {
> // Read the content from InputStream
> }
> )
> }) {code}
> The first diagram will be changed into this
> !image-2020-03-23-10-09-10-221.png!
> Notice that although “sending req to shard1” is wide, it won’t take long time
> since sending req is a very quick operation. With this operation, handling
> threads won’t be spin up until first bytes are sent back. Notice that in this
> approach we still have active threads waiting for more data from InputStream
> h2. 4. Solution 2: Buffering data and handle it inside jetty’s thread.
> Jetty have another
[GitHub] [lucene-solr] munendrasn commented on pull request #1900: SOLR-14036: Remove explicit distrib=false from /terms handler
munendrasn commented on pull request #1900: URL: https://github.com/apache/lucene-solr/pull/1900#issuecomment-696271215 @arafalov There is one already which I have modified(DistributedTermsComponentTest) - https://github.com/apache/lucene-solr/pull/1900/files#diff-9b9ccbcf271c6320902d92479615f4fbR73 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] arafalov commented on a change in pull request #1896: SOLR-14880: Support coreRootDirectory setting when create new cores from command line, in standalone mode
arafalov commented on a change in pull request #1896:
URL: https://github.com/apache/lucene-solr/pull/1896#discussion_r492241814
##
File path: solr/core/src/java/org/apache/solr/util/SolrCLI.java
##
@@ -1675,9 +1675,9 @@ protected void runImpl(CommandLine cli) throws Exception {
}
// convert raw JSON into user-friendly output
-solrHome = (String)systemInfo.get("solr_home");
-if (solrHome == null)
- solrHome = configsetsDir.getParentFile().getAbsolutePath();
+coreRootDirectory = (String)systemInfo.get("solr_core_root");
Review comment:
It also had to be introduced, check SOLR-14878
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] arafalov commented on pull request #1900: SOLR-14036: Remove explicit distrib=false from /terms handler
arafalov commented on pull request #1900: URL: https://github.com/apache/lucene-solr/pull/1900#issuecomment-696269537 I can't comment on the code, as I did not understand the shard part. I am happy if the extra parameter (distrib=false) is not needed. I did feel that maybe a test was missing somehow. Is there one that tests that distributed terms work? Especially, since terms handler is explicitly defining the Component Chain to be terms only and nothing else (not even sure if that's relevant, though). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1896: SOLR-14880: Support coreRootDirectory setting when create new cores from command line, in standalone mode
dsmiley commented on a change in pull request #1896:
URL: https://github.com/apache/lucene-solr/pull/1896#discussion_r492238398
##
File path: solr/core/src/java/org/apache/solr/util/SolrCLI.java
##
@@ -1675,9 +1675,9 @@ protected void runImpl(CommandLine cli) throws Exception {
}
// convert raw JSON into user-friendly output
-solrHome = (String)systemInfo.get("solr_home");
-if (solrHome == null)
- solrHome = configsetsDir.getParentFile().getAbsolutePath();
+coreRootDirectory = (String)systemInfo.get("solr_core_root");
Review comment:
Can you help my understand where exactly solr_core_root is populated? I
don't see it in SystemInfoHandler which I presume populates the response for
this.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] munendrasn commented on pull request #1900: SOLR-14036: Remove explicit distrib=false from /terms handler
munendrasn commented on pull request #1900: URL: https://github.com/apache/lucene-solr/pull/1900#issuecomment-696263900 >I think the change of default behavior for users using /terms should be master-only and have a note in solr-upgrade-notes.adoc. If you like, you could backport the underlying fix but not the change in default. At this point, I'm planning to keep this master only but if there is a need will backport the necessary changes to 8x 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] munendrasn commented on pull request #1900: SOLR-14036: Remove explicit distrib=false from /terms handler
munendrasn commented on pull request #1900: URL: https://github.com/apache/lucene-solr/pull/1900#issuecomment-696262897 @joel-bernstein Please review(not able to tags as a reviewer so the ping) 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on pull request #1900: SOLR-14036: Remove explicit distrib=false from /terms handler
dsmiley commented on pull request #1900: URL: https://github.com/apache/lucene-solr/pull/1900#issuecomment-696260676 I'm glad to see this :-) I think the change of default behavior for users using /terms should be master-only and have a note in `solr-upgrade-notes.adoc`. If you like, you could backport the underlying fix but not the change in 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1877: SOLR-13181: param macro expansion could throw
dsmiley commented on a change in pull request #1877:
URL: https://github.com/apache/lucene-solr/pull/1877#discussion_r492226769
##
File path:
solr/core/src/test/org/apache/solr/request/macro/TestMacroExpander.java
##
@@ -143,15 +142,31 @@ public void testMapExprExpandOn() {
String oldVal = System.getProperty("StreamingExpressionMacros","false");
System.setProperty("StreamingExpressionMacros", "true");
try {
- @SuppressWarnings({"rawtypes"})
- Map expanded = MacroExpander.expand(request);
- assertEquals("zero", ((String[])expanded.get("fq"))[0]);
- assertEquals("one", ((String[])expanded.get("fq"))[1]);
- assertEquals("two", ((String[]) expanded.get("fq"))[2]);
- assertEquals("three", ((String[]) expanded.get("fq"))[3]);
- assertEquals("one", ((String[])expanded.get("expr"))[0]);
+ Map expanded = MacroExpander.expand(request);
+ assertEquals("zero", expanded.get("fq")[0]);
+ assertEquals("one", expanded.get("fq")[1]);
+ assertEquals("two", expanded.get("fq")[2]);
+ assertEquals("three", expanded.get("fq")[3]);
+ assertEquals("one", expanded.get("expr")[0]);
} finally {
System.setProperty("StreamingExpressionMacros", oldVal);
}
}
+
+ @Test
+ public void testUnbalanced() { // SOLR-13181
+final MacroExpander meSkipOnMissingParams = new
MacroExpander(Collections.emptyMap());
+final MacroExpander meFailOnMissingParams = new
MacroExpander(Collections.emptyMap(), true);
+assertEquals("${noClose", meSkipOnMissingParams.expand("${noClose"));
Review comment:
I'm not 100% clear what you suggest; let me try to guess. Let's say the
parameter map has exactly one param == goodAnswer with value 42.
assertEquals("42", meSkipOnMissingParams.expand("${goodAnswer}"));
assertEquals("42", meFailOnMissingParams.expand("${goodAnswer}"));
Is that what you suggest?
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc opened a new pull request #1902: SOLR-14840: Overseer doc in asciidoc
murblanc opened a new pull request #1902: URL: https://github.com/apache/lucene-solr/pull/1902 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14840) Convert Overseer Google doc to asciidoc for addition to Git repo
[
https://issues.apache.org/jira/browse/SOLR-14840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199524#comment-17199524
]
Ilan Ginzburg commented on SOLR-14840:
--
Thanks [~ctargett]. Will merge then resolve this Jira. Good luck with better
weather!
> Convert Overseer Google doc to asciidoc for addition to Git repo
>
>
> Key: SOLR-14840
> URL: https://issues.apache.org/jira/browse/SOLR-14840
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Cassandra Targett
>Priority: Minor
>
> Back in April [~ilan] shared via the mailing list a Google doc he had written
> which provided extensive documentation of the Overseer. It's an impressive
> document, and one we should preserve in the repo for other developers to use.
> I recently offered to convert the Google doc to Asciidoc format to add it to
> the {{solr/dev-docs}} directory, so this issue is mostly so I can make a
> branch for Ilan (and others) to review.
> Mailing list thread:
> https://lists.apache.org/thread.html/rf41ae1356bd2e4e68b3c3d835c5e368493ae0ee14a024402c88c795e%40%3Cdev.lucene.apache.org%3E
> Original Google doc:
> https://docs.google.com/document/d/1KTHq3noZBVUQ7QNuBGEhujZ_duwTVpAsvN3Nz5anQUY/edit
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] cpoerschke commented on a change in pull request #1877: SOLR-13181: param macro expansion could throw
cpoerschke commented on a change in pull request #1877:
URL: https://github.com/apache/lucene-solr/pull/1877#discussion_r492216575
##
File path:
solr/core/src/test/org/apache/solr/request/macro/TestMacroExpander.java
##
@@ -143,15 +142,31 @@ public void testMapExprExpandOn() {
String oldVal = System.getProperty("StreamingExpressionMacros","false");
System.setProperty("StreamingExpressionMacros", "true");
try {
- @SuppressWarnings({"rawtypes"})
- Map expanded = MacroExpander.expand(request);
- assertEquals("zero", ((String[])expanded.get("fq"))[0]);
- assertEquals("one", ((String[])expanded.get("fq"))[1]);
- assertEquals("two", ((String[]) expanded.get("fq"))[2]);
- assertEquals("three", ((String[]) expanded.get("fq"))[3]);
- assertEquals("one", ((String[])expanded.get("expr"))[0]);
+ Map expanded = MacroExpander.expand(request);
+ assertEquals("zero", expanded.get("fq")[0]);
+ assertEquals("one", expanded.get("fq")[1]);
+ assertEquals("two", expanded.get("fq")[2]);
+ assertEquals("three", expanded.get("fq")[3]);
+ assertEquals("one", expanded.get("expr")[0]);
} finally {
System.setProperty("StreamingExpressionMacros", oldVal);
}
}
+
+ @Test
+ public void testUnbalanced() { // SOLR-13181
+final MacroExpander meSkipOnMissingParams = new
MacroExpander(Collections.emptyMap());
+final MacroExpander meFailOnMissingParams = new
MacroExpander(Collections.emptyMap(), true);
+assertEquals("${noClose", meSkipOnMissingParams.expand("${noClose"));
Review comment:
How about adding (say) `${goodAnswer} ${noClose` as another case and it
turning into `42 ${noClose` if there is a `goodAnswer=42` mapping i.e. to
demonstrate that absence of closing curly bracket partially affects expansion
(as opposed to no expansion at all happening)?
##
File path: solr/core/src/java/org/apache/solr/request/macro/MacroExpander.java
##
@@ -135,33 +135,34 @@ private String _expand(String val) {
}
}
else if (idx < 0) {
-if (sb == null) return val;
-sb.append(val.substring(start));
-return sb.toString();
+break;
}
// found unescaped "${"
- idx += macroStart.length();
+ final int matchedStart = idx;
- int rbrace = val.indexOf('}', idx);
+ int rbrace = val.indexOf('}', matchedStart + macroStart.length());
if (rbrace == -1) {
// no matching close brace...
-continue;
Review comment:
> ... fix infinite loop when no close ...
Ah, yes, good catch!
And since the logic in the loop is quite complex the "infinite loop" wording
inspired me to go lookup again about the _loop invariants_ and _loop variants_
concepts and work it through here:
* `val.size() - idx` looks like the loops variant and to ensure loop
termination it must decrease i.e. `idx` must advance (or we must break or
return out of the loop)
* `idx > 0` leads to advancing
* `idx < 0` previously returned and now it breaks i.e. either gets us out of
the loop
* `idx == 0` if combined with `rbrace == -1` i.e. no closing would get us
stuck in the loop if `continue` is used but both `return null` or `break` get
us out of the loop
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14036) TermsComponent distributed search (shards) doesn't work with SolrCloud
[
https://issues.apache.org/jira/browse/SOLR-14036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199521#comment-17199521
]
Munendra S N commented on SOLR-14036:
-
I had forgotten about this one. I have raised the PR(due to some reason it is
not linked in jira) - https://github.com/apache/lucene-solr/pull/1900
Removed the bunch of redundant checks from TermsComponent. Based on the
debugging, SOLR-3645 added distrib=false because shard requests also needs to
use /terms handler which wasn't possible in versions before 5x and needed
explicit shards.qt to be set to enabled distributed search. With SOLR-6311,
request path is used as qt for shard request if shards.qt and qt is not
specified which solves this issue
> TermsComponent distributed search (shards) doesn't work with SolrCloud
> --
>
> Key: SOLR-14036
> URL: https://issues.apache.org/jira/browse/SOLR-14036
> Project: Solr
> Issue Type: Improvement
> Components: SearchComponents - other
>Reporter: David Smiley
>Priority: Major
>
> My colleagues [~bruno.roustant] and [~antogruz] attempted to use the
> {{TermsComponent}} in SolrCloud on a collection with multiple shards. The
> results were inconsistent depending on which shard the client was talking
> with. Looking at the prepare() method, I can see this component reads the
> "shards" param. It should not have been coded that way; the SearchHandler or
> related machinery is responsible for parsing/processing that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14036) TermsComponent distributed search (shards) doesn't work with SolrCloud
[
https://issues.apache.org/jira/browse/SOLR-14036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-14036:
Status: Patch Available (was: Reopened)
> TermsComponent distributed search (shards) doesn't work with SolrCloud
> --
>
> Key: SOLR-14036
> URL: https://issues.apache.org/jira/browse/SOLR-14036
> Project: Solr
> Issue Type: Improvement
> Components: SearchComponents - other
>Reporter: David Smiley
>Assignee: Munendra S N
>Priority: Major
>
> My colleagues [~bruno.roustant] and [~antogruz] attempted to use the
> {{TermsComponent}} in SolrCloud on a collection with multiple shards. The
> results were inconsistent depending on which shard the client was talking
> with. Looking at the prepare() method, I can see this component reads the
> "shards" param. It should not have been coded that way; the SearchHandler or
> related machinery is responsible for parsing/processing that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-14036) TermsComponent distributed search (shards) doesn't work with SolrCloud
[
https://issues.apache.org/jira/browse/SOLR-14036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N reassigned SOLR-14036:
---
Assignee: Munendra S N
> TermsComponent distributed search (shards) doesn't work with SolrCloud
> --
>
> Key: SOLR-14036
> URL: https://issues.apache.org/jira/browse/SOLR-14036
> Project: Solr
> Issue Type: Improvement
> Components: SearchComponents - other
>Reporter: David Smiley
>Assignee: Munendra S N
>Priority: Major
>
> My colleagues [~bruno.roustant] and [~antogruz] attempted to use the
> {{TermsComponent}} in SolrCloud on a collection with multiple shards. The
> results were inconsistent depending on which shard the client was talking
> with. Looking at the prepare() method, I can see this component reads the
> "shards" param. It should not have been coded that way; the SearchHandler or
> related machinery is responsible for parsing/processing that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] tflobbe merged pull request #1892: Improve TestConfigSetsAPI
tflobbe merged pull request #1892: URL: https://github.com/apache/lucene-solr/pull/1892 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] TomMD opened a new pull request #1901: SOLR-14883 Add a Muse (Continuous assurance platform) configuration
TomMD opened a new pull request #1901: URL: https://github.com/apache/lucene-solr/pull/1901 # Description The Apache infrastructure team has installed the Muse GitHub application. In order for Lucene-Solr to benefit the application must understand how to build the project. While it has build heuristics, it does not guess between JDK8 or JDK11 (two JDKs most supported by several static analysis tools). Thus, this configuration explicitly instructs use of JDK11. # Solution Add a config.toml with `jdk11 = true`. # Tests I've run Muse with this configuration before. If, for some reason, the configuration is incorrect of has a typo then it at least won't negatively impact the rest of the project. # Checklist - [X] I have created a Jira issue and added the issue ID to my pull request title. - [X] I have developed this patch against the `master` branch. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
