[jira] [Commented] (LUCENE-9610) Fix failures of TestKnnGraph.testMerge
[ https://issues.apache.org/jira/browse/LUCENE-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232255#comment-17232255 ] ASF subversion and git services commented on LUCENE-9610: - Commit 3ae0ca23d937bef2865689748ac9e556b40aff38 in lucene-solr's branch refs/heads/master from Michael Sokolov [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3ae0ca2 ] LUCENE-9610: fix bug in previous test fix > Fix failures of TestKnnGraph.testMerge > -- > > Key: LUCENE-9610 > URL: https://issues.apache.org/jira/browse/LUCENE-9610 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael Sokolov >Priority: Major > > I saw three failures like those below rep[orted to the mailing list last > night. The seeds do not reproduce for me, but there's clearly something up > FAILED: org.apache.lucene.index.TestKnnGraph.testMerge > Error Message: > java.lang.AssertionError: Attempted to walk entire graph but only visited 255 > expected:<257> but was:<255> > > FAILED: org.apache.lucene.index.TestKnnGraph.testMerge > Error Message: > java.lang.AssertionError: Attempted to walk entire graph but only visited 104 > expected:<105> but was:<104> > Stack Trace: > java.lang.AssertionError: Attempted to walk entire graph but only visited 104 > expected:<105> but was:<104> > at > __randomizedtesting.SeedInfo.seed([F1E895FE123F786D:42494B1A1DE4CEF8]:0) > = > FAILED: org.apache.lucene.index.TestKnnGraph.testMerge > Error Message: > java.lang.AssertionError: Attempted to walk entire graph but only visited 104 > expected:<105> but was:<104> > Stack Trace: > java.lang.AssertionError: Attempted to walk entire graph but only visited 104 > expected:<105> but was:<104> > at > __randomizedtesting.SeedInfo.seed([F1E895FE123F786D:42494B1A1DE4CEF8]:0) -- 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-9413) Add a char filter corresponding to CJKWidthFilter
[
https://issues.apache.org/jira/browse/LUCENE-9413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232272#comment-17232272
]
Tomoko Uchida commented on LUCENE-9413:
---
Thanks! I created the PR just yesterday. I believe I've correctly ported the
awesome tricks on CJKWidthFilter into the char filter... hope it is ready to
be merged.
> Add a char filter corresponding to CJKWidthFilter
> -
>
> Key: LUCENE-9413
> URL: https://issues.apache.org/jira/browse/LUCENE-9413
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Tomoko Uchida
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In association with issues in Elasticsearch
> ([https://github.com/elastic/elasticsearch/issues/58384] and
> [https://github.com/elastic/elasticsearch/issues/58385]), it might be useful
> for Japanese default analyzer.
> Although I don't think it's a bug to not normalize FULL and HALF width
> characters before tokenization, the behaviour sometimes confuses beginners or
> users who have limited knowledge about Japanese analysis (and Unicode).
> If we have a FULL and HALF width character normalization filter in
> {{analyzers-common}}, we can include it into JapaneseAnalyzer (currently,
> JapaneseAnalyzer contains CJKWidthFilter but it is applied after tokenization
> so some of FULL width numbers or latin alphabets are separated by the
> tokenizer).
--
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-15000) Solr based enterprise level, one-stop search center products with high performance, high reliability and high scalability
[ https://issues.apache.org/jira/browse/SOLR-15000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232283#comment-17232283 ] bai sui commented on SOLR-15000: TO：David Thank you very much for your timely reply to my issue at the weekend 1）as you said “Community building is hard!”，I very much agree. Since leaving my last company in 2015, I have been focusing on building an enterprise application search platform and developing it on my own. Address is: [https://github.com/qlangtech/tis-solr|https://github.com/qlangtech/tis-solr]. It may be because there is not enough communication with the community, so there are not many users, so that there is no contributor to participate. It seems that there is still a gap with the requirements of the ASF incubation project. So, next I need to strengthen the construction of the community. 2) Thank you very much for telling me so many excellent projects, such as fess, Chorus, awesome-search, it seems that I am really lonely, I need to spend some time to learn about them. 3) Your suggestion is correct, *take all of the great parts of TIS, and maybe contribute to existing projects*. Next, I will consider this matter and feed back some good features in TIS to the community. 4) Regarding the fourth point, I have some ideas of my own. I think the reason for Elasitc's success is that Elasitc uses the user's perspective to visualize time series data as a breakthrough, and uses the ELK tool stack to firmly attract users. I think users are lazy, and users don't care if your product is "rolling a full application stack", don't you think? It may be that what I said is different from what you said. What you said is *project*, but what I said is *product*. tks so much for your replying > Solr based enterprise level, one-stop search center products with high > performance, high reliability and high scalability > - > > Key: SOLR-15000 > URL: https://issues.apache.org/jira/browse/SOLR-15000 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: bai sui >Priority: Minor > Attachments: add-collection-step-2-expert.png, > add-collection-step-2.png > > > h2. Summary > I have developed an enterprise application based on Solr，named TIS . Use TIS > can quickly build enterprise search service for you. TIS includes three > components: > - offline index building platform > The data is exported from ER database( mysql, sqlserver and so on) through > full table scanning, and then the wide table is constructed by local MR tool, > or the wide table is constructed directly by spark > - incremental real-time channel > It is transmitted to Kafka , and real-time stream calculation is carried out > by Flink and submitted to search engine to ensure that the data in search > engine and database are consistent in near real time > - search engine > currently，based on Solr8 > TIS integrate these components seamlessly and bring users one-stop, out of > the box experience. > h2. My question > I want to feed back my code to the community, but TIS focuses on Enterprise > Application Search, just as elasitc search focuses on visual analysis of time > series data. Because Solr is a general search product, *I don't think TIS can > be merged directly into Solr. Is it possible for TIS to be a new incubation > project under Apache?* > h2. TIS main Features > - The schema and solrconfig storage are separated from ZK and stored in > MySQL. The version management function is provided. Users can roll back to > the historical version of the configuration. > !add-collection-step-2-expert.png|width=500! > !add-collection-step-2.png|width=500! >Schema editing mode can be switched between visual editing mode or > advanced expert mode > - Define wide table rules based on the selected data table > - The offline index building component is provided. Outside the collection, > the data is built into Lucene segment file. Then, the segment file is > returned to the local disk where solrcore is located. The new index of reload > solrcore takes effect -- 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 #1972: SOLR-14915: Prometheus-exporter does not depend on Solr-core any longer
dsmiley commented on a change in pull request #1972:
URL: https://github.com/apache/lucene-solr/pull/1972#discussion_r523776751
##
File path: gradle/solr/packaging.gradle
##
@@ -76,7 +76,8 @@ configure(allprojects.findAll {project ->
project.path.startsWith(":solr:contrib
return true
}
}
-return externalLibs - configurations.solrPlatformLibs
+// libExt has logging libs, which we don't want. Lets users decide
what they want.
+return externalLibs - configurations.solrPlatformLibs -
project(':solr:server').configurations.getByName('libExt')
Review comment:
It might be considered hacky to reference a configuration of a specific
sub-project. Maybe libExt could be declared more top-level and be called
"loggingLibs" or something.
##
File path: solr/contrib/prometheus-exporter/bin/solr-exporter
##
@@ -123,8 +111,6 @@ else
GC_TUNE="$GC_TUNE"
fi
-EXTRA_JVM_ARGUMENTS="-Dlog4j.configurationFile=file:"$BASEDIR"/../../server/resources/log4j2-console.xml"
Review comment:
Instead, /conf is put on the classpath, and thus "log4j2.xml" is loaded
automatically based on Log4j2's automatic resolution.
##
File path: solr/contrib/prometheus-exporter/build.gradle
##
@@ -31,17 +30,57 @@ dependencies {
exclude group: "org.jruby.joni", module: "joni"
})
implementation ('net.sourceforge.argparse4j:argparse4j')
+ implementation ('com.github.ben-manes.caffeine:caffeine', {
+exclude group: "org.checkerframework", module: "checker-qual"
+exclude group: "com.google.errorprone", module: "error_prone_annotations"
+ })
- testImplementation ('org.apache.httpcomponents:httpcore')
- testImplementation ('org.eclipse.jetty:jetty-servlet')
+ runtimeOnly 'org.apache.logging.log4j:log4j-api'
Review comment:
Logging dependencies in Java is a pain. In a separate issue/PR, we
should explore this approach:
https://blog.gradle.org/addressing-logging-complexity-capabilities
##
File path:
solr/contrib/prometheus-exporter/src/java/org/apache/solr/prometheus/exporter/SolrExporter.java
##
@@ -68,7 +66,7 @@
private static final String[] ARG_CONFIG_FLAGS = {"-f", "--config-file"};
private static final String ARG_CONFIG_METAVAR = "CONFIG";
private static final String ARG_CONFIG_DEST = "configFile";
- private static final String ARG_CONFIG_DEFAULT = "solr-exporter-config.xml";
+ private static final String ARG_CONFIG_DEFAULT =
"conf/solr-exporter-config.xml";
Review comment:
@HoustonPutman you removed the conf/ and I'm putting it back. I'm not
sure why it worked with it gone. It may be related to other changes in this PR
that it's needed again. I tested that this works here both with `gw run` and
via executing normally from the built assembly. I didn't test Docker yet.
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-15001) Docker: require init_var_solr.sh; don't init in Dockerfile
David Smiley created SOLR-15001: --- Summary: Docker: require init_var_solr.sh; don't init in Dockerfile Key: SOLR-15001 URL: https://issues.apache.org/jira/browse/SOLR-15001 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: Docker Reporter: David Smiley Assignee: David Smiley I propose removing initialization of /var/solr from the Dockerfile, thus leaving only init_var_solr to do this. The fact that it's in two places means that the image has two solr.xml, two zoo.cfg, two log4j2.xml. This initialization itself must be maintained twice. That leads to confusion (it did with my colleagues and I) about which copy is going to be used. Imagine you are basing your company Solr Dockerfile on top of this one (i.e. official is the FROM) and need to do modifications. Do you modify /opt/solr/server/solr/solr.xml? Surprise surprise, sometimes it is copied to /var/solr/data/ by the init_var_solr script but _sometimes_ it isn't because the Dockerfile here will do it, thus ignoring the customizations made to solr.xml in the next image layer. After making this change, our wonderful tests exposed that solr-demo wasn't invoking init_var_solr. THIS ISSUE IS COPIED FROM https://github.com/docker-solr/docker-solr/pull/354 -- 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] zacharymorn commented on a change in pull request #2068: LUCENE-8982: Separate out native code to another module to allow cpp build with gradle
zacharymorn commented on a change in pull request #2068:
URL: https://github.com/apache/lucene-solr/pull/2068#discussion_r523798732
##
File path: gradle/native/disable-native.gradle
##
@@ -17,20 +17,65 @@
// This is the master switch to disable all tasks that compile
// native (cpp) code.
-def buildNative = propertyOrDefault("build.native", true).toBoolean()
+rootProject.ext {
+ buildNative = propertyOrDefault("build.native", true).toBoolean()
+}
+
+// Explicitly list all projects that should be configured for native
extensions.
+// We could scan for projects with a the cpp-library plugin but this is faster.
+def nativeProjects = allprojects.findAll {it.path in [
+":lucene:misc:native"
+]}
+
+def javaProjectsWithNativeDeps = allprojects.findAll {it.path in [
+":lucene:misc"
+]}
+
+// Set up defaults for projects with native dependencies.
+configure(javaProjectsWithNativeDeps, {
+ configurations {
Review comment:
> Unless those native extensions offer super performance boosts I'd
rather treat them as "sandbox", expert-level stuff and not include them in the
distribution by default?
Makes sense. I think as part of
https://issues.apache.org/jira/browse/LUCENE-8982 some performance measurement
utility may come out, so by then this can be more objectively measured to help
further discussions.
I guess this PR is ready for merge then? Please let me know if there's any
other improvement you would like me to make. Thanks again for your help on 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] dweiss commented on a change in pull request #2068: LUCENE-8982: Separate out native code to another module to allow cpp build with gradle
dweiss commented on a change in pull request #2068:
URL: https://github.com/apache/lucene-solr/pull/2068#discussion_r523804321
##
File path: gradle/native/disable-native.gradle
##
@@ -17,20 +17,65 @@
// This is the master switch to disable all tasks that compile
// native (cpp) code.
-def buildNative = propertyOrDefault("build.native", true).toBoolean()
+rootProject.ext {
+ buildNative = propertyOrDefault("build.native", true).toBoolean()
+}
+
+// Explicitly list all projects that should be configured for native
extensions.
+// We could scan for projects with a the cpp-library plugin but this is faster.
+def nativeProjects = allprojects.findAll {it.path in [
+":lucene:misc:native"
+]}
+
+def javaProjectsWithNativeDeps = allprojects.findAll {it.path in [
+":lucene:misc"
+]}
+
+// Set up defaults for projects with native dependencies.
+configure(javaProjectsWithNativeDeps, {
+ configurations {
Review comment:
Yep, I think it's ready! Please monitor jenkins so that we know should
something go wrong - if it does we can just turn native builds off (by default).
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
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 #2020: SOLR-14949: Ability to customize Solr Docker build
dsmiley commented on pull request #2020: URL: https://github.com/apache/lucene-solr/pull/2020#issuecomment-727655114 FWIW I don't think /help/docker.txt is a good place for this because the Docker module has it's very own folder, and so shouldn't it go there? I've been poking around the docker support today in the docker folder and had no clue this help file existed. 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 #1769: SOLR-14789: Absorb the docker-solr repo.
dsmiley commented on pull request #1769: URL: https://github.com/apache/lucene-solr/pull/1769#issuecomment-727679559 I'm looking at the docker image this produces closely, and I see it's more than a bit bloated thanks to this line: https://github.com/apache/lucene-solr/blob/3ae0ca23d937bef2865689748ac9e556b40aff38/solr/docker/Dockerfile#L45 COPY --from=solr_package "/opt/solr-$SOLR_VERSION.tgz" "/opt/solr-$SOLR_VERSION.tgz" Which adds an entire layer of waste that is all of Solr 😱 I'm also a confused why we need an entire gradle module `:solr:docker:package` just for providing input to the Dockerfile. I read the PR opening description which sort of says why it exists... but I think that could be provided all in one module using different tasks for the different steps. I'm also not sure we need to support Dockerfile.release-package does since the image production process is merged with the project; it needn't download a .tgz from anywhere. Right? I don't think direct production of the image prohibits the goals stated above about producing an official image. 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-6399) Implement unloadCollection in the Collections API
[ https://issues.apache.org/jira/browse/SOLR-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232537#comment-17232537 ] David Smiley commented on SOLR-6399: Assuming you are using docValues on appropriate fields (e.g. fields you facet, sort, group, custom relevancy calcs), and that you are using Solr 8+, most of the memory associated with each core is memory-mapped, and will be paged out by the OS if you are not using it. If you have thousands of cores, then this isn't good enough. I think the right solution is "transient cores" to be compatible with SolrCloud -- SOLR-5146 which isn't resolved. > Implement unloadCollection in the Collections API > - > > Key: SOLR-6399 > URL: https://issues.apache.org/jira/browse/SOLR-6399 > Project: Solr > Issue Type: New Feature >Reporter: dfdeshom >Priority: Major > Fix For: 6.0 > > > There is currently no way to unload a collection without deleting its > contents. There should be a way in the collections API to unload a collection > and reload it later, as needed. > A use case for this is the following: you store logs by day, with each day > having its own collection. You are required to store up to 2 years of data, > which adds up to 730 collections. Most of the time, you'll want to have 3 > days of data loaded for search. Having just 3 collections loaded into memory, > instead of 730 will make managing Solr easier. -- 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] zacharymorn commented on a change in pull request #2068: LUCENE-8982: Separate out native code to another module to allow cpp build with gradle
zacharymorn commented on a change in pull request #2068:
URL: https://github.com/apache/lucene-solr/pull/2068#discussion_r523918030
##
File path: gradle/native/disable-native.gradle
##
@@ -17,20 +17,65 @@
// This is the master switch to disable all tasks that compile
// native (cpp) code.
-def buildNative = propertyOrDefault("build.native", true).toBoolean()
+rootProject.ext {
+ buildNative = propertyOrDefault("build.native", true).toBoolean()
+}
+
+// Explicitly list all projects that should be configured for native
extensions.
+// We could scan for projects with a the cpp-library plugin but this is faster.
+def nativeProjects = allprojects.findAll {it.path in [
+":lucene:misc:native"
+]}
+
+def javaProjectsWithNativeDeps = allprojects.findAll {it.path in [
+":lucene:misc"
+]}
+
+// Set up defaults for projects with native dependencies.
+configure(javaProjectsWithNativeDeps, {
+ configurations {
Review comment:
Sure will do. Just to confirm these are all the jobs right
https://ci-builds.apache.org/job/Lucene/, and I guess job
`Lucene-Artifacts-master` requires the most attention / monitoring?
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-14970) elevation does not workout elevate.xml config
[
https://issues.apache.org/jira/browse/SOLR-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232567#comment-17232567
]
Munendra S N commented on SOLR-14970:
-
SOLR-11021 made specifying elevate.xml optional. Based on Git history,
SOLR-11865 did refactoring which introduces initialized variable. When
config-file is not specified, exception is thrown but this
[method|https://github.com/apache/lucene-solr/blob/3ae0ca23d937bef2865689748ac9e556b40aff38/solr/core/src/java/org/apache/solr/handler/component/QueryElevationComponent.java#L284]
ensures exception is not propagated to caller (expected behavior SOLR-11021)
but initialized variable is still false. Throwing exception when config-file is
not specified doesn't seem to be intended change based on SOLR-11865
The prepare method checks for
[initialization|https://github.com/apache/lucene-solr/blob/3ae0ca23d937bef2865689748ac9e556b40aff38/solr/core/src/java/org/apache/solr/handler/component/QueryElevationComponent.java#L458]
I think fix should be simple - to return immediately when config-file instead
of throwing the error(there might 1 or more places where this need to be
handled). Let me know if you are interested in providing the patch, would be
happy to review and commit it
> elevation does not workout elevate.xml config
> -
>
> Key: SOLR-14970
> URL: https://issues.apache.org/jira/browse/SOLR-14970
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.6.3
>Reporter: Bernd Wahlen
>Priority: Minor
>
> When i remove elevate.xml line from solrconfig.xml plus the file, elevation
> is not working and no error is logged.
> We put the ids directly in the query and we are not using the default fields
> or ids, so the xml is completely useless, but required to let the elevation
> component work, example query:
> {code:java}http://staging.qeep.net:8983/solr/profile_v2/elevate?q=%2Bapp_sns%3A%20qeep&sort=random_4239%20desc,%20id%20desc&elevateIds=361018,361343&forceElevation=true{code}
> {code:java}
>
>
> string
> elevate.xml
> elevated
>
>
>
>
> explicit
>
>
> elevator
>
>
> {code}
--
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] [Comment Edited] (SOLR-14970) elevation does not workout elevate.xml config
[
https://issues.apache.org/jira/browse/SOLR-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232567#comment-17232567
]
Munendra S N edited comment on SOLR-14970 at 11/16/20, 7:01 AM:
SOLR-11021 made specifying elevate.xml optional but seems not handled the case
while applying elevation at query time . Based on Git history, SOLR-11865 did
refactoring which introduces initialized variable. When config-file is not
specified, exception is thrown but this
[method|https://github.com/apache/lucene-solr/blob/3ae0ca23d937bef2865689748ac9e556b40aff38/solr/core/src/java/org/apache/solr/handler/component/QueryElevationComponent.java#L284]
ensures exception is not propagated to caller (expected behavior SOLR-11021)
but initialized variable is still false.
The prepare method checks for
[initialization|https://github.com/apache/lucene-solr/blob/3ae0ca23d937bef2865689748ac9e556b40aff38/solr/core/src/java/org/apache/solr/handler/component/QueryElevationComponent.java#L458]
I think fix should be simple - to return immediately when config-file instead
of throwing the error(there might 1 or more places where this need to be
handled). Let me know if you are interested in providing the patch, would be
happy to review and commit it
was (Author: munendrasn):
SOLR-11021 made specifying elevate.xml optional. Based on Git history,
SOLR-11865 did refactoring which introduces initialized variable. When
config-file is not specified, exception is thrown but this
[method|https://github.com/apache/lucene-solr/blob/3ae0ca23d937bef2865689748ac9e556b40aff38/solr/core/src/java/org/apache/solr/handler/component/QueryElevationComponent.java#L284]
ensures exception is not propagated to caller (expected behavior SOLR-11021)
but initialized variable is still false. Throwing exception when config-file is
not specified doesn't seem to be intended change based on SOLR-11865
The prepare method checks for
[initialization|https://github.com/apache/lucene-solr/blob/3ae0ca23d937bef2865689748ac9e556b40aff38/solr/core/src/java/org/apache/solr/handler/component/QueryElevationComponent.java#L458]
I think fix should be simple - to return immediately when config-file instead
of throwing the error(there might 1 or more places where this need to be
handled). Let me know if you are interested in providing the patch, would be
happy to review and commit it
> elevation does not workout elevate.xml config
> -
>
> Key: SOLR-14970
> URL: https://issues.apache.org/jira/browse/SOLR-14970
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.6.3
>Reporter: Bernd Wahlen
>Priority: Minor
>
> When i remove elevate.xml line from solrconfig.xml plus the file, elevation
> is not working and no error is logged.
> We put the ids directly in the query and we are not using the default fields
> or ids, so the xml is completely useless, but required to let the elevation
> component work, example query:
> {code:java}http://staging.qeep.net:8983/solr/profile_v2/elevate?q=%2Bapp_sns%3A%20qeep&sort=random_4239%20desc,%20id%20desc&elevateIds=361018,361343&forceElevation=true{code}
> {code:java}
>
>
> string
> elevate.xml
> elevated
>
>
>
>
> explicit
>
>
> elevator
>
>
> {code}
--
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-10532) The suggest.build and suggest.reload params should be distributed to all replicas
[ https://issues.apache.org/jira/browse/SOLR-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232576#comment-17232576 ] Jacek Kikiewicz commented on SOLR-10532: Wow, this is quite old, this issue is pretty annoying in solr-cloud setup (we run this on K8s and accessing nodes/pods directly is complicated). Could someone have a look at this? > The suggest.build and suggest.reload params should be distributed to all > replicas > - > > Key: SOLR-10532 > URL: https://issues.apache.org/jira/browse/SOLR-10532 > Project: Solr > Issue Type: Improvement > Components: SolrCloud, Suggester >Reporter: Shalin Shekhar Mangar >Priority: Major > > This is inspired by a discussion on solr-user. Today, the suggest.build and > suggest.reload parameters are all local to the replica receiving the request. > This is both confusing and annoying to users because the expectation is that > doing so will build/reload the suggest index on all replicas of a collection > but the reality is that it happens only on one replica of each shard as per > the normal distributed query process. > We should distribute the build and reload param to all replicas of a > collection before actually processing the query. -- 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 a change in pull request #2068: LUCENE-8982: Separate out native code to another module to allow cpp build with gradle
dweiss commented on a change in pull request #2068:
URL: https://github.com/apache/lucene-solr/pull/2068#discussion_r523949604
##
File path: gradle/native/disable-native.gradle
##
@@ -17,20 +17,65 @@
// This is the master switch to disable all tasks that compile
// native (cpp) code.
-def buildNative = propertyOrDefault("build.native", true).toBoolean()
+rootProject.ext {
+ buildNative = propertyOrDefault("build.native", true).toBoolean()
+}
+
+// Explicitly list all projects that should be configured for native
extensions.
+// We could scan for projects with a the cpp-library plugin but this is faster.
+def nativeProjects = allprojects.findAll {it.path in [
+":lucene:misc:native"
+]}
+
+def javaProjectsWithNativeDeps = allprojects.findAll {it.path in [
+":lucene:misc"
+]}
+
+// Set up defaults for projects with native dependencies.
+configure(javaProjectsWithNativeDeps, {
+ configurations {
Review comment:
I think the build mailing list is the easiest to spot problems -
bui...@lucene.apache.org. There will be some builds there from branches (these
can be ignored) but otherwise these are worth taking an occasional look at.
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
