[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4922 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4922/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 5 tests failed. FAILED: org.apache.solr.cloud.RecoveryAfterSoftCommitTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:51667/mm/hc/collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:51667/mm/hc/collection1 at __randomizedtesting.SeedInfo.seed([132FCEE6E81A1F:88471014481477E7]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1107) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1260) at org.apache.solr.cloud.RecoveryAfterSoftCommitTest.test(RecoveryAfterSoftCommitTest.java:87) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1010) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:985) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) 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
[JENKINS-EA] Lucene-Solr-BadApples-7.x-Linux (64bit/jdk-12-ea+12) - Build # 117 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-7.x-Linux/117/ Java: 64bit/jdk-12-ea+12 -XX:+UseCompressedOops -XX:+UseG1GC 48 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest Error Message: Could not find collection : AutoscalingHistoryHandlerTest_collection Stack Trace: org.apache.solr.common.SolrException: Could not find collection : AutoscalingHistoryHandlerTest_collection at __randomizedtesting.SeedInfo.seed([29E33BD26971584F]:0) at org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:118) at org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:258) at org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.waitForRecovery(AutoscalingHistoryHandlerTest.java:403) at org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.setupCluster(AutoscalingHistoryHandlerTest.java:97) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:835) FAILED: junit.framework.TestSuite.org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest Error Message: Could not find collection : AutoscalingHistoryHandlerTest_collection Stack Trace: org.apache.solr.common.SolrException: Could not find collection : AutoscalingHistoryHandlerTest_collection at __randomizedtesting.SeedInfo.seed([29E33BD26971584F]:0) at org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:118) at org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:258) at org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.waitForRecovery(AutoscalingHistoryHandlerTest.java:403) at org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.setupCluster(AutoscalingHistoryHandlerTest.java:97) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at
[jira] [Commented] (LUCENE-8374) Reduce reads for sparse DocValues
[
https://issues.apache.org/jira/browse/LUCENE-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682233#comment-16682233
]
Lucene/Solr QA commented on LUCENE-8374:
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
26s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 0m 19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 0m 19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 0m 19s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 30m
26s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 37m 1s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8374 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12947631/LUCENE-8374.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-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 42ee966 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | 1.8.0_191 |
| Test Results |
https://builds.apache.org/job/PreCommit-LUCENE-Build/121/testReport/ |
| modules | C: lucene lucene/core U: lucene |
| Console output |
https://builds.apache.org/job/PreCommit-LUCENE-Build/121/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Reduce reads for sparse DocValues
> -
>
> Key: LUCENE-8374
> URL: https://issues.apache.org/jira/browse/LUCENE-8374
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
>Affects Versions: 7.5, master (8.0)
>Reporter: Toke Eskildsen
>Priority: Major
> Labels: performance
> Fix For: 7.6
>
> Attachments: LUCENE-8374.patch, LUCENE-8374.patch, LUCENE-8374.patch,
> LUCENE-8374.patch, LUCENE-8374.patch, LUCENE-8374.patch, LUCENE-8374.patch,
> LUCENE-8374_branch_7_3.patch, LUCENE-8374_branch_7_3.patch.20181005,
> LUCENE-8374_branch_7_4.patch, LUCENE-8374_branch_7_5.patch,
> entire_index_logs.txt, image-2018-10-24-07-30-06-663.png,
> image-2018-10-24-07-30-56-962.png, single_vehicle_logs.txt,
> start-2018-10-24-1_snapshot___Users_tim_Snapshots__-_YourKit_Java_Profiler_2017_02-b75_-_64-bit.png,
>
> start-2018-10-24_snapshot___Users_tim_Snapshots__-_YourKit_Java_Profiler_2017_02-b75_-_64-bit.png
>
>
> The {{Lucene70DocValuesProducer}} has the internal classes
> {{SparseNumericDocValues}} and {{BaseSortedSetDocValues}} (sparse code path),
> which again uses {{IndexedDISI}} to handle the docID -> value-ordinal lookup.
> The value-ordinal is the index of the docID assuming an abstract tightly
> packed monotonically increasing list of docIDs: If the docIDs with
> corresponding values are {{[0, 4, 1432]}}, their value-ordinals will be {{[0,
> 1, 2]}}.
> h2. Outer blocks
> The lookup structure of {{IndexedDISI}} consists of blocks of 2^16 values
> (65536), where each block can be either {{ALL}}, {{DENSE}} (2^12 to 2^16
> values) or {{SPARSE}} (< 2^12 values ~= 6%). Consequently blocks vary quite a
> lot in size and ordinal resolving strategy.
> When a sparse Numeric DocValue is needed, the code first locates the block
> containing the wanted docID flag. It does so by iterating blocks one-by-one
> until it reaches the needed one, where each iteration requires a lookup in
> the underlying {{IndexSlice}}. For a common memory mapped index, this
[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 207 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/207/
6 tests failed.
FAILED:
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica
Error Message:
Expected new active leader null Live Nodes: [127.0.0.1:34395_solr,
127.0.0.1:34896_solr, 127.0.0.1:35838_solr] Last available state:
DocCollection(raceDeleteReplica_true//collections/raceDeleteReplica_true/state.json/13)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{"shard1":{
"range":"8000-7fff", "state":"active", "replicas":{
"core_node3":{ "core":"raceDeleteReplica_true_shard1_replica_n1",
"base_url":"https://127.0.0.1:39120/solr;,
"node_name":"127.0.0.1:39120_solr", "state":"down",
"type":"NRT", "leader":"true"}, "core_node6":{
"core":"raceDeleteReplica_true_shard1_replica_n5",
"base_url":"https://127.0.0.1:39120/solr;,
"node_name":"127.0.0.1:39120_solr", "state":"down",
"type":"NRT"}, "core_node4":{
"core":"raceDeleteReplica_true_shard1_replica_n2",
"base_url":"https://127.0.0.1:34395/solr;,
"node_name":"127.0.0.1:34395_solr", "state":"down",
"type":"NRT", "router":{"name":"compositeId"}, "maxShardsPerNode":"1",
"autoAddReplicas":"false", "nrtReplicas":"2", "tlogReplicas":"0"}
Stack Trace:
java.lang.AssertionError: Expected new active leader
null
Live Nodes: [127.0.0.1:34395_solr, 127.0.0.1:34896_solr, 127.0.0.1:35838_solr]
Last available state:
DocCollection(raceDeleteReplica_true//collections/raceDeleteReplica_true/state.json/13)={
"pullReplicas":"0",
"replicationFactor":"2",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
"core_node3":{
"core":"raceDeleteReplica_true_shard1_replica_n1",
"base_url":"https://127.0.0.1:39120/solr;,
"node_name":"127.0.0.1:39120_solr",
"state":"down",
"type":"NRT",
"leader":"true"},
"core_node6":{
"core":"raceDeleteReplica_true_shard1_replica_n5",
"base_url":"https://127.0.0.1:39120/solr;,
"node_name":"127.0.0.1:39120_solr",
"state":"down",
"type":"NRT"},
"core_node4":{
"core":"raceDeleteReplica_true_shard1_replica_n2",
"base_url":"https://127.0.0.1:34395/solr;,
"node_name":"127.0.0.1:34395_solr",
"state":"down",
"type":"NRT",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"2",
"tlogReplicas":"0"}
at
__randomizedtesting.SeedInfo.seed([93E108B40D2EF678:F9F7696465DCBCB2]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:280)
at
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:328)
at
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:223)
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:1742)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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
[jira] [Commented] (SOLR-12313) TestInjection#waitForInSyncWithLeader needs improvement.
[ https://issues.apache.org/jira/browse/SOLR-12313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682226#comment-16682226 ] Cao Manh Dat commented on SOLR-12313: - Thanks [~hossman], I can't reproduce the problem locally, but quite sure that my last commit helped on fixing the failure. > TestInjection#waitForInSyncWithLeader needs improvement. > > > Key: SOLR-12313 > URL: https://issues.apache.org/jira/browse/SOLR-12313 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Priority: Major > > This really should have some doc for why it would be used. > I also think it causes BasicDistributedZkTest to take forever for sometimes > and perhaps other tests? > I think checking for uncommitted data is probably a race condition and should > be removed. > Checking index versions should follow the rules that replication does - if > the slave is higher than the leader, it's in sync, being equal is not > required. If it's expected for a test it should be a specific test that > fails. This just introduces massive delays. -- 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-12313) TestInjection#waitForInSyncWithLeader needs improvement.
[ https://issues.apache.org/jira/browse/SOLR-12313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682225#comment-16682225 ] ASF subversion and git services commented on SOLR-12313: Commit 2fc689fbf9f8600baaeed385fac4bc678fd2cb18 in lucene-solr's branch refs/heads/branch_7x from [~caomanhdat] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2fc689f ] SOLR-12313: No need to wait for in-sync with leader in RecoveryAfterSoftCommitTest since we only care about recovery > TestInjection#waitForInSyncWithLeader needs improvement. > > > Key: SOLR-12313 > URL: https://issues.apache.org/jira/browse/SOLR-12313 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Priority: Major > > This really should have some doc for why it would be used. > I also think it causes BasicDistributedZkTest to take forever for sometimes > and perhaps other tests? > I think checking for uncommitted data is probably a race condition and should > be removed. > Checking index versions should follow the rules that replication does - if > the slave is higher than the leader, it's in sync, being equal is not > required. If it's expected for a test it should be a specific test that > fails. This just introduces massive delays. -- 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-12313) TestInjection#waitForInSyncWithLeader needs improvement.
[ https://issues.apache.org/jira/browse/SOLR-12313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682224#comment-16682224 ] ASF subversion and git services commented on SOLR-12313: Commit 90e264e647ae3e990ebd64a44642d0111b3b05b5 in lucene-solr's branch refs/heads/branch_7x from [~caomanhdat] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=90e264e ] SOLR-12313: Make the test finish quicker by lower down intervals > TestInjection#waitForInSyncWithLeader needs improvement. > > > Key: SOLR-12313 > URL: https://issues.apache.org/jira/browse/SOLR-12313 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Priority: Major > > This really should have some doc for why it would be used. > I also think it causes BasicDistributedZkTest to take forever for sometimes > and perhaps other tests? > I think checking for uncommitted data is probably a race condition and should > be removed. > Checking index versions should follow the rules that replication does - if > the slave is higher than the leader, it's in sync, being equal is not > required. If it's expected for a test it should be a specific test that > fails. This just introduces massive delays. -- 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-12313) TestInjection#waitForInSyncWithLeader needs improvement.
[ https://issues.apache.org/jira/browse/SOLR-12313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682223#comment-16682223 ] ASF subversion and git services commented on SOLR-12313: Commit 397b88aefa39d66d1310dfdea6b6d344ce1c9ce5 in lucene-solr's branch refs/heads/master from [~caomanhdat] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=397b88a ] SOLR-12313: No need to wait for in-sync with leader in RecoveryAfterSoftCommitTest since we only care about recovery > TestInjection#waitForInSyncWithLeader needs improvement. > > > Key: SOLR-12313 > URL: https://issues.apache.org/jira/browse/SOLR-12313 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Priority: Major > > This really should have some doc for why it would be used. > I also think it causes BasicDistributedZkTest to take forever for sometimes > and perhaps other tests? > I think checking for uncommitted data is probably a race condition and should > be removed. > Checking index versions should follow the rules that replication does - if > the slave is higher than the leader, it's in sync, being equal is not > required. If it's expected for a test it should be a specific test that > fails. This just introduces massive delays. -- 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-12955) Refactor DistributedUpdateProcessor
[
https://issues.apache.org/jira/browse/SOLR-12955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682210#comment-16682210
]
Lucene/Solr QA commented on SOLR-12955:
---
| (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} 3m
21s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 2m 0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 2m 0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 2m 0s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 44m 37s{color}
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 54m 27s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
solr.update.PeerSyncWithLeaderAndIndexFingerprintCachingTest |
| | solr.search.TestRecovery |
| | solr.update.PeerSyncWithBufferUpdatesTest |
| | solr.schema.TestSchemalessBufferedUpdates |
| | solr.update.PeerSyncTest |
| | solr.update.processor.TimeRoutedAliasUpdateProcessorTest |
| | solr.cloud.RecoveryAfterSoftCommitTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12955 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12947600/SOLR-12955.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 / 42ee966 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | 1.8.0_191 |
| unit |
https://builds.apache.org/job/PreCommit-SOLR-Build/222/artifact/out/patch-unit-solr_core.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/222/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/222/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Refactor DistributedUpdateProcessor
> ---
>
> Key: SOLR-12955
> URL: https://issues.apache.org/jira/browse/SOLR-12955
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Bar Rotstein
>Priority: Major
> Attachments: SOLR-12955.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Lately As I was skimming through Solr's code base I noticed that
> DistributedUpdateProcessor has a lot of nested if else statements, which
> hampers code readability.
--
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-7.x-Windows (64bit/jdk-12-ea+12) - Build # 881 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/881/ Java: 64bit/jdk-12-ea+12 -XX:+UseCompressedOops -XX:+UseParallelGC 12 tests failed. FAILED: org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.testFullImport Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_B93E934897A0D82F-001\tempDir-001\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_B93E934897A0D82F-001\tempDir-001\collection1 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_B93E934897A0D82F-001\tempDir-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_B93E934897A0D82F-001\tempDir-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_B93E934897A0D82F-001\tempDir-001\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_B93E934897A0D82F-001\tempDir-001\collection1 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_B93E934897A0D82F-001\tempDir-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_B93E934897A0D82F-001\tempDir-001 at __randomizedtesting.SeedInfo.seed([B93E934897A0D82F:3C92EED32FAF460F]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:318) at org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd$SolrInstance.tearDown(TestSolrEntityProcessorEndToEnd.java:361) at org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.tearDown(TestSolrEntityProcessorEndToEnd.java:142) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:993) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at
[JENKINS-EA] Lucene-Solr-BadApples-master-Linux (64bit/jdk-12-ea+12) - Build # 118 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/118/ Java: 64bit/jdk-12-ea+12 -XX:-UseCompressedOops -XX:+UseParallelGC 58 tests failed. FAILED: org.apache.solr.client.solrj.impl.CloudSolrClientTest.preferReplicaTypesTest Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([FA8D075468670673:C167A4E20FFECB7F]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.queryWithPreferReplicaTypes(CloudSolrClientTest.java:970) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.preferReplicaTypesTest(CloudSolrClientTest.java:893) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:835) FAILED:
[JENKINS] Lucene-Solr-BadApples-NightlyTests-master - Build # 36 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-NightlyTests-master/36/ 11 tests failed. FAILED: org.apache.lucene.codecs.lucene70.TestLucene70DocValuesFormat.testLongNumericsVsStoredFields Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([1A0A10E3BB04A5FF]:0) FAILED: junit.framework.TestSuite.org.apache.lucene.codecs.lucene70.TestLucene70DocValuesFormat Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([1A0A10E3BB04A5FF]:0) FAILED: org.apache.lucene.search.TestInetAddressRangeQueries.testRandomBig Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([15F4AD19D87C68BD]:0) FAILED: junit.framework.TestSuite.org.apache.lucene.search.TestInetAddressRangeQueries Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([15F4AD19D87C68BD]:0) FAILED: org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaFromClusterState Error Message: Collection not found: deleteFromClusterState_false Stack Trace: org.apache.solr.common.SolrException: Collection not found: deleteFromClusterState_false at __randomizedtesting.SeedInfo.seed([3002B0DFA5D21F5A:DE9B1BB29AEC64ED]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:851) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:177) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:138) at org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaFromClusterState(DeleteReplicaTest.java:183) at org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaFromClusterState(DeleteReplicaTest.java:174) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) 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)
[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1178 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1178/ No tests ran. Build Log: [...truncated 23412 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 2437 links (1990 relative) to 3207 anchors in 248 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-8.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:
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-9.0.4) - Build # 7615 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7615/ Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseG1GC 5 tests failed. FAILED: org.apache.solr.cloud.autoscaling.TriggerSetPropertiesIntegrationTest.testSetProperties Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([5A76AF3C453D8E7C:31127875F6101BF8]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.cloud.autoscaling.TriggerSetPropertiesIntegrationTest.testSetProperties(TriggerSetPropertiesIntegrationTest.java:111) 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:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: org.apache.solr.cloud.autoscaling.TriggerSetPropertiesIntegrationTest.testSetProperties Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([5A76AF3C453D8E7C:31127875F6101BF8]:0) at
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_172) - Build # 3065 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/3065/ Java: 64bit/jdk1.8.0_172 -XX:+UseCompressedOops -XX:+UseG1GC 2 tests failed. FAILED: org.apache.solr.client.solrj.impl.CloudSolrClientTest.testRouting Error Message: Error from server at https://127.0.0.1:39135/solr/collection1_shard2_replica_n2: Expected mime type application/octet-stream but got text/html.Error 404 Can not find: /solr/collection1_shard2_replica_n2/update HTTP ERROR 404 Problem accessing /solr/collection1_shard2_replica_n2/update. Reason: Can not find: /solr/collection1_shard2_replica_n2/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605 Stack Trace: org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from server at https://127.0.0.1:39135/solr/collection1_shard2_replica_n2: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/collection1_shard2_replica_n2/update HTTP ERROR 404 Problem accessing /solr/collection1_shard2_replica_n2/update. Reason: Can not find: /solr/collection1_shard2_replica_n2/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605 at __randomizedtesting.SeedInfo.seed([B44812ED394C534F:76FF2E853A0CA337]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:551) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1016) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.testRouting(CloudSolrClientTest.java:238) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at
[JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 904 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/904/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: org.apache.solr.update.processor.UpdateRequestProcessorFactoryTest.testUpdateDistribChainSkipping Error Message: Tests must be run with INFO level logging otherwise LogUpdateProcessor isn't used and can't be tested. Stack Trace: java.lang.AssertionError: Tests must be run with INFO level logging otherwise LogUpdateProcessor isn't used and can't be tested. at __randomizedtesting.SeedInfo.seed([DB69C00B0D9E7396:AA8D3EDD7B75545A]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.update.processor.UpdateRequestProcessorFactoryTest.testUpdateDistribChainSkipping(UpdateRequestProcessorFactoryTest.java:101) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED:
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-10.0.1) - Build # 23182 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23182/ Java: 64bit/jdk-10.0.1 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 3 tests failed. FAILED: org.apache.solr.cloud.RecoveryAfterSoftCommitTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:36575/collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:36575/collection1 at __randomizedtesting.SeedInfo.seed([59F0F47E42AA32E9:D1A4CBA4EC565F11]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1107) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1260) at org.apache.solr.cloud.RecoveryAfterSoftCommitTest.test(RecoveryAfterSoftCommitTest.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:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1010) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:985) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) 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
[JENKINS] Lucene-Solr-Tests-7.x - Build # 1020 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/1020/ 1 tests failed. FAILED: org.apache.solr.client.solrj.impl.CloudSolrClientTest.testVersionsAreReturned Error Message: Error from server at https://127.0.0.1:46769/solr/collection1_shard2_replica_n3: Expected mime type application/octet-stream but got text/html.Error 404 Can not find: /solr/collection1_shard2_replica_n3/update HTTP ERROR 404 Problem accessing /solr/collection1_shard2_replica_n3/update. Reason: Can not find: /solr/collection1_shard2_replica_n3/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605 Stack Trace: org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from server at https://127.0.0.1:46769/solr/collection1_shard2_replica_n3: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/collection1_shard2_replica_n3/update HTTP ERROR 404 Problem accessing /solr/collection1_shard2_replica_n3/update. Reason: Can not find: /solr/collection1_shard2_replica_n3/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605 at __randomizedtesting.SeedInfo.seed([FE592B1C1D5EE94E:69FD2298E477186]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:551) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1016) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:237) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.testVersionsAreReturned(CloudSolrClientTest.java:725) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 2152 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/2152/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC 6 tests failed. FAILED: org.apache.solr.cloud.cdcr.CdcrWithNodesRestartsTest.testBufferOnNonLeader Error Message: java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 127.0.0.1:38765/solr within 45000 ms Stack Trace: org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 127.0.0.1:38765/solr within 45000 ms at __randomizedtesting.SeedInfo.seed([3CA7D5534A5DB390:3CEDDA641C6DCB1A]:0) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:184) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:121) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:111) at org.apache.solr.cloud.MiniSolrCloudCluster.uploadConfigSet(MiniSolrCloudCluster.java:448) at org.apache.solr.cloud.cdcr.CdcrWithNodesRestartsTest.createTargetCollection(CdcrWithNodesRestartsTest.java:317) at org.apache.solr.cloud.cdcr.CdcrWithNodesRestartsTest.createCollections(CdcrWithNodesRestartsTest.java:335) at org.apache.solr.cloud.cdcr.CdcrWithNodesRestartsTest.testBufferOnNonLeader(CdcrWithNodesRestartsTest.java:62) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at
[jira] [Resolved] (LUCENE-5594) don't call 'svnversion' over and over in the build
[ https://issues.apache.org/jira/browse/LUCENE-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-5594. --- Resolution: Invalid No subversion anymore. > don't call 'svnversion' over and over in the build > -- > > Key: LUCENE-5594 > URL: https://issues.apache.org/jira/browse/LUCENE-5594 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Assignee: Uwe Schindler >Priority: Major > Fix For: 6.0, 5.0 > > > Some ant tasks (at least release packaging, i dunno what else), call > svnversion over and over and over for each module in the build. can we just > do this one time instead? -- 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-12313) TestInjection#waitForInSyncWithLeader needs improvement.
[
https://issues.apache.org/jira/browse/SOLR-12313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682055#comment-16682055
]
Hoss Man commented on SOLR-12313:
-
bq. RecoveryAfterSoftCommitTest has been failing roughly 50% of the time the
past few days - but only on master, ...
actually, it just occurred to me i was thinking about it backwards: it's
failing almost 50% of the time it's run by jenkins, but ~ half of those are on
7x where this change wasn't made. Which means on master jenkins builds, it's
failing almost 100% of the time.
...
It looks like {{tests.asserts}} is the key variable -- any seed i try with
{{-Dtests.asserts=true}} seems to fail, but {{-Dtests.asserts=false}} passes.
> TestInjection#waitForInSyncWithLeader needs improvement.
>
>
> Key: SOLR-12313
> URL: https://issues.apache.org/jira/browse/SOLR-12313
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mark Miller
>Priority: Major
>
> This really should have some doc for why it would be used.
> I also think it causes BasicDistributedZkTest to take forever for sometimes
> and perhaps other tests?
> I think checking for uncommitted data is probably a race condition and should
> be removed.
> Checking index versions should follow the rules that replication does - if
> the slave is higher than the leader, it's in sync, being equal is not
> required. If it's expected for a test it should be a specific test that
> fails. This just introduces massive delays.
--
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] (LUCENE-4417) Re-Add the backwards compatibility tests to 4.1 branch
[ https://issues.apache.org/jira/browse/LUCENE-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-4417. --- Resolution: Won't Fix Fix Version/s: (was: 6.0) (was: 4.9) > Re-Add the backwards compatibility tests to 4.1 branch > -- > > Key: LUCENE-4417 > URL: https://issues.apache.org/jira/browse/LUCENE-4417 > Project: Lucene - Core > Issue Type: Task > Components: general/test >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Major > > In 4.0 we have no backwards compatibility, but in 4.1 we must again > ivy-retrieve the 4.0 JAR file and run the core tests again (like in 3.6). We > may think about other modules, too, so all modules that must be backwards > compatible should be added to this build. > I will work on this once we have a release candidate in Maven Central. -- 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] (LUCENE-3451) Remove special handling of pure negative Filters in BooleanFilter, disallow pure negative queries in BooleanQuery
[ https://issues.apache.org/jira/browse/LUCENE-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-3451. --- Resolution: Won't Fix Fix Version/s: (was: 6.0) (was: 4.9) BooleanFilter is gone. > Remove special handling of pure negative Filters in BooleanFilter, disallow > pure negative queries in BooleanQuery > - > > Key: LUCENE-3451 > URL: https://issues.apache.org/jira/browse/LUCENE-3451 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Major > Attachments: LUCENE-3451.patch, LUCENE-3451.patch, LUCENE-3451.patch, > LUCENE-3451.patch, LUCENE-3451.patch > > > We should at least in Lucene 4.0 remove the hack in BooleanFilter that allows > pure negative Filter clauses. This is not supported by BooleanQuery and > confuses users (I think that's the problem in LUCENE-3450). > The hack is buggy, as it does not respect deleted documents and returns them > in its DocIdSet. > Also we should think about disallowing pure-negative Queries at all and throw > UOE. -- 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] [Closed] (LUCENE-3451) Remove special handling of pure negative Filters in BooleanFilter, disallow pure negative queries in BooleanQuery
[ https://issues.apache.org/jira/browse/LUCENE-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler closed LUCENE-3451. - > Remove special handling of pure negative Filters in BooleanFilter, disallow > pure negative queries in BooleanQuery > - > > Key: LUCENE-3451 > URL: https://issues.apache.org/jira/browse/LUCENE-3451 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Major > Attachments: LUCENE-3451.patch, LUCENE-3451.patch, LUCENE-3451.patch, > LUCENE-3451.patch, LUCENE-3451.patch > > > We should at least in Lucene 4.0 remove the hack in BooleanFilter that allows > pure negative Filter clauses. This is not supported by BooleanQuery and > confuses users (I think that's the problem in LUCENE-3450). > The hack is buggy, as it does not respect deleted documents and returns them > in its DocIdSet. > Also we should think about disallowing pure-negative Queries at all and throw > UOE. -- 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] [Closed] (LUCENE-3659) Allow per-RAMFile buffer sizes based on IOContext and source of data (e.g. copy from another directory)
[ https://issues.apache.org/jira/browse/LUCENE-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler closed LUCENE-3659. - > Allow per-RAMFile buffer sizes based on IOContext and source of data (e.g. > copy from another directory) > --- > > Key: LUCENE-3659 > URL: https://issues.apache.org/jira/browse/LUCENE-3659 > Project: Lucene - Core > Issue Type: Sub-task >Affects Versions: 4.0-ALPHA >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Major > Attachments: LUCENE-3659.patch, LUCENE-3659.patch, LUCENE-3659.patch, > LUCENE-3659.patch > > > Spinoff from several dev@lao issues: > - > [http://mail-archives.apache.org/mod_mbox/lucene-dev/201112.mbox/%3C001001ccbf1c%2471845830%24548d0890%24%40thetaphi.de%3E] > - issue LUCENE-3653 > The use cases for RAMDirectory are very limited and to prevent users from > using it for e.g. loading a 50 Gigabyte index from a file on disk, we should > improve the javadocs. -- 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] (LUCENE-3924) Optimize buffer size handling in RAMDirectory to make it more GC friendly
[ https://issues.apache.org/jira/browse/LUCENE-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-3924. --- Resolution: Won't Fix Fix Version/s: (was: 6.0) (was: 4.9) RAMDirectory is now deprecated and should not be used anymore. > Optimize buffer size handling in RAMDirectory to make it more GC friendly > - > > Key: LUCENE-3924 > URL: https://issues.apache.org/jira/browse/LUCENE-3924 > Project: Lucene - Core > Issue Type: Improvement > Components: core/store >Affects Versions: 4.0-ALPHA >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Major > > RAMDirectory currently uses a fixed buffer size of 1024 bytes to allocate > memory. This is very wasteful for large indexes. Improvements may be: > - per file buffer sizes based on IOContext and maximum segment size > - allocate only one buffer for files that are copied from another directory > - dynamically increae buffer size when files grow (makes seek() complicated) -- 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] [Closed] (LUCENE-3924) Optimize buffer size handling in RAMDirectory to make it more GC friendly
[ https://issues.apache.org/jira/browse/LUCENE-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler closed LUCENE-3924. - > Optimize buffer size handling in RAMDirectory to make it more GC friendly > - > > Key: LUCENE-3924 > URL: https://issues.apache.org/jira/browse/LUCENE-3924 > Project: Lucene - Core > Issue Type: Improvement > Components: core/store >Affects Versions: 4.0-ALPHA >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Major > > RAMDirectory currently uses a fixed buffer size of 1024 bytes to allocate > memory. This is very wasteful for large indexes. Improvements may be: > - per file buffer sizes based on IOContext and maximum segment size > - allocate only one buffer for files that are copied from another directory > - dynamically increae buffer size when files grow (makes seek() complicated) -- 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] (LUCENE-3659) Allow per-RAMFile buffer sizes based on IOContext and source of data (e.g. copy from another directory)
[ https://issues.apache.org/jira/browse/LUCENE-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-3659. --- Resolution: Won't Fix Fix Version/s: (was: 6.0) (was: 4.9) RAMDirectory is now deprecated and should no longer be used. > Allow per-RAMFile buffer sizes based on IOContext and source of data (e.g. > copy from another directory) > --- > > Key: LUCENE-3659 > URL: https://issues.apache.org/jira/browse/LUCENE-3659 > Project: Lucene - Core > Issue Type: Sub-task >Affects Versions: 4.0-ALPHA >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Major > Attachments: LUCENE-3659.patch, LUCENE-3659.patch, LUCENE-3659.patch, > LUCENE-3659.patch > > > Spinoff from several dev@lao issues: > - > [http://mail-archives.apache.org/mod_mbox/lucene-dev/201112.mbox/%3C001001ccbf1c%2471845830%24548d0890%24%40thetaphi.de%3E] > - issue LUCENE-3653 > The use cases for RAMDirectory are very limited and to prevent users from > using it for e.g. loading a 50 Gigabyte index from a file on disk, we should > improve the javadocs. -- 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] [Closed] (LUCENE-5594) don't call 'svnversion' over and over in the build
[ https://issues.apache.org/jira/browse/LUCENE-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler closed LUCENE-5594. - > don't call 'svnversion' over and over in the build > -- > > Key: LUCENE-5594 > URL: https://issues.apache.org/jira/browse/LUCENE-5594 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Assignee: Uwe Schindler >Priority: Major > > Some ant tasks (at least release packaging, i dunno what else), call > svnversion over and over and over for each module in the build. can we just > do this one time instead? -- 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-5594) don't call 'svnversion' over and over in the build
[ https://issues.apache.org/jira/browse/LUCENE-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-5594: -- Fix Version/s: (was: 6.0) (was: 5.0) > don't call 'svnversion' over and over in the build > -- > > Key: LUCENE-5594 > URL: https://issues.apache.org/jira/browse/LUCENE-5594 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Assignee: Uwe Schindler >Priority: Major > > Some ant tasks (at least release packaging, i dunno what else), call > svnversion over and over and over for each module in the build. can we just > do this one time instead? -- 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] (LUCENE-5605) Don't pass precisionStep directly to NRQ/NRF. Instead pass the FieldType
[ https://issues.apache.org/jira/browse/LUCENE-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-5605. --- Resolution: Won't Fix NRQ is deprecated and was removed recently. > Don't pass precisionStep directly to NRQ/NRF. Instead pass the FieldType > > > Key: LUCENE-5605 > URL: https://issues.apache.org/jira/browse/LUCENE-5605 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Major > > Currently in our Field API we use the FieldType class that contains the > information about data type and stuff like the numeric precisionStep. > Unfortunately in NumericRangeQuery/NumericRangeFilter, we still require the > precisionStep given in the query. For the user this is hard to understand, > leading to problems like passing a different precisionStep than the one which > was used for indexing. If we change that parameter in NRQ/NRF to take > FieldType, we can extract the precStep as an implementation detail. We just > have to check that the field type is a numeric one and is indexed. The user > cannot do anything wrong anymore, unless he creates a new, incompatible field > type. -- 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] [Closed] (LUCENE-5605) Don't pass precisionStep directly to NRQ/NRF. Instead pass the FieldType
[ https://issues.apache.org/jira/browse/LUCENE-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler closed LUCENE-5605. - > Don't pass precisionStep directly to NRQ/NRF. Instead pass the FieldType > > > Key: LUCENE-5605 > URL: https://issues.apache.org/jira/browse/LUCENE-5605 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Major > > Currently in our Field API we use the FieldType class that contains the > information about data type and stuff like the numeric precisionStep. > Unfortunately in NumericRangeQuery/NumericRangeFilter, we still require the > precisionStep given in the query. For the user this is hard to understand, > leading to problems like passing a different precisionStep than the one which > was used for indexing. If we change that parameter in NRQ/NRF to take > FieldType, we can extract the precStep as an implementation detail. We just > have to check that the field type is a numeric one and is indexed. The user > cannot do anything wrong anymore, unless he creates a new, incompatible field > type. -- 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] (LUCENE-4124) factor ByteBufferIndexInput out of MMapDirectory
[ https://issues.apache.org/jira/browse/LUCENE-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-4124. --- Resolution: Invalid Was done already. > factor ByteBufferIndexInput out of MMapDirectory > > > Key: LUCENE-4124 > URL: https://issues.apache.org/jira/browse/LUCENE-4124 > Project: Lucene - Core > Issue Type: Improvement > Components: core/store >Reporter: Robert Muir >Assignee: Uwe Schindler >Priority: Major > Attachments: LUCENE-4124.patch > > > I think we should factor a ByteBufferIndexInput out of MMapDir, leaving only > the mmap/unmapping in mmapdir. > Its a cleaner separation and would allow it to be used for other purposes > (e.g. direct or array-backed buffers) -- 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] [Closed] (LUCENE-4124) factor ByteBufferIndexInput out of MMapDirectory
[ https://issues.apache.org/jira/browse/LUCENE-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler closed LUCENE-4124. - > factor ByteBufferIndexInput out of MMapDirectory > > > Key: LUCENE-4124 > URL: https://issues.apache.org/jira/browse/LUCENE-4124 > Project: Lucene - Core > Issue Type: Improvement > Components: core/store >Reporter: Robert Muir >Assignee: Uwe Schindler >Priority: Major > Attachments: LUCENE-4124.patch > > > I think we should factor a ByteBufferIndexInput out of MMapDir, leaving only > the mmap/unmapping in mmapdir. > Its a cleaner separation and would allow it to be used for other purposes > (e.g. direct or array-backed buffers) -- 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] [Closed] (LUCENE-4417) Re-Add the backwards compatibility tests to 4.1 branch
[ https://issues.apache.org/jira/browse/LUCENE-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler closed LUCENE-4417. - > Re-Add the backwards compatibility tests to 4.1 branch > -- > > Key: LUCENE-4417 > URL: https://issues.apache.org/jira/browse/LUCENE-4417 > Project: Lucene - Core > Issue Type: Task > Components: general/test >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Major > > In 4.0 we have no backwards compatibility, but in 4.1 we must again > ivy-retrieve the 4.0 JAR file and run the core tests again (like in 3.6). We > may think about other modules, too, so all modules that must be backwards > compatible should be added to this build. > I will work on this once we have a release candidate in Maven Central. -- 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] (LUCENE-1710) Add byte/short to NumericUtils, NumericField and NumericRangeQuery
[ https://issues.apache.org/jira/browse/LUCENE-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-1710. --- Resolution: Won't Fix Fix Version/s: (was: 6.0) (was: 4.9) > Add byte/short to NumericUtils, NumericField and NumericRangeQuery > -- > > Key: LUCENE-1710 > URL: https://issues.apache.org/jira/browse/LUCENE-1710 > Project: Lucene - Core > Issue Type: New Feature > Components: core/index, core/search >Affects Versions: 2.9 >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Major > > Although NumericRangeQuery will not profit much from trie-encoding short/byte > fields (byte fields with e.g. precisionStep 8 would only create one > precision), it may be good to have these two data types available with > NumericField to be generally able to store them in prefix-encoded form in > index. > This is important for loading them into FieldCache where they require much > less memory. -- 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] [Closed] (LUCENE-1710) Add byte/short to NumericUtils, NumericField and NumericRangeQuery
[ https://issues.apache.org/jira/browse/LUCENE-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler closed LUCENE-1710. - > Add byte/short to NumericUtils, NumericField and NumericRangeQuery > -- > > Key: LUCENE-1710 > URL: https://issues.apache.org/jira/browse/LUCENE-1710 > Project: Lucene - Core > Issue Type: New Feature > Components: core/index, core/search >Affects Versions: 2.9 >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Major > > Although NumericRangeQuery will not profit much from trie-encoding short/byte > fields (byte fields with e.g. precisionStep 8 would only create one > precision), it may be good to have these two data types available with > NumericField to be generally able to store them in prefix-encoded form in > index. > This is important for loading them into FieldCache where they require much > less memory. -- 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-12313) TestInjection#waitForInSyncWithLeader needs improvement.
[
https://issues.apache.org/jira/browse/SOLR-12313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682039#comment-16682039
]
Hoss Man commented on SOLR-12313:
-
[~caomanhdat] ...
RecoveryAfterSoftCommitTest has been failing roughly 50% of the time the past
few days - but only on master, and git bisect identifies your
[13a8356|https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=13a8356]
commit as the cause...
Here is an example of a seed from jenkins that reproduces reliably for me (and
fails a the same place everytime: {{RecoveryAfterSoftCommitTest.java:87}} ) ...
{noformat}
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=RecoveryAfterSoftCommitTest -Dtests.method=test
-Dtests.seed=9AB4E0C0AB3BEF87 -Dtests.multiplier=3 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=ru
-Dtests.timezone=America/Indiana/Tell_City -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
[junit4] ERROR 78.5s | RecoveryAfterSoftCommitTest.test <<<
[junit4]> Throwable #1:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting
response from server at: http://127.0.0.1:52448/ol_wuc/collection1
[junit4]>at
__randomizedtesting.SeedInfo.seed([9AB4E0C0AB3BEF87:12E0DF1A05C7827F]:0)
[junit4]>at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654)
[junit4]>at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
[junit4]>at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
[junit4]>at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
[junit4]>at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1107)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
[junit4]>at
org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1260)
[junit4]>at
org.apache.solr.cloud.RecoveryAfterSoftCommitTest.test(RecoveryAfterSoftCommitTest.java:87)
[junit4]>at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1010)
[junit4]>at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:985)
[junit4]>at java.lang.Thread.run(Thread.java:748)
[junit4]> Caused by: java.net.SocketTimeoutException: Read timed out
[junit4]>at java.net.SocketInputStream.socketRead0(Native Method)
[junit4]>at
java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
[junit4]>at
java.net.SocketInputStream.read(SocketInputStream.java:171)
[junit4]>at
java.net.SocketInputStream.read(SocketInputStream.java:141)
[junit4]>at
org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
[junit4]>at
org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
[junit4]>at
org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282)
[junit4]>at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
[junit4]>at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
[junit4]>at
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
[junit4]>at
org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
[junit4]>at
org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
[junit4]>at
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
[junit4]>at
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
[junit4]>at
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
[junit4]>at
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
[junit4]>at
org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
[junit4]>at
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
[junit4]>at
[jira] [Commented] (LUCENE-8537) ant test command fails under lucene/tools
[
https://issues.apache.org/jira/browse/LUCENE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682036#comment-16682036
]
ASF subversion and git services commented on LUCENE-8537:
-
Commit f7e854bcbe4717fe593bd001adc65b2ee2819d9c in lucene-solr's branch
refs/heads/branch_7x from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f7e854b ]
LUCENE-8537: ant test command fails under lucene/tools
> ant test command fails under lucene/tools
> -
>
> Key: LUCENE-8537
> URL: https://issues.apache.org/jira/browse/LUCENE-8537
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: master (8.0)
>Reporter: Peter Somogyi
>Assignee: Uwe Schindler
>Priority: Minor
> Attachments: LUCENE-8537.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{ant test}} command executed under {{lucene/tools}} folder fails because
> it does not have {{junit.classpath}} property. Since the module does not have
> any test folder we could override the {{-test}} and {{-check-totals}} targets.
> {noformat}
> bash-3.2$ pwd
> /Users/peter.somogyi/repos/lucene-solr/lucene/tools
> bash-3.2$ ant test
> Buildfile: /Users/peter.somogyi/repos/lucene-solr/lucene/tools/build.xml
> ...
> -test:
>[junit4] says ciao! Master seed: 9A2ACC9B4A3C8553
> BUILD FAILED
> /Users/peter.somogyi/repos/lucene-solr/lucene/common-build.xml:1567: The
> following error occurred while executing this line:
> /Users/peter.somogyi/repos/lucene-solr/lucene/common-build.xml:1092:
> Reference junit.classpath not found.
> Total time: 1 second
> {noformat}
> I ran into this issue when uploaded a patch where I removed an import from
> this module. This triggered a module-level build during precommit that failed
> with this error.
--
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-8537) ant test command fails under lucene/tools
[
https://issues.apache.org/jira/browse/LUCENE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682035#comment-16682035
]
ASF subversion and git services commented on LUCENE-8537:
-
Commit efd3f17f9a98aa9544e8af5126ae892fbc14728c in lucene-solr's branch
refs/heads/master from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=efd3f17 ]
LUCENE-8537: ant test command fails under lucene/tools
> ant test command fails under lucene/tools
> -
>
> Key: LUCENE-8537
> URL: https://issues.apache.org/jira/browse/LUCENE-8537
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: master (8.0)
>Reporter: Peter Somogyi
>Assignee: Uwe Schindler
>Priority: Minor
> Attachments: LUCENE-8537.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{ant test}} command executed under {{lucene/tools}} folder fails because
> it does not have {{junit.classpath}} property. Since the module does not have
> any test folder we could override the {{-test}} and {{-check-totals}} targets.
> {noformat}
> bash-3.2$ pwd
> /Users/peter.somogyi/repos/lucene-solr/lucene/tools
> bash-3.2$ ant test
> Buildfile: /Users/peter.somogyi/repos/lucene-solr/lucene/tools/build.xml
> ...
> -test:
>[junit4] says ciao! Master seed: 9A2ACC9B4A3C8553
> BUILD FAILED
> /Users/peter.somogyi/repos/lucene-solr/lucene/common-build.xml:1567: The
> following error occurred while executing this line:
> /Users/peter.somogyi/repos/lucene-solr/lucene/common-build.xml:1092:
> Reference junit.classpath not found.
> Total time: 1 second
> {noformat}
> I ran into this issue when uploaded a patch where I removed an import from
> this module. This triggered a module-level build during precommit that failed
> with this error.
--
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-7.x-Linux (32bit/jdk1.8.0_172) - Build # 3064 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/3064/
Java: 32bit/jdk1.8.0_172 -client -XX:+UseParallelGC
6 tests failed.
FAILED:
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica
Error Message:
Expected new active leader null Live Nodes: [127.0.0.1:34447_solr,
127.0.0.1:37139_solr, 127.0.0.1:42413_solr] Last available state:
DocCollection(raceDeleteReplica_false//collections/raceDeleteReplica_false/state.json/12)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{"shard1":{
"range":"8000-7fff", "state":"active", "replicas":{
"core_node3":{ "core":"raceDeleteReplica_false_shard1_replica_n1",
"base_url":"http://127.0.0.1:45509/solr;,
"node_name":"127.0.0.1:45509_solr", "state":"down",
"type":"NRT", "force_set_state":"false", "leader":"true"},
"core_node6":{
"core":"raceDeleteReplica_false_shard1_replica_n5",
"base_url":"http://127.0.0.1:45509/solr;,
"node_name":"127.0.0.1:45509_solr", "state":"down",
"type":"NRT", "force_set_state":"false",
"router":{"name":"compositeId"}, "maxShardsPerNode":"1",
"autoAddReplicas":"false", "nrtReplicas":"2", "tlogReplicas":"0"}
Stack Trace:
java.lang.AssertionError: Expected new active leader
null
Live Nodes: [127.0.0.1:34447_solr, 127.0.0.1:37139_solr, 127.0.0.1:42413_solr]
Last available state:
DocCollection(raceDeleteReplica_false//collections/raceDeleteReplica_false/state.json/12)={
"pullReplicas":"0",
"replicationFactor":"2",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
"core_node3":{
"core":"raceDeleteReplica_false_shard1_replica_n1",
"base_url":"http://127.0.0.1:45509/solr;,
"node_name":"127.0.0.1:45509_solr",
"state":"down",
"type":"NRT",
"force_set_state":"false",
"leader":"true"},
"core_node6":{
"core":"raceDeleteReplica_false_shard1_replica_n5",
"base_url":"http://127.0.0.1:45509/solr;,
"node_name":"127.0.0.1:45509_solr",
"state":"down",
"type":"NRT",
"force_set_state":"false",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"2",
"tlogReplicas":"0"}
at
__randomizedtesting.SeedInfo.seed([7ED3B1A1FFE9B306:14C5D071971BF9CC]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:280)
at
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:334)
at
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:230)
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:1742)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at
[jira] [Created] (LUCENE-8561) Heap dump while search the index
Roshini created LUCENE-8561: --- Summary: Heap dump while search the index Key: LUCENE-8561 URL: https://issues.apache.org/jira/browse/LUCENE-8561 Project: Lucene - Core Issue Type: Bug Affects Versions: 4.3 Reporter: Roshini A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_IN_PAGE_ERROR (0xc006) at pc=0x08e02b78, pid=9892, tid=8688 # # JRE version: Java(TM) SE Runtime Environment (8.0_74-b02) (build 1.8.0_74-b02) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.74-b02 mixed mode windows-amd64 compressed oops) # Problematic frame: # J 45372 C2 org.apache.lucene.store.CompoundFileDirectory.readEntries(Lorg/apache/lucene/store/Directory$IndexInputSlicer;Lorg/apache/lucene/store/Directory;Ljava/lang/String;)Ljava/util/Map; (387 bytes) @ 0x08e02b78 [0x08e02a40+0x138] # # Failed to write core dump. Minidump has been disabled from the command line # # If you would like to submit a bug report, please visit: # [http://bugreport.java.com/bugreport/crash.jsp] -- 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-12759) Disable ExtractingRequestHandlerTest on JDK 11
[ https://issues.apache.org/jira/browse/SOLR-12759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682011#comment-16682011 ] ASF subversion and git services commented on SOLR-12759: Commit 70fe7e69329be8551d6a13538930aed7b1718a18 in lucene-solr's branch refs/heads/branch_7_6 from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=70fe7e6 ] SOLR-12759: fix regexp (case insensitive) (cherry picked from commit 0330372f044b18b4bfac820d24fe5ddc783fbe7a) > Disable ExtractingRequestHandlerTest on JDK 11 > -- > > Key: SOLR-12759 > URL: https://issues.apache.org/jira/browse/SOLR-12759 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - Solr Cell (Tika extraction) > Environment: JDK 11 and Tika 1.x >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 7.6 > > > ExtractingRequestHandlerTest has failed on a JDK 11 RC due to two conspiring > problems: (A) Tika 1.x sometimes calls Date.toString() when extracting > metadata (unreleased 2.x will fix this), (B) JDK 11 RC has a bug in some > locales like Arabic in which a Date.toString() will have a timezone offset > using its locale's characters for the digits instead of using EN_US. > I'll add an "assume" check so we don't see failures about this. -- 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-12964) Use advanceExact instead of advance in a few remaining json facet use cases
[
https://issues.apache.org/jira/browse/SOLR-12964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682006#comment-16682006
]
Michael McCandless commented on SOLR-12964:
---
{quote}what do you think about making {{DocValuesIterator}} public?
{quote}
+1
> Use advanceExact instead of advance in a few remaining json facet use cases
> ---
>
> Key: SOLR-12964
> URL: https://issues.apache.org/jira/browse/SOLR-12964
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
>Affects Versions: 7.5
>Reporter: Tim Underwood
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.6
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This updates 2 places in the JSON Facets code that uses the advance()/docID()
> pattern instead of the simpler advanceExact(). Most other usages in the
> faceting code already make use of advanceExact().
> The only remaining usage of advance() in org.apache.solr.search.facet is in:
> * UniqueAgg.BaseNumericAcc.collect
> * HLLAgg..BaseNumericAcc.collect
> The code for those of those looks very similar and probably makes sense to
> update but it would require changing the return type of the protected
> docIdSetIterator() method to return a DocValuesIterator in order to be able
> to call the advanceExact() method.
--
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-12759) Disable ExtractingRequestHandlerTest on JDK 11
[ https://issues.apache.org/jira/browse/SOLR-12759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681980#comment-16681980 ] Steve Rowe commented on SOLR-12759: --- Oops, re-resolved before mentioning: I think this should be backported to the newly cut branch_7_6 (given the fixVersion of 7.6). > Disable ExtractingRequestHandlerTest on JDK 11 > -- > > Key: SOLR-12759 > URL: https://issues.apache.org/jira/browse/SOLR-12759 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - Solr Cell (Tika extraction) > Environment: JDK 11 and Tika 1.x >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 7.6 > > > ExtractingRequestHandlerTest has failed on a JDK 11 RC due to two conspiring > problems: (A) Tika 1.x sometimes calls Date.toString() when extracting > metadata (unreleased 2.x will fix this), (B) JDK 11 RC has a bug in some > locales like Arabic in which a Date.toString() will have a timezone offset > using its locale's characters for the digits instead of using EN_US. > I'll add an "assume" check so we don't see failures about this. -- 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-12759) Disable ExtractingRequestHandlerTest on JDK 11
[ https://issues.apache.org/jira/browse/SOLR-12759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe resolved SOLR-12759. --- Resolution: Fixed > Disable ExtractingRequestHandlerTest on JDK 11 > -- > > Key: SOLR-12759 > URL: https://issues.apache.org/jira/browse/SOLR-12759 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - Solr Cell (Tika extraction) > Environment: JDK 11 and Tika 1.x >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 7.6 > > > ExtractingRequestHandlerTest has failed on a JDK 11 RC due to two conspiring > problems: (A) Tika 1.x sometimes calls Date.toString() when extracting > metadata (unreleased 2.x will fix this), (B) JDK 11 RC has a bug in some > locales like Arabic in which a Date.toString() will have a timezone offset > using its locale's characters for the digits instead of using EN_US. > I'll add an "assume" check so we don't see failures about this. -- 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-repro - Build # 1907 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/1907/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/372/consoleText [repro] Revision: 382fcb96ff0108dd6e112682a99201e964573267 [repro] Ant options: -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt [repro] Repro line: ant test -Dtestcase=CdcrWithNodesRestartsTest -Dtests.method=testBufferOnNonLeader -Dtests.seed=25D4BC3E933B5FDC -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt -Dtests.locale=fi-FI -Dtests.timezone=Europe/Vatican -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=RollingRestartTest -Dtests.method=test -Dtests.seed=25D4BC3E933B5FDC -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt -Dtests.locale=he -Dtests.timezone=Etc/GMT-8 -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=TestSimPolicyCloud -Dtests.method=testCreateCollectionSplitShard -Dtests.seed=25D4BC3E933B5FDC -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt -Dtests.locale=en-IE -Dtests.timezone=Australia/South -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=HdfsRestartWhileUpdatingTest -Dtests.method=test -Dtests.seed=25D4BC3E933B5FDC -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt -Dtests.locale=hu-HU -Dtests.timezone=Asia/Jerusalem -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=HdfsRestartWhileUpdatingTest -Dtests.seed=25D4BC3E933B5FDC -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt -Dtests.locale=hu-HU -Dtests.timezone=Asia/Jerusalem -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=CloudSolrClientTest -Dtests.method=testRouting -Dtests.seed=DF03696BD835E6F6 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt -Dtests.locale=en-MT -Dtests.timezone=America/Los_Angeles -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 0330372f044b18b4bfac820d24fe5ddc783fbe7a [repro] git fetch [repro] git checkout 382fcb96ff0108dd6e112682a99201e964573267 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/solrj [repro] CloudSolrClientTest [repro]solr/core [repro] RollingRestartTest [repro] HdfsRestartWhileUpdatingTest [repro] CdcrWithNodesRestartsTest [repro] TestSimPolicyCloud [repro] ant compile-test [...truncated 2716 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.CloudSolrClientTest" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt -Dtests.seed=DF03696BD835E6F6 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt -Dtests.locale=en-MT -Dtests.timezone=America/Los_Angeles -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 711 lines...] [repro] Setting last failure code to 256 [repro] ant compile-test [...truncated 1352 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=20 -Dtests.class="*.RollingRestartTest|*.HdfsRestartWhileUpdatingTest|*.CdcrWithNodesRestartsTest|*.TestSimPolicyCloud" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt -Dtests.seed=25D4BC3E933B5FDC -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt -Dtests.locale=he -Dtests.timezone=Etc/GMT-8 -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 59461 lines...] [repro] Setting last
[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk-9) - Build # 928 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/928/ Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseG1GC 5 tests failed. FAILED: org.apache.solr.cloud.TestTlogReplica.testRecovery Error Message: Can not find doc 7 in https://127.0.0.1:63904/solr Stack Trace: java.lang.AssertionError: Can not find doc 7 in https://127.0.0.1:63904/solr at __randomizedtesting.SeedInfo.seed([D2475B55C64E970D:13B722F9EB1E5DAA]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.apache.solr.cloud.TestTlogReplica.checkRTG(TestTlogReplica.java:902) at org.apache.solr.cloud.TestTlogReplica.testRecovery(TestTlogReplica.java:567) 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:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: org.apache.solr.cloud.TestTlogReplica.testRecovery Error Message: Can not find doc 7 in https://127.0.0.1:64226/solr Stack Trace: java.lang.AssertionError: Can
[JENKINS] Lucene-Solr-BadApples-Tests-7.x - Build # 212 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/212/ 1 tests failed. FAILED: org.apache.solr.client.solrj.impl.CloudSolrClientTest.testVersionsAreReturned Error Message: Error from server at http://127.0.0.1:41602/solr/collection1_shard2_replica_n3: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/collection1_shard2_replica_n3/update HTTP ERROR 404 Problem accessing /solr/collection1_shard2_replica_n3/update. Reason: Can not find: /solr/collection1_shard2_replica_n3/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605 Stack Trace: org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from server at http://127.0.0.1:41602/solr/collection1_shard2_replica_n3: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/collection1_shard2_replica_n3/update HTTP ERROR 404 Problem accessing /solr/collection1_shard2_replica_n3/update. Reason: Can not find: /solr/collection1_shard2_replica_n3/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605 at __randomizedtesting.SeedInfo.seed([8C20D7E2BF639726:74E62ED72C7A0FEE]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:551) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1016) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:237) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.testVersionsAreReturned(CloudSolrClientTest.java:725) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (SOLR-12759) Disable ExtractingRequestHandlerTest on JDK 11
[ https://issues.apache.org/jira/browse/SOLR-12759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681933#comment-16681933 ] David Smiley commented on SOLR-12759: - Thanks Steve. > Disable ExtractingRequestHandlerTest on JDK 11 > -- > > Key: SOLR-12759 > URL: https://issues.apache.org/jira/browse/SOLR-12759 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - Solr Cell (Tika extraction) > Environment: JDK 11 and Tika 1.x >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 7.6 > > > ExtractingRequestHandlerTest has failed on a JDK 11 RC due to two conspiring > problems: (A) Tika 1.x sometimes calls Date.toString() when extracting > metadata (unreleased 2.x will fix this), (B) JDK 11 RC has a bug in some > locales like Arabic in which a Date.toString() will have a timezone offset > using its locale's characters for the digits instead of using EN_US. > I'll add an "assume" check so we don't see failures about this. -- 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-12759) Disable ExtractingRequestHandlerTest on JDK 11
[ https://issues.apache.org/jira/browse/SOLR-12759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681932#comment-16681932 ] ASF subversion and git services commented on SOLR-12759: Commit 2e8d13973838144eb165d66f6bbb133b6c9f1ea9 in lucene-solr's branch refs/heads/branch_7x from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2e8d139 ] SOLR-12759: fix regexp (case insensitive) (cherry picked from commit 0330372f044b18b4bfac820d24fe5ddc783fbe7a) > Disable ExtractingRequestHandlerTest on JDK 11 > -- > > Key: SOLR-12759 > URL: https://issues.apache.org/jira/browse/SOLR-12759 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - Solr Cell (Tika extraction) > Environment: JDK 11 and Tika 1.x >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 7.6 > > > ExtractingRequestHandlerTest has failed on a JDK 11 RC due to two conspiring > problems: (A) Tika 1.x sometimes calls Date.toString() when extracting > metadata (unreleased 2.x will fix this), (B) JDK 11 RC has a bug in some > locales like Arabic in which a Date.toString() will have a timezone offset > using its locale's characters for the digits instead of using EN_US. > I'll add an "assume" check so we don't see failures about this. -- 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-12759) Disable ExtractingRequestHandlerTest on JDK 11
[ https://issues.apache.org/jira/browse/SOLR-12759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681931#comment-16681931 ] ASF subversion and git services commented on SOLR-12759: Commit 0330372f044b18b4bfac820d24fe5ddc783fbe7a in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0330372 ] SOLR-12759: fix regexp (case insensitive) > Disable ExtractingRequestHandlerTest on JDK 11 > -- > > Key: SOLR-12759 > URL: https://issues.apache.org/jira/browse/SOLR-12759 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - Solr Cell (Tika extraction) > Environment: JDK 11 and Tika 1.x >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 7.6 > > > ExtractingRequestHandlerTest has failed on a JDK 11 RC due to two conspiring > problems: (A) Tika 1.x sometimes calls Date.toString() when extracting > metadata (unreleased 2.x will fix this), (B) JDK 11 RC has a bug in some > locales like Arabic in which a Date.toString() will have a timezone offset > using its locale's characters for the digits instead of using EN_US. > I'll add an "assume" check so we don't see failures about this. -- 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-Linux (32bit/jdk1.8.0_172) - Build # 23181 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23181/ Java: 32bit/jdk1.8.0_172 -client -XX:+UseConcMarkSweepGC 7 tests failed. FAILED: org.apache.solr.client.solrj.impl.CloudSolrClientTest.testRouting Error Message: Error from server at https://127.0.0.1:35301/solr/collection1_shard2_replica_n3: Expected mime type application/octet-stream but got text/html.Error 404 Can not find: /solr/collection1_shard2_replica_n3/update HTTP ERROR 404 Problem accessing /solr/collection1_shard2_replica_n3/update. Reason: Can not find: /solr/collection1_shard2_replica_n3/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605 Stack Trace: org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from server at https://127.0.0.1:35301/solr/collection1_shard2_replica_n3: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/collection1_shard2_replica_n3/update HTTP ERROR 404 Problem accessing /solr/collection1_shard2_replica_n3/update. Reason: Can not find: /solr/collection1_shard2_replica_n3/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605 at __randomizedtesting.SeedInfo.seed([F85DDE013638CE38:3AEAE26935783E40]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:551) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1016) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.testRouting(CloudSolrClientTest.java:238) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at
Re: Lucene/Solr 7.6
I don't know if it's on the Release ToDo list, but we need a Jenkins job for the Ref Guide to be built from branch_7x also. On Fri, Nov 9, 2018 at 2:24 PM Nicholas Knize wrote: > Great work guys, and thanks! > > branch_7_6 has been cut and versions updated to 7.7 on branch_7x. Just > the normal reminder: > >- No new features may be committed to the branch. >- > >Documentation patches, build patches and serious bug fixes may be >committed to the branch. However, you should submit *all* patches you >want to commit to Jira first to give others the chance to review and >possibly vote against the patch. Keep in mind that it is our main intention >to keep the branch as stable as possible. >- All patches that are intended for the branch should first be >committed to the unstable branch, merged into the stable branch, and then >into the current release branch. >- Normal unstable and stable branch development may continue as usual. >However, if you plan to commit a big change to the unstable branch while >the branch feature freeze is in effect, think twice: can't the addition >wait a couple more days? Merges of bug fixes into the branch may become >more difficult. >- > >*Only* Jira issues with Fix version "X.Y" and priority "Blocker" will >delay a release candidate build. > > > Also, a quick request. It doesn't look like I have Jenkins admin rights. > Would someone (with the power) either mind granting me admin privileges or > add/update the Jenkins build tasks for the new branch? > > Thank you, > > - Nick > > On Fri, Nov 9, 2018 at 11:43 AM Chris Hostetter > wrote: > >> >> : I don't have any problem waiting until tomorrow to cut the branch. I >> : noticed a patch was just committed so let me know if you happen to >> resolve >> : this sooner than expected. >> >> Heh .. yeah, since I didn't hear back from you I stayed up a little later >> then usual the last 2 nights re-reviewing everything (that and the >> patch review from smiley gave me some re-assurance.) >> >> (As far as SOLR-12962 is concerned) Feel free to cut branch_7_6 whenever >> you're ready. >> >> >> >> >> : On Thu, Nov 8, 2018 at 3:59 PM Chris Hostetter < >> hossman_luc...@fucit.org> >> : wrote: >> : >> : > >> : > : Let me know if there are any other blockers that need to be resolved >> : > prior >> : > : to cutting the branch. If not, I will plan to cut the branch on >> Friday or >> : > : (provided they are close to resolution) whenever these issues are >> : > resolved. >> : > >> : > nknize: I'd like to try and get SOLR-12962 into 7.6... >> : > >> : > It's a new "opt in" feature, but one that should help prevent a lot of >> : > performance problems for people who want to try it out -- so I'd >> really >> : > like to release it ASAP so we can hopefully get feedback from folks >> who >> : > try it in time to consider changing the default to "opt out" ~8.0 (see >> : > SOLR-12963 and parent SOLR-8273 for background) >> : > >> : > The patch is currently feature complete -- the only 'nocommits' are >> for >> : > updating a small amount of documentation, which I should have done >> : > sometime thursday morning (GMT-0700). >> : > >> : > I'm currently having my machine hammer on the tests, and >> waiting/hoping >> : > for some patch review / sanity checks. >> : > >> : > >> : > My typically "personal workflow based on comfort level" for a change >> like >> : > this would be to do nothing but testing & self-review for at least a >> day >> : > before committing & backporting ... which would mean wrapping it up >> : > sometime friday afternoon (GMT-0700). >> : > >> : > Unless there are any objections, I'd appreciate knowing if either: >> : > >> : > 1) You would be ok holding off on cutting branch_7_6 until >> : > sometime *after* friday ? >> : > >> : > 2) Folks would be ok w/me backporting SOLR-12962 to banch_7_6 after >> : > you fork it (even though it's a new feature, not a blocker bug >> fix) ? >> : > >> : > >> : > Thoughts? Concerns? >> : > >> : > >> : > >> : > >> : > -Hoss >> : > http://www.lucidworks.com/ >> : > >> : > - >> : > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> : > For additional commands, e-mail: dev-h...@lucene.apache.org >> : > >> : > -- >> : >> : Nicholas Knize, Ph.D., GISP >> : Geospatial Software Guy | Elasticsearch >> : Apache Lucene Committer >> : nkn...@apache.org >> : >> >> -Hoss >> http://www.lucidworks.com/ >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> -- > > Nicholas Knize, Ph.D., GISP > Geospatial Software Guy | Elasticsearch > Apache Lucene Committer > nkn...@apache.org >
Re: Lucene/Solr 7.6
Great work guys, and thanks! branch_7_6 has been cut and versions updated to 7.7 on branch_7x. Just the normal reminder: - No new features may be committed to the branch. - Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit *all* patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible. - All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch. - Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult. - *Only* Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build. Also, a quick request. It doesn't look like I have Jenkins admin rights. Would someone (with the power) either mind granting me admin privileges or add/update the Jenkins build tasks for the new branch? Thank you, - Nick On Fri, Nov 9, 2018 at 11:43 AM Chris Hostetter wrote: > > : I don't have any problem waiting until tomorrow to cut the branch. I > : noticed a patch was just committed so let me know if you happen to > resolve > : this sooner than expected. > > Heh .. yeah, since I didn't hear back from you I stayed up a little later > then usual the last 2 nights re-reviewing everything (that and the > patch review from smiley gave me some re-assurance.) > > (As far as SOLR-12962 is concerned) Feel free to cut branch_7_6 whenever > you're ready. > > > > > : On Thu, Nov 8, 2018 at 3:59 PM Chris Hostetter > > : wrote: > : > : > > : > : Let me know if there are any other blockers that need to be resolved > : > prior > : > : to cutting the branch. If not, I will plan to cut the branch on > Friday or > : > : (provided they are close to resolution) whenever these issues are > : > resolved. > : > > : > nknize: I'd like to try and get SOLR-12962 into 7.6... > : > > : > It's a new "opt in" feature, but one that should help prevent a lot of > : > performance problems for people who want to try it out -- so I'd really > : > like to release it ASAP so we can hopefully get feedback from folks who > : > try it in time to consider changing the default to "opt out" ~8.0 (see > : > SOLR-12963 and parent SOLR-8273 for background) > : > > : > The patch is currently feature complete -- the only 'nocommits' are for > : > updating a small amount of documentation, which I should have done > : > sometime thursday morning (GMT-0700). > : > > : > I'm currently having my machine hammer on the tests, and waiting/hoping > : > for some patch review / sanity checks. > : > > : > > : > My typically "personal workflow based on comfort level" for a change > like > : > this would be to do nothing but testing & self-review for at least a > day > : > before committing & backporting ... which would mean wrapping it up > : > sometime friday afternoon (GMT-0700). > : > > : > Unless there are any objections, I'd appreciate knowing if either: > : > > : > 1) You would be ok holding off on cutting branch_7_6 until > : > sometime *after* friday ? > : > > : > 2) Folks would be ok w/me backporting SOLR-12962 to banch_7_6 after > : > you fork it (even though it's a new feature, not a blocker bug > fix) ? > : > > : > > : > Thoughts? Concerns? > : > > : > > : > > : > > : > -Hoss > : > http://www.lucidworks.com/ > : > > : > - > : > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > : > For additional commands, e-mail: dev-h...@lucene.apache.org > : > > : > -- > : > : Nicholas Knize, Ph.D., GISP > : Geospatial Software Guy | Elasticsearch > : Apache Lucene Committer > : nkn...@apache.org > : > > -Hoss > http://www.lucidworks.com/ > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Nicholas Knize, Ph.D., GISP Geospatial Software Guy | Elasticsearch Apache Lucene Committer nkn...@apache.org
[jira] [Commented] (LUCENE-8560) TestByteBuffersDirectory.testSeekPastEOF() failures with ByteArrayIndexInput
[
https://issues.apache.org/jira/browse/LUCENE-8560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681896#comment-16681896
]
Dawid Weiss commented on LUCENE-8560:
-
Here's a patch that shows what it looks like after removal of
ByteArrayIndexInput. I used ByteBuffersIndexInput as a replacement in
ReplicaNode because ByteBufferIndexInput is package private (this is related to
a discussion I had with Uwe about the possibility to open it up at some point).
I'm still waiting for branch_8x to be cut and I'll apply some more aggressive
cleanups in master then. Perhaps we can make that factory method in
ByteBufferIndexInput publicly available (or make a static factory method on
IndexInput), then ByteBuffersIndexInput can go away, etc.
> TestByteBuffersDirectory.testSeekPastEOF() failures with ByteArrayIndexInput
>
>
> Key: LUCENE-8560
> URL: https://issues.apache.org/jira/browse/LUCENE-8560
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
>Reporter: Steve Rowe
>Assignee: Dawid Weiss
>Priority: Minor
> Attachments: LUCENE-8560.patch, LUCENE-8560.patch
>
>
> Two reproducing seeds below. In both cases:
> * the {{IndexInput}} implementation is {{ByteArrayIndexInput}}
> * seeking to exactly EOF does not throw an exception
> * {{ByteArrayIndexInput.readByte()}} throws AIOOBE instead of the expected
> EOFException
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4903]:
> {noformat}
> Checking out Revision 856e28d8cf07cc34bc1361784bf00e7aceb3af97
> (refs/remotes/origin/master)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestByteBuffersDirectory -Dtests.method=testSeekPastEOF
> -Dtests.seed=BDFA8CEDB7C93AC1 -Dtests.slow=true -Dtests.locale=sr-RS
> -Dtests.timezone=Europe/Astrakhan -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.00s J0 | TestByteBuffersDirectory.testSeekPastEOF
> {impl=byte array (heap)} <<<
>[junit4]> Throwable #1: junit.framework.AssertionFailedError:
> Unexpected exception type, expected EOFException but got
> java.lang.ArrayIndexOutOfBoundsException: 1770
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([BDFA8CEDB7C93AC1:5DBC4714B74C4450]:0)
>[junit4]> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2680)
>[junit4]> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2669)
>[junit4]> at
> org.apache.lucene.store.BaseDirectoryTestCase.testSeekPastEOF(BaseDirectoryTestCase.java:516)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:844)
>[junit4]> Caused by: java.lang.ArrayIndexOutOfBoundsException: 1770
>[junit4]> at
> org.apache.lucene.store.ByteArrayIndexInput.readByte(ByteArrayIndexInput.java:145)
>[junit4]> at
> org.apache.lucene.store.BaseDirectoryTestCase.lambda$testSeekPastEOF$12(BaseDirectoryTestCase.java:518)
>[junit4]> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2675)
>[junit4]> ... 37 more
> [...]
>[junit4] 2> NOTE: test params are: codec=Lucene80,
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@2c972cf9),
> locale=sr-RS, timezone=Europe/Astrakhan
>[junit4] 2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 9
> (64-bit)/cpus=3,threads=1,free=157933784,total=235929600
> {noformat}
> Also (older) from
> [https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1645]:
> {noformat}
> [junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestByteBuffersDirectory -Dtests.method=testSeekPastEOF
> -Dtests.seed=90B07B6267E63464 -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=es-PR -Dtests.timezone=Australia/Currie -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
> [junit4] FAILURE 0.01s J1 | TestByteBuffersDirectory.testSeekPastEOF
> {impl=byte array (heap)} <<<
> [junit4]> Throwable #1: junit.framework.AssertionFailedError:
> Unexpected exception type, expected EOFException but got
> java.lang.ArrayIndexOutOfBoundsException: 1881
>
[jira] [Commented] (SOLR-12947) SolrJ Helper for JSON Request API
[ https://issues.apache.org/jira/browse/SOLR-12947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681893#comment-16681893 ] ASF subversion and git services commented on SOLR-12947: Commit 4410ef941acf02e752a599b5403091f86e66a9a2 in lucene-solr's branch refs/heads/master from [~gerlowskija] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4410ef9 ] SOLR-12947: Misc JsonQueryRequest code cleanup > SolrJ Helper for JSON Request API > - > > Key: SOLR-12947 > URL: https://issues.apache.org/jira/browse/SOLR-12947 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: clients - java, SolrJ >Affects Versions: 7.5 >Reporter: Jason Gerlowski >Assignee: Jason Gerlowski >Priority: Minor > Attachments: SOLR-12947.patch, SOLR-12947.patch, SOLR-12947.patch > > > The JSON request API is becoming increasingly popular for sending querying or > accessing the JSON faceting functionality. The query DSL is simple and easy > to understand, but crafting requests programmatically is tough in SolrJ. > Currently, SolrJ users must hardcode in the JSON body they want their request > to convey. Nothing helps them build the JSON request they're going for, > making use of these APIs manual and painful. > We should see what we can do to alleviate this. I'd like to tackle this work > in two pieces. This (the first piece) would introduces classes that make it > easier to craft non-faceting requests that use the JSON Request API. > Improving JSON Faceting support is a bit more involved (it likely requires > improvements to the Response as well as the Request objects), so I'll aim to > tackle that in a separate JIRA to keep things moving. -- 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-8560) TestByteBuffersDirectory.testSeekPastEOF() failures with ByteArrayIndexInput
[
https://issues.apache.org/jira/browse/LUCENE-8560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-8560:
Attachment: LUCENE-8560.patch
> TestByteBuffersDirectory.testSeekPastEOF() failures with ByteArrayIndexInput
>
>
> Key: LUCENE-8560
> URL: https://issues.apache.org/jira/browse/LUCENE-8560
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
>Reporter: Steve Rowe
>Assignee: Dawid Weiss
>Priority: Minor
> Attachments: LUCENE-8560.patch, LUCENE-8560.patch
>
>
> Two reproducing seeds below. In both cases:
> * the {{IndexInput}} implementation is {{ByteArrayIndexInput}}
> * seeking to exactly EOF does not throw an exception
> * {{ByteArrayIndexInput.readByte()}} throws AIOOBE instead of the expected
> EOFException
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4903]:
> {noformat}
> Checking out Revision 856e28d8cf07cc34bc1361784bf00e7aceb3af97
> (refs/remotes/origin/master)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestByteBuffersDirectory -Dtests.method=testSeekPastEOF
> -Dtests.seed=BDFA8CEDB7C93AC1 -Dtests.slow=true -Dtests.locale=sr-RS
> -Dtests.timezone=Europe/Astrakhan -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.00s J0 | TestByteBuffersDirectory.testSeekPastEOF
> {impl=byte array (heap)} <<<
>[junit4]> Throwable #1: junit.framework.AssertionFailedError:
> Unexpected exception type, expected EOFException but got
> java.lang.ArrayIndexOutOfBoundsException: 1770
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([BDFA8CEDB7C93AC1:5DBC4714B74C4450]:0)
>[junit4]> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2680)
>[junit4]> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2669)
>[junit4]> at
> org.apache.lucene.store.BaseDirectoryTestCase.testSeekPastEOF(BaseDirectoryTestCase.java:516)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:844)
>[junit4]> Caused by: java.lang.ArrayIndexOutOfBoundsException: 1770
>[junit4]> at
> org.apache.lucene.store.ByteArrayIndexInput.readByte(ByteArrayIndexInput.java:145)
>[junit4]> at
> org.apache.lucene.store.BaseDirectoryTestCase.lambda$testSeekPastEOF$12(BaseDirectoryTestCase.java:518)
>[junit4]> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2675)
>[junit4]> ... 37 more
> [...]
>[junit4] 2> NOTE: test params are: codec=Lucene80,
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@2c972cf9),
> locale=sr-RS, timezone=Europe/Astrakhan
>[junit4] 2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 9
> (64-bit)/cpus=3,threads=1,free=157933784,total=235929600
> {noformat}
> Also (older) from
> [https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1645]:
> {noformat}
> [junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestByteBuffersDirectory -Dtests.method=testSeekPastEOF
> -Dtests.seed=90B07B6267E63464 -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=es-PR -Dtests.timezone=Australia/Currie -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
> [junit4] FAILURE 0.01s J1 | TestByteBuffersDirectory.testSeekPastEOF
> {impl=byte array (heap)} <<<
> [junit4]> Throwable #1: junit.framework.AssertionFailedError:
> Unexpected exception type, expected EOFException but got
> java.lang.ArrayIndexOutOfBoundsException: 1881
> [junit4]> at
> __randomizedtesting.SeedInfo.seed([90B07B6267E63464:70F6B09B67634AF5]:0)
> [junit4]> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2683)
> [junit4]> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2672)
> [junit4]> at
> org.apache.lucene.store.BaseDirectoryTestCase.testSeekPastEOF(BaseDirectoryTestCase.java:516)
> [junit4]> at java.lang.Thread.run(Thread.java:748)
> [junit4]> Caused by: java.lang.ArrayIndexOutOfBoundsException: 1881
>
[jira] [Commented] (SOLR-12759) Disable ExtractingRequestHandlerTest on JDK 11
[
https://issues.apache.org/jira/browse/SOLR-12759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681868#comment-16681868
]
Steve Rowe commented on SOLR-12759:
---
FYI for me on MacOS with Oracle 1.8.0_112 and AdoptOpenJDK 11+28, the below
program lists {{ChST}} as the only short display name containing a lowercase
letter:
{code:java}
import java.util.TimeZone;
import java.util.Locale;
public class ListAllTimeZoneDisplayNames {
public static void main(String[] args) {
for (String id : TimeZone.getAvailableIDs()) {
String displayName = TimeZone.getTimeZone(id).getDisplayName(false,
TimeZone.SHORT, Locale.US);
if (displayName.matches(".*[a-z].*")) {
System.out.println(id + ": " + displayName);
}
}
}
}
{code}
Produces:
{noformat}
Pacific/Guam: ChST
Pacific/Saipan: ChST
{noformat}
FWIW Oracle Java 7.0.71 also includes {{America/Metlakatla: MeST}})
> Disable ExtractingRequestHandlerTest on JDK 11
> --
>
> Key: SOLR-12759
> URL: https://issues.apache.org/jira/browse/SOLR-12759
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - Solr Cell (Tika extraction)
> Environment: JDK 11 and Tika 1.x
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 7.6
>
>
> ExtractingRequestHandlerTest has failed on a JDK 11 RC due to two conspiring
> problems: (A) Tika 1.x sometimes calls Date.toString() when extracting
> metadata (unreleased 2.x will fix this), (B) JDK 11 RC has a bug in some
> locales like Arabic in which a Date.toString() will have a timezone offset
> using its locale's characters for the digits instead of using EN_US.
> I'll add an "assume" check so we don't see failures about this.
--
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] (SOLR-12759) Disable ExtractingRequestHandlerTest on JDK 11
[
https://issues.apache.org/jira/browse/SOLR-12759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681857#comment-16681857
]
Steve Rowe edited comment on SOLR-12759 at 11/9/18 7:20 PM:
Looks like the regex needs another adjustment, maybe relax it from
{{\[A-Z\]\{3,\}...}} to {{\[A-Za-z\]\{3,\}...}} to allow for case-insensitive
matching, which would match the currently problematic {{ChST}} locale below?
See e.g. [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/899]:
{noformat}
Checking out Revision d214f968d765e5c30c8782c5545c38d9aef487fe
(refs/remotes/origin/branch_7x)
[...]
[java-info] java version "1.8.0_191"
[java-info] Java(TM) SE Runtime Environment (1.8.0_191-b12, Oracle Corporation)
[java-info] Java HotSpot(TM) 64-Bit Server VM (25.191-b12, Oracle Corporation)
[java-info] Test args: [-XX:-UseCompressedOops -XX:+UseConcMarkSweepGC]
[...]
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=ExtractingRequestHandlerTest -Dtests.seed=B4BB8D072ABBC41E
-Dtests.slow=true -Dtests.locale=en-CA -Dtests.timezone=Pacific/Guam
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] ERROR 0.00s J0 | ExtractingRequestHandlerTest (suite) <<<
[junit4]> Throwable #1: java.lang.AssertionError: Is some other JVM
affected? Or bad regex? TzDisplayName: ChST
[junit4]>at
__randomizedtesting.SeedInfo.seed([B4BB8D072ABBC41E]:0)
[junit4]>at
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.beforeClass(ExtractingRequestHandlerTest.java:50)
[junit4]>at java.lang.Thread.run(Thread.java:748)
{noformat}
was (Author: steve_rowe):
Looks like the regex needs another adjustment, maybe relax it from
"[A-Z]{3,}([+-]\\d\\d(:\\d\\d)?)?}} to "[A-Za-z]{3,}([+-]\\d\\d(:\\d\\d)?)?" to
allow for case-insensitive matching, which would match the currently
problematic {{ChST}} locale below?
See e.g. [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/899]:
{noformat}
Checking out Revision d214f968d765e5c30c8782c5545c38d9aef487fe
(refs/remotes/origin/branch_7x)
[...]
[java-info] java version "1.8.0_191"
[java-info] Java(TM) SE Runtime Environment (1.8.0_191-b12, Oracle Corporation)
[java-info] Java HotSpot(TM) 64-Bit Server VM (25.191-b12, Oracle Corporation)
[java-info] Test args: [-XX:-UseCompressedOops -XX:+UseConcMarkSweepGC]
[...]
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=ExtractingRequestHandlerTest -Dtests.seed=B4BB8D072ABBC41E
-Dtests.slow=true -Dtests.locale=en-CA -Dtests.timezone=Pacific/Guam
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] ERROR 0.00s J0 | ExtractingRequestHandlerTest (suite) <<<
[junit4]> Throwable #1: java.lang.AssertionError: Is some other JVM
affected? Or bad regex? TzDisplayName: ChST
[junit4]>at
__randomizedtesting.SeedInfo.seed([B4BB8D072ABBC41E]:0)
[junit4]>at
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.beforeClass(ExtractingRequestHandlerTest.java:50)
[junit4]>at java.lang.Thread.run(Thread.java:748)
{noformat}
> Disable ExtractingRequestHandlerTest on JDK 11
> --
>
> Key: SOLR-12759
> URL: https://issues.apache.org/jira/browse/SOLR-12759
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - Solr Cell (Tika extraction)
> Environment: JDK 11 and Tika 1.x
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 7.6
>
>
> ExtractingRequestHandlerTest has failed on a JDK 11 RC due to two conspiring
> problems: (A) Tika 1.x sometimes calls Date.toString() when extracting
> metadata (unreleased 2.x will fix this), (B) JDK 11 RC has a bug in some
> locales like Arabic in which a Date.toString() will have a timezone offset
> using its locale's characters for the digits instead of using EN_US.
> I'll add an "assume" check so we don't see failures about this.
--
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] (SOLR-12759) Disable ExtractingRequestHandlerTest on JDK 11
[
https://issues.apache.org/jira/browse/SOLR-12759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681857#comment-16681857
]
Steve Rowe edited comment on SOLR-12759 at 11/9/18 7:18 PM:
Looks like the regex needs another adjustment, maybe relax it from
"[A-Z]{3,}([+-]\\d\\d(:\\d\\d)?)?}} to "[A-Za-z]{3,}([+-]\\d\\d(:\\d\\d)?)?" to
allow for case-insensitive matching, which would match the currently
problematic {{ChST}} locale below?
See e.g. [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/899]:
{noformat}
Checking out Revision d214f968d765e5c30c8782c5545c38d9aef487fe
(refs/remotes/origin/branch_7x)
[...]
[java-info] java version "1.8.0_191"
[java-info] Java(TM) SE Runtime Environment (1.8.0_191-b12, Oracle Corporation)
[java-info] Java HotSpot(TM) 64-Bit Server VM (25.191-b12, Oracle Corporation)
[java-info] Test args: [-XX:-UseCompressedOops -XX:+UseConcMarkSweepGC]
[...]
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=ExtractingRequestHandlerTest -Dtests.seed=B4BB8D072ABBC41E
-Dtests.slow=true -Dtests.locale=en-CA -Dtests.timezone=Pacific/Guam
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] ERROR 0.00s J0 | ExtractingRequestHandlerTest (suite) <<<
[junit4]> Throwable #1: java.lang.AssertionError: Is some other JVM
affected? Or bad regex? TzDisplayName: ChST
[junit4]>at
__randomizedtesting.SeedInfo.seed([B4BB8D072ABBC41E]:0)
[junit4]>at
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.beforeClass(ExtractingRequestHandlerTest.java:50)
[junit4]>at java.lang.Thread.run(Thread.java:748)
{noformat}
was (Author: steve_rowe):
Looks like the regex needs another adjustment, maybe relax it from
{{\[A-Z\]\{3,\}(\[+-\]\\d\\d(:\\d\\d)?)?}} to
{{[A-Za-z]{3,}([+-]\\d\\d(:\\d\\d)?)?}} to allow for case-insensitive matching,
which would match the currently problematic {{ChST}} locale below?
See e.g. [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/899]:
{noformat}
Checking out Revision d214f968d765e5c30c8782c5545c38d9aef487fe
(refs/remotes/origin/branch_7x)
[...]
[java-info] java version "1.8.0_191"
[java-info] Java(TM) SE Runtime Environment (1.8.0_191-b12, Oracle Corporation)
[java-info] Java HotSpot(TM) 64-Bit Server VM (25.191-b12, Oracle Corporation)
[java-info] Test args: [-XX:-UseCompressedOops -XX:+UseConcMarkSweepGC]
[...]
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=ExtractingRequestHandlerTest -Dtests.seed=B4BB8D072ABBC41E
-Dtests.slow=true -Dtests.locale=en-CA -Dtests.timezone=Pacific/Guam
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] ERROR 0.00s J0 | ExtractingRequestHandlerTest (suite) <<<
[junit4]> Throwable #1: java.lang.AssertionError: Is some other JVM
affected? Or bad regex? TzDisplayName: ChST
[junit4]>at
__randomizedtesting.SeedInfo.seed([B4BB8D072ABBC41E]:0)
[junit4]>at
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.beforeClass(ExtractingRequestHandlerTest.java:50)
[junit4]>at java.lang.Thread.run(Thread.java:748)
{noformat}
> Disable ExtractingRequestHandlerTest on JDK 11
> --
>
> Key: SOLR-12759
> URL: https://issues.apache.org/jira/browse/SOLR-12759
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - Solr Cell (Tika extraction)
> Environment: JDK 11 and Tika 1.x
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 7.6
>
>
> ExtractingRequestHandlerTest has failed on a JDK 11 RC due to two conspiring
> problems: (A) Tika 1.x sometimes calls Date.toString() when extracting
> metadata (unreleased 2.x will fix this), (B) JDK 11 RC has a bug in some
> locales like Arabic in which a Date.toString() will have a timezone offset
> using its locale's characters for the digits instead of using EN_US.
> I'll add an "assume" check so we don't see failures about this.
--
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] [Reopened] (SOLR-12759) Disable ExtractingRequestHandlerTest on JDK 11
[
https://issues.apache.org/jira/browse/SOLR-12759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe reopened SOLR-12759:
---
Looks like the regex needs another adjustment, maybe relax it from
{{\[A-Z\]\{3,\}(\[+-\]\\d\\d(:\\d\\d)?)?}} to
{{[A-Za-z]{3,}([+-]\\d\\d(:\\d\\d)?)?}} to allow for case-insensitive matching,
which would match the currently problematic {{ChST}} locale below?
See e.g. [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/899]:
{noformat}
Checking out Revision d214f968d765e5c30c8782c5545c38d9aef487fe
(refs/remotes/origin/branch_7x)
[...]
[java-info] java version "1.8.0_191"
[java-info] Java(TM) SE Runtime Environment (1.8.0_191-b12, Oracle Corporation)
[java-info] Java HotSpot(TM) 64-Bit Server VM (25.191-b12, Oracle Corporation)
[java-info] Test args: [-XX:-UseCompressedOops -XX:+UseConcMarkSweepGC]
[...]
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=ExtractingRequestHandlerTest -Dtests.seed=B4BB8D072ABBC41E
-Dtests.slow=true -Dtests.locale=en-CA -Dtests.timezone=Pacific/Guam
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] ERROR 0.00s J0 | ExtractingRequestHandlerTest (suite) <<<
[junit4]> Throwable #1: java.lang.AssertionError: Is some other JVM
affected? Or bad regex? TzDisplayName: ChST
[junit4]>at
__randomizedtesting.SeedInfo.seed([B4BB8D072ABBC41E]:0)
[junit4]>at
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.beforeClass(ExtractingRequestHandlerTest.java:50)
[junit4]>at java.lang.Thread.run(Thread.java:748)
{noformat}
> Disable ExtractingRequestHandlerTest on JDK 11
> --
>
> Key: SOLR-12759
> URL: https://issues.apache.org/jira/browse/SOLR-12759
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - Solr Cell (Tika extraction)
> Environment: JDK 11 and Tika 1.x
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 7.6
>
>
> ExtractingRequestHandlerTest has failed on a JDK 11 RC due to two conspiring
> problems: (A) Tika 1.x sometimes calls Date.toString() when extracting
> metadata (unreleased 2.x will fix this), (B) JDK 11 RC has a bug in some
> locales like Arabic in which a Date.toString() will have a timezone offset
> using its locale's characters for the digits instead of using EN_US.
> I'll add an "assume" check so we don't see failures about this.
--
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-MacOSX (64bit/jdk1.8.0) - Build # 4921 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4921/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 5 tests failed. FAILED: org.apache.solr.cloud.RecoveryAfterSoftCommitTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:58676/collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:58676/collection1 at __randomizedtesting.SeedInfo.seed([5F64F2B58AEE3984:D730CD6F2412547C]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1107) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1260) at org.apache.solr.cloud.RecoveryAfterSoftCommitTest.test(RecoveryAfterSoftCommitTest.java:87) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1010) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:985) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) 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
[jira] [Commented] (SOLR-12555) Replace try-fail-catch test patterns
[
https://issues.apache.org/jira/browse/SOLR-12555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681814#comment-16681814
]
Jason Gerlowski commented on SOLR-12555:
I don't have anything inflight at the moment, so go ahead. If that changes
though I'll be sure to post here and tag you. Thanks for the continued help
with this; really appreciate the effort.
> Replace try-fail-catch test patterns
>
>
> Key: SOLR-12555
> URL: https://issues.apache.org/jira/browse/SOLR-12555
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-12555-sorted-by-package.txt, SOLR-12555.txt
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> I recently added some test code through SOLR-12427 which used the following
> test anti-pattern:
> {code}
> try {
> actionExpectedToThrowException();
> fail("I expected this to throw an exception, but it didn't");
> catch (Exception e) {
> assertOnThrownException(e);
> }
> {code}
> Hoss (rightfully) objected that this should instead be written using the
> formulation below, which is clearer and more concise.
> {code}
> SolrException e = expectThrows(() -> {...});
> {code}
> We should remove many of these older formulations where it makes sense. Many
> of them were written before {{expectThrows}} was introduced, and having the
> old style assertions around makes it easier for them to continue creeping in.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8560) TestByteBuffersDirectory.testSeekPastEOF() failures with ByteArrayIndexInput
[
https://issues.apache.org/jira/browse/LUCENE-8560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681803#comment-16681803
]
Uwe Schindler commented on LUCENE-8560:
---
+1 to nuke it. Otherwise change the impl to be correct (catch AIOOBE and throw
EOF)
> TestByteBuffersDirectory.testSeekPastEOF() failures with ByteArrayIndexInput
>
>
> Key: LUCENE-8560
> URL: https://issues.apache.org/jira/browse/LUCENE-8560
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
>Reporter: Steve Rowe
>Assignee: Dawid Weiss
>Priority: Minor
> Attachments: LUCENE-8560.patch
>
>
> Two reproducing seeds below. In both cases:
> * the {{IndexInput}} implementation is {{ByteArrayIndexInput}}
> * seeking to exactly EOF does not throw an exception
> * {{ByteArrayIndexInput.readByte()}} throws AIOOBE instead of the expected
> EOFException
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4903]:
> {noformat}
> Checking out Revision 856e28d8cf07cc34bc1361784bf00e7aceb3af97
> (refs/remotes/origin/master)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestByteBuffersDirectory -Dtests.method=testSeekPastEOF
> -Dtests.seed=BDFA8CEDB7C93AC1 -Dtests.slow=true -Dtests.locale=sr-RS
> -Dtests.timezone=Europe/Astrakhan -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.00s J0 | TestByteBuffersDirectory.testSeekPastEOF
> {impl=byte array (heap)} <<<
>[junit4]> Throwable #1: junit.framework.AssertionFailedError:
> Unexpected exception type, expected EOFException but got
> java.lang.ArrayIndexOutOfBoundsException: 1770
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([BDFA8CEDB7C93AC1:5DBC4714B74C4450]:0)
>[junit4]> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2680)
>[junit4]> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2669)
>[junit4]> at
> org.apache.lucene.store.BaseDirectoryTestCase.testSeekPastEOF(BaseDirectoryTestCase.java:516)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:844)
>[junit4]> Caused by: java.lang.ArrayIndexOutOfBoundsException: 1770
>[junit4]> at
> org.apache.lucene.store.ByteArrayIndexInput.readByte(ByteArrayIndexInput.java:145)
>[junit4]> at
> org.apache.lucene.store.BaseDirectoryTestCase.lambda$testSeekPastEOF$12(BaseDirectoryTestCase.java:518)
>[junit4]> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2675)
>[junit4]> ... 37 more
> [...]
>[junit4] 2> NOTE: test params are: codec=Lucene80,
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@2c972cf9),
> locale=sr-RS, timezone=Europe/Astrakhan
>[junit4] 2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 9
> (64-bit)/cpus=3,threads=1,free=157933784,total=235929600
> {noformat}
> Also (older) from
> [https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1645]:
> {noformat}
> [junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestByteBuffersDirectory -Dtests.method=testSeekPastEOF
> -Dtests.seed=90B07B6267E63464 -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=es-PR -Dtests.timezone=Australia/Currie -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
> [junit4] FAILURE 0.01s J1 | TestByteBuffersDirectory.testSeekPastEOF
> {impl=byte array (heap)} <<<
> [junit4]> Throwable #1: junit.framework.AssertionFailedError:
> Unexpected exception type, expected EOFException but got
> java.lang.ArrayIndexOutOfBoundsException: 1881
> [junit4]> at
> __randomizedtesting.SeedInfo.seed([90B07B6267E63464:70F6B09B67634AF5]:0)
> [junit4]> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2683)
> [junit4]> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2672)
> [junit4]> at
> org.apache.lucene.store.BaseDirectoryTestCase.testSeekPastEOF(BaseDirectoryTestCase.java:516)
> [junit4]> at java.lang.Thread.run(Thread.java:748)
>
[jira] [Commented] (LUCENE-8560) TestByteBuffersDirectory.testSeekPastEOF() failures with ByteArrayIndexInput
[
https://issues.apache.org/jira/browse/LUCENE-8560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681789#comment-16681789
]
Steve Rowe commented on LUCENE-8560:
+1 to nuke ByteArrayIndexInput [~dweiss], in both cases users are not involved
in choice of exact implementation.
Probably the {{ByteBuffersDirectory.OUTPUT_AS_BYTE_ARRAY}} option could be
deprecated, and in the meantime its impl could be forwarded to the
{{OUTPUT_AS_ONE_BUFFER}} impl?
> TestByteBuffersDirectory.testSeekPastEOF() failures with ByteArrayIndexInput
>
>
> Key: LUCENE-8560
> URL: https://issues.apache.org/jira/browse/LUCENE-8560
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
>Reporter: Steve Rowe
>Assignee: Dawid Weiss
>Priority: Minor
> Attachments: LUCENE-8560.patch
>
>
> Two reproducing seeds below. In both cases:
> * the {{IndexInput}} implementation is {{ByteArrayIndexInput}}
> * seeking to exactly EOF does not throw an exception
> * {{ByteArrayIndexInput.readByte()}} throws AIOOBE instead of the expected
> EOFException
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4903]:
> {noformat}
> Checking out Revision 856e28d8cf07cc34bc1361784bf00e7aceb3af97
> (refs/remotes/origin/master)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestByteBuffersDirectory -Dtests.method=testSeekPastEOF
> -Dtests.seed=BDFA8CEDB7C93AC1 -Dtests.slow=true -Dtests.locale=sr-RS
> -Dtests.timezone=Europe/Astrakhan -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.00s J0 | TestByteBuffersDirectory.testSeekPastEOF
> {impl=byte array (heap)} <<<
>[junit4]> Throwable #1: junit.framework.AssertionFailedError:
> Unexpected exception type, expected EOFException but got
> java.lang.ArrayIndexOutOfBoundsException: 1770
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([BDFA8CEDB7C93AC1:5DBC4714B74C4450]:0)
>[junit4]> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2680)
>[junit4]> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2669)
>[junit4]> at
> org.apache.lucene.store.BaseDirectoryTestCase.testSeekPastEOF(BaseDirectoryTestCase.java:516)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:844)
>[junit4]> Caused by: java.lang.ArrayIndexOutOfBoundsException: 1770
>[junit4]> at
> org.apache.lucene.store.ByteArrayIndexInput.readByte(ByteArrayIndexInput.java:145)
>[junit4]> at
> org.apache.lucene.store.BaseDirectoryTestCase.lambda$testSeekPastEOF$12(BaseDirectoryTestCase.java:518)
>[junit4]> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2675)
>[junit4]> ... 37 more
> [...]
>[junit4] 2> NOTE: test params are: codec=Lucene80,
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@2c972cf9),
> locale=sr-RS, timezone=Europe/Astrakhan
>[junit4] 2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 9
> (64-bit)/cpus=3,threads=1,free=157933784,total=235929600
> {noformat}
> Also (older) from
> [https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1645]:
> {noformat}
> [junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestByteBuffersDirectory -Dtests.method=testSeekPastEOF
> -Dtests.seed=90B07B6267E63464 -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=es-PR -Dtests.timezone=Australia/Currie -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
> [junit4] FAILURE 0.01s J1 | TestByteBuffersDirectory.testSeekPastEOF
> {impl=byte array (heap)} <<<
> [junit4]> Throwable #1: junit.framework.AssertionFailedError:
> Unexpected exception type, expected EOFException but got
> java.lang.ArrayIndexOutOfBoundsException: 1881
> [junit4]> at
> __randomizedtesting.SeedInfo.seed([90B07B6267E63464:70F6B09B67634AF5]:0)
> [junit4]> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2683)
> [junit4]> at
>
[jira] [Comment Edited] (SOLR-12976) Unify RedactionUtils and metrics hiddenSysProps settings
[
https://issues.apache.org/jira/browse/SOLR-12976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681781#comment-16681781
]
Gus Heck edited comment on SOLR-12976 at 11/9/18 6:12 PM:
--
Monitoring leaks is what the metrics stuff is about, right? So that makes
sense. It's the UI stuff that concerns me. The list of properties should only
hide things if they are hidden well and good across the board.
A "schema-admin" role is basically what you are talking about at the end of
your comment. That's an interesting idea. Probably it should be driven by a
read-secret-sysprop
[permission|https://lucene.apache.org/solr/guide/7_5/rule-based-authorization-plugin.html#rule-based-authorization-plugin]
(or maybe part of the security-read permission?), which would then imply UI
redaction, Schema update(and other) prohibitions on use of secret property
expansion (input validation) and secret redaction for responses from API's. I'm
not yet familiar with the authorization plugin, so I don't quite know what my
suggestion implies though.
was (Author: gus_heck):
Monitoring leaks is what the metrics stuff is about, right? So that makes
sense. It's the UI stuff that concerns me. The list of properties should only
hide things if they are hidden well and good across the board.
A "schema-admin" role is basically what you are talking about at the end of
your comment. That's an interesting idea. Probably it should be driven by a
read-secret-sysprop
[permission|https://lucene.apache.org/solr/guide/7_5/rule-based-authorization-plugin.html#rule-based-authorization-plugin],
which would then imply UI redaction, Schema update(and other) prohibitions on
use of secret property expansion (input validation) and secret redaction for
responses from API's. I'm not yet familiar with the authorization plugin, so I
don't quite know what my suggestion implies though.
> Unify RedactionUtils and metrics hiddenSysProps settings
>
>
> Key: SOLR-12976
> URL: https://issues.apache.org/jira/browse/SOLR-12976
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Jan Høydahl
>Priority: Major
>
> System properties can contain sensitive data, and they are easily available
> from the Admin UI (/admin/info/system) and also from the Metrics API
> (/admin/metrics).
> By default the {{/admin/info/system}} redacts any sys prop with a key
> containing *password*. This can be configured with sysprop
> {{-Dsolr.redaction.system.pattern=}}
> The metrics API by default hides these sysprops from the API output:
> {code:java}
> "javax.net.ssl.keyStorePassword",
> "javax.net.ssl.trustStorePassword",
> "basicauth",
> "zkDigestPassword",
> "zkDigestReadonlyPassword"
> {code}
> You can redefine these by adding a section to {{solr.xml}}:
> ([https://lucene.apache.org/solr/guide/7_5/metrics-reporting.html#the-metrics-hiddensysprops-element])
> {code:xml}
>
>
>foo
>bar
>baz
>
> {code}
> h2. Unifying the two
> It is not very user firiendly to have two different systems for redacting
> system properties and two sets of defaults. This goals of this issue are
> * Keep only one set of defaults
> * Both metrics and system info handler will use the same source
> * It should be possible to change and persist the list without a full
> cluster restart, preferably though some API
> Note that the {{solr.redaction.system.pattern}} property is not documented in
> the ref guide, so this Jira should also fix documentation!
--
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-12976) Unify RedactionUtils and metrics hiddenSysProps settings
[
https://issues.apache.org/jira/browse/SOLR-12976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681781#comment-16681781
]
Gus Heck commented on SOLR-12976:
-
Monitoring leaks is what the metrics stuff is about, right? So that makes
sense. It's the UI stuff that concerns me. The list of properties should only
hide things if they are hidden well and good across the board.
A "schema-admin" role is basically what you are talking about at the end of
your comment. That's an interesting idea. Probably it should be driven by a
read-secret-sysprop
[permission|https://lucene.apache.org/solr/guide/7_5/rule-based-authorization-plugin.html#rule-based-authorization-plugin],
which would then imply UI redaction, Schema update(and other) prohibitions on
use of secret property expansion (input validation) and secret redaction for
responses from API's. I'm not yet familiar with the authorization plugin, so I
don't quite know what my suggestion implies though.
> Unify RedactionUtils and metrics hiddenSysProps settings
>
>
> Key: SOLR-12976
> URL: https://issues.apache.org/jira/browse/SOLR-12976
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Jan Høydahl
>Priority: Major
>
> System properties can contain sensitive data, and they are easily available
> from the Admin UI (/admin/info/system) and also from the Metrics API
> (/admin/metrics).
> By default the {{/admin/info/system}} redacts any sys prop with a key
> containing *password*. This can be configured with sysprop
> {{-Dsolr.redaction.system.pattern=}}
> The metrics API by default hides these sysprops from the API output:
> {code:java}
> "javax.net.ssl.keyStorePassword",
> "javax.net.ssl.trustStorePassword",
> "basicauth",
> "zkDigestPassword",
> "zkDigestReadonlyPassword"
> {code}
> You can redefine these by adding a section to {{solr.xml}}:
> ([https://lucene.apache.org/solr/guide/7_5/metrics-reporting.html#the-metrics-hiddensysprops-element])
> {code:xml}
>
>
>foo
>bar
>baz
>
> {code}
> h2. Unifying the two
> It is not very user firiendly to have two different systems for redacting
> system properties and two sets of defaults. This goals of this issue are
> * Keep only one set of defaults
> * Both metrics and system info handler will use the same source
> * It should be possible to change and persist the list without a full
> cluster restart, preferably though some API
> Note that the {{solr.redaction.system.pattern}} property is not documented in
> the ref guide, so this Jira should also fix documentation!
--
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: Lucene/Solr 7.6
Should I try and get a new patch for SOLR-629 working with 7.x? https://issues.apache.org/jira/browse/SOLR-629 Previous patches have been ignored, so I’d like somebody to promise to look at it. Getting those changes into the edismax code makes my brain hurt. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Nov 9, 2018, at 9:43 AM, Chris Hostetter wrote: > > > : I don't have any problem waiting until tomorrow to cut the branch. I > : noticed a patch was just committed so let me know if you happen to resolve > : this sooner than expected. > > Heh .. yeah, since I didn't hear back from you I stayed up a little later > then usual the last 2 nights re-reviewing everything (that and the > patch review from smiley gave me some re-assurance.) > > (As far as SOLR-12962 is concerned) Feel free to cut branch_7_6 whenever > you're ready. > > > > > : On Thu, Nov 8, 2018 at 3:59 PM Chris Hostetter > : wrote: > : > : > > : > : Let me know if there are any other blockers that need to be resolved > : > prior > : > : to cutting the branch. If not, I will plan to cut the branch on Friday > or > : > : (provided they are close to resolution) whenever these issues are > : > resolved. > : > > : > nknize: I'd like to try and get SOLR-12962 into 7.6... > : > > : > It's a new "opt in" feature, but one that should help prevent a lot of > : > performance problems for people who want to try it out -- so I'd really > : > like to release it ASAP so we can hopefully get feedback from folks who > : > try it in time to consider changing the default to "opt out" ~8.0 (see > : > SOLR-12963 and parent SOLR-8273 for background) > : > > : > The patch is currently feature complete -- the only 'nocommits' are for > : > updating a small amount of documentation, which I should have done > : > sometime thursday morning (GMT-0700). > : > > : > I'm currently having my machine hammer on the tests, and waiting/hoping > : > for some patch review / sanity checks. > : > > : > > : > My typically "personal workflow based on comfort level" for a change like > : > this would be to do nothing but testing & self-review for at least a day > : > before committing & backporting ... which would mean wrapping it up > : > sometime friday afternoon (GMT-0700). > : > > : > Unless there are any objections, I'd appreciate knowing if either: > : > > : > 1) You would be ok holding off on cutting branch_7_6 until > : > sometime *after* friday ? > : > > : > 2) Folks would be ok w/me backporting SOLR-12962 to banch_7_6 after > : > you fork it (even though it's a new feature, not a blocker bug fix) ? > : > > : > > : > Thoughts? Concerns? > : > > : > > : > > : > > : > -Hoss > : > http://www.lucidworks.com/ > : > > : > - > : > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > : > For additional commands, e-mail: dev-h...@lucene.apache.org > : > > : > -- > : > : Nicholas Knize, Ph.D., GISP > : Geospatial Software Guy | Elasticsearch > : Apache Lucene Committer > : nkn...@apache.org > : > > -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] [Commented] (SOLR-12981) Better support JSON faceting responses in SolrJ
[
https://issues.apache.org/jira/browse/SOLR-12981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681755#comment-16681755
]
Jason Gerlowski commented on SOLR-12981:
The attached patch creates an object called "JsonFacetingResponse" that
supports navigating faceting results. General outline:
{code}
*JsonFacetingResponse*
int getCount()
Object getVal()
List getFacetResultsByName(String name)
Double getStatFacetResultsByName(String name);
{code}
Some general notes/pros/cons:
- JsonFacetingResponse is recursive- it represents the top-level faceting
response, but it's also used to represent individual facet-buckets (which
themselves can have subfacets, etc.)
- it parses keys "count", and "val", and then treats any other JSON keys as the
names of subfacets. This is a misstep with some facet-types which have
optional keys/statistics (e.g. the numBuckets stat that is optionally computed
for "terms" facets). Partially to blame for this is that it's difficult to
look at the JSON faceting response and know what sort of facet we're parsing
the results of. If we had a reliable way to differentiate e.g. a "terms"
response bucket from a "range" response bucket, we could change the interfaces
in SolrJ to be a little more helpful. For example we could let users do things
like:
({{facetingResponse.getTermFacetResultsByName("categories").getNumBuckets()}}).
Musing aloud, I wonder how reasonable it'd be to add a "type" property to each
facet bucket. That'd make parsing and allowing access to this stuff much
easier.
- The response for heatmap facets is very different from the others. The
current WIP patch doesn't handle it currently, but there's no real blocker for
implementing it.
> Better support JSON faceting responses in SolrJ
> ---
>
> Key: SOLR-12981
> URL: https://issues.apache.org/jira/browse/SOLR-12981
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java, SolrJ
>Affects Versions: 7.5, master (8.0)
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-12981.patch
>
>
> SOLR-12947 created JsonQueryRequest to make using the JSON request API easier
> in SolrJ. SOLR-12965 is adding faceting support to this request object.
> This subtask of SOLR-12965 involves providing a way to parse the JSON
> faceting responses into easy-to-use SolrJ objects.
> Currently the only option for users is to manipulate the underlying NamedList
> directly. We should create a "JsonFacetingResponse" in the model of
> ClusteringResponse, SuggesterResponse, TermsResponse, etc. and add an
> accessor to {{QueryResponse}} for getting at the faceting results.
--
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-7.x-Linux (32bit/jdk1.8.0_172) - Build # 3063 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/3063/ Java: 32bit/jdk1.8.0_172 -server -XX:+UseParallelGC 2 tests failed. FAILED: org.apache.solr.client.solrj.impl.CloudSolrClientTest.testParallelUpdateQTime Error Message: Error from server at https://127.0.0.1:38161/solr/collection1_shard2_replica_n3: Expected mime type application/octet-stream but got text/html.Error 404 Can not find: /solr/collection1_shard2_replica_n3/update HTTP ERROR 404 Problem accessing /solr/collection1_shard2_replica_n3/update. Reason: Can not find: /solr/collection1_shard2_replica_n3/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605 Stack Trace: org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from server at https://127.0.0.1:38161/solr/collection1_shard2_replica_n3: Expected mime type application/octet-stream but got text/html. Error 404 Can not find: /solr/collection1_shard2_replica_n3/update HTTP ERROR 404 Problem accessing /solr/collection1_shard2_replica_n3/update. Reason: Can not find: /solr/collection1_shard2_replica_n3/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605 at __randomizedtesting.SeedInfo.seed([6FF212248F88003B:812A69B5C1F7D5A8]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:551) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1016) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.testParallelUpdateQTime(CloudSolrClientTest.java:146) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[GitHub] lucene-solr issue #495: LUCENE-8464: Implement ConstantScoreScorer#setMinCom...
Github user cbismuth commented on the issue: https://github.com/apache/lucene-solr/pull/495 Well you're right, without a static wrapper (see 19e156cedd343b27214538aec58f24e1d66105da) I can't assign approximation to `DocIdSetIterator.empty()` after setting `minCompetitiveScore`. I'll update this PR with your suggestions and I let you know, thanks a lot @jimczi for your help! --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene/Solr 7.6
: I don't have any problem waiting until tomorrow to cut the branch. I : noticed a patch was just committed so let me know if you happen to resolve : this sooner than expected. Heh .. yeah, since I didn't hear back from you I stayed up a little later then usual the last 2 nights re-reviewing everything (that and the patch review from smiley gave me some re-assurance.) (As far as SOLR-12962 is concerned) Feel free to cut branch_7_6 whenever you're ready. : On Thu, Nov 8, 2018 at 3:59 PM Chris Hostetter : wrote: : : > : > : Let me know if there are any other blockers that need to be resolved : > prior : > : to cutting the branch. If not, I will plan to cut the branch on Friday or : > : (provided they are close to resolution) whenever these issues are : > resolved. : > : > nknize: I'd like to try and get SOLR-12962 into 7.6... : > : > It's a new "opt in" feature, but one that should help prevent a lot of : > performance problems for people who want to try it out -- so I'd really : > like to release it ASAP so we can hopefully get feedback from folks who : > try it in time to consider changing the default to "opt out" ~8.0 (see : > SOLR-12963 and parent SOLR-8273 for background) : > : > The patch is currently feature complete -- the only 'nocommits' are for : > updating a small amount of documentation, which I should have done : > sometime thursday morning (GMT-0700). : > : > I'm currently having my machine hammer on the tests, and waiting/hoping : > for some patch review / sanity checks. : > : > : > My typically "personal workflow based on comfort level" for a change like : > this would be to do nothing but testing & self-review for at least a day : > before committing & backporting ... which would mean wrapping it up : > sometime friday afternoon (GMT-0700). : > : > Unless there are any objections, I'd appreciate knowing if either: : > : > 1) You would be ok holding off on cutting branch_7_6 until : > sometime *after* friday ? : > : > 2) Folks would be ok w/me backporting SOLR-12962 to banch_7_6 after : > you fork it (even though it's a new feature, not a blocker bug fix) ? : > : > : > Thoughts? Concerns? : > : > : > : > : > -Hoss : > http://www.lucidworks.com/ : > : > - : > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org : > For additional commands, e-mail: dev-h...@lucene.apache.org : > : > -- : : Nicholas Knize, Ph.D., GISP : Geospatial Software Guy | Elasticsearch : Apache Lucene Committer : nkn...@apache.org : -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-12981) Better support JSON faceting responses in SolrJ
[
https://issues.apache.org/jira/browse/SOLR-12981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski updated SOLR-12981:
---
Attachment: SOLR-12981.patch
> Better support JSON faceting responses in SolrJ
> ---
>
> Key: SOLR-12981
> URL: https://issues.apache.org/jira/browse/SOLR-12981
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java, SolrJ
>Affects Versions: 7.5, master (8.0)
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-12981.patch
>
>
> SOLR-12947 created JsonQueryRequest to make using the JSON request API easier
> in SolrJ. SOLR-12965 is adding faceting support to this request object.
> This subtask of SOLR-12965 involves providing a way to parse the JSON
> faceting responses into easy-to-use SolrJ objects.
> Currently the only option for users is to manipulate the underlying NamedList
> directly. We should create a "JsonFacetingResponse" in the model of
> ClusteringResponse, SuggesterResponse, TermsResponse, etc. and add an
> accessor to {{QueryResponse}} for getting at the faceting results.
--
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] (SOLR-12981) Better support JSON faceting responses in SolrJ
Jason Gerlowski created SOLR-12981:
--
Summary: Better support JSON faceting responses in SolrJ
Key: SOLR-12981
URL: https://issues.apache.org/jira/browse/SOLR-12981
Project: Solr
Issue Type: Sub-task
Security Level: Public (Default Security Level. Issues are Public)
Components: clients - java, SolrJ
Affects Versions: 7.5, master (8.0)
Reporter: Jason Gerlowski
Assignee: Jason Gerlowski
SOLR-12947 created JsonQueryRequest to make using the JSON request API easier
in SolrJ. SOLR-12965 is adding faceting support to this request object. This
subtask of SOLR-12965 involves providing a way to parse the JSON faceting
responses into easy-to-use SolrJ objects.
Currently the only option for users is to manipulate the underlying NamedList
directly. We should create a "JsonFacetingResponse" in the model of
ClusteringResponse, SuggesterResponse, TermsResponse, etc. and add an accessor
to {{QueryResponse}} for getting at the faceting results.
--
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: Lucene/Solr 7.6
I don't have any problem waiting until tomorrow to cut the branch. I noticed a patch was just committed so let me know if you happen to resolve this sooner than expected. On Thu, Nov 8, 2018 at 3:59 PM Chris Hostetter wrote: > > : Let me know if there are any other blockers that need to be resolved > prior > : to cutting the branch. If not, I will plan to cut the branch on Friday or > : (provided they are close to resolution) whenever these issues are > resolved. > > nknize: I'd like to try and get SOLR-12962 into 7.6... > > It's a new "opt in" feature, but one that should help prevent a lot of > performance problems for people who want to try it out -- so I'd really > like to release it ASAP so we can hopefully get feedback from folks who > try it in time to consider changing the default to "opt out" ~8.0 (see > SOLR-12963 and parent SOLR-8273 for background) > > The patch is currently feature complete -- the only 'nocommits' are for > updating a small amount of documentation, which I should have done > sometime thursday morning (GMT-0700). > > I'm currently having my machine hammer on the tests, and waiting/hoping > for some patch review / sanity checks. > > > My typically "personal workflow based on comfort level" for a change like > this would be to do nothing but testing & self-review for at least a day > before committing & backporting ... which would mean wrapping it up > sometime friday afternoon (GMT-0700). > > Unless there are any objections, I'd appreciate knowing if either: > > 1) You would be ok holding off on cutting branch_7_6 until > sometime *after* friday ? > > 2) Folks would be ok w/me backporting SOLR-12962 to banch_7_6 after > you fork it (even though it's a new feature, not a blocker bug fix) ? > > > Thoughts? Concerns? > > > > > -Hoss > http://www.lucidworks.com/ > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Nicholas Knize, Ph.D., GISP Geospatial Software Guy | Elasticsearch Apache Lucene Committer nkn...@apache.org
[jira] [Updated] (SOLR-12965) Add JSON faceting support to SolrJ
[
https://issues.apache.org/jira/browse/SOLR-12965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski updated SOLR-12965:
---
Summary: Add JSON faceting support to SolrJ (was: Add faceting support to
JsonQueryRequest)
> Add JSON faceting support to SolrJ
> --
>
> Key: SOLR-12965
> URL: https://issues.apache.org/jira/browse/SOLR-12965
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java, SolrJ
>Affects Versions: 7.5, master (8.0)
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-12965.patch, SOLR-12965.patch, SOLR-12965.patch,
> SOLR-12965.patch
>
>
> SOLR-12947 created {{JsonQueryRequest}}, a SolrJ class that makes it easier
> for users to make JSON-api requests in their Java/SolrJ code. Currently this
> class is missing any sort of faceting capabilities (I'd held off on adding
> this as a part of SOLR-12947 just to keep the issues smaller).
> This JIRA covers adding that missing faceting capability.
> There's a few ways we could handle it, but my first attempt at adding
> faceting support will probably have users specify a Map for
> each facet that they wish to add, similar to how complex queries were
> supported in SOLR-12947. This approach has some pros and cons:
> The benefit is how general the approach is- our interface stays resilient to
> any future changes to the syntax of the JSON API, and users can build facets
> that I'd never thought to explicitly test. The downside is that this doesn't
> offer much abstraction for users who are unfamiliar with our JSON syntax-
> they still have to know the JSON "schema" to build a map representing their
> facet. But in practice we can probably mitigate this downside by providing
> "facet builders" or some other helper classes to provide this abstraction in
> the common case.
> Hope to have a skeleton patch up soon.
--
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-7.x-Windows (64bit/jdk1.8.0_172) - Build # 880 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/880/ Java: 64bit/jdk1.8.0_172 -XX:-UseCompressedOops -XX:+UseSerialGC 4 tests failed. FAILED: org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testTriggerThrottling Error Message: Both triggers should have fired by now Stack Trace: java.lang.AssertionError: Both triggers should have fired by now at __randomizedtesting.SeedInfo.seed([629440E21F62B7B8:99B6E8C7CDC8542A]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testTriggerThrottling(TriggerIntegrationTest.java:222) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testTriggerThrottling Error Message: Both triggers should have fired by now Stack Trace: java.lang.AssertionError: Both triggers should have fired by now at
[GitHub] lucene-solr pull request #495: LUCENE-8464: Implement ConstantScoreScorer#se...
Github user cbismuth commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/495#discussion_r232324465
--- Diff:
lucene/core/src/java/org/apache/lucene/search/ConstantScoreScorer.java ---
@@ -70,7 +98,7 @@ public TwoPhaseIterator twoPhaseIterator() {
@Override
public int docID() {
-return disi.docID();
+return twoPhaseIterator != null ?
twoPhaseIterator.approximation().docID() : doc;
--- End diff --
Yes, it broke some tests.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr issue #495: LUCENE-8464: Implement ConstantScoreScorer#setMinCom...
Github user cbismuth commented on the issue: https://github.com/apache/lucene-solr/pull/495 Great! Exactly what I did except declaring a static inner class, Iâll declare it :+1: thanks! --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10648) Do not expose STOP.PORT and STOP.KEY in sysProps
[
https://issues.apache.org/jira/browse/SOLR-10648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681687#comment-16681687
]
Jason Gerlowski commented on SOLR-10648:
If any users are unswayed by Jan's rationale above (+1, btw) and would like to
hide sysprops from the Admin UI, then there _is_ a workaround for this. Users
can edit {{solr.in.sh}} and define the {{-Dsolr.redaction.system.pattern}}
sysprop under SOLR_OPTS:
{code}
SOLR_OPTS="$SOLR_OPTS
-Dsolr.redaction.system.pattern=(.*password.*|.*PORT|.*KEY)"
{code}
(Credit to Jan, who mentioned this on the mailing list)
> Do not expose STOP.PORT and STOP.KEY in sysProps
>
>
> Key: SOLR-10648
> URL: https://issues.apache.org/jira/browse/SOLR-10648
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: scripts and tools
>Reporter: Jan Høydahl
>Priority: Major
> Labels: security
>
> Currently anyone with HTTP access to Solr can see the Admin UI and all the
> system properties. In there you find
> {noformat}
> -DSTOP.KEY=solrrocks
> -DSTOP.PORT=7983
> {noformat}
> This means that anyone with this info can shut down Solr by hitting that port
> with the key (if it is not firewalled).
> I think the simple solution is to add STOP.PORT and STOP.KEY from
> {{$SOLR_START_OPTS}} to the {{$SOLR_JETTY_CONFIG[@]}} variable. It will still
> be visible on the cmdline but not over HTTP.
--
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-12786) Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure
[
https://issues.apache.org/jira/browse/SOLR-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681694#comment-16681694
]
Cassandra Targett commented on SOLR-12786:
--
I don't see I mentioned it before, but we would also need to make sure the
asciidoctor-ant version we're using is also updated to Asciidoctor 1.5.7 before
we can update the jekyll-asciidoc gem. The latest release of asciidoctor-ant
includes only Asciidoctor 1.5.6.2.
> Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure
> --
>
> Key: SOLR-12786
> URL: https://issues.apache.org/jira/browse/SOLR-12786
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build, documentation
>Affects Versions: master (8.0)
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: SOLR-12786.patch
>
>
> Currently the refguide build requires asciidoctor 1.5.6.2.
> People using {{gem install jekyll-asciidoc}} will end up with version 1.5.7,
> causing different header ID syntax and the build will break.
> Long term we should move to latest asciidoctor.
> It is already documented in README how to install the older 1.5.6.2 version.
>
--
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-12962) add an 'uninvertible' field(type) option (that defaults to "true" for backcompat)
[
https://issues.apache.org/jira/browse/SOLR-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681678#comment-16681678
]
ASF subversion and git services commented on SOLR-12962:
Commit 36ca27c36e90e33abbae8b6ce5359c7655c898c5 in lucene-solr's branch
refs/heads/branch_7x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=36ca27c ]
SOLR-12962: Added a new 'uninvertible' option for fields and fieldtypes. This
defaults to 'true' for backcompat allowing a FieldCache to be built for indexed
fields as needed, but users are encouraged to set this to false (using
docValues as needed) to reduce the risk of large fluxuations in heap size due
to unexpected attempts to sort/facet/function on non-docValue fields.
(cherry picked from commit 77a4bfaa90637cd3d9a8a2ef4889e163dab143aa)
Conflicts:
solr/core/src/test/org/apache/solr/BasicFunctionalityTest.java
> add an 'uninvertible' field(type) option (that defaults to "true" for
> backcompat)
> -
>
> Key: SOLR-12962
> URL: https://issues.apache.org/jira/browse/SOLR-12962
> Project: Solr
> Issue Type: Sub-task
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Fix For: 7.6, master (8.0)
>
> Attachments: SOLR-12962.patch, SOLR-12962.patch, SOLR-12962.patch,
> SOLR-12962.patch, SOLR-12962.patch
>
>
> field & fieldtype declarations should support an {{uninvertible}} option
> (which defaults to "true") for backcompat that dictates wether or not
> Uninversion can be performed on fields.
> See parent issue for more background/discussion.
--
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 pull request #495: LUCENE-8464: Implement ConstantScoreScorer#se...
Github user jimczi commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/495#discussion_r232311732
--- Diff:
lucene/core/src/java/org/apache/lucene/search/ConstantScoreScorer.java ---
@@ -70,7 +98,7 @@ public TwoPhaseIterator twoPhaseIterator() {
@Override
public int docID() {
-return disi.docID();
+return twoPhaseIterator != null ?
twoPhaseIterator.approximation().docID() : doc;
--- End diff --
This would introduce introduce a discrepancy between the docID returned by
the scorer and the one returned by the iterator. You need to apply the
indirection to the approximation of the `twoPhaseIterator` as explained
[here](https://github.com/apache/lucene-solr/pull/495#pullrequestreview-173485478).
---
-
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-12-ea+12) - Build # 23180 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23180/ Java: 64bit/jdk-12-ea+12 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 31 tests failed. FAILED: org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testSslWithInvalidPeerName Error Message: Could not find collection:second_collection Stack Trace: java.lang.AssertionError: Could not find collection:second_collection at __randomizedtesting.SeedInfo.seed([1A1139B60786C3B6:4DA07C0DC77A3CA7]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155) at org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkCreateCollection(TestMiniSolrCloudClusterSSL.java:263) at org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithCollectionCreations(TestMiniSolrCloudClusterSSL.java:249) at org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testSslWithInvalidPeerName(TestMiniSolrCloudClusterSSL.java:185) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) 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.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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) 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
[jira] [Commented] (SOLR-12555) Replace try-fail-catch test patterns
[
https://issues.apache.org/jira/browse/SOLR-12555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681605#comment-16681605
]
Bar Rotstein commented on SOLR-12555:
-
[~gerlowskija], do you have any packages that you've started working on?
I'd like to tackle a few if I'll have some free time this coming week,
and wouldn't want to accidentally have a collision.
> Replace try-fail-catch test patterns
>
>
> Key: SOLR-12555
> URL: https://issues.apache.org/jira/browse/SOLR-12555
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-12555-sorted-by-package.txt, SOLR-12555.txt
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> I recently added some test code through SOLR-12427 which used the following
> test anti-pattern:
> {code}
> try {
> actionExpectedToThrowException();
> fail("I expected this to throw an exception, but it didn't");
> catch (Exception e) {
> assertOnThrownException(e);
> }
> {code}
> Hoss (rightfully) objected that this should instead be written using the
> formulation below, which is clearer and more concise.
> {code}
> SolrException e = expectThrows(() -> {...});
> {code}
> We should remove many of these older formulations where it makes sense. Many
> of them were written before {{expectThrows}} was introduced, and having the
> old style assertions around makes it easier for them to continue creeping in.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12955) Refactor DistributedUpdateProcessor
[ https://issues.apache.org/jira/browse/SOLR-12955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bar Rotstein updated SOLR-12955: Attachment: SOLR-12955.patch > Refactor DistributedUpdateProcessor > --- > > Key: SOLR-12955 > URL: https://issues.apache.org/jira/browse/SOLR-12955 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Bar Rotstein >Priority: Major > Attachments: SOLR-12955.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Lately As I was skimming through Solr's code base I noticed that > DistributedUpdateProcessor has a lot of nested if else statements, which > hampers code readability. -- 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] (SOLR-12955) Refactor DistributedUpdateProcessor
[ https://issues.apache.org/jira/browse/SOLR-12955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681599#comment-16681599 ] Bar Rotstein edited comment on SOLR-12955 at 11/9/18 3:38 PM: -- I have uploaded a patch that has the latest commits that were pushed today to the associated PR. was (Author: brot): I have uploaded a patch that has the latest commits that were pushed today to the associated PR. > Refactor DistributedUpdateProcessor > --- > > Key: SOLR-12955 > URL: https://issues.apache.org/jira/browse/SOLR-12955 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Bar Rotstein >Priority: Major > Attachments: SOLR-12955.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Lately As I was skimming through Solr's code base I noticed that > DistributedUpdateProcessor has a lot of nested if else statements, which > hampers code readability. -- 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-12955) Refactor DistributedUpdateProcessor
[ https://issues.apache.org/jira/browse/SOLR-12955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681599#comment-16681599 ] Bar Rotstein commented on SOLR-12955: - I have uploaded a patch that has the latest commits that were pushed today to the associated PR. > Refactor DistributedUpdateProcessor > --- > > Key: SOLR-12955 > URL: https://issues.apache.org/jira/browse/SOLR-12955 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Bar Rotstein >Priority: Major > Attachments: SOLR-12955.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Lately As I was skimming through Solr's code base I noticed that > DistributedUpdateProcessor has a lot of nested if else statements, which > hampers code readability. -- 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-12962) add an 'uninvertible' field(type) option (that defaults to "true" for backcompat)
[
https://issues.apache.org/jira/browse/SOLR-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681594#comment-16681594
]
ASF subversion and git services commented on SOLR-12962:
Commit 77a4bfaa90637cd3d9a8a2ef4889e163dab143aa in lucene-solr's branch
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=77a4bfa ]
SOLR-12962: Added a new 'uninvertible' option for fields and fieldtypes. This
defaults to 'true' for backcompat allowing a FieldCache to be built for indexed
fields as needed, but users are encouraged to set this to false (using
docValues as needed) to reduce the risk of large fluxuations in heap size due
to unexpected attempts to sort/facet/function on non-docValue fields.
> add an 'uninvertible' field(type) option (that defaults to "true" for
> backcompat)
> -
>
> Key: SOLR-12962
> URL: https://issues.apache.org/jira/browse/SOLR-12962
> Project: Solr
> Issue Type: Sub-task
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Fix For: 7.6, master (8.0)
>
> Attachments: SOLR-12962.patch, SOLR-12962.patch, SOLR-12962.patch,
> SOLR-12962.patch, SOLR-12962.patch
>
>
> field & fieldtype declarations should support an {{uninvertible}} option
> (which defaults to "true") for backcompat that dictates wether or not
> Uninversion can be performed on fields.
> See parent issue for more background/discussion.
--
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) - Build # 7614 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7614/ Java: 64bit/jdk-11 -XX:+UseCompressedOops -XX:+UseG1GC 21 tests failed. FAILED: org.apache.solr.cloud.SplitShardTest.doTest Error Message: Error from server at https://127.0.0.1:50892/solr: Could not find collection : splitshardtest-collection Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:50892/solr: Could not find collection : splitshardtest-collection at __randomizedtesting.SeedInfo.seed([7A8938840CFCD2A:A0EC2B2C2D74DE93]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1107) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.cloud.SplitShardTest.doTest(SplitShardTest.java:64) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS] Lucene-Solr-Tests-master - Build # 2942 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2942/ 3 tests failed. FAILED: org.apache.solr.cloud.TestPullReplica.testKillLeader Error Message: Replica core_node4 not up to date after 10 seconds expected:<1> but was:<0> Stack Trace: java.lang.AssertionError: Replica core_node4 not up to date after 10 seconds expected:<1> but was:<0> at __randomizedtesting.SeedInfo.seed([88BA8797EFDA670C:C1AC73238D61F35A]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.solr.cloud.TestPullReplica.waitForNumDocsInAllReplicas(TestPullReplica.java:542) at org.apache.solr.cloud.TestPullReplica.waitForNumDocsInAllReplicas(TestPullReplica.java:533) at org.apache.solr.cloud.TestPullReplica.doTestNoLeader(TestPullReplica.java:403) at org.apache.solr.cloud.TestPullReplica.testKillLeader(TestPullReplica.java:309) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-12-ea+12) - Build # 3062 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/3062/
Java: 64bit/jdk-12-ea+12 -XX:+UseCompressedOops -XX:+UseSerialGC
29 tests failed.
FAILED:
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica
Error Message:
Expected new active leader null Live Nodes: [127.0.0.1:33289_solr,
127.0.0.1:33989_solr, 127.0.0.1:37143_solr] Last available state:
DocCollection(raceDeleteReplica_true//collections/raceDeleteReplica_true/state.json/11)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{"shard1":{
"range":"8000-7fff", "state":"active", "replicas":{
"core_node3":{ "core":"raceDeleteReplica_true_shard1_replica_n1",
"base_url":"http://127.0.0.1:41595/solr;,
"node_name":"127.0.0.1:41595_solr", "state":"down",
"type":"NRT", "leader":"true"}, "core_node6":{
"core":"raceDeleteReplica_true_shard1_replica_n5",
"base_url":"http://127.0.0.1:41595/solr;,
"node_name":"127.0.0.1:41595_solr", "state":"down",
"type":"NRT"}, "core_node4":{
"core":"raceDeleteReplica_true_shard1_replica_n2",
"base_url":"http://127.0.0.1:37143/solr;,
"node_name":"127.0.0.1:37143_solr", "state":"down",
"type":"NRT", "router":{"name":"compositeId"}, "maxShardsPerNode":"1",
"autoAddReplicas":"false", "nrtReplicas":"2", "tlogReplicas":"0"}
Stack Trace:
java.lang.AssertionError: Expected new active leader
null
Live Nodes: [127.0.0.1:33289_solr, 127.0.0.1:33989_solr, 127.0.0.1:37143_solr]
Last available state:
DocCollection(raceDeleteReplica_true//collections/raceDeleteReplica_true/state.json/11)={
"pullReplicas":"0",
"replicationFactor":"2",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
"core_node3":{
"core":"raceDeleteReplica_true_shard1_replica_n1",
"base_url":"http://127.0.0.1:41595/solr;,
"node_name":"127.0.0.1:41595_solr",
"state":"down",
"type":"NRT",
"leader":"true"},
"core_node6":{
"core":"raceDeleteReplica_true_shard1_replica_n5",
"base_url":"http://127.0.0.1:41595/solr;,
"node_name":"127.0.0.1:41595_solr",
"state":"down",
"type":"NRT"},
"core_node4":{
"core":"raceDeleteReplica_true_shard1_replica_n2",
"base_url":"http://127.0.0.1:37143/solr;,
"node_name":"127.0.0.1:37143_solr",
"state":"down",
"type":"NRT",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"2",
"tlogReplicas":"0"}
at
__randomizedtesting.SeedInfo.seed([443B8A0B90A80FBC:2E2DEBDBF85A4576]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:280)
at
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:334)
at
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:229)
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:1742)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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
[jira] [Commented] (SOLR-12976) Unify RedactionUtils and metrics hiddenSysProps settings
[
https://issues.apache.org/jira/browse/SOLR-12976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681486#comment-16681486
]
Jan Høydahl commented on SOLR-12976:
One use case could be multi tenancy. So you have a clients that get, say, only
read access to collection "foo", while another client gets r/w access to
collection "bar". Yet another client will have admin access. This is enforced
by the auth framework. So in this case it is important to make sure that the
"foo" client only can query this one collection and not see any system-level
secrets on any of the API endpoints.
Also, you don't want secrets to leak out to the monitoring tool you are using,
since it is not given that everyone with access to monitoring DB are also
super-users.
Now, I guess that the Admin UI will be pretty crippled already if you only have
read access to one collection, and no other permissions. Then the dashboard
won't even display anything meaningful and I don't think you'll get to use any
of the /admin/ handlers, so that is an easy one. But if you have an
administrator that should be allowed to create new collections or maintain a
schema via schema API, he/she should not necessarily also be allowed to see
other secrets?
> Unify RedactionUtils and metrics hiddenSysProps settings
>
>
> Key: SOLR-12976
> URL: https://issues.apache.org/jira/browse/SOLR-12976
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Jan Høydahl
>Priority: Major
>
> System properties can contain sensitive data, and they are easily available
> from the Admin UI (/admin/info/system) and also from the Metrics API
> (/admin/metrics).
> By default the {{/admin/info/system}} redacts any sys prop with a key
> containing *password*. This can be configured with sysprop
> {{-Dsolr.redaction.system.pattern=}}
> The metrics API by default hides these sysprops from the API output:
> {code:java}
> "javax.net.ssl.keyStorePassword",
> "javax.net.ssl.trustStorePassword",
> "basicauth",
> "zkDigestPassword",
> "zkDigestReadonlyPassword"
> {code}
> You can redefine these by adding a section to {{solr.xml}}:
> ([https://lucene.apache.org/solr/guide/7_5/metrics-reporting.html#the-metrics-hiddensysprops-element])
> {code:xml}
>
>
>foo
>bar
>baz
>
> {code}
> h2. Unifying the two
> It is not very user firiendly to have two different systems for redacting
> system properties and two sets of defaults. This goals of this issue are
> * Keep only one set of defaults
> * Both metrics and system info handler will use the same source
> * It should be possible to change and persist the list without a full
> cluster restart, preferably though some API
> Note that the {{solr.redaction.system.pattern}} property is not documented in
> the ref guide, so this Jira should also fix documentation!
--
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-12947) SolrJ Helper for JSON Request API
[
https://issues.apache.org/jira/browse/SOLR-12947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681485#comment-16681485
]
Jason Gerlowski commented on SOLR-12947:
bq. The standard name is TestJsonQueryRequest, this name
JsonQueryRequestUnitTest is quite uncommon
Yep, true enough, but I did have reasons for the name. I chose that name with
some of the recent test-improvement JIRAs in mind.
In SOLR-12939 there's been recent movement towards aligning on a test-naming
standardization. By my reading of the comments there {{TestFoo}} is the
majority in our codebase, but {{FooTest}} is more standard across Java projects
as a whole and seemed to be the winner in the discussion so far. So I went
with {{FooTest}}.
In SOLR-12921 Mark/David/Erick discussed separating unit and integration tests
either by name or package. To make their job in that JIRA the littlest bit
easier I included "Unit" and "Integration" in my test names. Even if nothing
ever happens with SOLR-12921 though, JsonQueryRequest still has two test
classes (one unit, the other integration). The class names need to be
different, so if you don't like having "Unit"/"Integration" in the names, is
there another disambiguating word you'd prefer?
Despite those reasons, I'm not strongly attached to the choice in any way. If
you care about it, I'm happy to rename.
bq. use computeIfAbsent()
Cool, hadn't seen this much before. Will do.
> SolrJ Helper for JSON Request API
> -
>
> Key: SOLR-12947
> URL: https://issues.apache.org/jira/browse/SOLR-12947
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java, SolrJ
>Affects Versions: 7.5
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-12947.patch, SOLR-12947.patch, SOLR-12947.patch
>
>
> The JSON request API is becoming increasingly popular for sending querying or
> accessing the JSON faceting functionality. The query DSL is simple and easy
> to understand, but crafting requests programmatically is tough in SolrJ.
> Currently, SolrJ users must hardcode in the JSON body they want their request
> to convey. Nothing helps them build the JSON request they're going for,
> making use of these APIs manual and painful.
> We should see what we can do to alleviate this. I'd like to tackle this work
> in two pieces. This (the first piece) would introduces classes that make it
> easier to craft non-faceting requests that use the JSON Request API.
> Improving JSON Faceting support is a bit more involved (it likely requires
> improvements to the Response as well as the Request objects), so I'll aim to
> tackle that in a separate JIRA to keep things moving.
--
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-repro - Build # 1906 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/1906/ [...truncated 33 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/1018/consoleText [repro] Revision: 761965224b64aec5e437432c1cdb0267aa4df99d [repro] Repro line: ant test -Dtestcase=IndexSizeTriggerTest -Dtests.method=testSplitIntegration -Dtests.seed=F1F40A3DB60C1FE -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=es-MX -Dtests.timezone=America/Santa_Isabel -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 74e3ff509e85982a5529ca99c8e3e9ec2f96770a [repro] git fetch [repro] git checkout 761965224b64aec5e437432c1cdb0267aa4df99d [...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] IndexSizeTriggerTest [repro] ant compile-test [...truncated 3580 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.IndexSizeTriggerTest" -Dtests.showOutput=onerror -Dtests.seed=F1F40A3DB60C1FE -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=es-MX -Dtests.timezone=America/Santa_Isabel -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 30626 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 2/5 failed: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest [repro] git checkout 74e3ff509e85982a5529ca99c8e3e9ec2f96770a [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 6 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12976) Unify RedactionUtils and metrics hiddenSysProps settings
[
https://issues.apache.org/jira/browse/SOLR-12976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681411#comment-16681411
]
Gus Heck commented on SOLR-12976:
-
{quote}document that you no longer can use property substitution for secrets
{quote}
That's an enormous break with back compatibility. I rather suspect one of the
main reasons people pass in secretive things as system props is to substitute
them in config. As I implied on the user list, I think it's pretty questionable
to give someone access to admin interface and admin api's (and therefore all
your data) and then try to hide stuff from them. What's the use case driving
this?
> Unify RedactionUtils and metrics hiddenSysProps settings
>
>
> Key: SOLR-12976
> URL: https://issues.apache.org/jira/browse/SOLR-12976
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Jan Høydahl
>Priority: Major
>
> System properties can contain sensitive data, and they are easily available
> from the Admin UI (/admin/info/system) and also from the Metrics API
> (/admin/metrics).
> By default the {{/admin/info/system}} redacts any sys prop with a key
> containing *password*. This can be configured with sysprop
> {{-Dsolr.redaction.system.pattern=}}
> The metrics API by default hides these sysprops from the API output:
> {code:java}
> "javax.net.ssl.keyStorePassword",
> "javax.net.ssl.trustStorePassword",
> "basicauth",
> "zkDigestPassword",
> "zkDigestReadonlyPassword"
> {code}
> You can redefine these by adding a section to {{solr.xml}}:
> ([https://lucene.apache.org/solr/guide/7_5/metrics-reporting.html#the-metrics-hiddensysprops-element])
> {code:xml}
>
>
>foo
>bar
>baz
>
> {code}
> h2. Unifying the two
> It is not very user firiendly to have two different systems for redacting
> system properties and two sets of defaults. This goals of this issue are
> * Keep only one set of defaults
> * Both metrics and system info handler will use the same source
> * It should be possible to change and persist the list without a full
> cluster restart, preferably though some API
> Note that the {{solr.redaction.system.pattern}} property is not documented in
> the ref guide, so this Jira should also fix documentation!
--
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-Linux (64bit/jdk-11) - Build # 23179 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23179/ Java: 64bit/jdk-11 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 35 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest Error Message: Could not find collection : AutoscalingHistoryHandlerTest_collection Stack Trace: org.apache.solr.common.SolrException: Could not find collection : AutoscalingHistoryHandlerTest_collection at __randomizedtesting.SeedInfo.seed([F0154F4E444591FE]:0) at org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:118) at org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:258) at org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.waitForRecovery(AutoscalingHistoryHandlerTest.java:403) at org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.setupCluster(AutoscalingHistoryHandlerTest.java:97) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:834) FAILED: junit.framework.TestSuite.org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest Error Message: Could not find collection : AutoscalingHistoryHandlerTest_collection Stack Trace: org.apache.solr.common.SolrException: Could not find collection : AutoscalingHistoryHandlerTest_collection at __randomizedtesting.SeedInfo.seed([F0154F4E444591FE]:0) at org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:118) at org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:258) at org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.waitForRecovery(AutoscalingHistoryHandlerTest.java:403) at org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.setupCluster(AutoscalingHistoryHandlerTest.java:97) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at
[GitHub] lucene-solr issue #495: LUCENE-8464: Implement ConstantScoreScorer#setMinCom...
Github user cbismuth commented on the issue: https://github.com/apache/lucene-solr/pull/495 Please ignore my previous comment as some tests are broken when the scorer has an approximation (see [here](https://github.com/apache/lucene-solr/blob/1acfca5ebcc4eb8600fe0fc0def160f610866f72/lucene/core/src/java/org/apache/lucene/search/Weight.java#L267-L273) and [here](https://github.com/apache/lucene-solr/blob/910a0231f6fc668426056e31d43e293248ff5ce1/lucene/test-framework/src/java/org/apache/lucene/search/AssertingLeafCollector.java#L48)). I'm working on fixing them. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 2151 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/2151/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 6 tests failed. FAILED: org.apache.solr.cloud.RecoveryAfterSoftCommitTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:65020/collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:65020/collection1 at __randomizedtesting.SeedInfo.seed([272A623DA88C8B23:AF7E5DE70670E6DB]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1107) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1260) at org.apache.solr.cloud.RecoveryAfterSoftCommitTest.test(RecoveryAfterSoftCommitTest.java:87) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1010) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:985) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) 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
