[JENKINS-EA] Lucene-Solr-BadApples-master-Linux (64bit/jdk-13-ea+shipilev-fastdebug) - Build # 222 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/222/ Java: 64bit/jdk-13-ea+shipilev-fastdebug -XX:+UseCompressedOops -XX:+UseParallelGC 10 tests failed. FAILED: org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica Error Message: Timeout occurred while waiting response from server at: https://127.0.0.1:33649/solr Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: https://127.0.0.1:33649/solr at __randomizedtesting.SeedInfo.seed([F8777208691A5CBD:926113D801E81677]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667) 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.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) 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.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:384) at org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:256) 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.randomizedtes
[jira] [Commented] (SOLR-13534) Dynamic loading of jars from a url
[
https://issues.apache.org/jira/browse/SOLR-13534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868283#comment-16868283
]
Noble Paul commented on SOLR-13534:
---
bq.Looks good to me; I think security was considered adequately.
The security aspect is not any worse than it already was.
bq.am I right that this "runtime lib" feature still is only limited to a small
subset of Solr defined interfaces and not yet any schema things that Lucene
defines
unfortunately, yes.
For jars loaded from remote urls , we can actually allow schema components to
be loaded from runtime lib because , unlike jars loaded from {{.system}}
collection, these are loaded when core is created
> Dynamic loading of jars from a url
> --
>
> Key: SOLR-13534
> URL: https://issues.apache.org/jira/browse/SOLR-13534
> Project: Solr
> Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Dynamic loading is possible from {{.system}} collection. It's much easier to
> host the jars on a remote service and load it from there. This way the user
> should have no problem in loading jars when the {{.system}} collection is not
> available for some reason.
> The steps should look as follows
> # get the hash of your jar file. {{openssl dgst -sha512 }}
> # upload it your hosting service . say the location is
> {{[http://host:port/my-jar/location|http://hostport/]}}
> # create a runtime lib entry for the collection as follows
> {code:java}
> curl http://localhost:8983/solr/techproducts/config -H
> 'Content-type:application/json' -d '{
>"add-runtimelib": { "name":"jarblobname",
> "sha512":"e94bb3990b39aacdabaa3eef7ca6102d96fa46766048da50269f25fd41164440a4e024d7a7fb0d5ec328cd8322bb65f5ba7886e076a8f224f78cb310fd45896d"
> , "url" : "http://host:port/my-jar/loaction"}
> }'
> {code}
> to update the jar, just repeat the steps and use the {{update-runtimelib}} to
> update the sha512 hash
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13534) Dynamic loading of jars from a url
[
https://issues.apache.org/jira/browse/SOLR-13534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul resolved SOLR-13534.
---
Resolution: Fixed
Fix Version/s: 8.2
> Dynamic loading of jars from a url
> --
>
> Key: SOLR-13534
> URL: https://issues.apache.org/jira/browse/SOLR-13534
> Project: Solr
> Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Dynamic loading is possible from {{.system}} collection. It's much easier to
> host the jars on a remote service and load it from there. This way the user
> should have no problem in loading jars when the {{.system}} collection is not
> available for some reason.
> The steps should look as follows
> # get the hash of your jar file. {{openssl dgst -sha512 }}
> # upload it your hosting service . say the location is
> {{[http://host:port/my-jar/location|http://hostport/]}}
> # create a runtime lib entry for the collection as follows
> {code:java}
> curl http://localhost:8983/solr/techproducts/config -H
> 'Content-type:application/json' -d '{
>"add-runtimelib": { "name":"jarblobname",
> "sha512":"e94bb3990b39aacdabaa3eef7ca6102d96fa46766048da50269f25fd41164440a4e024d7a7fb0d5ec328cd8322bb65f5ba7886e076a8f224f78cb310fd45896d"
> , "url" : "http://host:port/my-jar/loaction"}
> }'
> {code}
> to update the jar, just repeat the steps and use the {{update-runtimelib}} to
> update the sha512 hash
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-11.0.2) - Build # 8005 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/8005/ Java: 64bit/jdk-11.0.2 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.client.solrj.io.graph.GraphExpressionTest.testShortestPathStream Error Message: java.util.concurrent.ExecutionException: java.lang.RuntimeException: java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: params fq=predicate_s:knows&fl=from_s,to_s&qt=/export&sort=to_s+asc,from_s+asc&q=from_s:(bill)&distrib=false Stack Trace: java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.RuntimeException: java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: params fq=predicate_s:knows&fl=from_s,to_s&qt=/export&sort=to_s+asc,from_s+asc&q=from_s:(bill)&distrib=false at __randomizedtesting.SeedInfo.seed([67AEECEE2E8FC5C9:365B16324EC7F992]:0) at org.apache.solr.client.solrj.io.graph.ShortestPathStream.open(ShortestPathStream.java:365) at org.apache.solr.client.solrj.io.graph.GraphExpressionTest.getTuples(GraphExpressionTest.java:931) at org.apache.solr.client.solrj.io.graph.GraphExpressionTest.testShortestPathStream(GraphExpressionTest.java:172) 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 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(TestRuleIg
[JENKINS] Lucene-Solr-Tests-8.x - Build # 253 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/253/ All tests passed Build Log: [...truncated 64816 lines...] BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:634: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:101: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/build.xml:644: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:2093: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:2132: Compile failed; see the compiler error output for details. Total time: 111 minutes 8 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13532) Unable to start core recovery due to timeout in ping request
[
https://issues.apache.org/jira/browse/SOLR-13532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868245#comment-16868245
]
David Smiley commented on SOLR-13532:
-
Git blame shows [~caomanhdat] but it may predate him. WDYT Dat?
> Unable to start core recovery due to timeout in ping request
>
>
> Key: SOLR-13532
> URL: https://issues.apache.org/jira/browse/SOLR-13532
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 7.6
>Reporter: Suril Shah
>Priority: Major
>
> Discovered following issue with the core recovery:
> * Core recovery is not being initialized and throwing following exception
> message :
> {code:java}
> 2019-06-07 00:53:12.436 INFO
> (recoveryExecutor-4-thread-1-processing-n::8983_solr
> x:_shard41_replica_n2777 c: s:shard41
> r:core_node2778) x:_shard41_replica_n2777
> o.a.s.c.RecoveryStrategy Failed to connect leader http://:8983/solr
> on recovery, try again{code}
> * Above error occurs when ping request takes time more than a timeout period
> which is hard-coded to one second in solr source code. However In a general
> production setting it is common to have ping time more than one second,
> hence, the core recovery never starts and exception is thrown.
> * Also the other major concern is that this exception is logged as an info
> message, hence it is very difficult to identify the error if info logging is
> not enabled.
> * Please refer to following code snippet from the [source
> code|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L789-L803]
> to understand the above issue.
> {code:java}
> try (HttpSolrClient httpSolrClient = new
> HttpSolrClient.Builder(leaderReplica.getCoreUrl())
> .withSocketTimeout(1000)
> .withConnectionTimeout(1000)
>
> .withHttpClient(cc.getUpdateShardHandler().getRecoveryOnlyHttpClient())
> .build()) {
> SolrPingResponse resp = httpSolrClient.ping();
> return leaderReplica;
> } catch (IOException e) {
> log.info("Failed to connect leader {} on recovery, try again",
> leaderReplica.getBaseUrl());
> Thread.sleep(500);
> } catch (Exception e) {
> if (e.getCause() instanceof IOException) {
> log.info("Failed to connect leader {} on recovery, try again",
> leaderReplica.getBaseUrl());
> Thread.sleep(500);
> } else {
> return leaderReplica;
> }
> }
> {code}
> The above issue will have high impact in production level clusters, since
> cores not being able to recover may lead to data loss.
> Following improvements would be really helpful:
> 1. The [timeout for ping
> request|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L790-L791]
> in *RecoveryStrategy.java* should be configurable and the defaults set to
> high values like 15seconds.
> 2. The exception message in [line
> 797|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L797]
> and [line
> 801|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L801]
> in *RecoveryStrategy.java* should be logged as *error* messages instead of
> *info* messages
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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 # 734 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/734/ Java: 32bit/jdk1.8.0_201 -client -XX:+UseParallelGC All tests passed Build Log: [...truncated 63038 lines...] BUILD FAILED /home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:634: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:101: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/build.xml:644: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/common-build.xml:2093: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/common-build.xml:2132: Compile failed; see the compiler error output for details. Total time: 124 minutes 11 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13534) Dynamic loading of jars from a url
[
https://issues.apache.org/jira/browse/SOLR-13534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868231#comment-16868231
]
David Smiley commented on SOLR-13534:
-
Any reason this isn't marked Resolved yet?
> Dynamic loading of jars from a url
> --
>
> Key: SOLR-13534
> URL: https://issues.apache.org/jira/browse/SOLR-13534
> Project: Solr
> Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Dynamic loading is possible from {{.system}} collection. It's much easier to
> host the jars on a remote service and load it from there. This way the user
> should have no problem in loading jars when the {{.system}} collection is not
> available for some reason.
> The steps should look as follows
> # get the hash of your jar file. {{openssl dgst -sha512 }}
> # upload it your hosting service . say the location is
> {{[http://host:port/my-jar/location|http://hostport/]}}
> # create a runtime lib entry for the collection as follows
> {code:java}
> curl http://localhost:8983/solr/techproducts/config -H
> 'Content-type:application/json' -d '{
>"add-runtimelib": { "name":"jarblobname",
> "sha512":"e94bb3990b39aacdabaa3eef7ca6102d96fa46766048da50269f25fd41164440a4e024d7a7fb0d5ec328cd8322bb65f5ba7886e076a8f224f78cb310fd45896d"
> , "url" : "http://host:port/my-jar/loaction"}
> }'
> {code}
> to update the jar, just repeat the steps and use the {{update-runtimelib}} to
> update the sha512 hash
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13534) Dynamic loading of jars from a url
[
https://issues.apache.org/jira/browse/SOLR-13534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868228#comment-16868228
]
David Smiley commented on SOLR-13534:
-
Looks good to me; I think security was considered adequately.
[~noble.paul] am I right that this "runtime lib" feature _still_ is only
limited to a small subset of Solr defined interfaces and not yet any schema
things that Lucene defines (e.g. Tokenizers)? If yes: Yet the second
paragraph of the ref guide on this has examples involving two such things that
don't work... and we don't tell the user what does and doesn't work.
> Dynamic loading of jars from a url
> --
>
> Key: SOLR-13534
> URL: https://issues.apache.org/jira/browse/SOLR-13534
> Project: Solr
> Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Dynamic loading is possible from {{.system}} collection. It's much easier to
> host the jars on a remote service and load it from there. This way the user
> should have no problem in loading jars when the {{.system}} collection is not
> available for some reason.
> The steps should look as follows
> # get the hash of your jar file. {{openssl dgst -sha512 }}
> # upload it your hosting service . say the location is
> {{[http://host:port/my-jar/location|http://hostport/]}}
> # create a runtime lib entry for the collection as follows
> {code:java}
> curl http://localhost:8983/solr/techproducts/config -H
> 'Content-type:application/json' -d '{
>"add-runtimelib": { "name":"jarblobname",
> "sha512":"e94bb3990b39aacdabaa3eef7ca6102d96fa46766048da50269f25fd41164440a4e024d7a7fb0d5ec328cd8322bb65f5ba7886e076a8f224f78cb310fd45896d"
> , "url" : "http://host:port/my-jar/loaction"}
> }'
> {code}
> to update the jar, just repeat the steps and use the {{update-runtimelib}} to
> update the sha512 hash
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8859) Add an option to load the completion suggester's FST off-heap
[ https://issues.apache.org/jira/browse/LUCENE-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868213#comment-16868213 ] David Smiley commented on LUCENE-8859: -- +1 Nice > Add an option to load the completion suggester's FST off-heap > - > > Key: LUCENE-8859 > URL: https://issues.apache.org/jira/browse/LUCENE-8859 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jim Ferenczi >Priority: Minor > Attachments: LUCENE-8859.patch > > > Now that FSTs can be loaded off-heap > (https://issues.apache.org/jira/browse/LUCENE-8635) it would be nice to > expose this option in the completion suggester postings format. I didn't ran > any benchmark yet so I can't say it this really makes sense or not but I > wanted to get some opinion whether this could be a good trade-off. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-Solaris (64bit/jdk1.8.0) - Build # 189 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Solaris/189/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 64792 lines...] BUILD FAILED /export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/build.xml:634: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/build.xml:101: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/build.xml:644: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/lucene/common-build.xml:2093: The following error occurred while executing this line: /export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/lucene/common-build.xml:2132: Compile failed; see the compiler error output for details. Total time: 122 minutes 9 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13523) Atomic Update results in NullPointerException
[
https://issues.apache.org/jira/browse/SOLR-13523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868190#comment-16868190
]
Lucene/Solr QA commented on SOLR-13523:
---
| (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 3 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
1s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 57s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 50m 32s{color}
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 57m 25s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.DeleteShardTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13523 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12972259/SOLR-13523.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.4.0-137-generic #163~14.04.1-Ubuntu SMP Mon
Sep 24 17:14:57 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 / 0aa6b11 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | LTS |
| unit |
https://builds.apache.org/job/PreCommit-SOLR-Build/446/artifact/out/patch-unit-solr_core.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/446/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/446/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Atomic Update results in NullPointerException
> -
>
> Key: SOLR-13523
> URL: https://issues.apache.org/jira/browse/SOLR-13523
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 8.1
> Environment: * Operating system: Win10 v1803 build 17143.766
> * Java version:
> java 11.0.1 2018-10-16 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)
> * solr-spec: 8.1.1
> * solr-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:20:01
> * lucene-spec: 8.1.1
> * lucene-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:15:24
>Reporter: Kieran Devlin
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-13523.patch, SOLR-13523.patch, SOLR-13523.patch,
> SOLR-13523_WIP_bug_hunt.patch, XUBrk.png, Xn1RW.png, reproduce.sh
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Partially update a document via an atomic update, when I do so, the web sever
> responds with a 500 status with the stack trace:
> {code:java}
> { "responseHeader":{ "status":500, "QTime":1}, "error":{
> "trace":"java.lang.NullPointerException\r\n\tat
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.getFieldFromHierarchy(AtomicUpdateDocumentMerger.java:301)\r\n\tat
>
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDoc(AtomicUpdateDocumentMerger.java:398)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:697)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:372)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:
[JENKINS] Lucene-Solr-Tests-master - Build # 3393 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3393/ 1 tests failed. FAILED: org.apache.solr.cloud.cdcr.CdcrBootstrapTest.testConvertClusterToCdcrAndBootstrap Error Message: Error from server at https://127.0.0.1:46420/solr: Underlying core creation failed while creating collection: cdcr-target Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:46420/solr: Underlying core creation failed while creating collection: cdcr-target at __randomizedtesting.SeedInfo.seed([5E88D82C205F0A46:895FF75B94009201]: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.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) 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.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.cdcr.CdcrBootstrapTest.testConvertClusterToCdcrAndBootstrap(CdcrBootstrapTest.java:113) 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 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.S
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-13-ea+shipilev-fastdebug) - Build # 24256 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24256/ Java: 64bit/jdk-13-ea+shipilev-fastdebug -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 5 tests failed. FAILED: org.apache.solr.cloud.autoscaling.TestPolicyCloud.testCreateCollectionAddReplica Error Message: Timeout occurred while waiting response from server at: https://127.0.0.1:42529/solr Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: https://127.0.0.1:42529/solr at __randomizedtesting.SeedInfo.seed([5531CCA1E2839C3:857379E40F6BD165]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667) 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.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) 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.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:547) at org.apache.solr.cloud.autoscaling.TestPolicyCloud.after(TestPolicyCloud.java:87) 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$10.evaluate(RandomizedRunner.java:996) at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239) 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.evalu
[jira] [Updated] (SOLR-10291) Add matches Stream Evaluator to support regex matching
[ https://issues.apache.org/jira/browse/SOLR-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-10291: -- Summary: Add matches Stream Evaluator to support regex matching (was: Add match Stream Evaluator to support regex matching) > Add matches Stream Evaluator to support regex matching > -- > > Key: SOLR-10291 > URL: https://issues.apache.org/jira/browse/SOLR-10291 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Fix For: 8.2 > > Attachments: SOLR-10291.patch > > > It would be good to be able to match any regex as part of a having expression > etc... > Lucene/Solr does support regex queries but the match Evaluator would match > against un-analyzed blocks of texts, so it would eliminate any confusion > about what terms it was actually matching against. > This would support use cases like alerting on sensitive content that appear > in documents such as SSN and credit card numbers. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10291) Add match Stream Evaluator to support regex matching
[ https://issues.apache.org/jira/browse/SOLR-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein resolved SOLR-10291. --- Resolution: Resolved Fix Version/s: 8.2 > Add match Stream Evaluator to support regex matching > > > Key: SOLR-10291 > URL: https://issues.apache.org/jira/browse/SOLR-10291 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Fix For: 8.2 > > Attachments: SOLR-10291.patch > > > It would be good to be able to match any regex as part of a having expression > etc... > Lucene/Solr does support regex queries but the match Evaluator would match > against un-analyzed blocks of texts, so it would eliminate any confusion > about what terms it was actually matching against. > This would support use cases like alerting on sensitive content that appear > in documents such as SSN and credit card numbers. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10291) Add match Stream Evaluator to support regex matching
[ https://issues.apache.org/jira/browse/SOLR-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868151#comment-16868151 ] ASF subversion and git services commented on SOLR-10291: Commit 0aa6b11ae28d44469715c11a7cd427f0d1386af4 in lucene-solr's branch refs/heads/master from Joel Bernstein [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0aa6b11 ] SOLR-10291: Updates CHANGES.txt > Add match Stream Evaluator to support regex matching > > > Key: SOLR-10291 > URL: https://issues.apache.org/jira/browse/SOLR-10291 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Attachments: SOLR-10291.patch > > > It would be good to be able to match any regex as part of a having expression > etc... > Lucene/Solr does support regex queries but the match Evaluator would match > against un-analyzed blocks of texts, so it would eliminate any confusion > about what terms it was actually matching against. > This would support use cases like alerting on sensitive content that appear > in documents such as SSN and credit card numbers. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10291) Add match Stream Evaluator to support regex matching
[ https://issues.apache.org/jira/browse/SOLR-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868152#comment-16868152 ] ASF subversion and git services commented on SOLR-10291: Commit 1c27c473558e81bf14a1392d9da6ebd7a2f961e1 in lucene-solr's branch refs/heads/branch_8x from Joel Bernstein [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1c27c47 ] SOLR-10291: Updates CHANGES.txt > Add match Stream Evaluator to support regex matching > > > Key: SOLR-10291 > URL: https://issues.apache.org/jira/browse/SOLR-10291 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Attachments: SOLR-10291.patch > > > It would be good to be able to match any regex as part of a having expression > etc... > Lucene/Solr does support regex queries but the match Evaluator would match > against un-analyzed blocks of texts, so it would eliminate any confusion > about what terms it was actually matching against. > This would support use cases like alerting on sensitive content that appear > in documents such as SSN and credit card numbers. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta commented on a change in pull request #722: LUCENE-8863: enable loading external Kuromoji dictionary
mocobeta commented on a change in pull request #722: LUCENE-8863: enable
loading external Kuromoji dictionary
URL: https://github.com/apache/lucene-solr/pull/722#discussion_r295577419
##
File path:
lucene/analysis/kuromoji/src/java/org/apache/lucene/analysis/ja/dict/BinaryDictionary.java
##
@@ -46,13 +50,31 @@
public static final String POSDICT_HEADER = "kuromoji_dict_pos";
public static final int VERSION = 1;
+ static final String CLASSPATH = "classpath:";
+ static final String FILE = "file:";
+
+ private final String resourcePrefix;
private final ByteBuffer buffer;
private final int[] targetMapOffsets, targetMap;
private final String[] posDict;
private final String[] inflTypeDict;
private final String[] inflFormDict;
protected BinaryDictionary() throws IOException {
+this(CLASSPATH);
+ }
+
+ /**
+ * @param resourcePrefix - where to load resources (dictionaries) from.
Either "file:", followed
+ * by a filesystem directory and optionally a filename-prefix, or
"classpath:", followed by a
+ * classpath location prefix, or just plain "classpath:" to use this class's
name as the prefix.
+ */
+ protected BinaryDictionary(String resourcePrefix) throws IOException {
Review comment:
I missed the tests. OK, thanks!
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-MacOSX (64bit/jdk1.8.0) - Build # 195 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/195/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 64787 lines...] BUILD FAILED /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/build.xml:634: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/build.xml:101: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/build.xml:644: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/common-build.xml:2093: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/common-build.xml:2132: Compile failed; see the compiler error output for details. Total time: 142 minutes 31 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Audit logging API?
in the security documentation here:
https://lucene.apache.org/solr/guide/8_1/authentication-and-authorization-plugins.html#in-standalone-mode
we give the following advice:
Once security.json has been uploaded to ZooKeeper, you should use the
appropriate APIs for the plugins you’re using to update it. You can edit it
manually, but you must take care to remove any version data so it will be
properly updated across all ZooKeeper nodes. The version data is found at
the end of the security.json file, and will appear as the letter "v"
followed by a number, such as {"v":138}.
However, I don't see any API mentioned in
https://lucene.apache.org/solr/guide/8_1/audit-logging.html ? Is this
planned for the future?
Also I sort of wonder why security.json is keeping it's own version in the
json rather than relying on zookeeper's node versions like everything else?
What problem do we have there that we don't have in the rest of our json
files?
-Gus
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
[jira] [Commented] (SOLR-10291) Add match Stream Evaluator to support regex matching
[ https://issues.apache.org/jira/browse/SOLR-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868118#comment-16868118 ] ASF subversion and git services commented on SOLR-10291: Commit f5a39b5d081dbfd2d9f8e92a3824a7c53a185eab in lucene-solr's branch refs/heads/branch_8x from Joel Bernstein [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f5a39b5 ] SOLR-10291: Add match Stream Evaluator to support regex matching > Add match Stream Evaluator to support regex matching > > > Key: SOLR-10291 > URL: https://issues.apache.org/jira/browse/SOLR-10291 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Attachments: SOLR-10291.patch > > > It would be good to be able to match any regex as part of a having expression > etc... > Lucene/Solr does support regex queries but the match Evaluator would match > against un-analyzed blocks of texts, so it would eliminate any confusion > about what terms it was actually matching against. > This would support use cases like alerting on sensitive content that appear > in documents such as SSN and credit card numbers. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10291) Add match Stream Evaluator to support regex matching
[ https://issues.apache.org/jira/browse/SOLR-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-10291: -- Summary: Add match Stream Evaluator to support regex matching (was: Add match Boolean Stream Evaluator to support regex matching) > Add match Stream Evaluator to support regex matching > > > Key: SOLR-10291 > URL: https://issues.apache.org/jira/browse/SOLR-10291 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Attachments: SOLR-10291.patch > > > It would be good to be able to match any regex as part of a having expression > etc... > Lucene/Solr does support regex queries but the match Evaluator would match > against un-analyzed blocks of texts, so it would eliminate any confusion > about what terms it was actually matching against. > This would support use cases like alerting on sensitive content that appear > in documents such as SSN and credit card numbers. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10291) Add match Stream Evaluator to support regex matching
[ https://issues.apache.org/jira/browse/SOLR-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868115#comment-16868115 ] ASF subversion and git services commented on SOLR-10291: Commit e88366c9b621cef7d5ffe886a35c2a50992c38f2 in lucene-solr's branch refs/heads/master from Joel Bernstein [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e88366c ] SOLR-10291: Add match Stream Evaluator to support regex matching > Add match Stream Evaluator to support regex matching > > > Key: SOLR-10291 > URL: https://issues.apache.org/jira/browse/SOLR-10291 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Attachments: SOLR-10291.patch > > > It would be good to be able to match any regex as part of a having expression > etc... > Lucene/Solr does support regex queries but the match Evaluator would match > against un-analyzed blocks of texts, so it would eliminate any confusion > about what terms it was actually matching against. > This would support use cases like alerting on sensitive content that appear > in documents such as SSN and credit card numbers. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-8.x - Build # 252 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/252/ 1 tests failed. FAILED: org.apache.lucene.search.TestRegexpRandom2.testRegexps Error Message: Hit 2 docnumbers don't match Hits length1=23 length2=23 hit=0: doc24=1.0 shardIndex=0, doc24=1.0 shardIndex=0 hit=1: doc54=1.0 shardIndex=0, doc54=1.0 shardIndex=0 hit=2: doc135=1.0 shardIndex=0, doc168=1.0 shardIndex=0 hit=3: doc138=1.0 shardIndex=0, doc179=1.0 shardIndex=0 hit=4: doc168=1.0 shardIndex=0, doc202=1.0 shardIndex=0 hit=5: doc179=1.0 shardIndex=0, doc204=1.0 shardIndex=0 hit=6: doc202=1.0 shardIndex=0, doc242=1.0 shardIndex=0 hit=7: doc204=1.0 shardIndex=0, doc305=1.0 shardIndex=0 hit=8: doc242=1.0 shardIndex=0, doc308=1.0 shardIndex=0 hit=9: doc305=1.0 shardIndex=0, doc315=1.0 shardIndex=0 hit=10: doc308=1.0 shardIndex=0, doc332=1.0 shardIndex=0 hit=11: doc315=1.0 shardIndex=0, doc356=1.0 shardIndex=0 hit=12: doc332=1.0 shardIndex=0, doc362=1.0 shardIndex=0 hit=13: doc356=1.0 shardIndex=0, doc373=1.0 shardIndex=0 hit=14: doc362=1.0 shardIndex=0, doc384=1.0 shardIndex=0 hit=15: doc373=1.0 shardIndex=0, doc397=1.0 shardIndex=0 hit=16: doc384=1.0 shardIndex=0, doc432=1.0 shardIndex=0 hit=17: doc397=1.0 shardIndex=0, doc505=1.0 shardIndex=0 hit=18: doc432=1.0 shardIndex=0, doc508=1.0 shardIndex=0 hit=19: doc505=1.0 shardIndex=0, doc509=1.0 shardIndex=0 hit=20: doc508=1.0 shardIndex=0, doc510=1.0 shardIndex=0 hit=21: doc509=1.0 shardIndex=0, doc135=1.0 shardIndex=1 hit=22: doc510=1.0 shardIndex=0, doc138=1.0 shardIndex=1 for query:field:/-*../ Stack Trace: junit.framework.AssertionFailedError: Hit 2 docnumbers don't match Hits length1=23 length2=23 hit=0: doc24=1.0 shardIndex=0, doc24=1.0 shardIndex=0 hit=1: doc54=1.0 shardIndex=0, doc54=1.0 shardIndex=0 hit=2: doc135=1.0 shardIndex=0, doc168=1.0 shardIndex=0 hit=3: doc138=1.0 shardIndex=0, doc179=1.0 shardIndex=0 hit=4: doc168=1.0 shardIndex=0, doc202=1.0 shardIndex=0 hit=5: doc179=1.0 shardIndex=0, doc204=1.0 shardIndex=0 hit=6: doc202=1.0 shardIndex=0, doc242=1.0 shardIndex=0 hit=7: doc204=1.0 shardIndex=0, doc305=1.0 shardIndex=0 hit=8: doc242=1.0 shardIndex=0, doc308=1.0 shardIndex=0 hit=9: doc305=1.0 shardIndex=0, doc315=1.0 shardIndex=0 hit=10: doc308=1.0 shardIndex=0, doc332=1.0 shardIndex=0 hit=11: doc315=1.0 shardIndex=0, doc356=1.0 shardIndex=0 hit=12: doc332=1.0 shardIndex=0, doc362=1.0 shardIndex=0 hit=13: doc356=1.0 shardIndex=0, doc373=1.0 shardIndex=0 hit=14: doc362=1.0 shardIndex=0, doc384=1.0 shardIndex=0 hit=15: doc373=1.0 shardIndex=0, doc397=1.0 shardIndex=0 hit=16: doc384=1.0 shardIndex=0, doc432=1.0 shardIndex=0 hit=17: doc397=1.0 shardIndex=0, doc505=1.0 shardIndex=0 hit=18: doc432=1.0 shardIndex=0, doc508=1.0 shardIndex=0 hit=19: doc505=1.0 shardIndex=0, doc509=1.0 shardIndex=0 hit=20: doc508=1.0 shardIndex=0, doc510=1.0 shardIndex=0 hit=21: doc509=1.0 shardIndex=0, doc135=1.0 shardIndex=1 hit=22: doc510=1.0 shardIndex=0, doc138=1.0 shardIndex=1 for query:field:/-*../ at __randomizedtesting.SeedInfo.seed([DEB25242564B2AA0:3FEE135388E17D28]:0) at junit.framework.Assert.fail(Assert.java:57) at org.apache.lucene.search.CheckHits.checkEqual(CheckHits.java:205) at org.apache.lucene.search.TestRegexpRandom2.assertSame(TestRegexpRandom2.java:178) at org.apache.lucene.search.TestRegexpRandom2.testRegexps(TestRegexpRandom2.java:164) 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 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.ja
[jira] [Updated] (SOLR-10291) Add match Boolean Stream Evaluator to support regex matching
[ https://issues.apache.org/jira/browse/SOLR-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-10291: -- Attachment: SOLR-10291.patch > Add match Boolean Stream Evaluator to support regex matching > > > Key: SOLR-10291 > URL: https://issues.apache.org/jira/browse/SOLR-10291 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Attachments: SOLR-10291.patch > > > It would be good to be able to match any regex as part of a having expression > etc... > Lucene/Solr does support regex queries but the match Evaluator would match > against un-analyzed blocks of texts, so it would eliminate any confusion > about what terms it was actually matching against. > This would support use cases like alerting on sensitive content that appear > in documents such as SSN and credit card numbers. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Need to upgrade jenkins jdk-11 jobs >= 11.0.3 to fix JVM SSL bugs
Java 11.0.3 is much better on my machine. Earlier today I was using 11.0.1 and getting sporadic SSL errors on all my runs -- very frustrating. I don't have that problem since using 11.0.3. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Tue, Jun 18, 2019 at 5:45 PM Chris Hostetter wrote: > > TL;DR: Uwe: can you please upgrade the jdk-11 used on the apache lucene > jenkis jobs and your policeman jenkins jobs to 11.0.3 ? > > --- > > Dat & I have (coincidently) found ourselves both looking into some (long > standing) SSL weirdness that has only ever manifested on java>=11. > > Details can be found in SOLR-12988 & SOLR-12990 but the long and short of > it is there are at least 2 known OpenJDK bugs in SSL that have been > fixed in 11.0.3, which we are seeing evidence of in jenkins builds using > 11.0.2 > > https://bugs.openjdk.java.net/browse/JDK-8213202 > https://bugs.openjdk.java.net/browse/JDK-8212885 / JDK-8220723 > > (The nature of these bugs makes it hard -- at least AFAICT -- to try to > write any "assume" logic to auto-detect if they apply to the current JVM.) > > There may in fact still be other SSL related bugs in jdk 11.0.3, but it > will be hard to know until we at least upgrade to 11.0.3 to see what still > fails. > > Uwe / whomever has access: if you could help us out here it would be > appreciated. > > > > -Hoss > http://www.lucidworks.com/ > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Updated] (SOLR-13523) Atomic Update results in NullPointerException
[
https://issues.apache.org/jira/browse/SOLR-13523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-13523:
Affects Version/s: (was: 8.0)
8.1
> Atomic Update results in NullPointerException
> -
>
> Key: SOLR-13523
> URL: https://issues.apache.org/jira/browse/SOLR-13523
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 8.1
> Environment: * Operating system: Win10 v1803 build 17143.766
> * Java version:
> java 11.0.1 2018-10-16 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)
> * solr-spec: 8.1.1
> * solr-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:20:01
> * lucene-spec: 8.1.1
> * lucene-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:15:24
>Reporter: Kieran Devlin
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-13523.patch, SOLR-13523.patch, SOLR-13523.patch,
> SOLR-13523_WIP_bug_hunt.patch, XUBrk.png, Xn1RW.png, reproduce.sh
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Partially update a document via an atomic update, when I do so, the web sever
> responds with a 500 status with the stack trace:
> {code:java}
> { "responseHeader":{ "status":500, "QTime":1}, "error":{
> "trace":"java.lang.NullPointerException\r\n\tat
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.getFieldFromHierarchy(AtomicUpdateDocumentMerger.java:301)\r\n\tat
>
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDoc(AtomicUpdateDocumentMerger.java:398)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:697)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:372)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:337)\r\n\tat
>
> org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:337)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:223)\r\n\tat
>
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:475)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldNameMutatingUpdateProcessorFactory$1.processAdd(FieldNameMutatingUpdateProcessorFactory.java:75)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.AbstractDefaultValueUpdateProcessorFactory$DefaultValueUpdateProcessor.processAdd(AbstractDefaultValueUpdateProcessorFactory.java:92)\r\n\tat
>
> org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleAdds(JsonLoader.java:507)\r\n\tat
>
> org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:145)\r\n
[jira] [Updated] (SOLR-13523) Atomic Update results in NullPointerException
[
https://issues.apache.org/jira/browse/SOLR-13523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-13523:
Attachment: SOLR-13523.patch
Status: Patch Available (was: Patch Available)
Ugh; here's an updated patch. I finally ran the whole test suite and caught
two more issues:
* TestChildDocTransformer specifically wants to test with a root field but NOT
a nest path field. So I added a schema-root.xml for this case using a fairly
minimal schema, and tweaked the test where it assumed certain fields from the
default schema were multivalued and they are not here (wasn't fundamental to
the test).
* AtomicUpdateProcessorFactoryTest.testMultipleThreads: This test provokes
this assertion to fail:
https://github.com/apache/lucene-solr/blob/f26388d034fe5eadca7416aa63b509b8db2c7688/solr/core/src/java/org/apache/solr/update/processor/DistributedUpdateProcessor.java#L488.
I'm not so sure about that assertion. I commented it out in this patch.
[~moshebla] I really want to hear your input on this. I'm also rather
concerned about the potential for serious performance degradation on indexing
introduced by the caller of this method which will call
ulog.openRealtimeSearcher. This is new in 8.1 and only activated when
"isUsableForChildDocs" (i.e. merely has a root) and if the incoming doc has a
nested doc. Granted this is a separate issue we could discuss on SOLR-12638
which added it.
> Atomic Update results in NullPointerException
> -
>
> Key: SOLR-13523
> URL: https://issues.apache.org/jira/browse/SOLR-13523
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 8.0
> Environment: * Operating system: Win10 v1803 build 17143.766
> * Java version:
> java 11.0.1 2018-10-16 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)
> * solr-spec: 8.1.1
> * solr-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:20:01
> * lucene-spec: 8.1.1
> * lucene-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:15:24
>Reporter: Kieran Devlin
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-13523.patch, SOLR-13523.patch, SOLR-13523.patch,
> SOLR-13523_WIP_bug_hunt.patch, XUBrk.png, Xn1RW.png, reproduce.sh
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Partially update a document via an atomic update, when I do so, the web sever
> responds with a 500 status with the stack trace:
> {code:java}
> { "responseHeader":{ "status":500, "QTime":1}, "error":{
> "trace":"java.lang.NullPointerException\r\n\tat
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.getFieldFromHierarchy(AtomicUpdateDocumentMerger.java:301)\r\n\tat
>
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDoc(AtomicUpdateDocumentMerger.java:398)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:697)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:372)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:337)\r\n\tat
>
> org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:337)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:223)\r\n\tat
>
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:475)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
[JENKINS] Lucene-Solr-repro-Java11 - Build # 160 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro-Java11/160/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1875/consoleText [repro] Revision: 8a35088947321681b8850d2908a4d9bc83d960f6 [repro] Ant options: -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt [repro] Repro line: ant test -Dtestcase=RollingRestartTest -Dtests.method=test -Dtests.seed=F5493AEDEFCC5BC6 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.locale=sq-MK -Dtests.timezone=Asia/Dushanbe -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: e3752e87d005d407108f95e72b14c82d60f1c082 [repro] git fetch [repro] git checkout 8a35088947321681b8850d2908a4d9bc83d960f6 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] RollingRestartTest [repro] ant compile-test [...truncated 3311 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.RollingRestartTest" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.seed=F5493AEDEFCC5BC6 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.locale=sq-MK -Dtests.timezone=Asia/Dushanbe -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 906065 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 1/5 failed: org.apache.solr.cloud.RollingRestartTest [repro] git checkout e3752e87d005d407108f95e72b14c82d60f1c082 [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 5 lines...] - 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 (64bit/jdk-12) - Build # 733 - Still unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/733/ Java: 64bit/jdk-12 -XX:-UseCompressedOops -XX:+UseSerialGC 6 tests failed. FAILED: org.apache.solr.cloud.autoscaling.TestPolicyCloud.testCreateCollectionSplitShard Error Message: Timeout occurred while waiting response from server at: https://127.0.0.1:37319/solr Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: https://127.0.0.1:37319/solr at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667) 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.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) 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.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.autoscaling.TestPolicyCloud.testCreateCollectionSplitShard(TestPolicyCloud.java:246) 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 org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239) 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.e
[JENKINS] Lucene-Solr-Tests-master - Build # 3392 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3392/
All tests passed
Build Log:
[...truncated 64916 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1696750156
[ecj-lint] Compiling 69 source files to /tmp/ecj1696750156
[ecj-lint] invalid Class-Path header in manifest of jar file:
/x1/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:
/x1/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
[ecj-lint] --
[ecj-lint] 1. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 28)
[ecj-lint] import javax.naming.InitialContext;
[ecj-lint]^^^
[ecj-lint] The type javax.naming.InitialContext is not accessible
[ecj-lint] --
[ecj-lint] 2. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 29)
[ecj-lint] import javax.naming.NamingException;
[ecj-lint]
[ecj-lint] The type javax.naming.NamingException is not accessible
[ecj-lint] --
[ecj-lint] 3. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 182)
[ecj-lint] c = getFromJndi(initProps, jndiName);
[ecj-lint] ^^^
[ecj-lint] The method getFromJndi(Properties, String) from the type new
Callable(){} refers to the missing type NamingException
[ecj-lint] --
[ecj-lint] 4. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 245)
[ecj-lint] private Connection getFromJndi(final Properties initProps,
final String jndiName) throws NamingException,
[ecj-lint]
^^^
[ecj-lint] NamingException cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 5. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 249)
[ecj-lint] InitialContext ctx = new InitialContext();
[ecj-lint] ^^
[ecj-lint] InitialContext cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 6. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 249)
[ecj-lint] InitialContext ctx = new InitialContext();
[ecj-lint] ^^
[ecj-lint] InitialContext cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 6 problems (6 errors)
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:634: The
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:101: The
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/build.xml:651:
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/common-build.xml:479:
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:2009:
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:2048:
Compile failed; see the compiler error output for details.
Total time: 121 minutes 20 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] msokolov commented on issue #731: LUCENE-8865: Move to executor in IndexSearcher
msokolov commented on issue #731: LUCENE-8865: Move to executor in IndexSearcher URL: https://github.com/apache/lucene-solr/pull/731#issuecomment-503751011 +1 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13523) Atomic Update results in NullPointerException
[
https://issues.apache.org/jira/browse/SOLR-13523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867992#comment-16867992
]
Lucene/Solr QA commented on SOLR-13523:
---
| (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 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
7s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 4m 29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 4m 29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 4m 29s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 91m 58s{color}
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}105m 44s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.update.processor.AtomicUpdateProcessorFactoryTest |
| | solr.response.transform.TestChildDocTransformer |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13523 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12972228/SOLR-13523.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 / 9dab797 |
| 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/445/artifact/out/patch-unit-solr_core.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/445/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/445/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Atomic Update results in NullPointerException
> -
>
> Key: SOLR-13523
> URL: https://issues.apache.org/jira/browse/SOLR-13523
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 8.0
> Environment: * Operating system: Win10 v1803 build 17143.766
> * Java version:
> java 11.0.1 2018-10-16 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)
> * solr-spec: 8.1.1
> * solr-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:20:01
> * lucene-spec: 8.1.1
> * lucene-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:15:24
>Reporter: Kieran Devlin
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-13523.patch, SOLR-13523.patch,
> SOLR-13523_WIP_bug_hunt.patch, XUBrk.png, Xn1RW.png, reproduce.sh
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Partially update a document via an atomic update, when I do so, the web sever
> responds with a 500 status with the stack trace:
> {code:java}
> { "responseHeader":{ "status":500, "QTime":1}, "error":{
> "trace":"java.lang.NullPointerException\r\n\tat
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.getFieldFromHierarchy(AtomicUpdateDocumentMerger.java:301)\r\n\tat
>
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDoc(AtomicUpdateDocumentMerger.java:398)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:697)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:372)\r\n\tat
>
> org.apache.solr.update.processor.Distribute
[jira] [Commented] (LUCENE-8816) Decouple Kuromoji's morphological analyser and its dictionary
[ https://issues.apache.org/jira/browse/LUCENE-8816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867977#comment-16867977 ] Mike Sokolov commented on LUCENE-8816: -- LUCENE-8871 opened to cover moving dictionary builder tools into main kuromoji source tree, mostly so it gets tested properly. > Decouple Kuromoji's morphological analyser and its dictionary > - > > Key: LUCENE-8816 > URL: https://issues.apache.org/jira/browse/LUCENE-8816 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Tomoko Uchida >Priority: Major > > I've inspired by this mail-list thread. > > [http://mail-archives.apache.org/mod_mbox/lucene-java-user/201905.mbox/%3CCAGUSZHA3U_vWpRfxQb4jttT7sAOu%2BuaU8MfvXSYgNP9s9JNsXw%40mail.gmail.com%3E] > As many Japanese already know, default built-in dictionary bundled with > Kuromoji (MeCab IPADIC) is a bit old and no longer maintained for many years. > While it has been slowly obsoleted, well-maintained and/or extended > dictionaries risen up in recent years (e.g. > [mecab-ipadic-neologd|https://github.com/neologd/mecab-ipadic-neologd], > [UniDic|https://unidic.ninjal.ac.jp/]). To use them with Kuromoji, some > attempts/projects/efforts are made in Japan. > However current architecture - dictionary bundled jar - is essentially > incompatible with the idea "switch the system dictionary", and developers > have difficulties to do so. > Traditionally, the morphological analysis engine (viterbi logic) and the > encoded dictionary (language model) had been decoupled (like MeCab, the > origin of Kuromoji, or lucene-gosen). So actually decoupling them is a > natural idea, and I feel that it's good time to re-think the current > architecture. > Also this would be good for advanced users who have customized/re-trained > their own system dictionary. > Goals of this issue: > * Decouple JapaneseTokenizer itself and encoded system dictionary. > * Implement dynamic dictionary load mechanism. > * Provide developer-oriented dictionary build tool. > Non-goals: > * Provide learner or language model (it's up to users and should be outside > the scope). > I have not dove into the code yet, so have no idea about it's easy or > difficult at this moment. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8871) Move Kuromoji DictionaryBuilder tool from src/tools to src/
Mike Sokolov created LUCENE-8871:
Summary: Move Kuromoji DictionaryBuilder tool from src/tools to
src/
Key: LUCENE-8871
URL: https://issues.apache.org/jira/browse/LUCENE-8871
Project: Lucene - Core
Issue Type: Improvement
Reporter: Mike Sokolov
Currently tests in tools directories are not run as part of the normal testing
done by {{ant test}} - you have to explicitly run {{test-tools}}, which it
seems people don't do (and it might not survivie translation to gradle, who
knows), so [~rcmuir] suggested we just move the tools into the main source tree
(under src/java and src/test)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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+18) - Build # 24255 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24255/ Java: 64bit/jdk-13-ea+18 -XX:+UseCompressedOops -XX:+UseParallelGC 11 tests failed. FAILED: org.apache.solr.cloud.autoscaling.TestPolicyCloud.testCreateCollectionSplitShard Error Message: Timeout occurred while waiting response from server at: https://127.0.0.1:33147/solr Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: https://127.0.0.1:33147/solr at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667) 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.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) 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.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.autoscaling.TestPolicyCloud.testCreateCollectionSplitShard(TestPolicyCloud.java:246) 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 org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239) 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.Stat
[GitHub] [lucene-solr] msokolov commented on a change in pull request #722: LUCENE-8863: handle some edge cases in Kuromoji DictionaryBuilder, en…
msokolov commented on a change in pull request #722: LUCENE-8863: handle some
edge cases in Kuromoji DictionaryBuilder, en…
URL: https://github.com/apache/lucene-solr/pull/722#discussion_r295505621
##
File path:
lucene/analysis/kuromoji/src/java/org/apache/lucene/analysis/ja/dict/BinaryDictionary.java
##
@@ -46,13 +50,31 @@
public static final String POSDICT_HEADER = "kuromoji_dict_pos";
public static final int VERSION = 1;
+ static final String CLASSPATH = "classpath:";
+ static final String FILE = "file:";
+
+ private final String resourcePrefix;
private final ByteBuffer buffer;
private final int[] targetMapOffsets, targetMap;
private final String[] posDict;
private final String[] inflTypeDict;
private final String[] inflFormDict;
protected BinaryDictionary() throws IOException {
+this(CLASSPATH);
+ }
+
+ /**
+ * @param resourcePrefix - where to load resources (dictionaries) from.
Either "file:", followed
+ * by a filesystem directory and optionally a filename-prefix, or
"classpath:", followed by a
+ * classpath location prefix, or just plain "classpath:" to use this class's
name as the prefix.
+ */
+ protected BinaryDictionary(String resourcePrefix) throws IOException {
Review comment:
enum is a good idea; I'll update the patch. I added "file:" to enable unit
testing. We can't load a test dictionary from the classpath, I think. Another
possibility would be to pass in dictionaries directly somehow. EG we could
maybe have {{...DictionaryBuilder}} {{FST.save()}} to an in-memory buffer, but
this seemed like a more intrusive change since we can already save to a set of
files.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8863) Improve Kuromoji DictionaryBuilder error handling, and enable loading external dictionary for testing
[
https://issues.apache.org/jira/browse/LUCENE-8863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867970#comment-16867970
]
Mike Sokolov commented on LUCENE-8863:
--
Agreed - I'll edit the description to indicate how we added a constructor here
> Improve Kuromoji DictionaryBuilder error handling, and enable loading
> external dictionary for testing
> --
>
> Key: LUCENE-8863
> URL: https://issues.apache.org/jira/browse/LUCENE-8863
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Mike Sokolov
>Assignee: Mike Sokolov
>Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> While building a custom Kuromoji system dictionary, I discovered a few issues.
> First, the dictionary encoding has room for 13-bit (left and right) ids, but
> really only supports 12 bits since this was all that was needed for the
> IPADIC dictionary that ships with Kuromoji. The good news is we can easily
> add support by fixing the bit-twiddling math.
> Second, the dictionary builder has a number of assertions that help uncover
> problems in the input (like these overlarge ids), but the assertions aren't
> enabled by default, so an unsuspecting new user doesn't get any benefit from
> them, so we should upgrade to "real" exceptions.
> Finally, we want to handle the case of empty base forms differently. Kuromoji
> does stemming by substituting a base form for a word when there is a base
> form in the dictionary. Missing base forms are expected to be supplied as
> {{*}}, but if a dictionary provides an empty string base form, we would end
> up stripping that token completely. Since there is no possible meaning for an
> empty base form (and the dictionary builder already treats {{*}} and empty
> strings as equivalent in a number of other cases), I think we should simply
> ignore empty base forms (rather than replacing words with empty strings when
> tokenizing!)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8863) Improve Kuromoji DictionaryBuilder error handling, and enable loading external dictionary for testing
[
https://issues.apache.org/jira/browse/LUCENE-8863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Sokolov updated LUCENE-8863:
-
Summary: Improve Kuromoji DictionaryBuilder error handling, and enable
loading external dictionary for testing (was: Improve handling of edge cases
in Kuromoji's DIctionaryBuilder)
> Improve Kuromoji DictionaryBuilder error handling, and enable loading
> external dictionary for testing
> --
>
> Key: LUCENE-8863
> URL: https://issues.apache.org/jira/browse/LUCENE-8863
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Mike Sokolov
>Assignee: Mike Sokolov
>Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> While building a custom Kuromoji system dictionary, I discovered a few issues.
> First, the dictionary encoding has room for 13-bit (left and right) ids, but
> really only supports 12 bits since this was all that was needed for the
> IPADIC dictionary that ships with Kuromoji. The good news is we can easily
> add support by fixing the bit-twiddling math.
> Second, the dictionary builder has a number of assertions that help uncover
> problems in the input (like these overlarge ids), but the assertions aren't
> enabled by default, so an unsuspecting new user doesn't get any benefit from
> them, so we should upgrade to "real" exceptions.
> Finally, we want to handle the case of empty base forms differently. Kuromoji
> does stemming by substituting a base form for a word when there is a base
> form in the dictionary. Missing base forms are expected to be supplied as
> {{*}}, but if a dictionary provides an empty string base form, we would end
> up stripping that token completely. Since there is no possible meaning for an
> empty base form (and the dictionary builder already treats {{*}} and empty
> strings as equivalent in a number of other cases), I think we should simply
> ignore empty base forms (rather than replacing words with empty strings when
> tokenizing!)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8781) Explore FST direct array arc encoding
[
https://issues.apache.org/jira/browse/LUCENE-8781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867966#comment-16867966
]
Mike Sokolov edited comment on LUCENE-8781 at 6/19/19 8:09 PM:
---
re-closing after pushing fix that handled missing case (found while testing
memory codec)
was (Author: sokolov):
re-closing after pushing fix that handled missing case (in memory codec)
> Explore FST direct array arc encoding
> --
>
> Key: LUCENE-8781
> URL: https://issues.apache.org/jira/browse/LUCENE-8781
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Mike Sokolov
>Assignee: Dawid Weiss
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: FST-2-4.png, FST-6-9.png, FST-size.png
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> This issue is for exploring an alternate FST encoding of Arcs as full-sized
> arrays so Arcs are addressed directly by label, avoiding binary search that
> we use today for arrays of Arcs. PR:
> https://github.com/apache/lucene-solr/pull/657
> h3. Testing
> ant test passes. I added some unit tests that were helpful in uncovering bugs
> while
> implementing which are more difficult to chase down when uncovered by the
> randomized testing we already do. They don't really test anything new;
> they're just more focused.
> I'm not sure why, but ant precommit failed for me with:
> {noformat}
> ...lucene-solr/solr/common-build.xml:536: Check for forbidden API calls
> failed while scanning class
> 'org.apache.solr.metrics.reporters.SolrGangliaReporterTest'
> (SolrGangliaReporterTest.java): java.lang.ClassNotFoundException:
> info.ganglia.gmetric4j.gmetric.GMetric (while looking up details about
> referenced class 'info.ganglia.gmetric4j.gmetric.GMetric')
> {noformat}
> I also got Test2BFST running (it was originally timing out due to excessive
> calls to ramBytesUsage(), which seems to have gotten slow), and it passed;
> that change isn't include here.
> h4. Micro-benchmark
> I timed lookups in FST via FSTEnum.seekExact in a unit test under various
> conditions.
> h5. English words
> A test of looking up existing words in a dictionary of ~17 English words
> shows improvements; the numbers listed are % change in FST size, time to look
> up (FSTEnum.seekExact) words that are in the dict, and time to look up random
> strings that are not in the dict. The comparison is against the current
> codebase with the optimization disabled. A separate comparison of showed no
> significant change of the baseline (no opto applied) vs the current master
> FST impl with no code changes applied.
> || load=2|| load=4 || load=16 ||
> | +4, -6, -7 | +18, -11, -8 | +22, -11.5, -7 |
> The "load factor" used for those measurements controls when direct array arc
> encoding is used;
> namely when the number of outgoing arcs was > load * (max label - min label).
> h5. sequential and random terms
> The same test, with terms being a sequence of integers as strings shows a
> larger improvement, around 20% (load=4). This is presumably the best case for
> this delta, where every Arc is encoded as a direct lookup.
> When random lowercase ASCII strings are used, a smaller improvement of around
> 4% is seen.
> h4. luceneutil
> Testing w/luceneutil (wikimediumall) we see improvements mostly in the
> PKLookup case. Other results seem noisy, with perhaps a small improvment in
> some of the queries.
> {noformat}
> TaskQPS base StdDevQPS opto StdDev
> Pct diff
> OrHighHigh6.93 (3.0%)6.89 (3.1%)
> -0.5% ( -6% -5%)
>OrHighMed 45.15 (3.9%) 44.92 (3.5%)
> -0.5% ( -7% -7%)
> Wildcard8.72 (4.7%)8.69 (4.6%)
> -0.4% ( -9% -9%)
> AndHighLow 274.11 (2.6%) 273.58 (3.1%)
> -0.2% ( -5% -5%)
>OrHighLow 241.41 (1.9%) 241.11 (3.5%)
> -0.1% ( -5% -5%)
> AndHighMed 52.23 (4.1%) 52.41 (5.3%)
> 0.3% ( -8% - 10%)
> MedTerm 1026.24 (3.1%) 1030.52 (4.3%)
> 0.4% ( -6% -8%)
> HighTerm .10 (3.4%) 1116.70 (4.0%)
> 0.5% ( -6% -8%)
>HighTermDayOfYearSort 14.59 (8.2%) 14.73 (9.3%)
> 1.0% ( -15% - 20%)
> AndHighHigh 13.45 (6.2%) 13.61 (4.4%)
> 1.2% ( -8% - 12%)
>HighTermMonthSort 63.09 (12.5%) 64.13 (10.9%)
> 1.6% ( -19% - 28%)
> LowTerm 1338.94 (3.3%) 1383.90 (5.5%)
> 3.4% ( -5%
[jira] [Resolved] (LUCENE-8781) Explore FST direct array arc encoding
[
https://issues.apache.org/jira/browse/LUCENE-8781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Sokolov resolved LUCENE-8781.
--
Resolution: Fixed
re-closing after pushing fix that handled missing case (in memory codec)
> Explore FST direct array arc encoding
> --
>
> Key: LUCENE-8781
> URL: https://issues.apache.org/jira/browse/LUCENE-8781
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Mike Sokolov
>Assignee: Dawid Weiss
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: FST-2-4.png, FST-6-9.png, FST-size.png
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> This issue is for exploring an alternate FST encoding of Arcs as full-sized
> arrays so Arcs are addressed directly by label, avoiding binary search that
> we use today for arrays of Arcs. PR:
> https://github.com/apache/lucene-solr/pull/657
> h3. Testing
> ant test passes. I added some unit tests that were helpful in uncovering bugs
> while
> implementing which are more difficult to chase down when uncovered by the
> randomized testing we already do. They don't really test anything new;
> they're just more focused.
> I'm not sure why, but ant precommit failed for me with:
> {noformat}
> ...lucene-solr/solr/common-build.xml:536: Check for forbidden API calls
> failed while scanning class
> 'org.apache.solr.metrics.reporters.SolrGangliaReporterTest'
> (SolrGangliaReporterTest.java): java.lang.ClassNotFoundException:
> info.ganglia.gmetric4j.gmetric.GMetric (while looking up details about
> referenced class 'info.ganglia.gmetric4j.gmetric.GMetric')
> {noformat}
> I also got Test2BFST running (it was originally timing out due to excessive
> calls to ramBytesUsage(), which seems to have gotten slow), and it passed;
> that change isn't include here.
> h4. Micro-benchmark
> I timed lookups in FST via FSTEnum.seekExact in a unit test under various
> conditions.
> h5. English words
> A test of looking up existing words in a dictionary of ~17 English words
> shows improvements; the numbers listed are % change in FST size, time to look
> up (FSTEnum.seekExact) words that are in the dict, and time to look up random
> strings that are not in the dict. The comparison is against the current
> codebase with the optimization disabled. A separate comparison of showed no
> significant change of the baseline (no opto applied) vs the current master
> FST impl with no code changes applied.
> || load=2|| load=4 || load=16 ||
> | +4, -6, -7 | +18, -11, -8 | +22, -11.5, -7 |
> The "load factor" used for those measurements controls when direct array arc
> encoding is used;
> namely when the number of outgoing arcs was > load * (max label - min label).
> h5. sequential and random terms
> The same test, with terms being a sequence of integers as strings shows a
> larger improvement, around 20% (load=4). This is presumably the best case for
> this delta, where every Arc is encoded as a direct lookup.
> When random lowercase ASCII strings are used, a smaller improvement of around
> 4% is seen.
> h4. luceneutil
> Testing w/luceneutil (wikimediumall) we see improvements mostly in the
> PKLookup case. Other results seem noisy, with perhaps a small improvment in
> some of the queries.
> {noformat}
> TaskQPS base StdDevQPS opto StdDev
> Pct diff
> OrHighHigh6.93 (3.0%)6.89 (3.1%)
> -0.5% ( -6% -5%)
>OrHighMed 45.15 (3.9%) 44.92 (3.5%)
> -0.5% ( -7% -7%)
> Wildcard8.72 (4.7%)8.69 (4.6%)
> -0.4% ( -9% -9%)
> AndHighLow 274.11 (2.6%) 273.58 (3.1%)
> -0.2% ( -5% -5%)
>OrHighLow 241.41 (1.9%) 241.11 (3.5%)
> -0.1% ( -5% -5%)
> AndHighMed 52.23 (4.1%) 52.41 (5.3%)
> 0.3% ( -8% - 10%)
> MedTerm 1026.24 (3.1%) 1030.52 (4.3%)
> 0.4% ( -6% -8%)
> HighTerm .10 (3.4%) 1116.70 (4.0%)
> 0.5% ( -6% -8%)
>HighTermDayOfYearSort 14.59 (8.2%) 14.73 (9.3%)
> 1.0% ( -15% - 20%)
> AndHighHigh 13.45 (6.2%) 13.61 (4.4%)
> 1.2% ( -8% - 12%)
>HighTermMonthSort 63.09 (12.5%) 64.13 (10.9%)
> 1.6% ( -19% - 28%)
> LowTerm 1338.94 (3.3%) 1383.90 (5.5%)
> 3.4% ( -5% - 12%)
> PKLookup 120.45 (2.5%) 130.91 (3.5%)
> 8.7% ( 2% - 15%)
> {noformat}
> h4.FST perf tests
> I ran LookupBenchmarkTest to see the impact on the
[jira] [Commented] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867963#comment-16867963
]
ASF subversion and git services commented on SOLR-12988:
Commit 150e4f9863147354a489bbd62519bf2e586f41b9 in lucene-solr's branch
refs/heads/branch_8x from Cao Manh Dat
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=150e4f9 ]
SOLR-12988: Revert changes
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-12988.patch, SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should skip running
> tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867962#comment-16867962
]
ASF subversion and git services commented on SOLR-12988:
Commit e3752e87d005d407108f95e72b14c82d60f1c082 in lucene-solr's branch
refs/heads/master from Cao Manh Dat
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e3752e8 ]
SOLR-12988: Revert changes
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-12988.patch, SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should skip running
> tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] msokolov closed pull request #721: LUCENE-8781: add FST array-with-gap addressing to Util.readCeilArc
msokolov closed pull request #721: LUCENE-8781: add FST array-with-gap addressing to Util.readCeilArc URL: https://github.com/apache/lucene-solr/pull/721 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] msokolov commented on issue #721: LUCENE-8781: add FST array-with-gap addressing to Util.readCeilArc
msokolov commented on issue #721: LUCENE-8781: add FST array-with-gap addressing to Util.readCeilArc URL: https://github.com/apache/lucene-solr/pull/721#issuecomment-503726838 Yes, naturally, since that was what this was intended to fix. I thought I had said so, but I see there's no such comment here. Anyway I had a seed that failed before and succeeded after. In fact you didn't need any special seed, since it always failed before. One thing that confuses me is that the suggesters also seem to use this method, yet they never failed in my testing. I'm running again just to be sure, then I'll push. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12988:
Attachment: (was: SOLR-12988.patch)
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-12988.patch, SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should skip running
> tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-9.0.4) - Build # 318 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/318/
Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseG1GC
All tests passed
Build Log:
[...truncated 12913 lines...]
[javac] Compiling 55 source files to
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-test-framework\classes\java
[javac]
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\test-framework\src\java\org\apache\solr\util\SSLTestConfig.java:108:
error: cannot find symbol
[javac] if (Constants.JRE_IS_MINIMUM_JAVA11 &&
Runtime.version().compareTo(Runtime.Version.parse("11.0.3")) < 0) {
[javac] ^
[javac] symbol: method version()
[javac] location: class Runtime
[javac]
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\test-framework\src\java\org\apache\solr\util\SSLTestConfig.java:108:
error: cannot find symbol
[javac] if (Constants.JRE_IS_MINIMUM_JAVA11 &&
Runtime.version().compareTo(Runtime.Version.parse("11.0.3")) < 0) {
[javac]
^
[javac] symbol: variable Version
[javac] location: class Runtime
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors
BUILD FAILED
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\build.xml:634: The following
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\build.xml:578: The following
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\build.xml:59: The following
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build.xml:231: The
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\common-build.xml:558:
The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\common-build.xml:446:
The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\test-framework\build.xml:42:
The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\common-build.xml:2056:
Compile failed; see the compiler error output for details.
Total time: 28 minutes 33 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12988:
Attachment: SOLR-12988.patch
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-12988.patch, SOLR-12988.patch, SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should skip running
> tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867957#comment-16867957
]
Cao Manh Dat commented on SOLR-12988:
-
{quote}
That's very suprising since java.lang.Runtime.Version didn't exist until
java9...
{quote}
Hmm, now you mention, it seems weird too me as well. But the {{ant compile}}
success at my machine with java 1.8.0_191.
{quote}
But to re-iterate: even if/once we have a "good" patch (that can be backported
to 8x) i STILL think we need to revert all of these changes, and not move
forward with any patch (or existing changes to allow SSL testing on java11)
until the jenkins boxes are running 11.0.3.
{quote}
Ok that makes sense to me, I will revert changes and let you handle this issue,
since both of us understand the problem, we just need a way to handle the test
now which it seems you will handle it properly and more stable than me.
Just a note here, since the awaitsFix of Mark 6 months ago + the enforcment of
using Java 11 on master. None tests on master were run with HTTPS. Hoping that
this issue can move fast.
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-12988.patch, SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should skip running
> tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13548) Migrate Solr's Moin wiki to Confluence
[
https://issues.apache.org/jira/browse/SOLR-13548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867935#comment-16867935
]
Hoss Man commented on SOLR-13548:
-
{quote}I strongly suspect, though, that if we delete the space we can't
recreate it with the same name. It's possible Infra has some magic they can do
to the database itself.
{quote}
my confluence-fu is old and weak, but what about "moving" the space, ie:
renaming "solr" to "solr-old-ref-guide" ... then can we re-create a new space
named "solr" ?
(the redirects, IIRC, are on the HTTPD proxy server sitting in front of the
actual confluence port, so they should be unaffected by a space move/rename.
... but i would sanity check that with infra)
> Migrate Solr's Moin wiki to Confluence
> --
>
> Key: SOLR-13548
> URL: https://issues.apache.org/jira/browse/SOLR-13548
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> We have a deadline end of June to migrate Moin wiki to Confluence.
> This Jira will track migration of Solr's [https://wiki.apache.org/solr/] over
> to [https://cwiki.apache.org/confluence/display/SOLR]
> The old Confluence space currently hosts the old Reference Guide for version
> 6.5 before we moved to asciidoc. This will be overwritten.
> Steps:
> # Delete all pages in current SOLR space
> ## Q: Can we do a bulk delete ourselves or do we need to ask INFRA?
> # The rules in {{.htaccess}} which redirects to the 6.6 guide will remain as
> is
> # Run the migration tool at
> [https://selfserve.apache.org|https://selfserve.apache.org/]
> # Add a clearly visible link from front page to the ref guide for people
> landing there for docs
> After migration we'll clean up and weed out what is not needed, and then
> start moving developer-centric content into the main git repo (which will be
> covered in other JIRAs)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-13-ea+18) - Build # 8004 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/8004/ Java: 64bit/jdk-13-ea+18 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.NestedShardedAtomicUpdateTest.test Error Message: Error from server at http://127.0.0.1:64258/p_hln/yo/collection1: no servers hosting shard: shard1 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:64258/p_hln/yo/collection1: no servers hosting shard: shard1 at __randomizedtesting.SeedInfo.seed([DFF1FE3CB331C64E:57A5C1E61DCDABB6]: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.query(SolrClient.java:987) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1002) at org.apache.solr.cloud.NestedShardedAtomicUpdateTest.doNestedInplaceUpdateTest(NestedShardedAtomicUpdateTest.java:154) at org.apache.solr.cloud.NestedShardedAtomicUpdateTest.test(NestedShardedAtomicUpdateTest.java:56) 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 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.jav
[jira] [Commented] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867933#comment-16867933
]
Hoss Man commented on SOLR-12988:
-
bq. Firstly, I don't see any problem with compiling branch_8x on java8 locally.
That's very suprising since java.lang.Runtime.Version didn't exist until
java9...
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/732/
(and locally for me running w/ java8, java11, etc...)
{noformat}
[javac] Compiling 55 source files to
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/build/solr-test-framework/classes/java
[javac]
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/test-framework/src/java/org/apache/solr/util/SSLTestConfig.java:108:
error: cannot
find symbol
[javac] if (Constants.JRE_IS_MINIMUM_JAVA11 &&
Runtime.version().compareTo(Runtime.Version.parse("11.0.3")) < 0) {
[javac] ^
[javac] symbol: method version()
[javac] location: class Runtime
[javac]
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/test-framework/src/java/org/apache/solr/util/SSLTestConfig.java:108:
error: cannot
find symbol
[javac] if (Constants.JRE_IS_MINIMUM_JAVA11 &&
Runtime.version().compareTo(Runtime.Version.parse("11.0.3")) < 0) {
[javac]
^
[javac] symbol: variable Version
[javac] location: class Runtime
{noformat}
bq. Secondly, I rushed the commit to revert changes back to it used to be +
minimal checks so Jenkins will become happy. ...
No, you didn't "revert" anything back to "minimal checks" ... you "fixed
forward" to *different* checks. That's not the same as "reverting" to what we
had before: which was a known and relatively stable state.
We're talking about very fundemental changes to test infrastructure that impact
over a thousand tests -- we should be hammering on these locally for a *LONG*
time, with differnet JVMs, on both branches, before pushing forward any changes
-- and as i've suggested repeatedly: we should not push *ANY* serious changes
-- particularly jvm version dependent behavior cahnages -- until the jenkins
boxes are running 11.0.3, so _they_ are ready to hammer on whatever changes we
commit, in case there are *OTHER* SSL bugs we haven't found or considered yet.
Even if we have rock solid "don't use ssl unless 11.0.3" logic in our tests,
that's a potential time bomb that might go off w/some unknown bug once jenkins
is upgraded -- we shouldn't just leave that in our code waiting to see what
happens if/when you or I are offline for an extended period of time when
jenkins gets upgraded.
bq. ...does that most recent patch matched to your idea?
Well, besides the fact that it still uses Runtime.Version (so won't compile on
branch_8x) i guess it's ok? but i'm still a little worried about having it only
be conditional on the java versoin and not on the JVM impl...
bq. ...that could still lead to weird situations if/when people use non-OpenJDK
based JVMs, or potentially use their own builds of Open-JDK that they've
patched, etc...
Ideally i'd much rather have have a quick and dirty helper method we could use
to ask "does this jvm manifest this bug", that actually uses the SSLEngine to
see if these bugs get triggered -- but that's fairly non trivial, so i guess
just checking the version info is fine (although i think we should almost
certainly be checking the java vendor in addition to the java version)
But to re-iterate: even if/once we have a "good" patch (that can be backported
to 8x) i *STILL* think we need to revert all of these changes, and not move
forward with any patch (or existing changes to allow SSL testing on java11)
until the jenkins boxes are running 11.0.3.
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-12988.patch, SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should skip running
> tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell,
[GitHub] [lucene-solr] s1monw commented on a change in pull request #731: LUCENE-8865: Move to executor in IndexSearcher
s1monw commented on a change in pull request #731: LUCENE-8865: Move to
executor in IndexSearcher
URL: https://github.com/apache/lucene-solr/pull/731#discussion_r295483481
##
File path: lucene/core/src/test/org/apache/lucene/search/TestIndexSearcher.java
##
@@ -237,4 +241,28 @@ public void testGetSlices() throws Exception {
service.shutdown();
IOUtils.close(r, dir);
}
+
+ public void testOneSegmentExecutesOnTheCallerThread() throws IOException {
Review comment:
RandomIndexWriter is used in this test which does that.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] s1monw commented on a change in pull request #731: LUCENE-8865: Move to executor in IndexSearcher
s1monw commented on a change in pull request #731: LUCENE-8865: Move to
executor in IndexSearcher
URL: https://github.com/apache/lucene-solr/pull/731#discussion_r295483294
##
File path: lucene/core/src/test/org/apache/lucene/search/TestIndexSearcher.java
##
@@ -237,4 +241,28 @@ public void testGetSlices() throws Exception {
service.shutdown();
IOUtils.close(r, dir);
}
+
+ public void testOneSegmentExecutesOnTheCallerThread() throws IOException {
+List leaves = reader.leaves();
+AtomicInteger numExecutions = new AtomicInteger(0);
+IndexSearcher searcher = new IndexSearcher(reader, task -> {
+ numExecutions.incrementAndGet();
+ task.run();
+}) {
+ @Override
+ protected LeafSlice[] slices(List leaves) {
+ArrayList slices = new ArrayList<>();
+for (LeafReaderContext ctx : leaves) {
+ slices.add(new LeafSlice(Arrays.asList(ctx)));
+}
+return slices.toArray(new LeafSlice[0]);
+ }
+};
+searcher.search(new MatchAllDocsQuery(), 10);
+if (leaves.size() <= 1) {
Review comment:
it's in theory possible to have 0 leaves. That's why I did that
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13548) Migrate Solr's Moin wiki to Confluence
[
https://issues.apache.org/jira/browse/SOLR-13548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867918#comment-16867918
]
Cassandra Targett commented on SOLR-13548:
--
So...this is much more complicated than it sounded at first.
You cannot bulk delete pages in Confluence, so they have to be done one by one.
However, because of the {{.htaccess}} rules, you cannot get to each page to
delete it.
There seem to be a couple of utility plugins installed to assist in deleting
groups of pages (from https://cwiki.apache.org/confluence/display/solr, click
the "..." icon on the far right and they're near the bottom of the list), but
those seem to invoke the redirects in some way because trying to use one just
takes you to the new Ref Guide site.
Another option I found online is to use WebDAV to access the Confluence site.
But that doesn't allow you to delete either because no matter what I do it says
an "@exports" directory is in use. It's possible that Infra has locked us out
there.
It seems to me there are 2 options: ask Infra to remove the redirect rules so
we can delete them page-by-page, or go extreme and delete the space. I strongly
suspect, though, that if we delete the space we can't recreate it with the same
name. It's possible Infra has some magic they can do to the database itself.
> Migrate Solr's Moin wiki to Confluence
> --
>
> Key: SOLR-13548
> URL: https://issues.apache.org/jira/browse/SOLR-13548
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> We have a deadline end of June to migrate Moin wiki to Confluence.
> This Jira will track migration of Solr's [https://wiki.apache.org/solr/] over
> to [https://cwiki.apache.org/confluence/display/SOLR]
> The old Confluence space currently hosts the old Reference Guide for version
> 6.5 before we moved to asciidoc. This will be overwritten.
> Steps:
> # Delete all pages in current SOLR space
> ## Q: Can we do a bulk delete ourselves or do we need to ask INFRA?
> # The rules in {{.htaccess}} which redirects to the 6.6 guide will remain as
> is
> # Run the migration tool at
> [https://selfserve.apache.org|https://selfserve.apache.org/]
> # Add a clearly visible link from front page to the ref guide for people
> landing there for docs
> After migration we'll clean up and weed out what is not needed, and then
> start moving developer-centric content into the main git repo (which will be
> covered in other JIRAs)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-8.x - Build # 251 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/251/
All tests passed
Build Log:
[...truncated 12893 lines...]
[javac] Compiling 55 source files to
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/build/solr-test-framework/classes/java
[javac]
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/test-framework/src/java/org/apache/solr/util/SSLTestConfig.java:108:
error: cannot find symbol
[javac] if (Constants.JRE_IS_MINIMUM_JAVA11 &&
Runtime.version().compareTo(Runtime.Version.parse("11.0.3")) < 0) {
[javac]
^
[javac] symbol: variable Version
[javac] location: class Runtime
[javac]
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/test-framework/src/java/org/apache/solr/util/SSLTestConfig.java:108:
error: cannot find symbol
[javac] if (Constants.JRE_IS_MINIMUM_JAVA11 &&
Runtime.version().compareTo(Runtime.Version.parse("11.0.3")) < 0) {
[javac] ^
[javac] symbol: method version()
[javac] location: class Runtime
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:634: The
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:578: The
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:59: The
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/build.xml:231:
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:558:
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:446:
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/test-framework/build.xml:42:
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:2056:
Compile failed; see the compiler error output for details.
Total time: 90 minutes 22 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867897#comment-16867897
]
Cao Manh Dat commented on SOLR-12988:
-
[~hossman] does that most recent patch matched to your idea?
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-12988.patch, SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should skip running
> tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12988:
Attachment: SOLR-12988.patch
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-12988.patch, SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should skip running
> tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8858) Migrate Lucene's Moin wiki to Confluence
[ https://issues.apache.org/jira/browse/LUCENE-8858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867892#comment-16867892 ] Jan Høydahl commented on LUCENE-8858: - I filed INFRA-18628 as a follow-up to put Moin in read-only mode and to establish some redirects. Please chime in on what redirects you'd like for the Lucene WIKI - note that if we redirect to CWIKI we can do that now even if a page is a sub page of the "Old Moin Wiki" page, as long as the page title is stable after a future move. > Migrate Lucene's Moin wiki to Confluence > > > Key: LUCENE-8858 > URL: https://issues.apache.org/jira/browse/LUCENE-8858 > Project: Lucene - Core > Issue Type: Task > Components: general/website >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > We have a deadline end of June to migrate Moin wiki to Confluence. > This Jira will track migration of Lucene's > https://wiki.apache.org/lucene-java/ over to > https://cwiki.apache.org/confluence/display/LUCENE > The old Confluence space will be overwritten as it is not used. > After migration we'll clean up and weed out what is not needed, and then > start moving developer-centric content into the main git repo (which will be > covered in other JIRAs) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867891#comment-16867891
]
Cao Manh Dat commented on SOLR-12988:
-
Hi [~hossman] I kinda think we are misunderstanding each others here.
{quote}
that doesn't even fucking compile with java8
{quote}
Firstly, I don't see any problem with compiling branch_8x on java8 locally.
Secondly, I rushed the commit to revert changes back to it used to be + minimal
checks so Jenkins will become happy. THEN we can continue doing what we should
do after discussion.
Thirdly, I quite understand your idea now, so we should call {{assumFalse()}}
in {{SSLTestConfig}} whenever SSL is enabled on Java 11 -> 11.0.2. Luckily that
it still matches with issue's name and we do not need to change issue name
(again).
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should skip running
> tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13548) Migrate Solr's Moin wiki to Confluence
[
https://issues.apache.org/jira/browse/SOLR-13548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867882#comment-16867882
]
Jan Høydahl commented on SOLR-13548:
I have given the PMC full admin right over the SOLR space now.
> Migrate Solr's Moin wiki to Confluence
> --
>
> Key: SOLR-13548
> URL: https://issues.apache.org/jira/browse/SOLR-13548
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> We have a deadline end of June to migrate Moin wiki to Confluence.
> This Jira will track migration of Solr's [https://wiki.apache.org/solr/] over
> to [https://cwiki.apache.org/confluence/display/SOLR]
> The old Confluence space currently hosts the old Reference Guide for version
> 6.5 before we moved to asciidoc. This will be overwritten.
> Steps:
> # Delete all pages in current SOLR space
> ## Q: Can we do a bulk delete ourselves or do we need to ask INFRA?
> # The rules in {{.htaccess}} which redirects to the 6.6 guide will remain as
> is
> # Run the migration tool at
> [https://selfserve.apache.org|https://selfserve.apache.org/]
> # Add a clearly visible link from front page to the ref guide for people
> landing there for docs
> After migration we'll clean up and weed out what is not needed, and then
> start moving developer-centric content into the main git repo (which will be
> covered in other JIRAs)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-8.x-Linux (64bit/jdk-13-ea+18) - Build # 732 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/732/ Java: 64bit/jdk-13-ea+18 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 2101 lines...] [junit4] JVM J1: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/test/temp/junit4-J1-20190619_172150_91612443857019987011739.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 5 lines...] [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/test/temp/junit4-J2-20190619_172150_9155973669244436336794.syserr [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J2: EOF [...truncated 3 lines...] [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/test/temp/junit4-J0-20190619_172150_9149553278225198799007.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 304 lines...] [junit4] JVM J1: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/test-framework/test/temp/junit4-J1-20190619_173445_59217902673396633620792.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 3 lines...] [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/test-framework/test/temp/junit4-J0-20190619_173445_5929389522293892838975.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 3 lines...] [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/test-framework/test/temp/junit4-J2-20190619_173445_5995666965897709129246.syserr [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J2: EOF [...truncated 1080 lines...] [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/analysis/common/test/temp/junit4-J0-20190619_173656_5349477744539907272205.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 3 lines...] [junit4] JVM J1: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/analysis/common/test/temp/junit4-J1-20190619_173656_53416612225282151737188.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 3 lines...] [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/analysis/common/test/temp/junit4-J2-20190619_173656_53611249500746325238173.syserr [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J2: EOF [...truncated 255 lines...] [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/analysis/icu/test/temp/junit4-J0-20190619_174003_4872756113913980458232.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 3 lines...] [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/analysis/icu/test/temp/junit4-J2-20190619_174003_49317112024119675773444.
[jira] [Commented] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867866#comment-16867866
]
Hoss Man commented on SOLR-12988:
-
Here's what i think...
# You should revert *EVERYTHING* you've commited to this issue – including
your most recent commit to branch_8x *that doesn't even fucking compile with
java8 !*
# We should wait for Uwe to have a chance to see & respond to my email
requesting that jenkins be upgrade to 11.0.3 (it's only been 1 day)
# You should slow WAAAY down on things, and stop rushing to commit things.
Twice now you've asked me my opinion (w/o even posting a patch showing exactly
what your suggestion was) and then rushed to commit changes (the first time
only 2 hours later, the second 10 minutes later ... both while i was asleep)
... apparently w/o even checking to see if it compiled first! if you want
opinions on your ideas give people time to (wake up and) think about it, other
wise why bother asking?
# Once Jenkins is running 11.0.3, *THEN* we should do the bare minimum to
re-enable SSL testing, and wait until we see lots and lots of jenkins builds,
running 11.0.3, to confirm there aren't any *other* SSL problems, before we
make any other decisions about changes to either the Runtime behavior of solr,
or to the tests.
{quote}But I kinda wondering what we should do with the tests? Should we
enforce tests to run in TLSv1.2 for 11 to 11.02? Since not all developers -
jenkins do know this and do the upgrade their sdk?
{quote}
I already shared my thoughts on this...
{quote}Fundementally i think it's a very bad idea to have Solr's behavior
radically change based on introspection of the JVM details – it makes it very
hard to test/reproduce problems. I think it makes a lot more sense for solr to
simply log "Your JVM is known to have some problems, see URL for details" and
let the failures happen if they are going to happen. ...
{quote}
if devs are running tests with a broken JVM, then the tests can & should fail
... that's the job of the tests. it's a bad idea to make the tests "hide" the
failure by "faking" that things work using a degraded cipher, or skipping SSL
completely (yes, i also think mark's changes to SSLTestConfig in December as
part of his commit on this issue was a terrible idea as well) ... the *ONLY*
thing we should _consider_ allowing tests to change about their behavior if
they see a JVM is "broken" is to {{SKIP}} ie:
assume(SomethingThatIsFalseForTheBrokenJVM) ...
{quote}(on the Junit tests side, having assumes around JVM version is fine –
because even then it's not a "silent" behavior change, it's an explicitly "test
ignored because XYZ")
{quote}
...fundementally, this psuedo-code (which mark added to SSLTestConfig in
december and still exists in a slightly diff form in your latest commit) should
*NOT* exist anywhere in our test scaffolding...
{code:java}
if (testOrRandomizationWantsSSL && isCurrentJVMBrokenWithSSL()) {
testOrRandomizationWantsSSL = false;
}
{code}
instead, it should be...
{code:java}
if (testOrRandomizationWantsSSL) {
assumeFalse("Test (or randomization) wants to use SSL for this seed, " +
"but SSL is known to fail on your JVM",
isCurrentJVMBrokenWithSSL());
}
{code}
Saying "we're going to have our this silently use TLSv1.2 (or skip SSL) on your
JVM because it's broken even though that's not what would happen if you tried
to actually run solr on ths broken JVM" is the absolute worst possible thing we
can do.
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should skip running
> tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
Re: Use of JIRA fixVersion
"I'm less sure about requiring that the fix version is not set before resolving the issue" Yeah, this aspect I don't think is particularly important either way. We can establish a preference to leave blank until release time, but say Blocker issues are a good exception. It'd be nice to have internal dev docs for us to write these down in so we can refer to them, particularly to share with new committers as well. Were you planning to do this Jan? ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Jun 19, 2019 at 12:22 PM Mark Miller wrote: > Can we address this in JIRA? In the past I've seen this handled in JIRA by > also having a 'target' version field - this is the intended version you > want to land in and you set it right away. Things were configured so you > could only set the fix version when you resolved I think. Then you would > use target for release blockers and such. Fix would just tell you what it's > actually in. > > On Mon, Jun 17, 2019 at 4:49 AM Adrien Grand wrote: > >> +1 to Jan's proposal about not adding master when changes are also pushed >> to the previous major, I like the additional consistency with our >> CHANGES.txt. >> >> I'm less sure about requiring that the fix version is not set before >> resolving the issue, I have used this in combination with the blocker label >> to mean that an issue needs to be addressed before releasing, sometimes it >> will be the next minor, sometimes the next major. For the record, the >> ReleaseTodo[1] recommends to check for blockers by filtering by priority >> and fixVersion. >> >> [1] https://wiki.apache.org/lucene-java/ReleaseTodo >> >> On Fri, Jun 14, 2019 at 11:30 PM Gus Heck wrote: >> >>> FWIW I tend to agree with Erick here on both his points, but the second >>> one more strongly than the first. The first I can live with either way >>> really so long as it's clearly documented somewhere (besides this thread). >>> >>> If we don't update the changes in master for bug fixes when we're >>> committing, who's going to go collect and add them later? I'm not sure I'm >>> that big a fan of generating changes... I haven't looked at Yetus >>> specifically but I suspect that this will just leave us with the title from >>> the Jira, and often some additional detail for changes is worthwhile beyond >>> what the title says. So if we create a field in Jira that is the Changes >>> text, and make it required in the resolution screen fine to generate from >>> that, but I think there's real value in the current system because you wind >>> up writing a final short 1-4 line summary focused on "what the user needs >>> to know" >>> >>> Also line 3, the feature only in 8x (but not master) is a very odd case >>> in that table, I'm not sure when that would happen? could happen for a bug >>> that is fixed by other changes in master, but for a feature? >>> >>> Also if we aren't marking branches explicitly maybe the 9.0 (master) tag >>> should say 9.0 (unreleased)? Sure most developers know master is typically >>> unreleased, but why add that mental leap. It's possible that someone less >>> technical, or who is a student will stumble in from a link on SO... >>> >>> -Gus >>> >>> On Thu, Jun 13, 2019 at 3:23 PM David Smiley >>> wrote: >>> +1 to your plan Jan. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Thu, Jun 13, 2019 at 8:40 AM Jan Høydahl wrote: > Trying to reach a conclusion (or perhaps a vote) on this. > > Here is a table that sums up my proposal. Basically it means in most > cases stop adding master as fixVersion. > > Type Committed to fixVersion CHANGES.txt section > Feature master master (9.0) 9.0 > Feature master, branch_8x 8.2 8.2 > Feature branch_8x 8.2 8.2 > Bugfix master master (9.0) none (unreleased bug) > Bugfix master, branch_8x 8.2 8.2 > Bugfix master, branch_8x, branch_8_1 8.1.2, 8.2 8.1.2, 8.2 > Bugfix branch_8x 8.2 8.2 > Bugfix branch_8_1 8.1.2 8.1.2 > Bugfix branch_8x, branch_7_7 7.7.3, 8.2 7.7.3, 8.2 > > In addition to this, we should all wait until commit time with setting > fixVersion. > > To find branches for a JIRA, you just translate fixVersion to branch, > e.g. 8.1.2, 8.2 -> branch_8_1, branch_8x. > For features, if it is unclear whether master has the commit, check > gitbot log or git log > For bugfixes, there are cases where the bug does not exist in master > at all, and that can be reflected in affectsVersion field. > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > 3. jun. 2019 kl. 19:56 skrev David Smiley : > > Right JIRA fixVersion has its use, and that would satisfy this > use-case? It's what Jan proposes to do this very thing as part of > generating release notes in a semi-automated way. > > ~
[JENKINS-MAVEN] Lucene-Solr-Maven-8.x #131: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-8.x/131/ No tests ran. Build Log: [...truncated 11983 lines...] BUILD FAILED /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/build.xml:673: The following error occurred while executing this line: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/build.xml:223: The following error occurred while executing this line: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/solr/common-build.xml:66: The following error occurred while executing this line: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/solr/common-build.xml:61: The following error occurred while executing this line: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/solr/build.xml:506: The following error occurred while executing this line: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/solr/build.xml:416: The following error occurred while executing this line: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/solr/test-framework/build.xml:42: The following error occurred while executing this line: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/lucene/common-build.xml:2056: Compile failed; see the compiler error output for details. Total time: 9 minutes 13 seconds Build step 'Invoke Ant' marked build as failure Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - 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+shipilev-fastdebug) - Build # 24254 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24254/ Java: 64bit/jdk-13-ea+shipilev-fastdebug -XX:-UseCompressedOops -XX:+UseParallelGC 8 tests failed. FAILED: org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica Error Message: Timeout occurred while waiting response from server at: https://127.0.0.1:36545/solr Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: https://127.0.0.1:36545/solr at __randomizedtesting.SeedInfo.seed([63511F1BA6323BD7:9477ECBCEC0711D]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667) 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.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) 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.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:384) at org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:256) 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
[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1367 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1367/ No tests ran. Build Log: [...truncated 24664 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2581 links (2111 relative) to 3394 anchors in 259 files [echo] Validated Links & Anchors via: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked [untar] Expanding: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-9.0.0.tgz into /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: i
[GitHub] [lucene-solr] dsmiley commented on issue #726: LUCENE-8632: New XYShape Field and Queries for indexing and searching general cartesian geometries
dsmiley commented on issue #726: LUCENE-8632: New XYShape Field and Queries for indexing and searching general cartesian geometries URL: https://github.com/apache/lucene-solr/pull/726#issuecomment-503650988 Yeah, lets do that then (another issue). When the spatial stuff "graduates", as some say, out of sandbox. This stuff here can stay in sandbox since it's where LatLonShape is now. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - 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 # 1875 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1875/ 1 tests failed. FAILED: org.apache.solr.cloud.RollingRestartTest.test Error Message: Timeout occurred while waiting response from server at: http://127.0.0.1:44416/qplhq/t Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: http://127.0.0.1:44416/qplhq/t at __randomizedtesting.SeedInfo.seed([F5493AEDEFCC5BC6:7D1D05374130363E]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667) 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.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) 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.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.RollingRestartTest.restartWithRolesTest(RollingRestartTest.java:74) at org.apache.solr.cloud.RollingRestartTest.test(RollingRestartTest.java:53) 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.NoShadowingOrO
[jira] [Commented] (SOLR-13559) AliasIntegrationTest.testClusterStateProviderAPI fails to often
[ https://issues.apache.org/jira/browse/SOLR-13559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867845#comment-16867845 ] Gus Heck commented on SOLR-13559: - I also tried beasting 100 times with just one runner no joy there either. (or rather all joy and no fail). Yes the code SAYS it waits for this to exist, but evidently it dosn't... it's probably a zk propgation or something funky with the caching in BaseHttpClusterStateProvider... I do notice that it does getAliases(false); in getAliasProperties(String alias) but I haven't been able to convince myself as to why that would only sometimes be a problem... > AliasIntegrationTest.testClusterStateProviderAPI fails to often > --- > > Key: SOLR-13559 > URL: https://issues.apache.org/jira/browse/SOLR-13559 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Affects Versions: master (9.0) >Reporter: Gus Heck >Priority: Minor > > Recent failure rates for AliasIntegrationTest.testClusterStateProviderAPI > have been around 4% which is too high. > (http://fucit.org/solr-jenkins-reports/failure-report.html). I've beasted 100 > runs a couple times and not reproduced it but then hit a failure in it during > a normal test run today, so I'm going to start this ticket and record the > trace. I have yet to dig through the zips for the logs from the builds. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12357) TRA: Pre-emptively create next collection
[ https://issues.apache.org/jira/browse/SOLR-12357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867837#comment-16867837 ] Gus Heck commented on SOLR-12357: - These are interesting possibilities and I do have ideas here, but these should be discussed on the dev list and/or in their own ticket. > TRA: Pre-emptively create next collection > -- > > Key: SOLR-12357 > URL: https://issues.apache.org/jira/browse/SOLR-12357 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Fix For: 7.5 > > Attachments: SOLR-12357.patch > > Time Spent: 9.5h > Remaining Estimate: 0h > > When adding data to a Time Routed Alias (TRA), we sometimes need to create > new collections. Today we only do this synchronously – on-demand when a > document is coming in. But this can add delays as the documents inbound are > held up for a collection to be created. And, there may be a problem like a > lack of resources (e.g. ample SolrCloud nodes with space) that the policy > framework defines. Such problems could be rectified sooner rather than later > assume there is log alerting in place (definitely out of scope here). > Pre-emptive TRA collection needs a time window configuration parameter, > perhaps named something like "preemptiveCreateWindowMs". If a document's > timestamp is within this time window _from the end time of the head/lead > collection_ then the collection can be created pre-eptively. If no data is > being sent to the TRA, no collections will be auto created, nor will it > happen if older data is being added. It may be convenient to effectively > limit this time setting to the _smaller_ of this value and the TRA interval > window, which I think is a fine limitation. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8855) Add Accountable to Query implementations
[
https://issues.apache.org/jira/browse/LUCENE-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki updated LUCENE-8855:
--
Attachment: LUCENE-8855.patch
> Add Accountable to Query implementations
>
>
> Key: LUCENE-8855
> URL: https://issues.apache.org/jira/browse/LUCENE-8855
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: LUCENE-8855.patch, LUCENE-8855.patch, LUCENE-8855.patch
>
>
> Query implementations should also support {{Accountable}} API in order to
> monitor the memory consumption e.g. in caches where either keys or values are
> {{Query}} instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8855) Add Accountable to Query implementations
[
https://issues.apache.org/jira/browse/LUCENE-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki updated LUCENE-8855:
--
Attachment: (was: LUCENE-8855.patch)
> Add Accountable to Query implementations
>
>
> Key: LUCENE-8855
> URL: https://issues.apache.org/jira/browse/LUCENE-8855
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: LUCENE-8855.patch, LUCENE-8855.patch, LUCENE-8855.patch
>
>
> Query implementations should also support {{Accountable}} API in order to
> monitor the memory consumption e.g. in caches where either keys or values are
> {{Query}} instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8855) Add Accountable to Query implementations
[
https://issues.apache.org/jira/browse/LUCENE-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867821#comment-16867821
]
Andrzej Bialecki commented on LUCENE-8855:
---
Updated patch:
* includes RamUsageEstimator improvements from previous patch
* uses QueryVisitor for traversing the Query tree
* adds Accountable to some of the classes that may be larger than default
estimate
* similarly, adds Accountable to Queries that may be much larger than the
default estimate (10x or more).
> Add Accountable to Query implementations
>
>
> Key: LUCENE-8855
> URL: https://issues.apache.org/jira/browse/LUCENE-8855
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: LUCENE-8855.patch, LUCENE-8855.patch, LUCENE-8855.patch
>
>
> Query implementations should also support {{Accountable}} API in order to
> monitor the memory consumption e.g. in caches where either keys or values are
> {{Query}} instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8855) Add Accountable to Query implementations
[
https://issues.apache.org/jira/browse/LUCENE-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki updated LUCENE-8855:
--
Attachment: LUCENE-8855.patch
> Add Accountable to Query implementations
>
>
> Key: LUCENE-8855
> URL: https://issues.apache.org/jira/browse/LUCENE-8855
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: LUCENE-8855.patch, LUCENE-8855.patch, LUCENE-8855.patch
>
>
> Query implementations should also support {{Accountable}} API in order to
> monitor the memory consumption e.g. in caches where either keys or values are
> {{Query}} instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8870) Support numeric value in Field class
[
https://issues.apache.org/jira/browse/LUCENE-8870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867819#comment-16867819
]
Namgyu Kim commented on LUCENE-8870:
About the TestField class,
I think its class structure needs to be changed slightly.
It is no direct connection with this issue.
But I plan to modify it like TestIntPoint, TestDoublePoint, ...
Should not the test class name depend on the class name?
What do you think about it?
> Support numeric value in Field class
>
>
> Key: LUCENE-8870
> URL: https://issues.apache.org/jira/browse/LUCENE-8870
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Namgyu Kim
>Priority: Major
> Attachments: LUCENE-8870.patch
>
>
> I checked the following comment in Field class.
> {code:java}
> // TODO: allow direct construction of int, long, float, double value too..?
> {code}
> We already have some fields like IntPoint and StoredField, but I think it's
> okay.
> The test cases are set in the TestField class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8870) Support numeric value in Field class
[
https://issues.apache.org/jira/browse/LUCENE-8870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Namgyu Kim updated LUCENE-8870:
---
Attachment: LUCENE-8870.patch
> Support numeric value in Field class
>
>
> Key: LUCENE-8870
> URL: https://issues.apache.org/jira/browse/LUCENE-8870
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Namgyu Kim
>Priority: Major
> Attachments: LUCENE-8870.patch
>
>
> I checked the following comment in Field class.
> {code:java}
> // TODO: allow direct construction of int, long, float, double value too..?
> {code}
> We already have some fields like IntPoint and StoredField, but I think it's
> okay.
> The test cases are set in the TestField class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8870) Support numeric value in Field class
Namgyu Kim created LUCENE-8870:
--
Summary: Support numeric value in Field class
Key: LUCENE-8870
URL: https://issues.apache.org/jira/browse/LUCENE-8870
Project: Lucene - Core
Issue Type: New Feature
Reporter: Namgyu Kim
Attachments: LUCENE-8870.patch
I checked the following comment in Field class.
{code:java}
// TODO: allow direct construction of int, long, float, double value too..?
{code}
We already have some fields like IntPoint and StoredField, but I think it's
okay.
The test cases are set in the TestField class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13523) Atomic Update results in NullPointerException
[
https://issues.apache.org/jira/browse/SOLR-13523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867815#comment-16867815
]
David Smiley commented on SOLR-13523:
-
Suggested CHANGES.txt (Bug):
{quote}SOLR-13523: Atomic Updates were broken when the schema declared the new
\_nest_path_ field even if you weren't using nested docs. In-place updates
were not affected (worked). Reminder: if you don't need nested docs then
remove both \_root_ and \_nest_path_ !
{quote}
CC [~caomanhdat] I think this nasty bug ought to be fixed in 8.1.2
> Atomic Update results in NullPointerException
> -
>
> Key: SOLR-13523
> URL: https://issues.apache.org/jira/browse/SOLR-13523
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 8.0
> Environment: * Operating system: Win10 v1803 build 17143.766
> * Java version:
> java 11.0.1 2018-10-16 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)
> * solr-spec: 8.1.1
> * solr-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:20:01
> * lucene-spec: 8.1.1
> * lucene-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:15:24
>Reporter: Kieran Devlin
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-13523.patch, SOLR-13523.patch,
> SOLR-13523_WIP_bug_hunt.patch, XUBrk.png, Xn1RW.png, reproduce.sh
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Partially update a document via an atomic update, when I do so, the web sever
> responds with a 500 status with the stack trace:
> {code:java}
> { "responseHeader":{ "status":500, "QTime":1}, "error":{
> "trace":"java.lang.NullPointerException\r\n\tat
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.getFieldFromHierarchy(AtomicUpdateDocumentMerger.java:301)\r\n\tat
>
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDoc(AtomicUpdateDocumentMerger.java:398)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:697)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:372)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:337)\r\n\tat
>
> org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:337)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:223)\r\n\tat
>
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:475)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldNameMutatingUpdateProcessorFactory$1.processAdd(FieldNameMutatingUpdateProcessorFactory.java:75)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.AbstractDefaultV
[jira] [Updated] (SOLR-13523) Atomic Update results in NullPointerException
[
https://issues.apache.org/jira/browse/SOLR-13523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-13523:
Assignee: David Smiley
Attachment: SOLR-13523.patch
Status: Patch Available (was: Patch Available)
I'm attaching a complete fix as a patch file. The GitHub PR and earlier
patches bear no resemblance to this; they were more exploratory. So I started
afresh.
The {{test-files/solr/collection1/conf/schema.xml}} schema is used by a ton of
tests including AtomicUpdatesTest. Surprisingly, most test schemas including
this one has it's root field declared as stored=true. This is odd because
there's no need for it except for a very niche feature in 8.0 involving
submitting an atomic update directly to a child doc; and we've got a separate
schema and test just for that case. So I set it to false. I also added
nest_path to this schema so as to make our default tests exercise code paths
closer to the default schema. AtomicUpdatesTest then fails, revealing the bug.
The bug fix is as I mentioned earlier -- DistributedUpdateProcesor that
assumes it can get the root field from a document it retrieved from the index
or TLog. Well it's very rare realistically it will be able to. So if it's
null (which will be typical), we don't go down the code path of atomic updates
to child docs, which would doom in an NPE.
The AtomicUpdatesTest was asserting the number of fields, which changed with
the removal of root being stored, so I removed these assertions as I don't
think they were useful at all.
The UpdateRequestProcessorFactoryTest was updated to accommodate the presence
of NestedUpdateProcessor.
I had difficulty getting tests runs to pass due to Java 11 and SSL issues since
I don't have 11.0.3 available yet. But AFAICT the patch hasn't broken stuff.
> Atomic Update results in NullPointerException
> -
>
> Key: SOLR-13523
> URL: https://issues.apache.org/jira/browse/SOLR-13523
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 8.0
> Environment: * Operating system: Win10 v1803 build 17143.766
> * Java version:
> java 11.0.1 2018-10-16 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)
> * solr-spec: 8.1.1
> * solr-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:20:01
> * lucene-spec: 8.1.1
> * lucene-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:15:24
>Reporter: Kieran Devlin
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-13523.patch, SOLR-13523.patch,
> SOLR-13523_WIP_bug_hunt.patch, XUBrk.png, Xn1RW.png, reproduce.sh
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Partially update a document via an atomic update, when I do so, the web sever
> responds with a 500 status with the stack trace:
> {code:java}
> { "responseHeader":{ "status":500, "QTime":1}, "error":{
> "trace":"java.lang.NullPointerException\r\n\tat
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.getFieldFromHierarchy(AtomicUpdateDocumentMerger.java:301)\r\n\tat
>
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDoc(AtomicUpdateDocumentMerger.java:398)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:697)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:372)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:337)\r\n\tat
>
> org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:337)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:223)\r\n\tat
>
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:475)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
[jira] [Commented] (LUCENE-8816) Decouple Kuromoji's morphological analyser and its dictionary
[ https://issues.apache.org/jira/browse/LUCENE-8816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867793#comment-16867793 ] Tomoko Uchida commented on LUCENE-8816: --- I opened LUCENE-8869 to just decouple the system dictionary resource to a separated jar, and use it as default (as is). > Decouple Kuromoji's morphological analyser and its dictionary > - > > Key: LUCENE-8816 > URL: https://issues.apache.org/jira/browse/LUCENE-8816 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Tomoko Uchida >Priority: Major > > I've inspired by this mail-list thread. > > [http://mail-archives.apache.org/mod_mbox/lucene-java-user/201905.mbox/%3CCAGUSZHA3U_vWpRfxQb4jttT7sAOu%2BuaU8MfvXSYgNP9s9JNsXw%40mail.gmail.com%3E] > As many Japanese already know, default built-in dictionary bundled with > Kuromoji (MeCab IPADIC) is a bit old and no longer maintained for many years. > While it has been slowly obsoleted, well-maintained and/or extended > dictionaries risen up in recent years (e.g. > [mecab-ipadic-neologd|https://github.com/neologd/mecab-ipadic-neologd], > [UniDic|https://unidic.ninjal.ac.jp/]). To use them with Kuromoji, some > attempts/projects/efforts are made in Japan. > However current architecture - dictionary bundled jar - is essentially > incompatible with the idea "switch the system dictionary", and developers > have difficulties to do so. > Traditionally, the morphological analysis engine (viterbi logic) and the > encoded dictionary (language model) had been decoupled (like MeCab, the > origin of Kuromoji, or lucene-gosen). So actually decoupling them is a > natural idea, and I feel that it's good time to re-think the current > architecture. > Also this would be good for advanced users who have customized/re-trained > their own system dictionary. > Goals of this issue: > * Decouple JapaneseTokenizer itself and encoded system dictionary. > * Implement dynamic dictionary load mechanism. > * Provide developer-oriented dictionary build tool. > Non-goals: > * Provide learner or language model (it's up to users and should be outside > the scope). > I have not dove into the code yet, so have no idea about it's easy or > difficult at this moment. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Use of JIRA fixVersion
Can we address this in JIRA? In the past I've seen this handled in JIRA by also having a 'target' version field - this is the intended version you want to land in and you set it right away. Things were configured so you could only set the fix version when you resolved I think. Then you would use target for release blockers and such. Fix would just tell you what it's actually in. On Mon, Jun 17, 2019 at 4:49 AM Adrien Grand wrote: > +1 to Jan's proposal about not adding master when changes are also pushed > to the previous major, I like the additional consistency with our > CHANGES.txt. > > I'm less sure about requiring that the fix version is not set before > resolving the issue, I have used this in combination with the blocker label > to mean that an issue needs to be addressed before releasing, sometimes it > will be the next minor, sometimes the next major. For the record, the > ReleaseTodo[1] recommends to check for blockers by filtering by priority > and fixVersion. > > [1] https://wiki.apache.org/lucene-java/ReleaseTodo > > On Fri, Jun 14, 2019 at 11:30 PM Gus Heck wrote: > >> FWIW I tend to agree with Erick here on both his points, but the second >> one more strongly than the first. The first I can live with either way >> really so long as it's clearly documented somewhere (besides this thread). >> >> If we don't update the changes in master for bug fixes when we're >> committing, who's going to go collect and add them later? I'm not sure I'm >> that big a fan of generating changes... I haven't looked at Yetus >> specifically but I suspect that this will just leave us with the title from >> the Jira, and often some additional detail for changes is worthwhile beyond >> what the title says. So if we create a field in Jira that is the Changes >> text, and make it required in the resolution screen fine to generate from >> that, but I think there's real value in the current system because you wind >> up writing a final short 1-4 line summary focused on "what the user needs >> to know" >> >> Also line 3, the feature only in 8x (but not master) is a very odd case >> in that table, I'm not sure when that would happen? could happen for a bug >> that is fixed by other changes in master, but for a feature? >> >> Also if we aren't marking branches explicitly maybe the 9.0 (master) tag >> should say 9.0 (unreleased)? Sure most developers know master is typically >> unreleased, but why add that mental leap. It's possible that someone less >> technical, or who is a student will stumble in from a link on SO... >> >> -Gus >> >> On Thu, Jun 13, 2019 at 3:23 PM David Smiley >> wrote: >> >>> +1 to your plan Jan. >>> >>> ~ David Smiley >>> Apache Lucene/Solr Search Developer >>> http://www.linkedin.com/in/davidwsmiley >>> >>> >>> On Thu, Jun 13, 2019 at 8:40 AM Jan Høydahl >>> wrote: >>> Trying to reach a conclusion (or perhaps a vote) on this. Here is a table that sums up my proposal. Basically it means in most cases stop adding master as fixVersion. Type Committed to fixVersion CHANGES.txt section Feature master master (9.0) 9.0 Feature master, branch_8x 8.2 8.2 Feature branch_8x 8.2 8.2 Bugfix master master (9.0) none (unreleased bug) Bugfix master, branch_8x 8.2 8.2 Bugfix master, branch_8x, branch_8_1 8.1.2, 8.2 8.1.2, 8.2 Bugfix branch_8x 8.2 8.2 Bugfix branch_8_1 8.1.2 8.1.2 Bugfix branch_8x, branch_7_7 7.7.3, 8.2 7.7.3, 8.2 In addition to this, we should all wait until commit time with setting fixVersion. To find branches for a JIRA, you just translate fixVersion to branch, e.g. 8.1.2, 8.2 -> branch_8_1, branch_8x. For features, if it is unclear whether master has the commit, check gitbot log or git log For bugfixes, there are cases where the bug does not exist in master at all, and that can be reflected in affectsVersion field. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com 3. jun. 2019 kl. 19:56 skrev David Smiley : Right JIRA fixVersion has its use, and that would satisfy this use-case? It's what Jan proposes to do this very thing as part of generating release notes in a semi-automated way. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Mon, Jun 3, 2019 at 11:38 AM Erick Erickson wrote: > > > > On Jun 3, 2019, at 6:41 AM, David Smiley > wrote: > > > > If someone wants to know what branches an issue was committed to, > then review the bot comments to find out. > > What if I want to form a query that shows me all JIRAs fixed in > version X.Y.Z? > > A bot comments with “branch_5x” doesn’t tell me which minor version > it’s in, 5.1? 5.5? > - > To unsubscribe, e-mail: dev-unsubscr...@lu
[JENKINS] Lucene-Solr-8.x-Solaris (64bit/jdk1.8.0) - Build # 188 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Solaris/188/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
All tests passed
Build Log:
[...truncated 12825 lines...]
[javac] Compiling 55 source files to
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/build/solr-test-framework/classes/java
[javac]
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/test-framework/src/java/org/apache/solr/util/SSLTestConfig.java:108:
error: cannot find symbol
[javac] if (Constants.JRE_IS_MINIMUM_JAVA11 &&
Runtime.version().compareTo(Runtime.Version.parse("11.0.3")) < 0) {
[javac]
^
[javac] symbol: variable Version
[javac] location: class Runtime
[javac]
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/test-framework/src/java/org/apache/solr/util/SSLTestConfig.java:108:
error: cannot find symbol
[javac] if (Constants.JRE_IS_MINIMUM_JAVA11 &&
Runtime.version().compareTo(Runtime.Version.parse("11.0.3")) < 0) {
[javac] ^
[javac] symbol: method version()
[javac] location: class Runtime
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors
BUILD FAILED
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/build.xml:634: The
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/build.xml:578: The
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/build.xml:59: The
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/build.xml:231: The
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/common-build.xml:558:
The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/common-build.xml:446:
The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/test-framework/build.xml:42:
The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/lucene/common-build.xml:2056:
Compile failed; see the compiler error output for details.
Total time: 28 minutes 46 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8869) Build kuromoji system dictionary as a separated jar and load it from JapaneseTokenizer at runtime
[
https://issues.apache.org/jira/browse/LUCENE-8869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated LUCENE-8869:
--
Description:
This is a sub-task for LUCENE-8816.
In this issue, I will try to make small but self-contained changes to kuromoji
system dictionary.
- Make it possible to build a jar that contains (maybe) only dictionary data
resource generated by the {{build-dict}} task.
-- Maybe a new ant target will be added.
- Make it possible to load external dictionary when initializing
JapaneseTokenizer.
-- Some work are already done on LUCENE-8863
- Decouple current system dictionary data (mecab ipadic) from kuromoji itself
and use it as default (Possibly it can be done with another issue).
Also, some refactoring of the directory/source tree structure may be needed.
was:
This is a sub-task for LUCENE-8816.
In this issue, I will try to make small but self-contained changes to kuromoji
system dictionary.
- Make it possible to build a jar that contains (maybe) only dictionary data
resource generated by the {{build-dict}} task.
- Make it possible to load external dictionary when initializing
JapaneseTokenizer.
-- Some work are already done on LUCENE-8863
- Decouple current system dictionary data (mecab ipadic) from kuromoji itself
and use it as default (Possibly it can be done with another issue).
Also, some refactoring of the directory/source tree structure may be needed.
> Build kuromoji system dictionary as a separated jar and load it from
> JapaneseTokenizer at runtime
> -
>
> Key: LUCENE-8869
> URL: https://issues.apache.org/jira/browse/LUCENE-8869
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Priority: Major
>
> This is a sub-task for LUCENE-8816.
> In this issue, I will try to make small but self-contained changes to
> kuromoji system dictionary.
> - Make it possible to build a jar that contains (maybe) only dictionary data
> resource generated by the {{build-dict}} task.
> -- Maybe a new ant target will be added.
> - Make it possible to load external dictionary when initializing
> JapaneseTokenizer.
> -- Some work are already done on LUCENE-8863
> - Decouple current system dictionary data (mecab ipadic) from kuromoji
> itself and use it as default (Possibly it can be done with another issue).
> Also, some refactoring of the directory/source tree structure may be needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8869) Build kuromoji system dictionary as a separated jar and load it from JapaneseTokenizer at runtime
Tomoko Uchida created LUCENE-8869:
-
Summary: Build kuromoji system dictionary as a separated jar and
load it from JapaneseTokenizer at runtime
Key: LUCENE-8869
URL: https://issues.apache.org/jira/browse/LUCENE-8869
Project: Lucene - Core
Issue Type: Improvement
Components: modules/analysis
Reporter: Tomoko Uchida
This is a sub-task for LUCENE-8816.
In this issue, I will try to make small but self-contained changes to kuromoji
system dictionary.
- Make it possible to build a jar that contains (maybe) only dictionary data
resource generated by the {{build-dict}} task.
- Make it possible to load external dictionary when initializing
JapaneseTokenizer.
-- Some work are already done on LUCENE-8863
- Decouple current system dictionary data (mecab ipadic) from kuromoji itself
and use it as default (Possibly it can be done with another issue).
Also, some refactoring of the directory/source tree structure may be needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] nknize commented on issue #726: LUCENE-8632: New XYShape Field and Queries for indexing and searching general cartesian geometries
nknize commented on issue #726: LUCENE-8632: New XYShape Field and Queries for indexing and searching general cartesian geometries URL: https://github.com/apache/lucene-solr/pull/726#issuecomment-503627542 With extensions like this (and possibly more to come) it certainly adds a lot to core. I'm not at all bound to the idea that `LatLonShape` **must** go in core. The `spatial` module is largely empty so I'm certainly open to relocating both `LatLonShape` and `XYShape` to the spatial module while keeping it dependency free and having only `LatLonPoint` in core. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13523) Atomic Update results in NullPointerException
[
https://issues.apache.org/jira/browse/SOLR-13523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-13523:
Component/s: (was: JSON Request API)
> Atomic Update results in NullPointerException
> -
>
> Key: SOLR-13523
> URL: https://issues.apache.org/jira/browse/SOLR-13523
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 8.0
> Environment: * Operating system: Win10 v1803 build 17143.766
> * Java version:
> java 11.0.1 2018-10-16 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)
> * solr-spec: 8.1.1
> * solr-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:20:01
> * lucene-spec: 8.1.1
> * lucene-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:15:24
>Reporter: Kieran Devlin
>Priority: Major
> Attachments: SOLR-13523.patch, SOLR-13523_WIP_bug_hunt.patch,
> XUBrk.png, Xn1RW.png, reproduce.sh
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Partially update a document via an atomic update, when I do so, the web sever
> responds with a 500 status with the stack trace:
> {code:java}
> { "responseHeader":{ "status":500, "QTime":1}, "error":{
> "trace":"java.lang.NullPointerException\r\n\tat
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.getFieldFromHierarchy(AtomicUpdateDocumentMerger.java:301)\r\n\tat
>
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDoc(AtomicUpdateDocumentMerger.java:398)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:697)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:372)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:337)\r\n\tat
>
> org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:337)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:223)\r\n\tat
>
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:475)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldNameMutatingUpdateProcessorFactory$1.processAdd(FieldNameMutatingUpdateProcessorFactory.java:75)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.AbstractDefaultValueUpdateProcessorFactory$DefaultValueUpdateProcessor.processAdd(AbstractDefaultValueUpdateProcessorFactory.java:92)\r\n\tat
>
> org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleAdds(JsonLoader.java:507)\r\n\tat
>
> org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:145)\r\n\tat
>
> org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load(JsonLoade
[jira] [Created] (SOLR-13563) SPLITSHARD - Using LINK method fails on disk usage checks
Andrew Kettmann created SOLR-13563:
--
Summary: SPLITSHARD - Using LINK method fails on disk usage checks
Key: SOLR-13563
URL: https://issues.apache.org/jira/browse/SOLR-13563
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: AutoScaling, SolrCloud
Affects Versions: 7.7.2
Reporter: Andrew Kettmann
Attachments: disk_check.patch
Raised this on the mailing list and was told to open an issue, copy/pasting the
context here:
Using Solr 7.7.2 Docker image, testing some of the new autoscale features, huge
fan so far. Tested with the link method on a 2GB core and found that it took
less than 1MB of additional space. Filled the core quite a bit larger, 12GB of
a 20GB PVC, and now splitting the shard fails with the following error message
on my overseer:
{code:java}
2019-06-18 16:27:41.754 ERROR
(OverseerThreadFactory-49-thread-5-processing-n:10.0.192.74:8983_solr)
[c:test_autoscale s:shard1 ]
o.a.s.c.a.c.OverseerCollectionMessageHandler Collection: test_autoscale
operation: splitshard
failed:org.apache.solr.common.SolrException: not enough free disk space
to perform index split on node 10.0.193.23:8983_solr, required:
23.35038321465254, available: 7.811378479003906
at
org.apache.solr.cloud.api.collections.SplitShardCmd.checkDiskSpace(SplitShardCmd.java:567)
at
org.apache.solr.cloud.api.collections.SplitShardCmd.split(SplitShardCmd.java:138)
at
org.apache.solr.cloud.api.collections.SplitShardCmd.call(SplitShardCmd.java:94)
at
org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:294)
at
org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:505)
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
I attempted sending the request to the node itself to see if it did anything
different, but no luck. My parameters are (Note Python formatting as that is my
language of choice):
{code:java}
splitparams = {'action':'SPLITSHARD',
'collection':'test_autoscale',
'shard':'shard1',
'splitMethod':'link',
'timing':'true',
'async':'shardsplitasync'}{code}
And this is confirmed by the log message from the node itself:
{code:java}
2019-06-18 16:27:41.730 INFO
(qtp1107530534-16) [c:test_autoscale ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/collections
params={async=shardsplitasync&timing=true&action=SPLITSHARD&collection=test_autoscale&shard=shard1&splitMethod=link}
status=0 QTime=20{code}
While it is true I do not have enough space if I were using the rewrite method,
the link method on a 2GB core used an additional less than 1MB of space. Is
there something I am missing here? is there an option to disable the disk space
check that I need to pass? I can't find anything in the documentation at this
point.
--
After this initial email, I found the issue and compiled with the attached
patch and running the modification on the overseer only resolved the issue, as
the overseer is what runs the check.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-MacOSX (64bit/jdk-11.0.2) - Build # 194 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/194/ Java: 64bit/jdk-11.0.2 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 2102 lines...] [junit4] JVM J0: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/core/test/temp/junit4-J0-20190619_151045_7429085281110853374715.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 5 lines...] [junit4] JVM J1: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/core/test/temp/junit4-J1-20190619_151045_7428135470514486651873.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 299 lines...] [junit4] JVM J0: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/test-framework/test/temp/junit4-J0-20190619_152606_21215276941889753626002.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [junit4] JVM J1: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/test-framework/test/temp/junit4-J1-20190619_152606_2129921217083685735024.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 1080 lines...] [junit4] JVM J1: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/analysis/common/test/temp/junit4-J1-20190619_152753_0211959143445253907225.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 3 lines...] [junit4] JVM J0: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/analysis/common/test/temp/junit4-J0-20190619_152753_0209477454934837621174.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 259 lines...] [junit4] JVM J0: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/analysis/icu/test/temp/junit4-J0-20190619_153240_98915723175828187906714.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [junit4] JVM J1: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/analysis/icu/test/temp/junit4-J1-20190619_153240_9931869099838759898287.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 253 lines...] [junit4] JVM J0: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/analysis/kuromoji/test/temp/junit4-J0-20190619_153302_57816921580037860097584.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 3 lines...] [junit4] JVM J1: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/analysis/kuromoji/test/temp/junit4-J1-20190619_153302_5781155977509709446949.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 162 lines...] [junit4] JVM J1: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/analysis/morfologik/test/temp/junit4-J1-20190619_153350_23415828848976745653320.syserr
[GitHub] [lucene-solr] mocobeta commented on a change in pull request #722: LUCENE-8863: handle some edge cases in Kuromoji DictionaryBuilder, en…
mocobeta commented on a change in pull request #722: LUCENE-8863: handle some
edge cases in Kuromoji DictionaryBuilder, en…
URL: https://github.com/apache/lucene-solr/pull/722#discussion_r295361715
##
File path:
lucene/analysis/kuromoji/src/java/org/apache/lucene/analysis/ja/dict/BinaryDictionary.java
##
@@ -46,13 +50,31 @@
public static final String POSDICT_HEADER = "kuromoji_dict_pos";
public static final int VERSION = 1;
+ static final String CLASSPATH = "classpath:";
+ static final String FILE = "file:";
+
+ private final String resourcePrefix;
private final ByteBuffer buffer;
private final int[] targetMapOffsets, targetMap;
private final String[] posDict;
private final String[] inflTypeDict;
private final String[] inflFormDict;
protected BinaryDictionary() throws IOException {
+this(CLASSPATH);
+ }
+
+ /**
+ * @param resourcePrefix - where to load resources (dictionaries) from.
Either "file:", followed
+ * by a filesystem directory and optionally a filename-prefix, or
"classpath:", followed by a
+ * classpath location prefix, or just plain "classpath:" to use this class's
name as the prefix.
+ */
+ protected BinaryDictionary(String resourcePrefix) throws IOException {
Review comment:
If the resourcePrefix parameter takes only "classpath:" or "file:", would it
be possible to use enum here instead of arbitrary String?.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta commented on a change in pull request #722: LUCENE-8863: handle some edge cases in Kuromoji DictionaryBuilder, en…
mocobeta commented on a change in pull request #722: LUCENE-8863: handle some
edge cases in Kuromoji DictionaryBuilder, en…
URL: https://github.com/apache/lucene-solr/pull/722#discussion_r295366836
##
File path:
lucene/analysis/kuromoji/src/java/org/apache/lucene/analysis/ja/dict/BinaryDictionary.java
##
@@ -46,13 +50,31 @@
public static final String POSDICT_HEADER = "kuromoji_dict_pos";
public static final int VERSION = 1;
+ static final String CLASSPATH = "classpath:";
+ static final String FILE = "file:";
+
+ private final String resourcePrefix;
private final ByteBuffer buffer;
private final int[] targetMapOffsets, targetMap;
private final String[] posDict;
private final String[] inflTypeDict;
private final String[] inflFormDict;
protected BinaryDictionary() throws IOException {
+this(CLASSPATH);
+ }
+
+ /**
+ * @param resourcePrefix - where to load resources (dictionaries) from.
Either "file:", followed
+ * by a filesystem directory and optionally a filename-prefix, or
"classpath:", followed by a
+ * classpath location prefix, or just plain "classpath:" to use this class's
name as the prefix.
+ */
+ protected BinaryDictionary(String resourcePrefix) throws IOException {
Review comment:
And just wondering, why do we need "file:" prefix? I feel like that loading
the dictionary data from arbitrary location could be problematic... (Am I
missing anything?)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta commented on a change in pull request #722: LUCENE-8863: handle some edge cases in Kuromoji DictionaryBuilder, en…
mocobeta commented on a change in pull request #722: LUCENE-8863: handle some
edge cases in Kuromoji DictionaryBuilder, en…
URL: https://github.com/apache/lucene-solr/pull/722#discussion_r295361715
##
File path:
lucene/analysis/kuromoji/src/java/org/apache/lucene/analysis/ja/dict/BinaryDictionary.java
##
@@ -46,13 +50,31 @@
public static final String POSDICT_HEADER = "kuromoji_dict_pos";
public static final int VERSION = 1;
+ static final String CLASSPATH = "classpath:";
+ static final String FILE = "file:";
+
+ private final String resourcePrefix;
private final ByteBuffer buffer;
private final int[] targetMapOffsets, targetMap;
private final String[] posDict;
private final String[] inflTypeDict;
private final String[] inflFormDict;
protected BinaryDictionary() throws IOException {
+this(CLASSPATH);
+ }
+
+ /**
+ * @param resourcePrefix - where to load resources (dictionaries) from.
Either "file:", followed
+ * by a filesystem directory and optionally a filename-prefix, or
"classpath:", followed by a
+ * classpath location prefix, or just plain "classpath:" to use this class's
name as the prefix.
+ */
+ protected BinaryDictionary(String resourcePrefix) throws IOException {
Review comment:
If the resourcePrefix parameter takes only "classpath:" or "file:", would it
be possible to use enum here instead of arbitrary String (for safety)?.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta commented on a change in pull request #722: LUCENE-8863: handle some edge cases in Kuromoji DictionaryBuilder, en…
mocobeta commented on a change in pull request #722: LUCENE-8863: handle some
edge cases in Kuromoji DictionaryBuilder, en…
URL: https://github.com/apache/lucene-solr/pull/722#discussion_r295366836
##
File path:
lucene/analysis/kuromoji/src/java/org/apache/lucene/analysis/ja/dict/BinaryDictionary.java
##
@@ -46,13 +50,31 @@
public static final String POSDICT_HEADER = "kuromoji_dict_pos";
public static final int VERSION = 1;
+ static final String CLASSPATH = "classpath:";
+ static final String FILE = "file:";
+
+ private final String resourcePrefix;
private final ByteBuffer buffer;
private final int[] targetMapOffsets, targetMap;
private final String[] posDict;
private final String[] inflTypeDict;
private final String[] inflFormDict;
protected BinaryDictionary() throws IOException {
+this(CLASSPATH);
+ }
+
+ /**
+ * @param resourcePrefix - where to load resources (dictionaries) from.
Either "file:", followed
+ * by a filesystem directory and optionally a filename-prefix, or
"classpath:", followed by a
+ * classpath location prefix, or just plain "classpath:" to use this class's
name as the prefix.
+ */
+ protected BinaryDictionary(String resourcePrefix) throws IOException {
Review comment:
And just wondering, why do we need "file:" prefix? I feel like that loading
the dictionary data from arbitrary location could be problematic... (Am I
missed anything?)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] colvinco commented on a change in pull request #723: SOLR-13545: AutoClose stream in ContentStreamUpdateRequest
colvinco commented on a change in pull request #723: SOLR-13545: AutoClose
stream in ContentStreamUpdateRequest
URL: https://github.com/apache/lucene-solr/pull/723#discussion_r295354220
##
File path:
solr/solrj/src/test/org/apache/solr/client/solrj/SolrExampleTests.java
##
@@ -710,10 +714,18 @@ public void testContentStreamRequest() throws Exception {
Assert.assertEquals(0, rsp.getResults().getNumFound());
ContentStreamUpdateRequest up = new ContentStreamUpdateRequest("/update");
-up.addFile(getFile("solrj/books.csv"), "application/csv");
+// Create a copy of the file, which can be deleted after uploading.
+// If the stream isn't closed, the file deletion will fail on Windows,
+// though it will succeed on linux regardless
+final File file = new File("temp/books_copy.csv");
Review comment:
Thanks, for some reason I thought that createTempFile() wouldn't work for
what I was doing (too late at night). I've changed that
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-8.x - Build # 250 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/250/
All tests passed
Build Log:
[...truncated 12859 lines...]
[javac] Compiling 55 source files to
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/build/solr-test-framework/classes/java
[javac]
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/test-framework/src/java/org/apache/solr/util/SSLTestConfig.java:108:
error: cannot find symbol
[javac] if (Constants.JRE_IS_MINIMUM_JAVA11 &&
Runtime.version().compareTo(Runtime.Version.parse("11.0.3")) < 0) {
[javac]
^
[javac] symbol: variable Version
[javac] location: class Runtime
[javac]
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/test-framework/src/java/org/apache/solr/util/SSLTestConfig.java:108:
error: cannot find symbol
[javac] if (Constants.JRE_IS_MINIMUM_JAVA11 &&
Runtime.version().compareTo(Runtime.Version.parse("11.0.3")) < 0) {
[javac] ^
[javac] symbol: method version()
[javac] location: class Runtime
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:634: The
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:578: The
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:59: The
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/build.xml:231:
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:558:
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:446:
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/test-framework/build.xml:42:
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:2056:
Compile failed; see the compiler error output for details.
Total time: 40 minutes 49 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8863) Improve handling of edge cases in Kuromoji's DIctionaryBuilder
[
https://issues.apache.org/jira/browse/LUCENE-8863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867709#comment-16867709
]
Tomoko Uchida commented on LUCENE-8863:
---
One small thing:
I think the issue title should be changed to more descriptive one. (It's hard
to imagine to me that new Dictionary constructors was added with an issue named
"Improve handling of edge cases in Kuromoji's DIctionaryBuilder"...)
> Improve handling of edge cases in Kuromoji's DIctionaryBuilder
> --
>
> Key: LUCENE-8863
> URL: https://issues.apache.org/jira/browse/LUCENE-8863
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Mike Sokolov
>Assignee: Mike Sokolov
>Priority: Major
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> While building a custom Kuromoji system dictionary, I discovered a few issues.
> First, the dictionary encoding has room for 13-bit (left and right) ids, but
> really only supports 12 bits since this was all that was needed for the
> IPADIC dictionary that ships with Kuromoji. The good news is we can easily
> add support by fixing the bit-twiddling math.
> Second, the dictionary builder has a number of assertions that help uncover
> problems in the input (like these overlarge ids), but the assertions aren't
> enabled by default, so an unsuspecting new user doesn't get any benefit from
> them, so we should upgrade to "real" exceptions.
> Finally, we want to handle the case of empty base forms differently. Kuromoji
> does stemming by substituting a base form for a word when there is a base
> form in the dictionary. Missing base forms are expected to be supplied as
> {{*}}, but if a dictionary provides an empty string base form, we would end
> up stripping that token completely. Since there is no possible meaning for an
> empty base form (and the dictionary builder already treats {{*}} and empty
> strings as equivalent in a number of other cases), I think we should simply
> ignore empty base forms (rather than replacing words with empty strings when
> tokenizing!)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-8.x-Linux (64bit/jdk-13-ea+18) - Build # 731 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/731/
Java: 64bit/jdk-13-ea+18 -XX:-UseCompressedOops -XX:+UseParallelGC
All tests passed
Build Log:
[...truncated 12908 lines...]
[javac] Compiling 55 source files to
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/build/solr-test-framework/classes/java
[javac]
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/test-framework/src/java/org/apache/solr/util/SSLTestConfig.java:108:
error: cannot find symbol
[javac] if (Constants.JRE_IS_MINIMUM_JAVA11 &&
Runtime.version().compareTo(Runtime.Version.parse("11.0.3")) < 0) {
[javac] ^
[javac] symbol: method version()
[javac] location: class Runtime
[javac]
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/test-framework/src/java/org/apache/solr/util/SSLTestConfig.java:108:
error: cannot find symbol
[javac] if (Constants.JRE_IS_MINIMUM_JAVA11 &&
Runtime.version().compareTo(Runtime.Version.parse("11.0.3")) < 0) {
[javac]
^
[javac] symbol: variable Version
[javac] location: class Runtime
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:634: The following
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:578: The following
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:59: The following error
occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/build.xml:231: The following
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/common-build.xml:558: The
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/common-build.xml:446: The
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/test-framework/build.xml:42:
The following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/common-build.xml:2056:
Compile failed; see the compiler error output for details.
Total time: 33 minutes 24 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13560) Add isNull and notNull Stream Evaluators
[
https://issues.apache.org/jira/browse/SOLR-13560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein resolved SOLR-13560.
---
Resolution: Fixed
Fix Version/s: 8.2
> Add isNull and notNull Stream Evaluators
>
>
> Key: SOLR-13560
> URL: https://issues.apache.org/jira/browse/SOLR-13560
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-13560.patch
>
>
> This ticket adds two Stream Evaluators for testing for null values in Tuples.
> These are much needed functions as currently null values are not possible to
> detect with the *eq* Stream Evaluator because null values are evaluated to
> the parameter name, rather then null. This change was made to support String
> literal parameters without quotes.
> The isNull and notNull Stream Evaluators properly detect nulls so they can be
> used to filter tuples in a *having* expression or replace nulls in a *select*
> expression.
> Sample syntax for null filtering:
> {code:java}
> having(random(testapp, q="*:*", fl="response_d", rows="2"),
>notNull(response_d)){code}
> Sample syntax for null filterring:
> {code:java}
> select(random(testapp, q="*:*", fl="id, response_d", rows="2"),
>id,
>if(isNull(response_d),-1, response_d) as response_d){code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13560) Add isNull and notNull Stream Evaluators
[
https://issues.apache.org/jira/browse/SOLR-13560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867671#comment-16867671
]
ASF subversion and git services commented on SOLR-13560:
Commit cf8ac4dbcf499913686041c35d991518bb65df4c in lucene-solr's branch
refs/heads/branch_8x from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cf8ac4d ]
SOLR-13560: Update CHANGES.txt
> Add isNull and notNull Stream Evaluators
>
>
> Key: SOLR-13560
> URL: https://issues.apache.org/jira/browse/SOLR-13560
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-13560.patch
>
>
> This ticket adds two Stream Evaluators for testing for null values in Tuples.
> These are much needed functions as currently null values are not possible to
> detect with the *eq* Stream Evaluator because null values are evaluated to
> the parameter name, rather then null. This change was made to support String
> literal parameters without quotes.
> The isNull and notNull Stream Evaluators properly detect nulls so they can be
> used to filter tuples in a *having* expression or replace nulls in a *select*
> expression.
> Sample syntax for null filtering:
> {code:java}
> having(random(testapp, q="*:*", fl="response_d", rows="2"),
>notNull(response_d)){code}
> Sample syntax for null filterring:
> {code:java}
> select(random(testapp, q="*:*", fl="id, response_d", rows="2"),
>id,
>if(isNull(response_d),-1, response_d) as response_d){code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
