[jira] [Updated] (SOLR-13661) A package management system for Solr
[ https://issues.apache.org/jira/browse/SOLR-13661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-13661: -- Description: Solr needs a unified cohesive package management system so that users can deploy/redeploy plugins in a safe manner. This is an umbrella issue to eventually build that solution > A package management system for Solr > > > Key: SOLR-13661 > URL: https://issues.apache.org/jira/browse/SOLR-13661 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > > Solr needs a unified cohesive package management system so that users can > deploy/redeploy plugins in a safe manner. This is an umbrella issue to > eventually build that solution -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11266) V2 API returning wrong content-type
[
https://issues.apache.org/jira/browse/SOLR-11266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-11266:
Resolution: Done
Assignee: Munendra S N
Fix Version/s: master (9.0)
Status: Resolved (was: Patch Available)
> V2 API returning wrong content-type
> ---
>
> Key: SOLR-11266
> URL: https://issues.apache.org/jira/browse/SOLR-11266
> Project: Solr
> Issue Type: Improvement
> Components: v2 API
>Reporter: Ishan Chattopadhyaya
>Assignee: Munendra S N
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-11266.patch, SOLR-11266.patch
>
>
> The content-type of the returned value is wrong in many places. It should
> return "application/json", but instead returns "application/text-plan".
> Here's an example:
> {code}
> [ishan@t430 ~] $ curl -v
> "http://localhost:8983/api/collections/products/select?q=*:*=0;
> * Trying 127.0.0.1...
> * TCP_NODELAY set
> * Connected to localhost (127.0.0.1) port 8983 (#0)
> > GET /api/collections/products/select?q=*:*=0 HTTP/1.1
> > Host: localhost:8983
> > User-Agent: curl/7.51.0
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Content-Type: text/plain;charset=utf-8
> < Content-Length: 184
> <
> {
> "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":1,
> "params":{
> "q":"*:*",
> "rows":"0"}},
> "response":{"numFound":260,"start":0,"docs":[]
> }}
> * Curl_http_done: called premature == 0
> * Connection #0 to host localhost left intact
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11266) V2 API returning wrong content-type
[
https://issues.apache.org/jira/browse/SOLR-11266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895770#comment-16895770
]
ASF subversion and git services commented on SOLR-11266:
Commit cb94eeb4919ff6484f186f534377d9ad9b24c33c in lucene-solr's branch
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cb94eeb ]
SOLR-11266: remove content-type override from _default configSet
> V2 API returning wrong content-type
> ---
>
> Key: SOLR-11266
> URL: https://issues.apache.org/jira/browse/SOLR-11266
> Project: Solr
> Issue Type: Improvement
> Components: v2 API
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-11266.patch, SOLR-11266.patch
>
>
> The content-type of the returned value is wrong in many places. It should
> return "application/json", but instead returns "application/text-plan".
> Here's an example:
> {code}
> [ishan@t430 ~] $ curl -v
> "http://localhost:8983/api/collections/products/select?q=*:*=0;
> * Trying 127.0.0.1...
> * TCP_NODELAY set
> * Connected to localhost (127.0.0.1) port 8983 (#0)
> > GET /api/collections/products/select?q=*:*=0 HTTP/1.1
> > Host: localhost:8983
> > User-Agent: curl/7.51.0
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Content-Type: text/plain;charset=utf-8
> < Content-Length: 184
> <
> {
> "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":1,
> "params":{
> "q":"*:*",
> "rows":"0"}},
> "response":{"numFound":260,"start":0,"docs":[]
> }}
> * Curl_http_done: called premature == 0
> * Connection #0 to host localhost left intact
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-Linux (32bit/jdk1.8.0_201) - Build # 942 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/942/ Java: 32bit/jdk1.8.0_201 -server -XX:+UseSerialGC 6 tests failed. FAILED: org.apache.solr.schema.TestUseDocValuesAsStored.testDuplicateMultiValued Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([73440C50A1B3C8FE:9D9918706F023E42]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:947) at org.apache.solr.schema.TestUseDocValuesAsStored.doTest(TestUseDocValuesAsStored.java:367) at org.apache.solr.schema.TestUseDocValuesAsStored.testDuplicateMultiValued(TestUseDocValuesAsStored.java:167) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=*[count(//arr[@name='test_is_dvo']/int)=3] xml response was:
[jira] [Commented] (SOLR-13659) Cache implementations should be loadable/reloadable from runtime libraries
[ https://issues.apache.org/jira/browse/SOLR-13659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895739#comment-16895739 ] ASF subversion and git services commented on SOLR-13659: Commit 1c2392ddbb98e961921272ba0c779bf0644840e1 in lucene-solr's branch refs/heads/jira/SOLR-13659 from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1c2392d ] SOLR-13659: initial commit > Cache implementations should be loadable/reloadable from runtime libraries > -- > > Key: SOLR-13659 > URL: https://issues.apache.org/jira/browse/SOLR-13659 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > Cache implementation class is currently loaded from the SolrConfig > classloader -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 429 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/429/
All tests passed
Build Log:
[...truncated 64128 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj2133920299
[ecj-lint] Compiling 1283 source files to /tmp/ecj2133920299
[ecj-lint] Processing annotations
[ecj-lint] Annotations processed
[ecj-lint] Processing annotations
[ecj-lint] No elements to process
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
[ecj-lint] --
[ecj-lint] 1. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
(at line 219)
[ecj-lint] return (NamedList) new
JavaBinCodec(resolver).unmarshal(in);
[ecj-lint]^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 2. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 788)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] 3. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 794)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 19)
[ecj-lint] import javax.naming.Context;
[ecj-lint]
[ecj-lint] The type javax.naming.Context is not accessible
[ecj-lint] --
[ecj-lint] 5. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 20)
[ecj-lint] import javax.naming.InitialContext;
[ecj-lint]^^^
[ecj-lint] The type javax.naming.InitialContext is not accessible
[ecj-lint] --
[ecj-lint] 6. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 21)
[ecj-lint] import javax.naming.NamingException;
[ecj-lint]
[ecj-lint] The type javax.naming.NamingException is not accessible
[ecj-lint] --
[ecj-lint] 7. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 22)
[ecj-lint] import javax.naming.NoInitialContextException;
[ecj-lint]^^
[ecj-lint] The type javax.naming.NoInitialContextException is not accessible
[ecj-lint] --
[ecj-lint] 8. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 776)
[ecj-lint] Context c = new InitialContext();
[ecj-lint] ^^^
[ecj-lint] Context cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 9. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 776)
[ecj-lint] Context c = new InitialContext();
[ecj-lint] ^^
[ecj-lint] InitialContext cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 10. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 779)
[ecj-lint] } catch (NoInitialContextException e) {
[ecj-lint] ^
[ecj-lint] NoInitialContextException cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 11. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 781)
[ecj-lint] } catch (NamingException e) {
[ecj-lint] ^^^
[ecj-lint] NamingException cannot be
[jira] [Commented] (SOLR-12555) Replace try-fail-catch test patterns
[
https://issues.apache.org/jira/browse/SOLR-12555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895713#comment-16895713
]
Lucene/Solr QA commented on SOLR-12555:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 89 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
38s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 5m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 22s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 22s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m
27s{color} | {color:green} dataimporthandler in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 15s{color}
| {color:red} extraction in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m
6s{color} | {color:green} ltr in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
52s{color} | {color:green} velocity in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 51m
22s{color} | {color:green} core in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 7m
10s{color} | {color:green} solrj in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
22s{color} | {color:green} test-framework in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 79m 34s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12555 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12976134/SOLR-12555.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 70a8deb |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
| unit |
https://builds.apache.org/job/PreCommit-SOLR-Build/515/artifact/out/patch-unit-solr_contrib_extraction.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/515/testReport/ |
| modules | C: solr/contrib/dataimporthandler solr/contrib/extraction
solr/contrib/ltr solr/contrib/velocity solr/core solr/solrj solr/test-framework
U: solr |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/515/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Replace try-fail-catch test patterns
>
>
> Key: SOLR-12555
> URL: https://issues.apache.org/jira/browse/SOLR-12555
> Project: Solr
> Issue Type: Test
> Components: Tests
>Affects Versions: 8.0
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-12555-sorted-by-package.txt, SOLR-12555.patch,
> SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.patch,
> SOLR-12555.txt
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> I recently added some test code through SOLR-12427 which used the following
> test anti-pattern:
> {code}
> try {
> actionExpectedToThrowException();
> fail("I expected this to throw an exception, but it didn't");
> catch (Exception e) {
> assertOnThrownException(e);
> }
> {code}
> Hoss (rightfully) objected that this should instead be written using the
> formulation below, which is clearer and more concise.
> {code}
> SolrException
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-12.0.1) - Build # 24469 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24469/ Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.schema.TestUseDocValuesAsStored.testDuplicateMultiValued Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([76BC5A6650E2A727:98614E469E53519B]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:947) at org.apache.solr.schema.TestUseDocValuesAsStored.doTest(TestUseDocValuesAsStored.java:367) at org.apache.solr.schema.TestUseDocValuesAsStored.testDuplicateMultiValued(TestUseDocValuesAsStored.java:165) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:835) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//arr[@name='test_ss_dv']/str[.='X'] xml response was:
[jira] [Created] (SOLR-13662) Script support for managing packages
Noble Paul created SOLR-13662:
-
Summary: Script support for managing packages
Key: SOLR-13662
URL: https://issues.apache.org/jira/browse/SOLR-13662
Project: Solr
Issue Type: Sub-task
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul
example scripts
{code}
#add a repo to your Solr cluster. This adds the public key of the repo to our
Solr ZK
# also store the file in /package-repo in ZK
bin/solr plugin add-repo
# searches all the registered repos for the pakage 'solr-highlighting" and
version :0.1 and add
# the package to solr cluster. After it's done thes component will be added to
collections, coll1,coll2,coll3
bin/solr plugin install solr-highlighting:0.1 -c coll1,coll2,coll3
# deploy an already installed package to an existing set of collections
bin/solr plugin deploy solr-highlighting -c coll1,coll2
# update an existing package solr-highlighting to , version '0.2'. This
automatically
#updates all the collections using this package
bin/solr plugin update solr-highlighting:0.2
# search and list all the registered repos for a component which has a string
'highlight' in description
bin/solr plugin search “highlight”
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13659) Cache implementations should be loadable/reloadable from runtime libraries
[ https://issues.apache.org/jira/browse/SOLR-13659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-13659: -- Issue Type: Sub-task (was: Improvement) Parent: SOLR-13661 > Cache implementations should be loadable/reloadable from runtime libraries > -- > > Key: SOLR-13659 > URL: https://issues.apache.org/jira/browse/SOLR-13659 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > Cache implementation class is currently loaded from the SolrConfig > classloader -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13564) Runtime libs loaded from remote URLs should be available to all components
[
https://issues.apache.org/jira/browse/SOLR-13564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13564:
--
Issue Type: Sub-task (was: Improvement)
Parent: SOLR-13661
> Runtime libs loaded from remote URLs should be available to all components
> --
>
> Key: SOLR-13564
> URL: https://issues.apache.org/jira/browse/SOLR-13564
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> The runtime libs loaded from remote URLs are loaded at core startup. This
> means we could make this classes visible to every component (including
> components in {{schema.xml}})
> So, if there are runtime libs with the {{"url"}} attribute the classloader
> will be created and that'll be the classloader for all components loaded in
> the core.
> So what about legacy jars loaded from the {{.system}} collection?
> They will be visible only to the components specially marked with
> {{runtimeLib="true"}} . Even those components can load classes from the jars
> loaded from remote urls
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13650) Support for named global classloaders
[
https://issues.apache.org/jira/browse/SOLR-13650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13650:
--
Issue Type: Sub-task (was: Improvement)
Parent: SOLR-13661
> Support for named global classloaders
> -
>
> Key: SOLR-13650
> URL: https://issues.apache.org/jira/browse/SOLR-13650
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add-package": {
>"name": "my-package" ,
> "url" : "http://host:port/url/of/jar;,
> "sha512":""
> }
> }' http://localhost:8983/api/cluster
> {code}
> This means that Solr creates a globally accessible classloader with a name
> {{my-package}} which contains all the jars of that package.
> A component should be able to use the package by using the {{"package" :
> "my-package"}}.
> eg:
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "create-searchcomponent": {
> "name": "my-searchcomponent" ,
> "class" : "my.path.to.ClassName",
> "package" : "my-package"
> }
> }' http://localhost:8983/api/c/mycollection/config
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13565) Node level runtime libs loaded from remote urls
[
https://issues.apache.org/jira/browse/SOLR-13565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13565:
--
Issue Type: Sub-task (was: Improvement)
Parent: SOLR-13661
> Node level runtime libs loaded from remote urls
> ---
>
> Key: SOLR-13565
> URL: https://issues.apache.org/jira/browse/SOLR-13565
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Custom components to be loaded at a CorContainer level
> How to configure this?
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add-runtimelib": {
> "name": "lib-name" ,
> "url" : "http://host:port/url/of/jar;,
> "sha512":""
> }
> }' http://localhost:8983/api/cluster
> {code}
> How to update your jars?
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "update-runtimelib": {
> "name": "lib-name" ,
> "url" : "http://host:port/url/of/jar;,
> "sha512":""
> }
> }' http://localhost:8983/api/cluster
> {code}
> This only loads the components used in CoreContainer and it does not need to
> restart the Solr node
> The configuration lives in the file {{/clusterprops.json}} in ZK.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13661) A package management system for Solr
Noble Paul created SOLR-13661: - Summary: A package management system for Solr Key: SOLR-13661 URL: https://issues.apache.org/jira/browse/SOLR-13661 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13645) Add analytics function to format/extract components from dates
[
https://issues.apache.org/jira/browse/SOLR-13645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895689#comment-16895689
]
Lucene/Solr QA commented on SOLR-13645:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
4s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 2m 36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 2m 27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 2m 27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate ref guide {color} |
{color:green} 2m 27s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m
53s{color} | {color:green} analytics in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 10m 55s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13645 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12976133/SOLR-13645-Analytics-function-for-date-components.patch
|
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns validaterefguide |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 70a8deb |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/514/testReport/ |
| modules | C: solr/contrib/analytics solr/solr-ref-guide U: solr |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/514/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Add analytics function to format/extract components from dates
> --
>
> Key: SOLR-13645
> URL: https://issues.apache.org/jira/browse/SOLR-13645
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 8.1.1
>Reporter: Neal Sidhwaney
>Priority: Minor
> Attachments: SOLR-13645-Analytics-function-for-date-components.patch,
> SOLR-13645-Analytics-function-for-date-components.patch,
> SOLR-13645-Analytics-function-for-date-components.patch,
> SOLR-13645-Analytics-function-for-date-components.patch,
> SOLR-13645-Analytics-function-for-date-components.patch,
> SOLR-13645-Analytics-function-for-date-components.patch
>
>
> It's helpful when running analytics to be able to do manipulation on dates
> such as extracting month/day/year, converting to th week of year, etc, and
> other formatting as many existing libraries provide. I have a patch going
> through final testing that will add this to the analytcs library.
> One thing I'm sort of amibvialent about is that it exposes that we use Java
> date parsing in the analytics function, because the syntax is the same format
> string that SimpleDateFormat accepts. Ideally there would be an abstraction
> between the analytics language and what's used on the backend to implement
> it. On the other hand, implementing a syntax for time/date formatting is
> something that's been done many many times before, and this is not the only
> place where Java date particulars show through. It would be good to revisit
> this at a later time.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13660) AbstractFullDistribZkTestBase.waitForActiveReplicaCount is broken
[
https://issues.apache.org/jira/browse/SOLR-13660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-13660:
Attachment: SOLR-13660.patch
Status: Open (was: Open)
Allthough this method is not used directly in many Solr tests that subclass
{{AbstractFullDistribZkTestBase}} it is used by other methods in
{{AbstractFullDistribZkTestBase}} -- including when creating the
{{DEFAULT_COLLECTION}}.
Because of the esoteric way {{AbstractFullDistribZkTestBase}} initializes it's
collections (and jetty instances) almost every replica created starts in
recovery -- so as a result of this bug, subclasses may frequently see their
test methods being invoked before the expected number of shards/replicas.
In at least one case (TestCloudSchemaless) this has lead to test failures
(ultimately due to requests timing out when trying to add documents) as a
result of test client operations competing with multiple concurrent replica
recoveries on CPU constrained jenkins machines.
The attached patch:
* fixes {{waitForActiveReplicaCount(...)}} to check that the replicas are active
* deprecates and updates the javadocs of {{getTotalReplicas(...)}} to make it
clear that this method doesn't care about the status of the replica.
** this method was formally used by {{waitForActiveReplicaCount(...)}}
* also makes some related fixes to {{createJettys(...)}}:
** adds some comments clarifying how this method initializes the shards vs
addingthe replicas
** improves the initial slice count check to use existing helper methods which
also verifies the slices are active
*** this doesn't really affect the correctness of the method given how the
collection is used at this point, but helps simplify the code.
> AbstractFullDistribZkTestBase.waitForActiveReplicaCount is broken
> -
>
> Key: SOLR-13660
> URL: https://issues.apache.org/jira/browse/SOLR-13660
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13660.patch
>
>
> {{AbstractFullDistribZkTestBase.waitForActiveReplicaCount(...)}} is broken,
> and does not actually check that the replicas are active.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13660) AbstractFullDistribZkTestBase.waitForActiveReplicaCount is broken
[
https://issues.apache.org/jira/browse/SOLR-13660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-13660:
Status: Patch Available (was: Open)
> AbstractFullDistribZkTestBase.waitForActiveReplicaCount is broken
> -
>
> Key: SOLR-13660
> URL: https://issues.apache.org/jira/browse/SOLR-13660
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13660.patch
>
>
> {{AbstractFullDistribZkTestBase.waitForActiveReplicaCount(...)}} is broken,
> and does not actually check that the replicas are active.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13660) AbstractFullDistribZkTestBase.waitForActiveReplicaCount is broken
Hoss Man created SOLR-13660:
---
Summary: AbstractFullDistribZkTestBase.waitForActiveReplicaCount
is broken
Key: SOLR-13660
URL: https://issues.apache.org/jira/browse/SOLR-13660
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man
{{AbstractFullDistribZkTestBase.waitForActiveReplicaCount(...)}} is broken, and
does not actually check that the replicas are active.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8776) Start offset going backwards has a legitimate purpose
[ https://issues.apache.org/jira/browse/LUCENE-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895624#comment-16895624 ] Ram Venkat commented on LUCENE-8776: [~dsmiley] It would be challenging to discuss highlighting, in the context of this thread, without also discussing offsets. If you are asking me whether that particular feature in UnifiedHighlighter will solve my problem, based on my current understanding, answer would be 'no'. I can explain more if you want me to. To solve my problem, either offsets have to go backwards or I have to rewrite my search logic to treat adjacency on either side differently. > Start offset going backwards has a legitimate purpose > - > > Key: LUCENE-8776 > URL: https://issues.apache.org/jira/browse/LUCENE-8776 > Project: Lucene - Core > Issue Type: Bug > Components: core/search >Affects Versions: 7.6 >Reporter: Ram Venkat >Priority: Major > > Here is the use case where startOffset can go backwards: > Say there is a line "Organic light-emitting-diode glows", and I want to run > span queries and highlight them properly. > During index time, light-emitting-diode is split into three words, which > allows me to search for 'light', 'emitting' and 'diode' individually. The > three words occupy adjacent positions in the index, as 'light' adjacent to > 'emitting' and 'light' at a distance of two words from 'diode' need to match > this word. So, the order of words after splitting are: Organic, light, > emitting, diode, glows. > But, I also want to search for 'organic' being adjacent to > 'light-emitting-diode' or 'light-emitting-diode' being adjacent to 'glows'. > The way I solved this was to also generate 'light-emitting-diode' at two > positions: (a) In the same position as 'light' and (b) in the same position > as 'glows', like below: > ||organic||light||emitting||diode||glows|| > | |light-emitting-diode| |light-emitting-diode| | > |0|1|2|3|4| > The positions of the two 'light-emitting-diode' are 1 and 3, but the offsets > are obviously the same. This works beautifully in Lucene 5.x in both > searching and highlighting with span queries. > But when I try this in Lucene 7.6, it hits the condition "Offsets must not go > backwards" at DefaultIndexingChain:818. This IllegalArgumentException is > being thrown without any comments on why this check is needed. As I explained > above, startOffset going backwards is perfectly valid, to deal with word > splitting and span operations on these specialized use cases. On the other > hand, it is not clear what value is added by this check and which highlighter > code is affected by offsets going backwards. This same check is done at > BaseTokenStreamTestCase:245. > I see others talk about how this check found bugs in WordDelimiter etc. but > it also prevents legitimate use cases. Can this check be removed? -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8776) Start offset going backwards has a legitimate purpose
[ https://issues.apache.org/jira/browse/LUCENE-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895597#comment-16895597 ] David Smiley commented on LUCENE-8776: -- I think your response/question is about tokenstream contracts with offsets and not about highlighting, and that's well established territory already discussed in this thread. > Start offset going backwards has a legitimate purpose > - > > Key: LUCENE-8776 > URL: https://issues.apache.org/jira/browse/LUCENE-8776 > Project: Lucene - Core > Issue Type: Bug > Components: core/search >Affects Versions: 7.6 >Reporter: Ram Venkat >Priority: Major > > Here is the use case where startOffset can go backwards: > Say there is a line "Organic light-emitting-diode glows", and I want to run > span queries and highlight them properly. > During index time, light-emitting-diode is split into three words, which > allows me to search for 'light', 'emitting' and 'diode' individually. The > three words occupy adjacent positions in the index, as 'light' adjacent to > 'emitting' and 'light' at a distance of two words from 'diode' need to match > this word. So, the order of words after splitting are: Organic, light, > emitting, diode, glows. > But, I also want to search for 'organic' being adjacent to > 'light-emitting-diode' or 'light-emitting-diode' being adjacent to 'glows'. > The way I solved this was to also generate 'light-emitting-diode' at two > positions: (a) In the same position as 'light' and (b) in the same position > as 'glows', like below: > ||organic||light||emitting||diode||glows|| > | |light-emitting-diode| |light-emitting-diode| | > |0|1|2|3|4| > The positions of the two 'light-emitting-diode' are 1 and 3, but the offsets > are obviously the same. This works beautifully in Lucene 5.x in both > searching and highlighting with span queries. > But when I try this in Lucene 7.6, it hits the condition "Offsets must not go > backwards" at DefaultIndexingChain:818. This IllegalArgumentException is > being thrown without any comments on why this check is needed. As I explained > above, startOffset going backwards is perfectly valid, to deal with word > splitting and span operations on these specialized use cases. On the other > hand, it is not clear what value is added by this check and which highlighter > code is affected by offsets going backwards. This same check is done at > BaseTokenStreamTestCase:245. > I see others talk about how this check found bugs in WordDelimiter etc. but > it also prevents legitimate use cases. Can this check be removed? -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8776) Start offset going backwards has a legitimate purpose
[ https://issues.apache.org/jira/browse/LUCENE-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895585#comment-16895585 ] Ram Venkat commented on LUCENE-8776: [~dsmiley] I have not tried the UnifiedHighlighter yet. Phrases getting a highlight tag as a whole is a very useful and cool feature. My problem is that I cannot tell the highlighter that I want the highlight to begin at an earlier offset than the offset of the previous token. Is there a way to communicate that information to the UnifiedHighlighter? > Start offset going backwards has a legitimate purpose > - > > Key: LUCENE-8776 > URL: https://issues.apache.org/jira/browse/LUCENE-8776 > Project: Lucene - Core > Issue Type: Bug > Components: core/search >Affects Versions: 7.6 >Reporter: Ram Venkat >Priority: Major > > Here is the use case where startOffset can go backwards: > Say there is a line "Organic light-emitting-diode glows", and I want to run > span queries and highlight them properly. > During index time, light-emitting-diode is split into three words, which > allows me to search for 'light', 'emitting' and 'diode' individually. The > three words occupy adjacent positions in the index, as 'light' adjacent to > 'emitting' and 'light' at a distance of two words from 'diode' need to match > this word. So, the order of words after splitting are: Organic, light, > emitting, diode, glows. > But, I also want to search for 'organic' being adjacent to > 'light-emitting-diode' or 'light-emitting-diode' being adjacent to 'glows'. > The way I solved this was to also generate 'light-emitting-diode' at two > positions: (a) In the same position as 'light' and (b) in the same position > as 'glows', like below: > ||organic||light||emitting||diode||glows|| > | |light-emitting-diode| |light-emitting-diode| | > |0|1|2|3|4| > The positions of the two 'light-emitting-diode' are 1 and 3, but the offsets > are obviously the same. This works beautifully in Lucene 5.x in both > searching and highlighting with span queries. > But when I try this in Lucene 7.6, it hits the condition "Offsets must not go > backwards" at DefaultIndexingChain:818. This IllegalArgumentException is > being thrown without any comments on why this check is needed. As I explained > above, startOffset going backwards is perfectly valid, to deal with word > splitting and span operations on these specialized use cases. On the other > hand, it is not clear what value is added by this check and which highlighter > code is affected by offsets going backwards. This same check is done at > BaseTokenStreamTestCase:245. > I see others talk about how this check found bugs in WordDelimiter etc. but > it also prevents legitimate use cases. Can this check be removed? -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11.0.3) - Build # 24468 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24468/ Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -XX:+UseG1GC 4 tests failed. FAILED: org.apache.solr.search.facet.TestCloudJSONFacetSKG.testRandom Error Message: No live SolrServers available to handle this request:[https://127.0.0.1:43127/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[https://127.0.0.1:43127/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection] at __randomizedtesting.SeedInfo.seed([937DCA30C386FD09:E131EF3F72E64B7A]:0) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:345) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:987) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1002) at org.apache.solr.search.facet.TestCloudJSONFacetSKG.getNumFound(TestCloudJSONFacetSKG.java:669) at org.apache.solr.search.facet.TestCloudJSONFacetSKG.verifySKGResults(TestCloudJSONFacetSKG.java:446) at org.apache.solr.search.facet.TestCloudJSONFacetSKG.assertFacetSKGsAreCorrect(TestCloudJSONFacetSKG.java:392) at org.apache.solr.search.facet.TestCloudJSONFacetSKG.assertFacetSKGsAreCorrect(TestCloudJSONFacetSKG.java:402) at org.apache.solr.search.facet.TestCloudJSONFacetSKG.assertFacetSKGsAreCorrect(TestCloudJSONFacetSKG.java:349) at org.apache.solr.search.facet.TestCloudJSONFacetSKG.testRandom(TestCloudJSONFacetSKG.java:274) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at
[JENKINS] Lucene-Solr-NightlyTests-8.2 - Build # 17 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.2/17/ No tests ran. Build Log: [...truncated 25 lines...] ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the server svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ... 4 more java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
[jira] [Created] (SOLR-13659) Cache implementations should be loadable/reloadable from runtime libraries
Noble Paul created SOLR-13659: - Summary: Cache implementations should be loadable/reloadable from runtime libraries Key: SOLR-13659 URL: https://issues.apache.org/jira/browse/SOLR-13659 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul Assignee: Noble Paul Cache implementation class is currently loaded from the SolrConfig classloader -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13399) compositeId support for shard splitting
[ https://issues.apache.org/jira/browse/SOLR-13399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-13399: Attachment: SOLR-13399_testfix.patch Status: Reopened (was: Reopened) Attaching patch to fix the test bug by explicitly forcing the number of bits in the test when using tri-level ids "foo/16!bar!doc1" > compositeId support for shard splitting > --- > > Key: SOLR-13399 > URL: https://issues.apache.org/jira/browse/SOLR-13399 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley >Assignee: Yonik Seeley >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13399.patch, SOLR-13399.patch, > SOLR-13399_testfix.patch > > > Shard splitting does not currently have a way to automatically take into > account the actual distribution (number of documents) in each hash bucket > created by using compositeId hashing. > We should probably add a parameter *splitByPrefix* to the *SPLITSHARD* > command that would look at the number of docs sharing each compositeId prefix > and use that to create roughly equal sized buckets by document count rather > than just assuming an equal distribution across the entire hash range. > Like normal shard splitting, we should bias against splitting within hash > buckets unless necessary (since that leads to larger query fanout.) . Perhaps > this warrants a parameter that would control how much of a size mismatch is > tolerable before resorting to splitting within a bucket. > *allowedSizeDifference*? > To more quickly calculate the number of docs in each bucket, we could index > the prefix in a different field. Iterating over the terms for this field > would quickly give us the number of docs in each (i.e lucene keeps track of > the doc count for each term already.) Perhaps the implementation could be a > flag on the *id* field... something like *indexPrefixes* and poly-fields that > would cause the indexing to be automatically done and alleviate having to > pass in an additional field during indexing and during the call to > *SPLITSHARD*. This whole part is an optimization though and could be split > off into its own issue if desired. > > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-8.2 - Build # 34 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.2/34/ 1 tests failed. FAILED: org.apache.solr.schema.TestUseDocValuesAsStored.testDuplicateMultiValued Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([69AC8730651B9CCD:87719310ABAA6A71]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:947) at org.apache.solr.schema.TestUseDocValuesAsStored.doTest(TestUseDocValuesAsStored.java:367) at org.apache.solr.schema.TestUseDocValuesAsStored.testDuplicateMultiValued(TestUseDocValuesAsStored.java:172) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//arr[@name='enums_dvo']/str[.='Not Available'] xml response was:
[jira] [Commented] (SOLR-13399) compositeId support for shard splitting
[ https://issues.apache.org/jira/browse/SOLR-13399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895494#comment-16895494 ] Yonik Seeley commented on SOLR-13399: - OK, figured out the issue... It turns out that if you have foo!, foo!bar! will normally not nest under it. The number of bits used for the first part of the hash is dynamic depending on the number of levels in the composite hash ID. That's unfortunate for a number of reasons. It also breaks the initial bi-level hash that guaranteed that you could just add a prefix to any document id without any escaping (i.e. if your ID happens to contain "!", it can cause the document hash to fall outside of the parent hash prefix.) It looks like is working as designed (according to SOLR-5320), but it was certainly surprising since it prevents hash routing from working out-of-the-box in conjunction with tri-level ids without explicitly specifying bits with the "/" notation. > compositeId support for shard splitting > --- > > Key: SOLR-13399 > URL: https://issues.apache.org/jira/browse/SOLR-13399 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley >Assignee: Yonik Seeley >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13399.patch, SOLR-13399.patch > > > Shard splitting does not currently have a way to automatically take into > account the actual distribution (number of documents) in each hash bucket > created by using compositeId hashing. > We should probably add a parameter *splitByPrefix* to the *SPLITSHARD* > command that would look at the number of docs sharing each compositeId prefix > and use that to create roughly equal sized buckets by document count rather > than just assuming an equal distribution across the entire hash range. > Like normal shard splitting, we should bias against splitting within hash > buckets unless necessary (since that leads to larger query fanout.) . Perhaps > this warrants a parameter that would control how much of a size mismatch is > tolerable before resorting to splitting within a bucket. > *allowedSizeDifference*? > To more quickly calculate the number of docs in each bucket, we could index > the prefix in a different field. Iterating over the terms for this field > would quickly give us the number of docs in each (i.e lucene keeps track of > the doc count for each term already.) Perhaps the implementation could be a > flag on the *id* field... something like *indexPrefixes* and poly-fields that > would cause the indexing to be automatically done and alleviate having to > pass in an additional field during indexing and during the call to > *SPLITSHARD*. This whole part is an optimization though and could be split > off into its own issue if desired. > > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12555) Replace try-fail-catch test patterns
[
https://issues.apache.org/jira/browse/SOLR-12555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895469#comment-16895469
]
Munendra S N commented on SOLR-12555:
-
[^SOLR-12555.patch]
Patch with only solr changes. I'm planning to commit this module by module if
there are many changes.
[~gerlowskija] any suggestions here??
> Replace try-fail-catch test patterns
>
>
> Key: SOLR-12555
> URL: https://issues.apache.org/jira/browse/SOLR-12555
> Project: Solr
> Issue Type: Test
> Components: Tests
>Affects Versions: 8.0
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-12555-sorted-by-package.txt, SOLR-12555.patch,
> SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.patch,
> SOLR-12555.txt
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> I recently added some test code through SOLR-12427 which used the following
> test anti-pattern:
> {code}
> try {
> actionExpectedToThrowException();
> fail("I expected this to throw an exception, but it didn't");
> catch (Exception e) {
> assertOnThrownException(e);
> }
> {code}
> Hoss (rightfully) objected that this should instead be written using the
> formulation below, which is clearer and more concise.
> {code}
> SolrException e = expectThrows(() -> {...});
> {code}
> We should remove many of these older formulations where it makes sense. Many
> of them were written before {{expectThrows}} was introduced, and having the
> old style assertions around makes it easier for them to continue creeping in.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12555) Replace try-fail-catch test patterns
[
https://issues.apache.org/jira/browse/SOLR-12555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-12555:
Attachment: SOLR-12555.patch
> Replace try-fail-catch test patterns
>
>
> Key: SOLR-12555
> URL: https://issues.apache.org/jira/browse/SOLR-12555
> Project: Solr
> Issue Type: Test
> Components: Tests
>Affects Versions: 8.0
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-12555-sorted-by-package.txt, SOLR-12555.patch,
> SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.patch,
> SOLR-12555.txt
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> I recently added some test code through SOLR-12427 which used the following
> test anti-pattern:
> {code}
> try {
> actionExpectedToThrowException();
> fail("I expected this to throw an exception, but it didn't");
> catch (Exception e) {
> assertOnThrownException(e);
> }
> {code}
> Hoss (rightfully) objected that this should instead be written using the
> formulation below, which is clearer and more concise.
> {code}
> SolrException e = expectThrows(() -> {...});
> {code}
> We should remove many of these older formulations where it makes sense. Many
> of them were written before {{expectThrows}} was introduced, and having the
> old style assertions around makes it easier for them to continue creeping in.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8938) Replace try-fail-catch test patterns
[
https://issues.apache.org/jira/browse/LUCENE-8938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated LUCENE-8938:
-
Resolution: Fixed
Fix Version/s: 8.3
Status: Resolved (was: Patch Available)
> Replace try-fail-catch test patterns
>
>
> Key: LUCENE-8938
> URL: https://issues.apache.org/jira/browse/LUCENE-8938
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Fix For: 8.3
>
> Attachments: LUCENE-8938.patch
>
>
> Replace try-fail-catch test patterns with {{expectThrows}} wherever possible.
> This is spawned from SOLR-12555
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13657) Fix TestXPathRecordReader.testUnsupported_Xpaths
[
https://issues.apache.org/jira/browse/SOLR-13657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N resolved SOLR-13657.
-
Resolution: Fixed
Fix Version/s: 8.3
> Fix TestXPathRecordReader.testUnsupported_Xpaths
>
>
> Key: SOLR-13657
> URL: https://issues.apache.org/jira/browse/SOLR-13657
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Minor
> Fix For: 8.3
>
>
> {{tTestXPathRecordReader.testUnsupported_Xpaths}} covers some negative cases
> for xpath
> While working on SOLR-12555, found that, here NPE thrown as rr is never set
> not the expected exception
> {code:java}
> try {
> rr.addField("bold" ,"b",false);
> fail("A RuntimeException was expected: 'b' xpaths must begin with
> '/'.");
> }
> catch (RuntimeException ex) { }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13645) Add analytics function to format/extract components from dates
[ https://issues.apache.org/jira/browse/SOLR-13645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895461#comment-16895461 ] Neal Sidhwaney commented on SOLR-13645: --- Just an FYI - I rebased on top of HEAD, no action necessary. THanks, Neal > Add analytics function to format/extract components from dates > -- > > Key: SOLR-13645 > URL: https://issues.apache.org/jira/browse/SOLR-13645 > Project: Solr > Issue Type: New Feature >Affects Versions: 8.1.1 >Reporter: Neal Sidhwaney >Priority: Minor > Attachments: SOLR-13645-Analytics-function-for-date-components.patch, > SOLR-13645-Analytics-function-for-date-components.patch, > SOLR-13645-Analytics-function-for-date-components.patch, > SOLR-13645-Analytics-function-for-date-components.patch, > SOLR-13645-Analytics-function-for-date-components.patch, > SOLR-13645-Analytics-function-for-date-components.patch > > > It's helpful when running analytics to be able to do manipulation on dates > such as extracting month/day/year, converting to th week of year, etc, and > other formatting as many existing libraries provide. I have a patch going > through final testing that will add this to the analytcs library. > One thing I'm sort of amibvialent about is that it exposes that we use Java > date parsing in the analytics function, because the syntax is the same format > string that SimpleDateFormat accepts. Ideally there would be an abstraction > between the analytics language and what's used on the backend to implement > it. On the other hand, implementing a syntax for time/date formatting is > something that's been done many many times before, and this is not the only > place where Java date particulars show through. It would be good to revisit > this at a later time. > > > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8938) Replace try-fail-catch test patterns
[
https://issues.apache.org/jira/browse/LUCENE-8938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895460#comment-16895460
]
ASF subversion and git services commented on LUCENE-8938:
-
Commit b82d345e2831a805bd0027289199d4e5935fa7c4 in lucene-solr's branch
refs/heads/branch_8x from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b82d345 ]
LUCENE-8938: use expectThrows() to verify the ex thrown in tests
> Replace try-fail-catch test patterns
>
>
> Key: LUCENE-8938
> URL: https://issues.apache.org/jira/browse/LUCENE-8938
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Attachments: LUCENE-8938.patch
>
>
> Replace try-fail-catch test patterns with {{expectThrows}} wherever possible.
> This is spawned from SOLR-12555
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13645) Add analytics function to format/extract components from dates
[ https://issues.apache.org/jira/browse/SOLR-13645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neal Sidhwaney updated SOLR-13645: -- Attachment: SOLR-13645-Analytics-function-for-date-components.patch > Add analytics function to format/extract components from dates > -- > > Key: SOLR-13645 > URL: https://issues.apache.org/jira/browse/SOLR-13645 > Project: Solr > Issue Type: New Feature >Affects Versions: 8.1.1 >Reporter: Neal Sidhwaney >Priority: Minor > Attachments: SOLR-13645-Analytics-function-for-date-components.patch, > SOLR-13645-Analytics-function-for-date-components.patch, > SOLR-13645-Analytics-function-for-date-components.patch, > SOLR-13645-Analytics-function-for-date-components.patch, > SOLR-13645-Analytics-function-for-date-components.patch, > SOLR-13645-Analytics-function-for-date-components.patch > > > It's helpful when running analytics to be able to do manipulation on dates > such as extracting month/day/year, converting to th week of year, etc, and > other formatting as many existing libraries provide. I have a patch going > through final testing that will add this to the analytcs library. > One thing I'm sort of amibvialent about is that it exposes that we use Java > date parsing in the analytics function, because the syntax is the same format > string that SimpleDateFormat accepts. Ideally there would be an abstraction > between the analytics language and what's used on the backend to implement > it. On the other hand, implementing a syntax for time/date formatting is > something that's been done many many times before, and this is not the only > place where Java date particulars show through. It would be good to revisit > this at a later time. > > > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13657) Fix TestXPathRecordReader.testUnsupported_Xpaths
[
https://issues.apache.org/jira/browse/SOLR-13657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895459#comment-16895459
]
ASF subversion and git services commented on SOLR-13657:
Commit bb3372a17c041fcc7cbc248ffc510bb6b0db419b in lucene-solr's branch
refs/heads/branch_8x from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=bb3372a ]
SOLR-13657: fix unsupported xpath test in TestXPathRecordReader
* use expectThrows to verify the exception and the message
* fix NPE in the test
> Fix TestXPathRecordReader.testUnsupported_Xpaths
>
>
> Key: SOLR-13657
> URL: https://issues.apache.org/jira/browse/SOLR-13657
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Minor
>
> {{tTestXPathRecordReader.testUnsupported_Xpaths}} covers some negative cases
> for xpath
> While working on SOLR-12555, found that, here NPE thrown as rr is never set
> not the expected exception
> {code:java}
> try {
> rr.addField("bold" ,"b",false);
> fail("A RuntimeException was expected: 'b' xpaths must begin with
> '/'.");
> }
> catch (RuntimeException ex) { }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13657) Fix TestXPathRecordReader.testUnsupported_Xpaths
[
https://issues.apache.org/jira/browse/SOLR-13657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895452#comment-16895452
]
ASF subversion and git services commented on SOLR-13657:
Commit 1d303cee7f533fa8edb3477bf14fbc5f5bf3d563 in lucene-solr's branch
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1d303ce ]
SOLR-13657: fix unsupported xpath test in TestXPathRecordReader
* use expectThrows to verify the exception and the message
* fix NPE in the test
> Fix TestXPathRecordReader.testUnsupported_Xpaths
>
>
> Key: SOLR-13657
> URL: https://issues.apache.org/jira/browse/SOLR-13657
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Minor
>
> {{tTestXPathRecordReader.testUnsupported_Xpaths}} covers some negative cases
> for xpath
> While working on SOLR-12555, found that, here NPE thrown as rr is never set
> not the expected exception
> {code:java}
> try {
> rr.addField("bold" ,"b",false);
> fail("A RuntimeException was expected: 'b' xpaths must begin with
> '/'.");
> }
> catch (RuntimeException ex) { }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8938) Replace try-fail-catch test patterns
[
https://issues.apache.org/jira/browse/LUCENE-8938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895453#comment-16895453
]
ASF subversion and git services commented on LUCENE-8938:
-
Commit 70a8deb0abedd42aec86b10a8da2676737853514 in lucene-solr's branch
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=70a8deb ]
LUCENE-8938: use expectThrows() to verify the ex thrown in tests
> Replace try-fail-catch test patterns
>
>
> Key: LUCENE-8938
> URL: https://issues.apache.org/jira/browse/LUCENE-8938
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Attachments: LUCENE-8938.patch
>
>
> Replace try-fail-catch test patterns with {{expectThrows}} wherever possible.
> This is spawned from SOLR-12555
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8938) Replace try-fail-catch test patterns
[
https://issues.apache.org/jira/browse/LUCENE-8938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895439#comment-16895439
]
Lucene/Solr QA commented on LUCENE-8938:
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 24 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
34s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 0m 39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 0m 39s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 5m
15s{color} | {color:green} common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 16m
34s{color} | {color:green} core in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
38s{color} | {color:green} join in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
28s{color} | {color:green} queryparser in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
29s{color} | {color:green} replicator in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
14s{color} | {color:green} sandbox in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m
17s{color} | {color:green} suggest in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
4s{color} | {color:green} test-framework in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 38m 10s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8938 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12976090/LUCENE-8938.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24
10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / b8289abeeb |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-LUCENE-Build/200/testReport/ |
| modules | C: lucene/analysis/common lucene/core lucene/join
lucene/queryparser lucene/replicator lucene/sandbox lucene/suggest
lucene/test-framework U: lucene |
| Console output |
https://builds.apache.org/job/PreCommit-LUCENE-Build/200/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Replace try-fail-catch test patterns
>
>
> Key: LUCENE-8938
> URL: https://issues.apache.org/jira/browse/LUCENE-8938
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Attachments: LUCENE-8938.patch
>
>
> Replace try-fail-catch test patterns with {{expectThrows}} wherever possible.
> This is spawned from SOLR-12555
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13579) Create resource management API
[ https://issues.apache.org/jira/browse/SOLR-13579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895371#comment-16895371 ] Andrzej Bialecki commented on SOLR-13579: -- bq. Hmmm, Did you mean to upload a diff patch? the latests i see (#12975831) still contains lots of new class names refering to "Resource" instead of "Component" ... I meant the use of "component" where it refers to Solr components - previous versions of the patch confusingly referred to these components as "resources", hence eg. ManagedResource -> ManagedComponent. Other names are related to the management of actual hardware resources (ram, IO, etc.) so I felt the remaining class names with ..resource.. are still appropriate here. > Create resource management API > -- > > Key: SOLR-13579 > URL: https://issues.apache.org/jira/browse/SOLR-13579 > Project: Solr > Issue Type: New Feature >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, > SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch > > > Resource management framework API supporting the goals outlined in SOLR-13578. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13658) Discuss adding the new "var" construct to the forbidden API list.
[
https://issues.apache.org/jira/browse/SOLR-13658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895370#comment-16895370
]
Erick Erickson commented on SOLR-13658:
---
Assigning it to myself to track, anyone who wants to take it over please do.
> Discuss adding the new "var" construct to the forbidden API list.
> -
>
> Key: SOLR-13658
> URL: https://issues.apache.org/jira/browse/SOLR-13658
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> Personally, I'm strongly against allowing the "var" construct in Lucene/Solr
> code. I think it's a wonderful opportunity to introduce bugs that won't be
> found until runtime as well as making maintainence significantly harder. I
> don't even think for a project like Solr it would save any time overall...
> So let's discuss this ahead of time and see if we can reach a consensus. I'll
> start the discussion off:
> My baseline argument is that for a large complex project, especially ones
> with many different people coding, I want the compiler to give me all the
> help possible. And the "var" construct takes away some of that help.
> I’ve seen this argument go around at least 4 times in my career. The argument
> that “it takes longer to write if you have to type all this stuff” is bogus.
> Last I knew, 80% of the time spent is in maintaining/reading it. So the
> argument “I can write faster” means I can save some fraction of the 20% of
> the time writing the original code but spend many times that figuring out
> what the code is actually doing the other 80% of the time.
> The IDE makes _writing_ this slightly faster, admittedly.
> {code:java}
> Whatever what = new Whatever();
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> {code}
> But once that’s done, if I’m reading the code again I don't have any clue what
> {code:java}
> kidding or blivet
> {code}
> are. Here's the signature for getComplex:
> {code:java}
> Map> getComplex()
> {code}
> I have to go over to the definition (which I admit is easier than it used to
> be in the bad old days, but still) to find out.
> HERE'S THE PART I REALLY OBJECT TO!
> The above I could probably live with, maybe we could get the InteliJ
> developers and see if they can make hover show the inference. What I will
> kick and scream about is introducing bugs that are not found until runtime.
> Even this obvious stupidity fails with a ClassCastException:
> {code:java}
> var corny = new TreeMap();
> corny.put("one", "two");
> corny.get(1);
> {code}
> But it's much worse when using classes from somewhere else. For instance,
> change the underlying class in the first example to return
> {code:java}
> Map>{code}
> .
> This code that used to work now throws an error, _but it compiles_.
> {code:java}
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> var blah = kidding.get("stuff").get(1); // generates ClassCastException:
> class java.lang.String cannot be cast to class java.lang.Integer
> {code}
> So in order to save some time writing (that I claim will be lost multiple
> times over when maintaining the code) we'll introduce run-time errors that
> will take a bunch _more_ time to figure out, and won’t be found during unit
> tests unless and until we have complete code coverage.
> If there's a way to insure that this kind of thing can't get into the code
> and we implement that, I could be persuaded, but let's make that an explicit
> requirement (and find a suitable task for the build system, precommit or
> whatever).
> The floor is open...
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13658) Discuss adding the new "var" construct to the forbidden API list.
[
https://issues.apache.org/jira/browse/SOLR-13658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson reassigned SOLR-13658:
-
Assignee: Erick Erickson
> Discuss adding the new "var" construct to the forbidden API list.
> -
>
> Key: SOLR-13658
> URL: https://issues.apache.org/jira/browse/SOLR-13658
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> Personally, I'm strongly against allowing the "var" construct in Lucene/Solr
> code. I think it's a wonderful opportunity to introduce bugs that won't be
> found until runtime as well as making maintainence significantly harder. I
> don't even think for a project like Solr it would save any time overall...
> So let's discuss this ahead of time and see if we can reach a consensus. I'll
> start the discussion off:
> My baseline argument is that for a large complex project, especially ones
> with many different people coding, I want the compiler to give me all the
> help possible. And the "var" construct takes away some of that help.
> I’ve seen this argument go around at least 4 times in my career. The argument
> that “it takes longer to write if you have to type all this stuff” is bogus.
> Last I knew, 80% of the time spent is in maintaining/reading it. So the
> argument “I can write faster” means I can save some fraction of the 20% of
> the time writing the original code but spend many times that figuring out
> what the code is actually doing the other 80% of the time.
> The IDE makes _writing_ this slightly faster, admittedly.
> {code:java}
> Whatever what = new Whatever();
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> {code}
> But once that’s done, if I’m reading the code again I don't have any clue what
> {code:java}
> kidding or blivet
> {code}
> are. Here's the signature for getComplex:
> {code:java}
> Map> getComplex()
> {code}
> I have to go over to the definition (which I admit is easier than it used to
> be in the bad old days, but still) to find out.
> HERE'S THE PART I REALLY OBJECT TO!
> The above I could probably live with, maybe we could get the InteliJ
> developers and see if they can make hover show the inference. What I will
> kick and scream about is introducing bugs that are not found until runtime.
> Even this obvious stupidity fails with a ClassCastException:
> {code:java}
> var corny = new TreeMap();
> corny.put("one", "two");
> corny.get(1);
> {code}
> But it's much worse when using classes from somewhere else. For instance,
> change the underlying class in the first example to return
> {code:java}
> Map>{code}
> .
> This code that used to work now throws an error, _but it compiles_.
> {code:java}
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> var blah = kidding.get("stuff").get(1); // generates ClassCastException:
> class java.lang.String cannot be cast to class java.lang.Integer
> {code}
> So in order to save some time writing (that I claim will be lost multiple
> times over when maintaining the code) we'll introduce run-time errors that
> will take a bunch _more_ time to figure out, and won’t be found during unit
> tests unless and until we have complete code coverage.
> If there's a way to insure that this kind of thing can't get into the code
> and we implement that, I could be persuaded, but let's make that an explicit
> requirement (and find a suitable task for the build system, precommit or
> whatever).
> The floor is open...
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13658) Discuss adding the new "var" construct to the forbidden API list.
Erick Erickson created SOLR-13658:
-
Summary: Discuss adding the new "var" construct to the forbidden
API list.
Key: SOLR-13658
URL: https://issues.apache.org/jira/browse/SOLR-13658
Project: Solr
Issue Type: Wish
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: master (9.0)
Reporter: Erick Erickson
Personally, I'm strongly against allowing the "var" construct in Lucene/Solr
code. I think it's a wonderful opportunity to introduce bugs that won't be
found until runtime as well as making maintainence significantly harder. I
don't even think for a project like Solr it would save any time overall...
So let's discuss this ahead of time and see if we can reach a consensus. I'll
start the discussion off:
My baseline argument is that for a large complex project, especially ones with
many different people coding, I want the compiler to give me all the help
possible. And the "var" construct takes away some of that help.
I’ve seen this argument go around at least 4 times in my career. The argument
that “it takes longer to write if you have to type all this stuff” is bogus.
Last I knew, 80% of the time spent is in maintaining/reading it. So the
argument “I can write faster” means I can save some fraction of the 20% of the
time writing the original code but spend many times that figuring out what the
code is actually doing the other 80% of the time.
The IDE makes _writing_ this slightly faster, admittedly.
{code:java}
Whatever what = new Whatever();
var kidding = what.getComplex();
var blivet = kidding.get("stuff");
{code}
But once that’s done, if I’m reading the code again I don't have any clue what
{code:java}
kidding or blivet
{code}
are. Here's the signature for getComplex:
{code:java}
Map> getComplex()
{code}
I have to go over to the definition (which I admit is easier than it used to be
in the bad old days, but still) to find out.
HERE'S THE PART I REALLY OBJECT TO!
The above I could probably live with, maybe we could get the InteliJ developers
and see if they can make hover show the inference. What I will kick and scream
about is introducing bugs that are not found until runtime. Even this obvious
stupidity fails with a ClassCastException:
{code:java}
var corny = new TreeMap();
corny.put("one", "two");
corny.get(1);
{code}
But it's much worse when using classes from somewhere else. For instance,
change the underlying class in the first example to return
{code:java}
Map>{code}
.
This code that used to work now throws an error, _but it compiles_.
{code:java}
var kidding = what.getComplex();
var blivet = kidding.get("stuff");
var blah = kidding.get("stuff").get(1); // generates ClassCastException: class
java.lang.String cannot be cast to class java.lang.Integer
{code}
So in order to save some time writing (that I claim will be lost multiple times
over when maintaining the code) we'll introduce run-time errors that will take
a bunch _more_ time to figure out, and won’t be found during unit tests unless
and until we have complete code coverage.
If there's a way to insure that this kind of thing can't get into the code and
we implement that, I could be persuaded, but let's make that an explicit
requirement (and find a suitable task for the build system, precommit or
whatever).
The floor is open...
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8937) Avoid agressive stemming on numbers in the FrenchMinimalStemmer
[ https://issues.apache.org/jira/browse/LUCENE-8937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895358#comment-16895358 ] Steve Rowe commented on LUCENE-8937: +1 for the change. > Avoid agressive stemming on numbers in the FrenchMinimalStemmer > --- > > Key: LUCENE-8937 > URL: https://issues.apache.org/jira/browse/LUCENE-8937 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Gallou >Priority: Minor > Attachments: 0001-adds-test-cases-on-french-minimal-stemmer.patch, > 0002-check-if-the-last-character-is-a-letter-before-remov.patch, > SOLR-8937.patch > > > Here is the discussion on the mailing list : > [http://mail-archives.apache.org/mod_mbox/lucene-java-user/201907.mbox/browser] > The light stemmer removes the last character of a word if the last two > characters are identical. > We can see that here: > > [https://github.com/apache/lucene-solr/blob/master/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchLightStemmer.java#L263] > In this light stemmer, there is a check to avoid altering the token if the > token is a number. > The minimal stemmer also removes the last character of a word if the last > two characters are identical. > We can see that here: > > [https://github.com/apache/lucene-solr/blob/master/lucene/analysis/common/src/java/org/apache/lucene/analysis/fr/FrenchMinimalStemmer.java#L77] > But in this minimal stemmer there is no check to see if the character is a > letter or not. > So when we have numeric tokens with the last two characters identical they > are altered. > For example "1234567899" will be stemmed as "123456789". > It could be great of it's not altered. > Here is the same issue for the LightStemmer : > https://issues.apache.org/jira/browse/LUCENE-4063 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13122) Ability to query aliases in Solr Admin UI
[ https://issues.apache.org/jira/browse/SOLR-13122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895220#comment-16895220 ] Jan Høydahl commented on SOLR-13122: Pushed a new commit that also displays alias properties on the alias-overview sub menu. There is still some CSS issues with wrapping long key/values properly, but that could also be handled as a followup. Will merge today or tomorrow. > Ability to query aliases in Solr Admin UI > - > > Key: SOLR-13122 > URL: https://issues.apache.org/jira/browse/SOLR-13122 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Reporter: mosh >Assignee: Jan Høydahl >Priority: Major > Labels: UI > Fix For: 8.3 > > Attachments: alias-collection-menu-selected.png, > alias-collection-view.png, alias-collections-menu.png, > alias-collections-menu.png, alias-delete-dialogue.png, alias-dropdown.png, > alias-properties.png, alias-select-double.png, alias-view.png, > new-collection-dropdown.png, new-oll-overview.png > > Time Spent: 10m > Remaining Estimate: 0h > > After having recently toyed with Time Routed Alias in SolrCloud, > we have noticed there is no way to query an alias from the admin UI, > since the combo box only contains the current collection in the cluster. > Solr Admin UI ought to have a way to query these aliases, for better > convenience. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1913 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1913/ No tests ran. Build Log: [...truncated 25 lines...] ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the server svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ... 4 more java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
[jira] [Commented] (SOLR-7889) Secure ZooKeeper should be easy and the default
[
https://issues.apache.org/jira/browse/SOLR-7889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895190#comment-16895190
]
Erick Erickson commented on SOLR-7889:
--
+1
> Secure ZooKeeper should be easy and the default
> ---
>
> Key: SOLR-7889
> URL: https://issues.apache.org/jira/browse/SOLR-7889
> Project: Solr
> Issue Type: Improvement
> Components: security
>Reporter: Jan Høydahl
>Priority: Critical
> Labels: security, zookeeper
>
> ZooKeeper security is documented at
> https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control but
> is not trivial to setup, see http://search-lucene.com/m/eHNlqr6EnMrP6O
> As we enable more and more security stuff, securing ZK should be easier to do
> and ideally the default. This is an umbrella for such improvements.
> When all of this is in place and working, perhaps even Solr should refuse to
> start if Auth/Autz plugins are in use and ZK communication is not properly
> protected, e.g. require {{bin/solr start --insecure}} to override.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-13-ea+26) - Build # 24466 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24466/ Java: 64bit/jdk-13-ea+26 -XX:-UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 5134 lines...] [junit4] JVM J1: stdout was not empty, see: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/backward-codecs/test/temp/junit4-J1-20190729_114608_2753787480043909187533.sysout [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] # [junit4] # A fatal error has been detected by the Java Runtime Environment: [junit4] # [junit4] # SIGSEGV (0xb) at pc=0x7fcc679418e6, pid=25122, tid=25158 [junit4] # [junit4] # JRE version: OpenJDK Runtime Environment (13.0+26) (build 13-ea+26) [junit4] # Java VM: OpenJDK 64-Bit Server VM (13-ea+26, mixed mode, tiered, parallel gc, linux-amd64) [junit4] # Problematic frame: [junit4] # V [libjvm.so+0xcad8e6] PhaseIdealLoop::split_up(Node*, Node*, Node*)+0x7f6 [junit4] # [junit4] # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again [junit4] # [junit4] # An error report file with more information is saved as: [junit4] # /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/backward-codecs/test/J1/hs_err_pid25122.log [junit4] [thread 25186 also had an error][thread 26731 also had an error] [junit4] [junit4] [junit4] -- Timeout during error reporting after 120 s. -- [junit4] # [ timer expired, abort... ] [junit4] <<< JVM J1: EOF [...truncated 3 lines...] [junit4] ERROR: JVM J1 ended with an exception, command line: /home/jenkins/tools/java/64bit/jdk-13-ea+26/bin/java -XX:-UseCompressedOops -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/jenkins/workspace/Lucene-Solr-master-Linux/heapdumps -ea -esa --illegal-access=deny -Dtests.prefix=tests -Dtests.seed=A43CE1EC155FEBB3 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=9.0.0 -Dtests.cleanthreads=perMethod -Djava.util.logging.config.file=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/junit4/logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false -Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=3 -DtempDir=./temp -Djava.io.tmpdir=./temp -Dcommon.dir=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene -Dclover.db.dir=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/clover/db -Djava.security.policy=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/junit4/tests.policy -Dtests.LUCENE_VERSION=9.0.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Djdk.map.althashing.threshold=0 -Dtests.src.home=/home/jenkins/workspace/Lucene-Solr-master-Linux -Djava.security.egd=file:/dev/./urandom -Djunit4.childvm.cwd=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/backward-codecs/test/J1 -Djunit4.tempDir=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/backward-codecs/test/temp -Djunit4.childvm.id=1 -Djunit4.childvm.count=3 -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Dtests.filterstacks=true -Dtests.leaveTemporary=false -Dtests.badapples=false -classpath
BadApple report
Here it is after a hiatus. I have moved from California to South Orange, NJ… it’s a long story why. But I’ll be glad to tell y’all about driving a Chevy Bolt EV across country and how Wyoming has very few commercial charging options… But I did get to see Old Faithful erupt… Any, I won’t make any annotation changes this week. It’ll be a little strange for the next 3 weeks as I’ll pick up the last 4 summaries for the report and there’s a two week gap. So fixes in the last week won’t be reflected in the reports for up to 6 weeks after they were made. Full report attached. **Annotated tests that didn't fail in the last 4 weeks. **Tests removed from the next two lists because they were specified in 'doNotEnable' in the properties file MoveReplicaHDFSTest.testNormalFailedMove **Annotations will be removed from the following tests because they haven't failed in the last 4 rollups. **Methods: 1 SolrZkClientTest.testSimpleUpdateACLs Failures in Hoss' reports for the last 4 rollups. There were 338 unannotated tests that failed in Hoss' rollups. Ordered by the date I downloaded the rollup file, newest->oldest. See above for the dates the files were collected These tests were NOT BadApple'd or AwaitsFix'd All tests that failed 4 weeks running will be BadApple'd unless there are objections Failures in the last 4 reports.. Report Pct runsfails test 0123 2.2 896 21 AliasIntegrationTest.testClusterStateProviderAPI 0123 52.2 1046183 BasicAuthIntegrationTest.testBasicAuth 0123 0.7 921 5 CollectionPropsTest.testReadWriteCached 0123 38.5 89 23 HdfsAutoAddReplicasIntegrationTest.testSimple 0123 0.7 928 10 HttpPartitionWithTlogReplicasTest.test 0123 0.8 858 31 LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud 0123 0.8 870 9 RollingRestartTest.test 0123 21.1 112 17 ShardSplitTest.testSplitWithChaosMonkey 0123 0.8 877 9 SystemCollectionCompatTest.testBackCompat Will BadApple all tests above this line except ones listed at the top** DO NOT ENABLE LIST: MoveReplicaHDFSTest.testFailedMove MoveReplicaHDFSTest.testNormalFailedMove TestControlledRealTimeReopenThread.testCRTReopen TestICUNormalizer2CharFilter.testRandomStrings TestICUTokenizerCJK TestImpersonationWithHadoopAuth.testForwarding TestLTRReRankingPipeline.testDifferentTopN TestRandomChains DO NOT ANNOTATE LIST CdcrBidirectionalTest.testBiDir IndexSizeTriggerTest.testMergeIntegration IndexSizeTriggerTest.testMixedBounds IndexSizeTriggerTest.testSplitIntegration IndexSizeTriggerTest.testTrigger InfixSuggestersTest.testShutdownDuringBuild ShardSplitTest.test ShardSplitTest.testSplitMixedReplicaTypes ShardSplitTest.testSplitWithChaosMonkey TestLatLonShapeQueries.testRandomBig TestRandomChains.testRandomChainsWithLargeStrings TestTriggerIntegration.testSearchRate Processing file (History bit 3): HOSS-2019-07-29.csv Processing file (History bit 2): HOSS-2019-07-08.csv Processing file (History bit 1): HOSS-2019-07-01.csv Processing file (History bit 0): HOSS-2019-06-24.csv Number of AwaitsFix: 38 Number of BadApples: 12 Raw fail count by week totals, most recent week first (corresponds to bits): Week: 0 had 47 failures Week: 1 had 142 failures Week: 2 had 123 failures Week: 3 had 152 failures **Annotated tests that didn't fail in the last 4 weeks. **Tests removed from the next two lists because they were specified in 'doNotEnable' in the properties file MoveReplicaHDFSTest.testNormalFailedMove **Annotations will be removed from the following tests because they haven't failed in the last 4 rollups. **Methods: 1 SolrZkClientTest.testSimpleUpdateACLs Failures in Hoss' reports for the last 4 rollups. There were 338 unannotated tests that failed in Hoss' rollups. Ordered by the date I downloaded the rollup file, newest->oldest. See above for the dates the files were collected These tests were NOT BadApple'd or AwaitsFix'd All tests that failed 4 weeks running will be BadApple'd unless there are objections Failures in the last 4 reports.. Report Pct runsfails test 0123 2.2 896 21 AliasIntegrationTest.testClusterStateProviderAPI 0123 52.2 1046183 BasicAuthIntegrationTest.testBasicAuth 0123 0.7 921 5 CollectionPropsTest.testReadWriteCached 0123 38.5 89 23 HdfsAutoAddReplicasIntegrationTest.testSimple 0123 0.7 928 10 HttpPartitionWithTlogReplicasTest.test 0123 0.8 858 31 LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud 0123 0.8 870 9 RollingRestartTest.test 0123 21.1
Register port 8983 with IANA?
Have we attempted to register Solr's default port with IANA before? https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml https://tools.ietf.org/html/rfc6335 Not that anyone cares, people choose ports freely anyway. But it's 8983 is pretty standardized so why not? -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-8935) BooleanQuery with no scoring clauses cannot skip documents when running TOP_SCORES mode
[ https://issues.apache.org/jira/browse/LUCENE-8935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Ferenczi resolved LUCENE-8935. -- Resolution: Fixed Fix Version/s: 8.3 master (9.0) > BooleanQuery with no scoring clauses cannot skip documents when running > TOP_SCORES mode > --- > > Key: LUCENE-8935 > URL: https://issues.apache.org/jira/browse/LUCENE-8935 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jim Ferenczi >Priority: Minor > Fix For: master (9.0), 8.3 > > Attachments: LUCENE-8935.patch > > > Today a boolean query that is composed of filtering clauses only (more than > one) cannot skip documents when the search is executed with the TOP_SCORES > mode. However since all documents have a score of 0 it should be possible to > early terminate the query as soon as we collected enough top hits. Wrapping > the resulting boolean scorer in a constant score scorer should allow early > termination in this case and would speed up the retrieval of top hits case > considerably if the total hit count is not requested. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8935) BooleanQuery with no scoring clauses cannot skip documents when running TOP_SCORES mode
[ https://issues.apache.org/jira/browse/LUCENE-8935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895050#comment-16895050 ] ASF subversion and git services commented on LUCENE-8935: - Commit c557e4323daaff43d041d0599b254d94f1b8d792 in lucene-solr's branch refs/heads/branch_8x from jimczi [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c557e43 ] LUCENE-8935: BooleanQuery with no scoring clause can now early terminate the query when the total hits is not requested. > BooleanQuery with no scoring clauses cannot skip documents when running > TOP_SCORES mode > --- > > Key: LUCENE-8935 > URL: https://issues.apache.org/jira/browse/LUCENE-8935 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jim Ferenczi >Priority: Minor > Attachments: LUCENE-8935.patch > > > Today a boolean query that is composed of filtering clauses only (more than > one) cannot skip documents when the search is executed with the TOP_SCORES > mode. However since all documents have a score of 0 it should be possible to > early terminate the query as soon as we collected enough top hits. Wrapping > the resulting boolean scorer in a constant score scorer should allow early > termination in this case and would speed up the retrieval of top hits case > considerably if the total hit count is not requested. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8935) BooleanQuery with no scoring clauses cannot skip documents when running TOP_SCORES mode
[ https://issues.apache.org/jira/browse/LUCENE-8935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895037#comment-16895037 ] ASF subversion and git services commented on LUCENE-8935: - Commit b8289abeebb23b10ea02b8a27d6b6c07deaa9e50 in lucene-solr's branch refs/heads/master from jimczi [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b8289ab ] LUCENE-8935: BooleanQuery with no scoring clause can now early terminate the query when the total hits is not requested. > BooleanQuery with no scoring clauses cannot skip documents when running > TOP_SCORES mode > --- > > Key: LUCENE-8935 > URL: https://issues.apache.org/jira/browse/LUCENE-8935 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jim Ferenczi >Priority: Minor > Attachments: LUCENE-8935.patch > > > Today a boolean query that is composed of filtering clauses only (more than > one) cannot skip documents when the search is executed with the TOP_SCORES > mode. However since all documents have a score of 0 it should be possible to > early terminate the query as soon as we collected enough top hits. Wrapping > the resulting boolean scorer in a constant score scorer should allow early > termination in this case and would speed up the retrieval of top hits case > considerably if the total hit count is not requested. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8764) Add "export all terms" feature to Luke
[ https://issues.apache.org/jira/browse/LUCENE-8764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895028#comment-16895028 ] Leonardo Menezes commented on LUCENE-8764: -- [~tomoko] Great :) My email is [m...@lmenezes.com|mailto:m...@lmenezes.com] And thank you again for looking into this. > Add "export all terms" feature to Luke > -- > > Key: LUCENE-8764 > URL: https://issues.apache.org/jira/browse/LUCENE-8764 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/luke >Reporter: Tomoko Uchida >Priority: Major > Labels: beginner > Attachments: LUCENE-8764.patch, LUCENE-8764.patch, LUCENE-8764.patch, > Screenshot 2019-07-23 12.29.06.png, Screenshot 2019-07-24 12.35.48.png, > Screenshot 2019-07-24 12.36.00.png, Screenshot 2019-07-24 12.36.27.png, > Screenshot 2019-07-25 13.20.40.png, Screenshot 2019-07-25 13.20.48.png, > Screenshot 2019-07-25 13.21.03.png, Screenshot 2019-07-25 13.25.23.png > > > This is a migrated issue from previous Luke project in GitHub: > [https://github.com/DmitryKey/luke/issues/3] (There are users' requests so I > moved this from GitHub to Jira) > You can browse terms in arbitrary field via Luke GUI, but in some cases > "exporting all terms (and optionally docids) to a file" feature would be > useful for further inspection. It might be similar to Solr's terms component. > As for the user interface, "Export terms" button should be located in > Overview tab and/or Documents tab. > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7889) Secure ZooKeeper should be easy and the default
[
https://issues.apache.org/jira/browse/SOLR-7889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895022#comment-16895022
]
Jan Høydahl commented on SOLR-7889:
---
ZK 3.5.5 adds secureClientPort, so i should already be possible to use SSL.
However, in ZK 3.6 there will be something called *port unification* which
allows to use the same port for both normal and encrypted traffic, and the
zkClient lib will adapt automatically just by telling it to use SSL. That will
provide for a better end user experience when migrating a non-ssl ZK ensemble
to a SSL one, since you can just upgrade zk and then flip clients to SSL one at
a time. Same will go for AdminServer.
But we should first document the current state, as it could take years for a
new ZK version to be released :)
> Secure ZooKeeper should be easy and the default
> ---
>
> Key: SOLR-7889
> URL: https://issues.apache.org/jira/browse/SOLR-7889
> Project: Solr
> Issue Type: Improvement
> Components: security
>Reporter: Jan Høydahl
>Priority: Critical
> Labels: security, zookeeper
>
> ZooKeeper security is documented at
> https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control but
> is not trivial to setup, see http://search-lucene.com/m/eHNlqr6EnMrP6O
> As we enable more and more security stuff, securing ZK should be easier to do
> and ideally the default. This is an umbrella for such improvements.
> When all of this is in place and working, perhaps even Solr should refuse to
> start if Auth/Autz plugins are in use and ZK communication is not properly
> protected, e.g. require {{bin/solr start --insecure}} to override.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8764) Add "export all terms" feature to Luke
[ https://issues.apache.org/jira/browse/LUCENE-8764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895006#comment-16895006 ] Tomoko Uchida commented on LUCENE-8764: --- [~lmenezes]: Would you tell me your e-mail address to credit your name with e-mail as the Author of this commit? (I cannot find it from JIRA.) > Add "export all terms" feature to Luke > -- > > Key: LUCENE-8764 > URL: https://issues.apache.org/jira/browse/LUCENE-8764 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/luke >Reporter: Tomoko Uchida >Priority: Major > Labels: beginner > Attachments: LUCENE-8764.patch, LUCENE-8764.patch, LUCENE-8764.patch, > Screenshot 2019-07-23 12.29.06.png, Screenshot 2019-07-24 12.35.48.png, > Screenshot 2019-07-24 12.36.00.png, Screenshot 2019-07-24 12.36.27.png, > Screenshot 2019-07-25 13.20.40.png, Screenshot 2019-07-25 13.20.48.png, > Screenshot 2019-07-25 13.21.03.png, Screenshot 2019-07-25 13.25.23.png > > > This is a migrated issue from previous Luke project in GitHub: > [https://github.com/DmitryKey/luke/issues/3] (There are users' requests so I > moved this from GitHub to Jira) > You can browse terms in arbitrary field via Luke GUI, but in some cases > "exporting all terms (and optionally docids) to a file" feature would be > useful for further inspection. It might be similar to Solr's terms component. > As for the user interface, "Export terms" button should be located in > Overview tab and/or Documents tab. > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8764) Add "export all terms" feature to Luke
[ https://issues.apache.org/jira/browse/LUCENE-8764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895000#comment-16895000 ] Tomoko Uchida commented on LUCENE-8764: --- I have looked into the code. +1 to the patch. I'd like to make a few small changes to the UI (e.g., adjust component size and add some texts about this feature), and commit it shortly. > Add "export all terms" feature to Luke > -- > > Key: LUCENE-8764 > URL: https://issues.apache.org/jira/browse/LUCENE-8764 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/luke >Reporter: Tomoko Uchida >Priority: Major > Labels: beginner > Attachments: LUCENE-8764.patch, LUCENE-8764.patch, LUCENE-8764.patch, > Screenshot 2019-07-23 12.29.06.png, Screenshot 2019-07-24 12.35.48.png, > Screenshot 2019-07-24 12.36.00.png, Screenshot 2019-07-24 12.36.27.png, > Screenshot 2019-07-25 13.20.40.png, Screenshot 2019-07-25 13.20.48.png, > Screenshot 2019-07-25 13.21.03.png, Screenshot 2019-07-25 13.25.23.png > > > This is a migrated issue from previous Luke project in GitHub: > [https://github.com/DmitryKey/luke/issues/3] (There are users' requests so I > moved this from GitHub to Jira) > You can browse terms in arbitrary field via Luke GUI, but in some cases > "exporting all terms (and optionally docids) to a file" feature would be > useful for further inspection. It might be similar to Solr's terms component. > As for the user interface, "Export terms" button should be located in > Overview tab and/or Documents tab. > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8929) Early Terminating CollectorManager
[ https://issues.apache.org/jira/browse/LUCENE-8929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Atri Sharma updated LUCENE-8929: Issue Type: Sub-task (was: Improvement) Parent: LUCENE-8940 > Early Terminating CollectorManager > -- > > Key: LUCENE-8929 > URL: https://issues.apache.org/jira/browse/LUCENE-8929 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Atri Sharma >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > We should have an early terminating collector manager which accurately tracks > hits across all of its collectors and determines when there are enough hits, > allowing all the collectors to abort. > The options for the same are: > 1) Shared total count : Global "scoreboard" where all collectors update their > current hit count. At the end of each document's collection, collector checks > if N > threshold, and aborts if true > 2) State Reporting Collectors: Collectors report their total number of counts > collected periodically using a callback mechanism, and get a proceed or abort > decision. > 1) has the overhead of synchronization in the hot path, 2) can collect > unnecessary hits before aborting. > I am planning to work on 2), unless objections -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8939) Shared Hit Count Early Termination
[ https://issues.apache.org/jira/browse/LUCENE-8939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Atri Sharma updated LUCENE-8939: Summary: Shared Hit Count Early Termination (was: Global Early Termination For Sorted Collections) > Shared Hit Count Early Termination > -- > > Key: LUCENE-8939 > URL: https://issues.apache.org/jira/browse/LUCENE-8939 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Atri Sharma >Priority: Major > > When collecting hits across sorted segments, it should be possible to > terminate early across all slices when enough hits have been collected > globally i.e. hit count > numHits AND hit count < totalHitsThreshold -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8940) Early Termination Across Slices
Atri Sharma created LUCENE-8940: --- Summary: Early Termination Across Slices Key: LUCENE-8940 URL: https://issues.apache.org/jira/browse/LUCENE-8940 Project: Lucene - Core Issue Type: Improvement Reporter: Atri Sharma This JIRA tracks efforts for global early termination when segments are sorted. The cases being chased are: 1) Sorted segments -- hit count > numHits but less than threshold 2) Sorted segments and sort key is non score -- use shared PQ 3) Sorted segments and sort key is score -- propagate global minimum score -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8939) Global Early Termination For Sorted Collections
[ https://issues.apache.org/jira/browse/LUCENE-8939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Atri Sharma updated LUCENE-8939: Issue Type: Sub-task (was: Improvement) Parent: LUCENE-8940 > Global Early Termination For Sorted Collections > --- > > Key: LUCENE-8939 > URL: https://issues.apache.org/jira/browse/LUCENE-8939 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Atri Sharma >Priority: Major > > When collecting hits across sorted segments, it should be possible to > terminate early across all slices when enough hits have been collected > globally i.e. hit count > numHits AND hit count < totalHitsThreshold -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8939) Global Early Termination For Sorted Collections
Atri Sharma created LUCENE-8939: --- Summary: Global Early Termination For Sorted Collections Key: LUCENE-8939 URL: https://issues.apache.org/jira/browse/LUCENE-8939 Project: Lucene - Core Issue Type: Improvement Reporter: Atri Sharma When collecting hits across sorted segments, it should be possible to terminate early across all slices when enough hits have been collected globally i.e. hit count > numHits AND hit count < totalHitsThreshold -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 3463 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3463/ 1 tests failed. FAILED: org.apache.solr.schema.TestCloudSchemaless.test Error Message: Error from server at http://127.0.0.1:36818/collection1: Error trying to proxy request for url: http://127.0.0.1:41728/collection1/update Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:36818/collection1: Error trying to proxy request for url: http://127.0.0.1:41728/collection1/update at __randomizedtesting.SeedInfo.seed([A7858CC93764E4D6:2FD1B3139998892E]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85) at org.apache.solr.schema.TestCloudSchemaless.test(TestCloudSchemaless.java:114) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk1.8.0_201) - Build # 937 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/937/ Java: 64bit/jdk1.8.0_201 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.CollectionPropsTest Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([17AD3A12A7A970E4]:0) FAILED: org.apache.solr.cloud.CollectionPropsTest.testReadWriteCached Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([17AD3A12A7A970E4]:0) Build Log: [...truncated 15904 lines...] [junit4] Suite: org.apache.solr.cloud.CollectionPropsTest [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.CollectionPropsTest_17AD3A12A7A970E4-001/init-core-data-001 [junit4] 2> 302027 WARN (SUITE-CollectionPropsTest-seed#[17AD3A12A7A970E4]-worker) [ ] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=2 numCloses=2 [junit4] 2> 302027 INFO (SUITE-CollectionPropsTest-seed#[17AD3A12A7A970E4]-worker) [ ] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) w/NUMERIC_DOCVALUES_SYSPROP=true [junit4] 2> 302028 INFO (SUITE-CollectionPropsTest-seed#[17AD3A12A7A970E4]-worker) [ ] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: @org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl=None) [junit4] 2> 302028 INFO (SUITE-CollectionPropsTest-seed#[17AD3A12A7A970E4]-worker) [ ] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom [junit4] 2> 302028 INFO (SUITE-CollectionPropsTest-seed#[17AD3A12A7A970E4]-worker) [ ] o.a.s.c.CollectionPropsTest Using legacyCloud?: false [junit4] 2> 302029 INFO (SUITE-CollectionPropsTest-seed#[17AD3A12A7A970E4]-worker) [ ] o.a.s.c.MiniSolrCloudCluster Starting cluster of 4 servers in /home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.CollectionPropsTest_17AD3A12A7A970E4-001/tempDir-001 [junit4] 2> 302029 INFO (SUITE-CollectionPropsTest-seed#[17AD3A12A7A970E4]-worker) [ ] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 302029 INFO (ZkTestServer Run Thread) [ ] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 302029 INFO (ZkTestServer Run Thread) [ ] o.a.s.c.ZkTestServer Starting server [junit4] 2> 302129 INFO (SUITE-CollectionPropsTest-seed#[17AD3A12A7A970E4]-worker) [ ] o.a.s.c.ZkTestServer start zk server on port:37445 [junit4] 2> 302129 INFO (SUITE-CollectionPropsTest-seed#[17AD3A12A7A970E4]-worker) [ ] o.a.s.c.ZkTestServer parse host and port list: 127.0.0.1:37445 [junit4] 2> 302129 INFO (SUITE-CollectionPropsTest-seed#[17AD3A12A7A970E4]-worker) [ ] o.a.s.c.ZkTestServer connecting to 127.0.0.1 37445 [junit4] 2> 302131 INFO (SUITE-CollectionPropsTest-seed#[17AD3A12A7A970E4]-worker) [ ] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 302133 INFO (zkConnectionManagerCallback-2054-thread-1) [ ] o.a.s.c.c.ConnectionManager zkClient has connected [junit4] 2> 302133 INFO (SUITE-CollectionPropsTest-seed#[17AD3A12A7A970E4]-worker) [ ] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 302136 INFO (SUITE-CollectionPropsTest-seed#[17AD3A12A7A970E4]-worker) [ ] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 302139 INFO (zkConnectionManagerCallback-2056-thread-1) [ ] o.a.s.c.c.ConnectionManager zkClient has connected [junit4] 2> 302139 INFO (SUITE-CollectionPropsTest-seed#[17AD3A12A7A970E4]-worker) [ ] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 302139 INFO (SUITE-CollectionPropsTest-seed#[17AD3A12A7A970E4]-worker) [ ] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 302141 INFO (zkConnectionManagerCallback-2058-thread-1) [ ] o.a.s.c.c.ConnectionManager zkClient has connected [junit4] 2> 302141 INFO (SUITE-CollectionPropsTest-seed#[17AD3A12A7A970E4]-worker) [ ] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 302244 WARN (jetty-launcher-2059-thread-4) [ ] o.e.j.s.AbstractConnector Ignoring deprecated socket close linger time [junit4] 2> 302244 WARN (jetty-launcher-2059-thread-3) [ ] o.e.j.s.AbstractConnector Ignoring deprecated socket close linger time [junit4] 2> 302244 WARN (jetty-launcher-2059-thread-2) [ ] o.e.j.s.AbstractConnector Ignoring deprecated socket close linger time [junit4] 2> 302244 WARN
