[jira] [Created] (SOLR-15016) Replica placement plugins should use container plugins API / configs
Andrzej Bialecki created SOLR-15016:
---
Summary: Replica placement plugins should use container plugins
API / configs
Key: SOLR-15016
URL: https://issues.apache.org/jira/browse/SOLR-15016
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: Plugin system
Reporter: Andrzej Bialecki
Assignee: Andrzej Bialecki
Replica placement API currently uses its own way of loading plugin
implementations and their config.
Instead it should use a more robust mechanism supported by
{{ContainerPluginsAPI}} and {{ContainerPluginsRegistry}}.
--
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-12302) Reproducing BasicDistributedZkTest failure
[
https://issues.apache.org/jira/browse/SOLR-12302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17238764#comment-17238764
]
Erick Erickson commented on SOLR-12302:
---
A different flavor of failure "too many open files". Tested on a mac (which is
sometimes flaky), also by [~gezapeti] on a linux box with ulimit -n set to
1024000
{code}
ant test -Dtestcase=BasicDistributedZkTest -Dtests.method=test
-Dtests.seed=B3EC105A75D33F30 -Dtests.multiplier=2 -Dtests.nightly=true
-Dtests.slow=true
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
-Dtests.locale=ga -Dtests.timezone=Asia/Harbin -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
{code}
> Reproducing BasicDistributedZkTest failure
> --
>
> Key: SOLR-12302
> URL: https://issues.apache.org/jira/browse/SOLR-12302
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud, Tests
>Reporter: Steven Rowe
>Priority: Major
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/27],
> reproduced 5/5 iterations:
> {noformat}
> Checking out Revision 1409ab8f84ab0949b1da095f03dc94d3b74db5cf
> (refs/remotes/origin/master)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=BasicDistributedZkTest -Dtests.method=test
> -Dtests.seed=AC56303341F3D845 -Dtests.multiplier=3 -Dtests.slow=true
> -Dtests.badapples=true -Dtests.locale=es-CO -Dtests.timezone=America/Cayman
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR 45.6s J0 | BasicDistributedZkTest.test <<<
>[junit4]> Throwable #1:
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://127.0.0.1:37571/_ya/c/collection1: Async exception
> during distributed update: Error from server at
> http://127.0.0.1:34927/_ya/c/collection1_shard1_replica_n43: Bad Request
>[junit4]> request:
> http://127.0.0.1:34927/_ya/c/collection1_shard1_replica_n43/update?update.chain=distrib-dup-test-chain-explicit&update.distrib=TOLEADER&distrib.from=http%3A%2F%2F127.0.0.1%3A37571%2F_ya%2Fc%2Fcollection1_shard2_replica_n41%2F&wt=javabin&version=2
>[junit4]> Remote error message: Exception writing document id 46 to
> the index; possible analysis error.
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([AC56303341F3D845:24020FE9EF0FB5BD]:0)
>[junit4]> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
>[junit4]> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
>[junit4]> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
>[junit4]> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
>[junit4]> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
>[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase.add(BaseDistributedSearchTestCase.java:507)
>[junit4]> at
> org.apache.solr.cloud.BasicDistributedZkTest.testUpdateProcessorsRunOnlyOnce(BasicDistributedZkTest.java:684)
>[junit4]> at
> org.apache.solr.cloud.BasicDistributedZkTest.test(BasicDistributedZkTest.java:378)
>[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
>[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
>[junit4]> at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene70):
> {regex_dup_A_s=Lucene50(blocksize=128),
> regex_dup_B_s=PostingsFormat(name=Asserting),
> SubjectTerms_mfacet=PostingsFormat(name=Asserting),
> multiDefault=Lucene50(blocksize=128), genre_s=Lucene50(blocksize=128),
> author_t=Lucene50(blocksize=128), series_t=Lucene50(blocksize=128),
> rnd_b=PostingsFormat(name=LuceneVarGapFixedInterval),
> oddField_s=Lucene50(blocksize=128), a_t=PostingsFormat(name=Asserting),
> cat=PostingsFormat(name=Asserting), foo_b=Lucene50(blocksize=128),
> name=PostingsFormat(name=LuceneVarGapFixedInterval),
> inStock=Lucene50(blocksize=128),
> id=PostingsFormat(name=LuceneVarGapFixedInterval),
> text=Lucene50(blocksize=128)},
> docValues:{other_tl1=DocValuesFormat(name=Lucene70),
> range_facet_l_dv=DocValuesFormat(name=Memory),
> n_l1=DocValuesFormat(name=Lucene70),
> intDefault=DocValuesFormat(name=Lucene70),
> n_td1=DocValuesFormat(name=Asserting), n_d1=DocValuesFormat(name=Lucene70),
> range_facet_l=DocValuesFormat(name=Lucene70),
> n_f1=DocValuesFo
[jira] [Commented] (SOLR-14996) Facet incorrect counts when FQ exclusion applied with collapsing
[
https://issues.apache.org/jira/browse/SOLR-14996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17238774#comment-17238774
]
Yevhen Tienkaiev commented on SOLR-14996:
-
This becomes critical, since this error also produce different set of facets
depending on what sequence of shards query is executed.
Can someone seriously take a look on this?
> Facet incorrect counts when FQ exclusion applied with collapsing
>
>
> Key: SOLR-14996
> URL: https://issues.apache.org/jira/browse/SOLR-14996
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: faceting
>Affects Versions: 8.6.3
>Reporter: Yevhen Tienkaiev
>Priority: Critical
>
> *numFound* not correct according to what is displayed in facets with
> exclusion when used collapsing and FQ with tag.
> Here example query:
> {code}
> curl --location --request GET
> 'http://localhost:8981/solr/test/select?facet.field={!ex=selected}job_type&facet=on&fq={!collapse%20field=user_id}&fq={!tag=selected}job_type:thinker&q=*:*&rows=0'
> {code}
> result is:
> {code}
> {
> "responseHeader": {
> "zkConnected": true,
> "status": 0,
> "QTime": 15,
> "params": {
> "q": "*:*",
> "facet.field": "{!ex=selected}job_type",
> "fq": [
> "{!collapse field=user_id}",
> "{!tag=selected}job_type:thinker"
> ],
> "rows": "0",
> "facet": "on"
> }
> },
> "response": {
> "numFound": 850,
> "start": 0,
> "maxScore": 1.0,
> "numFoundExact": true,
> "docs": []
> },
> "facet_counts": {
> "facet_queries": {},
> "facet_fields": {
> "job_type": [
> "runner",
> 220,
> "developer",
> 202,
> "digger",
> 202,
> "thinker",
> 195,
> "ninja",
> 181
> ]
> },
> "facet_ranges": {},
> "facet_intervals": {},
> "facet_heatmaps": {}
> }
> }
> {code}
> as you can see there FQ with
> {code}
> {!tag=selected}job_type:thinker
> {code}
> and facets with
> {code}
> {!ex=selected}job_type
> {code}
> in results I see for *thinker* 195, but *numFound* is 850.
> Expected:
> *thinker* 195, *numFound* is 195
> *or*
> *thinker* 850, *numFound* is 850
> You can use this simple project to reproduce the issue
> https://github.com/Hronom/solr-cloud-basic-auth/tree/main/solr-cloud-playground-collapsing
--
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] cammiemw opened a new pull request #2097: LUCENE-9537
cammiemw opened a new pull request #2097: URL: https://github.com/apache/lucene-solr/pull/2097 # Description This pull request implements logic from our academic search engine Indri: http://www.lemurproject.org/indri.php. The functionality that is implemented is a smoothing score for search terms or subqueries that are not present in the document being scored. The smoothing score acts like an idf so that documents that do not have terms or subqueries that are more frequent in the index are not penalized as much as documents that do not have less frequent terms or subqueries. Additionally, Indri's dirichelet smoothing similarity has been added. # Solution The smoothingScore method has been added to the Scorable interface and implemented in the abstract class Scorer. The classes IndriAndQuery, IndriAndWeight, and IndriAndScorer have been added to call the smoothingScore method on documents where the search term or subquery are not present. The class IndriDirichletSimilarity has been added for implementing Indri's equation for the Language Model with Dirichlet smoothing. # Tests TestIndriAndQuery and TestIndriDirichletSmoothing have been added. I am happy to expand upon these tests and implement more tests. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `master` branch. - [x] I have run `./gradlew check`. - [x] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). 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-9537) Add Indri Search Engine Functionality to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-9537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17238786#comment-17238786 ] Cameron VandenBerg commented on LUCENE-9537: Hi [~mikemccand], I have created the pull request for this ticket on github. I did my best to follow all coding and formatting standards. Thank you, Cameron VandenBerg > 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 >Priority: Major > Labels: patch > Attachments: LUCENE-9537.patch, LUCENE-INDRI.patch > > Time Spent: 10m > Remaining Estimate: 0h > > 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] [Created] (SOLR-15017) The core's lib/ folder content is not loaded in the classloader anymore
Thomas Mortagne created SOLR-15017:
--
Summary: The core's lib/ folder content is not loaded in the
classloader anymore
Key: SOLR-15017
URL: https://issues.apache.org/jira/browse/SOLR-15017
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.7
Reporter: Thomas Mortagne
I just upgraded solr-core (I'm using Solr in embedded mode) from 8.5.1 to 8.7.0
and it seems that the lib subfolder inside a core folder is not taken into
account anymore.
Works fine when I move the lib folder one level up (in the Solr home folder)
but when the lib folder with the plugins is located in the core folder it
cannot find any of the class.
I debugged it a little and I think the regression was caused by the refactoring
done in
https://github.com/apache/lucene-solr/commit/732348ec7f9c6b6f7bf9d539a40e50d16198#diff-473fbcdab103c08461ad1b3c3bb1c6d56f1bcd16d6ce341d80855db2cb20a427R749
: the handling of the lib/ core's sub folder was moved to
SolrConfig#initLibs() but unfortunately the check to make sure there is at
least one {{}} element in the configuration file was not removed which
means that if you don't have any of those then the content of the lib/ folder
is totally ignored.
That debugging was easy enough but I don't know Solr internals enough to
propose something clean to fix the issue in a pull request.
The workaround is to make sure there is at least one {{}} element in the core's solrconfig.xml file.
--
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-15017) The core's lib/ folder content is not loaded in the classloader anymore
[
https://issues.apache.org/jira/browse/SOLR-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated SOLR-15017:
---
Description:
I just upgraded solr-core (I'm using Solr in embedded mode) from 8.5.1 to 8.7.0
and it seems that the lib subfolder inside a core folder is not taken into
account anymore.
Works fine when I move the lib folder one level up (in the Solr home folder)
but when the lib folder with the plugins is located in the core folder it
cannot find any of the class.
I debugged it a little and I think the regression was caused by the refactoring
done in
https://github.com/apache/lucene-solr/commit/732348ec7f9c6b6f7bf9d539a40e50d16198#diff-473fbcdab103c08461ad1b3c3bb1c6d56f1bcd16d6ce341d80855db2cb20a427R749
: the handling of the lib/ core's sub folder was moved to
SolrConfig#initLibs() but unfortunately the check to make sure there is at
least one {{}} element in the configuration file was not removed which
means that if you don't have any of those then the content of the lib/ folder
is totally ignored.
That debugging was easy enough but I don't know Solr internals enough to
propose something clean to fix the issue in a pull request.
The workaround is to make sure there is at least one {{}} (for example
) element in the core's solrconfig.xml
file.
was:
I just upgraded solr-core (I'm using Solr in embedded mode) from 8.5.1 to 8.7.0
and it seems that the lib subfolder inside a core folder is not taken into
account anymore.
Works fine when I move the lib folder one level up (in the Solr home folder)
but when the lib folder with the plugins is located in the core folder it
cannot find any of the class.
I debugged it a little and I think the regression was caused by the refactoring
done in
https://github.com/apache/lucene-solr/commit/732348ec7f9c6b6f7bf9d539a40e50d16198#diff-473fbcdab103c08461ad1b3c3bb1c6d56f1bcd16d6ce341d80855db2cb20a427R749
: the handling of the lib/ core's sub folder was moved to
SolrConfig#initLibs() but unfortunately the check to make sure there is at
least one {{}} element in the configuration file was not removed which
means that if you don't have any of those then the content of the lib/ folder
is totally ignored.
That debugging was easy enough but I don't know Solr internals enough to
propose something clean to fix the issue in a pull request.
The workaround is to make sure there is at least one {{}} element in the core's solrconfig.xml file.
> The core's lib/ folder content is not loaded in the classloader anymore
> ---
>
> Key: SOLR-15017
> URL: https://issues.apache.org/jira/browse/SOLR-15017
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.7
>Reporter: Thomas Mortagne
>Priority: Blocker
>
> I just upgraded solr-core (I'm using Solr in embedded mode) from 8.5.1 to
> 8.7.0 and it seems that the lib subfolder inside a core folder is not taken
> into account anymore.
> Works fine when I move the lib folder one level up (in the Solr home folder)
> but when the lib folder with the plugins is located in the core folder it
> cannot find any of the class.
> I debugged it a little and I think the regression was caused by the
> refactoring done in
> https://github.com/apache/lucene-solr/commit/732348ec7f9c6b6f7bf9d539a40e50d16198#diff-473fbcdab103c08461ad1b3c3bb1c6d56f1bcd16d6ce341d80855db2cb20a427R749
> : the handling of the lib/ core's sub folder was moved to
> SolrConfig#initLibs() but unfortunately the check to make sure there is at
> least one {{}} element in the configuration file was not removed which
> means that if you don't have any of those then the content of the lib/ folder
> is totally ignored.
> That debugging was easy enough but I don't know Solr internals enough to
> propose something clean to fix the issue in a pull request.
> The workaround is to make sure there is at least one {{}} (for example
> ) element in the core's
> solrconfig.xml file.
--
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-15017) The core's lib/ folder content is not loaded in the classloader anymore when the core's configuration does not define any element
[
https://issues.apache.org/jira/browse/SOLR-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated SOLR-15017:
---
Summary: The core's lib/ folder content is not loaded in the classloader
anymore when the core's configuration does not define any element (was:
The core's lib/ folder content is not loaded in the classloader anymore)
> The core's lib/ folder content is not loaded in the classloader anymore when
> the core's configuration does not define any element
> ---
>
> Key: SOLR-15017
> URL: https://issues.apache.org/jira/browse/SOLR-15017
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.7
>Reporter: Thomas Mortagne
>Priority: Blocker
>
> I just upgraded solr-core (I'm using Solr in embedded mode) from 8.5.1 to
> 8.7.0 and it seems that the lib subfolder inside a core folder is not taken
> into account anymore.
> Works fine when I move the lib folder one level up (in the Solr home folder)
> but when the lib folder with the plugins is located in the core folder it
> cannot find any of the class.
> I debugged it a little and I think the regression was caused by the
> refactoring done in
> https://github.com/apache/lucene-solr/commit/732348ec7f9c6b6f7bf9d539a40e50d16198#diff-473fbcdab103c08461ad1b3c3bb1c6d56f1bcd16d6ce341d80855db2cb20a427R749
> : the handling of the lib/ core's sub folder was moved to
> SolrConfig#initLibs() but unfortunately the check to make sure there is at
> least one {{}} element in the configuration file was not removed which
> means that if you don't have any of those then the content of the lib/ folder
> is totally ignored.
> That debugging was easy enough but I don't know Solr internals enough to
> propose something clean to fix the issue in a pull request.
> The workaround is to make sure there is at least one {{}} element (for
> example ) in the core's
> solrconfig.xml file.
--
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-15017) The core's lib/ folder content is not loaded in the classloader anymore
[
https://issues.apache.org/jira/browse/SOLR-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated SOLR-15017:
---
Description:
I just upgraded solr-core (I'm using Solr in embedded mode) from 8.5.1 to 8.7.0
and it seems that the lib subfolder inside a core folder is not taken into
account anymore.
Works fine when I move the lib folder one level up (in the Solr home folder)
but when the lib folder with the plugins is located in the core folder it
cannot find any of the class.
I debugged it a little and I think the regression was caused by the refactoring
done in
https://github.com/apache/lucene-solr/commit/732348ec7f9c6b6f7bf9d539a40e50d16198#diff-473fbcdab103c08461ad1b3c3bb1c6d56f1bcd16d6ce341d80855db2cb20a427R749
: the handling of the lib/ core's sub folder was moved to
SolrConfig#initLibs() but unfortunately the check to make sure there is at
least one {{}} element in the configuration file was not removed which
means that if you don't have any of those then the content of the lib/ folder
is totally ignored.
That debugging was easy enough but I don't know Solr internals enough to
propose something clean to fix the issue in a pull request.
The workaround is to make sure there is at least one {{}} element (for
example ) in the core's solrconfig.xml
file.
was:
I just upgraded solr-core (I'm using Solr in embedded mode) from 8.5.1 to 8.7.0
and it seems that the lib subfolder inside a core folder is not taken into
account anymore.
Works fine when I move the lib folder one level up (in the Solr home folder)
but when the lib folder with the plugins is located in the core folder it
cannot find any of the class.
I debugged it a little and I think the regression was caused by the refactoring
done in
https://github.com/apache/lucene-solr/commit/732348ec7f9c6b6f7bf9d539a40e50d16198#diff-473fbcdab103c08461ad1b3c3bb1c6d56f1bcd16d6ce341d80855db2cb20a427R749
: the handling of the lib/ core's sub folder was moved to
SolrConfig#initLibs() but unfortunately the check to make sure there is at
least one {{}} element in the configuration file was not removed which
means that if you don't have any of those then the content of the lib/ folder
is totally ignored.
That debugging was easy enough but I don't know Solr internals enough to
propose something clean to fix the issue in a pull request.
The workaround is to make sure there is at least one {{}} (for example
) element in the core's solrconfig.xml
file.
> The core's lib/ folder content is not loaded in the classloader anymore
> ---
>
> Key: SOLR-15017
> URL: https://issues.apache.org/jira/browse/SOLR-15017
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.7
>Reporter: Thomas Mortagne
>Priority: Blocker
>
> I just upgraded solr-core (I'm using Solr in embedded mode) from 8.5.1 to
> 8.7.0 and it seems that the lib subfolder inside a core folder is not taken
> into account anymore.
> Works fine when I move the lib folder one level up (in the Solr home folder)
> but when the lib folder with the plugins is located in the core folder it
> cannot find any of the class.
> I debugged it a little and I think the regression was caused by the
> refactoring done in
> https://github.com/apache/lucene-solr/commit/732348ec7f9c6b6f7bf9d539a40e50d16198#diff-473fbcdab103c08461ad1b3c3bb1c6d56f1bcd16d6ce341d80855db2cb20a427R749
> : the handling of the lib/ core's sub folder was moved to
> SolrConfig#initLibs() but unfortunately the check to make sure there is at
> least one {{}} element in the configuration file was not removed which
> means that if you don't have any of those then the content of the lib/ folder
> is totally ignored.
> That debugging was easy enough but I don't know Solr internals enough to
> propose something clean to fix the issue in a pull request.
> The workaround is to make sure there is at least one {{}} element (for
> example ) in the core's
> solrconfig.xml file.
--
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-15017) The core's lib/ folder content is not loaded in the classloader anymore when the core's configuration does not define any element
[
https://issues.apache.org/jira/browse/SOLR-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated SOLR-15017:
---
Labels: regression (was: )
> The core's lib/ folder content is not loaded in the classloader anymore when
> the core's configuration does not define any element
> ---
>
> Key: SOLR-15017
> URL: https://issues.apache.org/jira/browse/SOLR-15017
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.7
>Reporter: Thomas Mortagne
>Priority: Blocker
> Labels: regression
>
> I just upgraded solr-core (I'm using Solr in embedded mode) from 8.5.1 to
> 8.7.0 and it seems that the lib subfolder inside a core folder is not taken
> into account anymore.
> Works fine when I move the lib/ folder one level up (in the Solr home folder)
> but when the lib folder with the plugins is located in the core folder it
> cannot find any of the classes.
> I debugged it a little and I think the regression was caused by the
> refactoring done in
> https://github.com/apache/lucene-solr/commit/732348ec7f9c6b6f7bf9d539a40e50d16198#diff-473fbcdab103c08461ad1b3c3bb1c6d56f1bcd16d6ce341d80855db2cb20a427R749
> : the handling of the lib/ core's sub folder was moved to
> SolrConfig#initLibs() but unfortunately the check to make sure there is at
> least one {{}} element in the configuration file was not removed which
> means that if you don't have any of those then the content of the lib/ folder
> is totally ignored.
> That debugging was easy enough but I don't know Solr internals enough to
> propose something clean to fix the issue in a pull request.
> The workaround is to make sure there is at least one {{}} element (for
> example ) in the core's
> solrconfig.xml file.
--
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-15017) The core's lib/ folder content is not loaded in the classloader anymore when the core's configuration does not define any element
[
https://issues.apache.org/jira/browse/SOLR-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated SOLR-15017:
---
Description:
I just upgraded solr-core (I'm using Solr in embedded mode) from 8.5.1 to 8.7.0
and it seems that the lib subfolder inside a core folder is not taken into
account anymore.
Works fine when I move the lib/ folder one level up (in the Solr home folder)
but when the lib folder with the plugins is located in the core folder it
cannot find any of the classes.
I debugged it a little and I think the regression was caused by the refactoring
done in
https://github.com/apache/lucene-solr/commit/732348ec7f9c6b6f7bf9d539a40e50d16198#diff-473fbcdab103c08461ad1b3c3bb1c6d56f1bcd16d6ce341d80855db2cb20a427R749
: the handling of the lib/ core's sub folder was moved to
SolrConfig#initLibs() but unfortunately the check to make sure there is at
least one {{}} element in the configuration file was not removed which
means that if you don't have any of those then the content of the lib/ folder
is totally ignored.
That debugging was easy enough but I don't know Solr internals enough to
propose something clean to fix the issue in a pull request.
The workaround is to make sure there is at least one {{}} element (for
example ) in the core's solrconfig.xml
file.
was:
I just upgraded solr-core (I'm using Solr in embedded mode) from 8.5.1 to 8.7.0
and it seems that the lib subfolder inside a core folder is not taken into
account anymore.
Works fine when I move the lib folder one level up (in the Solr home folder)
but when the lib folder with the plugins is located in the core folder it
cannot find any of the class.
I debugged it a little and I think the regression was caused by the refactoring
done in
https://github.com/apache/lucene-solr/commit/732348ec7f9c6b6f7bf9d539a40e50d16198#diff-473fbcdab103c08461ad1b3c3bb1c6d56f1bcd16d6ce341d80855db2cb20a427R749
: the handling of the lib/ core's sub folder was moved to
SolrConfig#initLibs() but unfortunately the check to make sure there is at
least one {{}} element in the configuration file was not removed which
means that if you don't have any of those then the content of the lib/ folder
is totally ignored.
That debugging was easy enough but I don't know Solr internals enough to
propose something clean to fix the issue in a pull request.
The workaround is to make sure there is at least one {{}} element (for
example ) in the core's solrconfig.xml
file.
> The core's lib/ folder content is not loaded in the classloader anymore when
> the core's configuration does not define any element
> ---
>
> Key: SOLR-15017
> URL: https://issues.apache.org/jira/browse/SOLR-15017
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.7
>Reporter: Thomas Mortagne
>Priority: Blocker
>
> I just upgraded solr-core (I'm using Solr in embedded mode) from 8.5.1 to
> 8.7.0 and it seems that the lib subfolder inside a core folder is not taken
> into account anymore.
> Works fine when I move the lib/ folder one level up (in the Solr home folder)
> but when the lib folder with the plugins is located in the core folder it
> cannot find any of the classes.
> I debugged it a little and I think the regression was caused by the
> refactoring done in
> https://github.com/apache/lucene-solr/commit/732348ec7f9c6b6f7bf9d539a40e50d16198#diff-473fbcdab103c08461ad1b3c3bb1c6d56f1bcd16d6ce341d80855db2cb20a427R749
> : the handling of the lib/ core's sub folder was moved to
> SolrConfig#initLibs() but unfortunately the check to make sure there is at
> least one {{}} element in the configuration file was not removed which
> means that if you don't have any of those then the content of the lib/ folder
> is totally ignored.
> That debugging was easy enough but I don't know Solr internals enough to
> propose something clean to fix the issue in a pull request.
> The workaround is to make sure there is at least one {{}} element (for
> example ) in the core's
> solrconfig.xml file.
--
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] iverase commented on pull request #2094: LUCENE-9047: Move the Directory APIs to be little endian
iverase commented on pull request #2094: URL: https://github.com/apache/lucene-solr/pull/2094#issuecomment-733826001 I had another iteration and add better backwards compatibility support to: * FST: I had to change slightly one test which I am not sure what is testing. All other test pass. * BlockTreeTermsReader * CompressingStoredFieldsReader * CompressingTermVectorsReader * FileIndexReader: This looks a bit strange as I store the version in one file (data file) but affects how we read the meta file. 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-15018) Atomic update deletes child documents if schema has catch-all ignore field
Andreas Hubold created SOLR-15018:
-
Summary: Atomic update deletes child documents if schema has
catch-all ignore field
Key: SOLR-15018
URL: https://issues.apache.org/jira/browse/SOLR-15018
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: update
Affects Versions: 8.6.3
Reporter: Andreas Hubold
Nested child documents disappear when some unrelated fields of a parent
document are atomically updated, if the schema contains a catch-all dynamic
field to ignore unknown fields like:
{noformat}
{noformat}
{{DistributedUpdateProcessor#getUpdatedDocument}} tries to reconstruct the
original document, but it does not receive nested documents from
{{RealTimeComponent#getInputDocument}}. Nested documents are correctly found in
the index but get lost when {{RealTimeGetComponent#toSolrInputDocument}}
creates a SolrInputDocument for it. The problematic code is:
{code:java}
SchemaField sf = schema.getFieldOrNull(fname);
if (sf != null) {
if ((!sf.hasDocValues() && !sf.stored()) || schema.isCopyFieldTarget(sf))
continue;
} {code}
The code finds the "ignored" SchemaField as matching field for the nested
document name (loaded from _nest_path_). Because of that they're not added to
the SolrInputDocument.
--
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-15018) Atomic update deletes child documents if schema has catch-all ignore field
[
https://issues.apache.org/jira/browse/SOLR-15018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17238818#comment-17238818
]
Andreas Hubold commented on SOLR-15018:
---
Also mentioned on the solr-user mailing list:
[https://mail-archives.apache.org/mod_mbox/lucene-solr-user/202011.mbox/%3Cad098efe-c895-bf5d-078d-f214731f841d%40coremedia.com%3E]
A possible workaround is to remove the catch-all "ignored" field, and replace
it with a custom UpdateRequestProcessor that removes unknown fields (except
those that are used for nested documents).
I'm not sure, but another possible workaround might be to add an unused schema
field (stored="true") with the name of the nested document. I didn't test that
because it would be quite confusing, as also said in the reference guide
[https://lucene.apache.org/solr/guide/8_6/indexing-nested-documents.html#schema-configuration]
{quote}Even though child documents are provided as field values syntactically
and with SolrJ, it’s a matter of syntax and it isn’t an actual field in the
schema. Consequently, the field need not be defined in the schema and probably
shouldn’t be as it would be confusing. There is no child document field type,
at least not yet.
{quote}
> Atomic update deletes child documents if schema has catch-all ignore field
> --
>
> Key: SOLR-15018
> URL: https://issues.apache.org/jira/browse/SOLR-15018
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update
>Affects Versions: 8.6.3
>Reporter: Andreas Hubold
>Priority: Major
> Labels: AtomicUpdate, ChildDocuments, NestedDocuments
>
> Nested child documents disappear when some unrelated fields of a parent
> document are atomically updated, if the schema contains a catch-all dynamic
> field to ignore unknown fields like:
> {noformat}
>
> class="solr.StrField" /> {noformat}
> {{DistributedUpdateProcessor#getUpdatedDocument}} tries to reconstruct the
> original document, but it does not receive nested documents from
> {{RealTimeComponent#getInputDocument}}. Nested documents are correctly found
> in the index but get lost when {{RealTimeGetComponent#toSolrInputDocument}}
> creates a SolrInputDocument for it. The problematic code is:
> {code:java}
> SchemaField sf = schema.getFieldOrNull(fname);
> if (sf != null) {
> if ((!sf.hasDocValues() && !sf.stored()) || schema.isCopyFieldTarget(sf))
> continue;
> } {code}
> The code finds the "ignored" SchemaField as matching field for the nested
> document name (loaded from _nest_path_). Because of that they're not added to
> the SolrInputDocument.
--
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-15013) Reproducing test failure TestFieldCacheSort 8x
[
https://issues.apache.org/jira/browse/SOLR-15013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17238964#comment-17238964
]
Erick Erickson commented on SOLR-15013:
---
[~mikemccand], [~dsmiley] [~simonwillnauer] (pinging you three since you all
seemed to be involved in the JIRA). According to git bisect, this was
introduced in LUCENE-8962, obviously it's intermittent...
IDK whether this is a problem with the Solr test making invalid assumptions or
exercising the code differently than Lucene tests or what...
The bisect output:
2f2146aad46b5969e6fbc99d85e21f595aba56c9 is the first bad commit
commit 2f2146aad46b5969e6fbc99d85e21f595aba56c9
Author: Simon Willnauer
Date: Mon Aug 24 20:19:08 2020 +0200
LUCENE-8962: Merge segments on getReader (#1623)
Add IndexWriter merge-on-refresh feature to selectively merge
small segments on getReader, subject to a configurable timeout,
to improve search performance by reducing the number of small
segments for searching.
Co-authored-by: Mike McCandless
:04 04 578b66c5e1314e00e54af200b05a1c800e81b677
25e42bfacb0f273470828cec5302d28d1d3c6415 M lucene
:04 04 719e8d598b6ea9f6075e1aa9c3382016dbbafc2f
2522a431d009881dbdfe06a5a3753302c4eb0a24 M solr
> Reproducing test failure TestFieldCacheSort 8x
> --
>
> Key: SOLR-15013
> URL: https://issues.apache.org/jira/browse/SOLR-15013
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erick Erickson
>Priority: Major
>
> ant test -Dtestcase=TestFieldCacheSort
> -Dtests.method=testEmptyStringVsNullStringSort -Dtests.seed=2E14D932C133811F
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=hr-BA
> -Dtests.timezone=America/Scoresbysund -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1
>
>
> [junit4] Started J0 PID(96093@localhost).
> [junit4] Suite: org.apache.solr.uninverting.TestFieldCacheSort
> [junit4] 2> 1334 INFO
> (SUITE-TestFieldCacheSort-seed#[2E14D932C133811F]-worker) [ ]
> o.a.s.SolrTestCase Setting 'solr.default.confdir' system property to
> test-framework derived value of
> '/Users/Erick/apache/solr/solrtest8/solr/server/solr/configsets/_default/conf'
> [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestFieldCacheSort
> -Dtests.method=testEmptyStringVsNullStringSort -Dtests.seed=2E14D932C133811F
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=hr-BA -Dtests.timezone=America/Scoresbysund
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
> [junit4] FAILURE 0.40s | TestFieldCacheSort.testEmptyStringVsNullStringSort
> <<<
> [junit4] > Throwable #1: java.lang.AssertionError: expected:<1> but was:<0>
> [junit4] > at
> __randomizedtesting.SeedInfo.seed([2E14D932C133811F:4FF7EBE5B95287AF]:0)
> [junit4] > at
> org.apache.solr.uninverting.TestFieldCacheSort.testEmptyStringVsNullStringSort(TestFieldCacheSort.java:1610)
> [junit4] > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit4] > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit4] > at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit4] > at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> [junit4] > at java.base/java.lang.Thread.run(Thread.java:834)
> [junit4] 2> NOTE: test params are: codec=CheapBastard,
> sim=Asserting(RandomSimilarity(queryNorm=false): \{t=DFR I(F)BZ(0.3)}),
> locale=hr-BA, timezone=America/Scoresbysund
> [junit4] 2> NOTE: Mac OS X 10.16 x86_64/AdoptOpenJDK 11.0.5
> (64-bit)/cpus=12,threads=1,free=468375472,total=536870912
--
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-14958) zkHost sys prop requirement prevents sane/safe cloud test usage
[
https://issues.apache.org/jira/browse/SOLR-14958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-14958:
--
Attachment: SOLR-14958.patch
Assignee: Chris M. Hostetter
Status: Open (was: Open)
Attaching patch with suggested changes...
This isn't quite as clean as i was hoping, just because of how many different
places in this call stack tests expect to be able to call directly and have a
zkHost sys prop picked up -- i didn't want to try to "fix" all of those tests
here and now, but it helped to ensure all the basis were covered in the new
code.
what's important is that in the new code, there is never any chance that zkHost
sys prop will be read by mistake in place of an explicitly configured zkHost
node property -- so MiiSolrCloudCluster (and future work in SOLR-14903) can
work sanely w/o depending on action at a distance from a system property
> zkHost sys prop requirement prevents sane/safe cloud test usage
> ---
>
> Key: SOLR-14958
> URL: https://issues.apache.org/jira/browse/SOLR-14958
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-14958.patch
>
>
> (This is somewhat analogous to SOLR-14934, but AFAICT only affects tests)
> MiniSolrCloudCluster - and/or any test that wants to run "cloud" nodes that
> pull solr.xml from ZooKeeper - currently *only* works because it calls
> {{System.setProperty("zkHost",...)}} - there is no other mechanism to
> communicate a 'zkHost' connection information to a Solr node (w/o hardcoding
> the value in a {{solr.xml}} file already on disk), making it unsafe to have
> multiple "solr clusters" running in a single JVM.
> SolrDispatchFilter already supports the ability to read properties from
> "context" attributes (which is currently leveraged by our test
> infrastructure) which are used to specify the "node properties" for the core
> container, and allow per-node overrides of system properties with the same
> name when parsing variables in solr.xml. But! ... SolrDispatchFilter does
> not consult these node properties when deciding where to try and load
> solr.xml from.
> Even if we "fix" SolrDispatchFilter to look for 'zkHost' in the node
> properties, SolrXmlConfig supports a {{}} option in the
> {{}} section. if that option is missing, then
> {{System.getProperty("zkHost")}} is used as a default - *IGNORING ANY zkHost
> IN THE NODE PROPERTIES*.
> I think we should try to fix this discrepency, and make it possible to run a
> {{MiniSolrCloud}} cluster w/o relying on setting 'zkHost' sys prop.
--
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 #2094: LUCENE-9047: Move the Directory APIs to be little endian
dweiss commented on pull request #2094: URL: https://github.com/apache/lucene-solr/pull/2094#issuecomment-734138279 The fst test verifies byte order of internal data serializer (reverse vs. normal byte order). Every time I look at this diff I have a gut feeling that it should be possible to do this switch in a more transparent way... Even with all the temporary buffers we write to, etc. IndexInput and IndexOutput extend from DataInput/DataOutput. What if those classes were forced to carry the byte order with them (much like byte buffers do)? Initially this would mean all of DataInput/DataOutput we create would have an explicit big endian. We could then gradually switch these to LE for new codecs (in theory all the paired read/write of more complex types should still work) and eventually prohibit BE in DataInput/DataOutput constructor once all the backward codecs are gone... I am tempted to try out this approach this weekend, just out of curiosity. What do you think, @iverase ? 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
