[jira] [Commented] (SOLR-10428) CloudSolrClient: Qerying multiple collection aliases leads to SolrException: Collection not found

[Philip Pock (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513381#comment-16513381
 ] 

Philip Pock commented on SOLR-10428:


Works as expected with version 7.2.0 and 7.3.1

> CloudSolrClient: Qerying multiple collection aliases leads to SolrException: 
> Collection not found
> -
>
> Key: SOLR-10428
> URL: https://issues.apache.org/jira/browse/SOLR-10428
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.4, 6.4.1, 6.4.2, 6.5, 7.0
>Reporter: Philip Pock
>Priority: Minor
>
> We have multiple collections and an alias is created for each of them. e.g.:
> alias-a -> collection-a, alias-b -> collection-b
> We search in multiple collections by passing the aliases of the collections 
> in the collections parameter.
> {code}solrClient.query("alias-a,alias-b", params, 
> SolrRequest.METHOD.POST){code}
> The client can't find the collection and throws an Exception. Relevant parts 
> of the stacktrace using v6.5.0:
> {noformat}
> org.apache.solr.common.SolrException: Collection not found: collection-a
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1394)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1087)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1057)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
>   at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:974)
> {noformat}
> Everything works fine with a single alias.
> I think this issue was introduced with SOLR-9784. Please see my comment below.
> {code:title=org.apache.solr.client.solrj.impl.CloudSolrClient }
> Set getCollectionNames(String collection) {
> List rawCollectionsList = StrUtils.splitSmart(collection, ",", 
> true);
> Set collectionNames = new HashSet<>();
> for (String collectionName : rawCollectionsList) {
>   if (stateProvider.getState(collectionName) == null) {
> // I assume that collectionName should be passed to getAlias here
> String alias = stateProvider.getAlias(collection);
> if (alias != null) {
>   List aliasList = StrUtils.splitSmart(alias, ",", true);
>   collectionNames.addAll(aliasList);
>   continue;
> }
>   throw new SolrException(ErrorCode.BAD_REQUEST, "Collection not 
> found: " + collectionName);
> }
>   collectionNames.add(collectionName);
> }
> return collectionNames;
>   }
> {code}
> The suggested change is similar to the previous revision: 
> https://github.com/apache/lucene-solr/commit/5650939a8d41b7bad584947a2c9dcedf3774b8de#diff-c8d54eacd46180b332c86c7ae448abaeL1301



--
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-Linux (64bit/jdk-11-ea+14) - Build # 2130 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2130/
Java: 64bit/jdk-11-ea+14 -XX:-UseCompressedOops -XX:+UseG1GC

3 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:
last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/67)={   
"replicationFactor":"2",   "pullReplicas":"0",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"2",   
"autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0",   
"autoCreated":"true",   "shards":{ "shard2":{   "replicas":{ 
"core_node3":{   
"core":"testSplitIntegration_collection_shard2_replica_n3",   
"leader":"true",   "SEARCHER.searcher.maxDoc":11,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":15740, 
  "node_name":"127.0.0.1:10001_solr",   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":1.4659017324447632E-5,   
"SEARCHER.searcher.numDocs":11}, "core_node4":{   
"core":"testSplitIntegration_collection_shard2_replica_n4",   
"SEARCHER.searcher.maxDoc":11,   "SEARCHER.searcher.deletedDocs":0, 
  "INDEX.sizeInBytes":15740,   "node_name":"127.0.0.1:1_solr",  
 "state":"active",   "type":"NRT",   
"INDEX.sizeInGB":1.4659017324447632E-5,   
"SEARCHER.searcher.numDocs":11}},   "range":"0-7fff",   
"state":"active"}, "shard1":{   "stateTimestamp":"1529039220117036750", 
  "replicas":{ "core_node1":{   
"core":"testSplitIntegration_collection_shard1_replica_n1",   
"leader":"true",   "SEARCHER.searcher.maxDoc":14,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":17240, 
  "node_name":"127.0.0.1:10001_solr",   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":1.605600118637085E-5,   
"SEARCHER.searcher.numDocs":14}, "core_node2":{   
"core":"testSplitIntegration_collection_shard1_replica_n2",   
"SEARCHER.searcher.maxDoc":14,   "SEARCHER.searcher.deletedDocs":0, 
  "INDEX.sizeInBytes":17240,   "node_name":"127.0.0.1:1_solr",  
 "state":"active",   "type":"NRT",   
"INDEX.sizeInGB":1.605600118637085E-5,   
"SEARCHER.searcher.numDocs":14}},   "range":"8000-",   
"state":"inactive"}, "shard1_1":{   "parent":"shard1",   
"stateTimestamp":"1529039220133137600",   "range":"c000-",  
 "state":"active",   "replicas":{ "core_node10":{   
"leader":"true",   
"core":"testSplitIntegration_collection_shard1_1_replica1",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":13740,   "node_name":"127.0.0.1:1_solr",   
"base_url":"http://127.0.0.1:1/solr;,   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":1.2796372175216675E-5, 
  "SEARCHER.searcher.numDocs":7}, "core_node9":{   
"core":"testSplitIntegration_collection_shard1_1_replica0",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":13740,   "node_name":"127.0.0.1:10001_solr",   
"base_url":"http://127.0.0.1:10001/solr;,   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":1.2796372175216675E-5, 
  "SEARCHER.searcher.numDocs":7}}}, "shard1_0":{   "parent":"shard1",   
"stateTimestamp":"1529039220132931500",   "range":"8000-bfff",  
 "state":"active",   "replicas":{ "core_node7":{   
"leader":"true",   
"core":"testSplitIntegration_collection_shard1_0_replica0",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":23980,   "node_name":"127.0.0.1:10001_solr",   
"base_url":"http://127.0.0.1:10001/solr;,   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":2.2333115339279175E-5, 
  "SEARCHER.searcher.numDocs":7}, "core_node8":{   
"core":"testSplitIntegration_collection_shard1_0_replica1",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":23980,   "node_name":"127.0.0.1:1_solr",   
"base_url":"http://127.0.0.1:1/solr;,   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":2.2333115339279175E-5, 
  "SEARCHER.searcher.numDocs":7}

Stack Trace:
java.util.concurrent.TimeoutException: last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/67)={
  "replicationFactor":"2",
  "pullReplicas":"0",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"2",
  

[JENKINS] Lucene-Solr-repro - Build # 820 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/820/

[...truncated 63 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-Tests-7.x/641/consoleText

[repro] Revision: b1213a318433f73a8a6ab24545a58eea835a5e1e

[repro] Repro line:  ant test  -Dtestcase=SearchRateTriggerTest 
-Dtests.method=testTrigger -Dtests.seed=D3437D4D01F1D854 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=ar-MA -Dtests.timezone=Indian/Chagos 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestTriggerIntegration 
-Dtests.method=testTriggerThrottling -Dtests.seed=D3437D4D01F1D854 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ga-IE 
-Dtests.timezone=Africa/Timbuktu -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=CdcrBidirectionalTest 
-Dtests.method=testBiDir -Dtests.seed=D3437D4D01F1D854 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=ar-KW 
-Dtests.timezone=America/Indiana/Petersburg -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestSkipOverseerOperations 
-Dtests.method=testSkipDownOperations -Dtests.seed=D3437D4D01F1D854 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=sr 
-Dtests.timezone=SystemV/AST4 -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=StreamDecoratorTest 
-Dtests.method=testParallelExecutorStream -Dtests.seed=72F6966F40C50918 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=sr-CS 
-Dtests.timezone=Asia/Singapore -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: 
228a84fd6db3ef5fc1624d69e1c82a1f02c51352
[repro] git fetch
[repro] git checkout b1213a318433f73a8a6ab24545a58eea835a5e1e

[...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]   StreamDecoratorTest
[repro]solr/core
[repro]   CdcrBidirectionalTest
[repro]   TestSkipOverseerOperations
[repro]   TestTriggerIntegration
[repro]   SearchRateTriggerTest
[repro] ant compile-test

[...truncated 2468 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.StreamDecoratorTest" -Dtests.showOutput=onerror  
-Dtests.seed=72F6966F40C50918 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=sr-CS -Dtests.timezone=Asia/Singapore -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[...truncated 296 lines...]
[repro] ant compile-test

[...truncated 1331 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=20 
-Dtests.class="*.CdcrBidirectionalTest|*.TestSkipOverseerOperations|*.TestTriggerIntegration|*.SearchRateTriggerTest"
 -Dtests.showOutput=onerror  -Dtests.seed=D3437D4D01F1D854 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=ar-KW 
-Dtests.timezone=America/Indiana/Petersburg -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[...truncated 10092 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.client.solrj.io.stream.StreamDecoratorTest
[repro]   0/5 failed: org.apache.solr.cloud.TestSkipOverseerOperations
[repro]   0/5 failed: org.apache.solr.cloud.autoscaling.SearchRateTriggerTest
[repro]   1/5 failed: org.apache.solr.cloud.cdcr.CdcrBidirectionalTest
[repro]   4/5 failed: 
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration
[repro] git checkout 228a84fd6db3ef5fc1624d69e1c82a1f02c51352

[...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

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1911 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1911/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

9 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:
events: [CapturedEvent{timestamp=4306415278834536, stage=STARTED, 
actionName='null', event={   "id":"f4ca802ecb4b8T781v7kopzylbwzdafejroe4xz",   
"source":"index_size_trigger2",   "eventTime":4306409137943736,   
"eventType":"INDEXSIZE",   "properties":{ "__start__":1, 
"aboveSize":{"testSplitIntegration_collection":["{\"core_node1\":{\n
\"leader\":\"true\",\n\"SEARCHER.searcher.maxDoc\":25,\n
\"SEARCHER.searcher.deletedDocs\":0,\n\"INDEX.sizeInBytes\":22740,\n
\"node_name\":\"127.0.0.1:10003_solr\",\n\"type\":\"NRT\",\n
\"SEARCHER.searcher.numDocs\":25,\n\"__bytes__\":22740,\n
\"core\":\"testSplitIntegration_collection_shard1_replica_n1\",\n
\"__docs__\":25,\n\"violationType\":\"aboveDocs\",\n
\"state\":\"active\",\n\"INDEX.sizeInGB\":2.117827534675598E-5,\n
\"shard\":\"shard1\",\n
\"collection\":\"testSplitIntegration_collection\"}}"]}, "belowSize":{},
 "_enqueue_time_":4306415263348336, "requestedOps":["Op{action=SPLITSHARD, 
hints={COLL_SHARD=[{\n  \"first\":\"testSplitIntegration_collection\",\n  
\"second\":\"shard1\"}]}}"]}}, context={}, config={   
"trigger":"index_size_trigger2",   "stage":[ "STARTED", "ABORTED", 
"SUCCEEDED", "FAILED"],   "afterAction":[ "compute_plan", 
"execute_plan"],   
"class":"org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest$CapturingTriggerListener",
   "beforeAction":[ "compute_plan", "execute_plan"]}, message='null'}, 
CapturedEvent{timestamp=4306416492690086, stage=BEFORE_ACTION, 
actionName='compute_plan', event={   
"id":"f4ca802ecb4b8T781v7kopzylbwzdafejroe4xz",   
"source":"index_size_trigger2",   "eventTime":4306409137943736,   
"eventType":"INDEXSIZE",   "properties":{ "__start__":1, 
"aboveSize":{"testSplitIntegration_collection":["{\"core_node1\":{\n
\"leader\":\"true\",\n\"SEARCHER.searcher.maxDoc\":25,\n
\"SEARCHER.searcher.deletedDocs\":0,\n\"INDEX.sizeInBytes\":22740,\n
\"node_name\":\"127.0.0.1:10003_solr\",\n\"type\":\"NRT\",\n
\"SEARCHER.searcher.numDocs\":25,\n\"__bytes__\":22740,\n
\"core\":\"testSplitIntegration_collection_shard1_replica_n1\",\n
\"__docs__\":25,\n\"violationType\":\"aboveDocs\",\n
\"state\":\"active\",\n\"INDEX.sizeInGB\":2.117827534675598E-5,\n
\"shard\":\"shard1\",\n
\"collection\":\"testSplitIntegration_collection\"}}"]}, "belowSize":{},
 "_enqueue_time_":4306415263348336, "requestedOps":["Op{action=SPLITSHARD, 
hints={COLL_SHARD=[{\n  \"first\":\"testSplitIntegration_collection\",\n  
\"second\":\"shard1\"}]}}"]}}, 
context={properties.BEFORE_ACTION=[compute_plan], source=index_size_trigger2}, 
config={   "trigger":"index_size_trigger2",   "stage":[ "STARTED", 
"ABORTED", "SUCCEEDED", "FAILED"],   "afterAction":[ 
"compute_plan", "execute_plan"],   
"class":"org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest$CapturingTriggerListener",
   "beforeAction":[ "compute_plan", "execute_plan"]}, message='null'}, 
CapturedEvent{timestamp=4306416543074936, stage=AFTER_ACTION, 
actionName='compute_plan', event={   
"id":"f4ca802ecb4b8T781v7kopzylbwzdafejroe4xz",   
"source":"index_size_trigger2",   "eventTime":4306409137943736,   
"eventType":"INDEXSIZE",   "properties":{ "__start__":1, 
"aboveSize":{"testSplitIntegration_collection":["{\"core_node1\":{\n
\"leader\":\"true\",\n\"SEARCHER.searcher.maxDoc\":25,\n
\"SEARCHER.searcher.deletedDocs\":0,\n\"INDEX.sizeInBytes\":22740,\n
\"node_name\":\"127.0.0.1:10003_solr\",\n\"type\":\"NRT\",\n
\"SEARCHER.searcher.numDocs\":25,\n\"__bytes__\":22740,\n
\"core\":\"testSplitIntegration_collection_shard1_replica_n1\",\n
\"__docs__\":25,\n\"violationType\":\"aboveDocs\",\n
\"state\":\"active\",\n\"INDEX.sizeInGB\":2.117827534675598E-5,\n
\"shard\":\"shard1\",\n
\"collection\":\"testSplitIntegration_collection\"}}"]}, "belowSize":{},
 "_enqueue_time_":4306415263348336, "requestedOps":["Op{action=SPLITSHARD, 
hints={COLL_SHARD=[{\n  \"first\":\"testSplitIntegration_collection\",\n  
\"second\":\"shard1\"}]}}"]}}, 
context={properties.operations=[{class=org.apache.solr.client.solrj.request.CollectionAdminRequest$SplitShard,
 method=GET, params.action=SPLITSHARD, 
params.collection=testSplitIntegration_collection, params.shard=shard1}], 
properties.BEFORE_ACTION=[compute_plan], source=index_size_trigger2, 
properties.AFTER_ACTION=[compute_plan]}, config={   
"trigger":"index_size_trigger2",   "stage":[ "STARTED", "ABORTED", 
"SUCCEEDED", "FAILED"],   "afterAction":[ "compute_plan", 
"execute_plan"],   

[JENKINS] Lucene-Solr-NightlyTests-7.4 - Build # 5 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.4/5/

3 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([712BB0A4B11EF4A:54ABF9BAA9007AB0]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:406)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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.metrics.rrd.SolrRrdBackendFactoryTest.testBasic

Error Message:
{} expected:<1> but was:<0>

Stack Trace:
java.lang.AssertionError: {} expected:<1> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([712BB0A4B11EF4A:ACE8A61F94CD6964]:0)
at org.junit.Assert.fail(Assert.java:93)
 

[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk-9) - Build # 687 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/687/
Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseG1GC

7 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:
last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/68)={   
"replicationFactor":"2",   "pullReplicas":"0",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"2",   
"autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0",   
"autoCreated":"true",   "shards":{ "shard2":{   "replicas":{ 
"core_node3":{   
"core":"testSplitIntegration_collection_shard2_replica_n3",   
"leader":"true",   "SEARCHER.searcher.maxDoc":11,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":15740, 
  "node_name":"127.0.0.1:1_solr",   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":1.4659017324447632E-5,   
"SEARCHER.searcher.numDocs":11}, "core_node4":{   
"core":"testSplitIntegration_collection_shard2_replica_n4",   
"SEARCHER.searcher.maxDoc":11,   "SEARCHER.searcher.deletedDocs":0, 
  "INDEX.sizeInBytes":15740,   "node_name":"127.0.0.1:10001_solr",  
 "state":"active",   "type":"NRT",   
"INDEX.sizeInGB":1.4659017324447632E-5,   
"SEARCHER.searcher.numDocs":11}},   "range":"0-7fff",   
"state":"active"}, "shard1":{   "stateTimestamp":"1529031484743218450", 
  "replicas":{ "core_node1":{   
"core":"testSplitIntegration_collection_shard1_replica_n1",   
"leader":"true",   "SEARCHER.searcher.maxDoc":14,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":17240, 
  "node_name":"127.0.0.1:1_solr",   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":1.605600118637085E-5,   
"SEARCHER.searcher.numDocs":14}, "core_node2":{   
"core":"testSplitIntegration_collection_shard1_replica_n2",   
"SEARCHER.searcher.maxDoc":14,   "SEARCHER.searcher.deletedDocs":0, 
  "INDEX.sizeInBytes":17240,   "node_name":"127.0.0.1:10001_solr",  
 "state":"active",   "type":"NRT",   
"INDEX.sizeInGB":1.605600118637085E-5,   
"SEARCHER.searcher.numDocs":14}},   "range":"8000-",   
"state":"inactive"}, "shard1_1":{   "parent":"shard1",   
"stateTimestamp":"1529031484773471600",   "range":"c000-",  
 "state":"active",   "replicas":{ "core_node10":{   
"leader":"true",   
"core":"testSplitIntegration_collection_shard1_1_replica1",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":13740,   "node_name":"127.0.0.1:1_solr",   
"base_url":"http://127.0.0.1:1/solr;,   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":1.2796372175216675E-5, 
  "SEARCHER.searcher.numDocs":7}, "core_node9":{   
"core":"testSplitIntegration_collection_shard1_1_replica0",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":13740,   "node_name":"127.0.0.1:10001_solr",   
"base_url":"http://127.0.0.1:10001/solr;,   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":1.2796372175216675E-5, 
  "SEARCHER.searcher.numDocs":7}}}, "shard1_0":{   "parent":"shard1",   
"stateTimestamp":"1529031484773066600",   "range":"8000-bfff",  
 "state":"active",   "replicas":{ "core_node7":{   
"leader":"true",   
"core":"testSplitIntegration_collection_shard1_0_replica0",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":23980,   "node_name":"127.0.0.1:10001_solr",   
"base_url":"http://127.0.0.1:10001/solr;,   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":2.2333115339279175E-5, 
  "SEARCHER.searcher.numDocs":7}, "core_node8":{   
"core":"testSplitIntegration_collection_shard1_0_replica1",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":23980,   "node_name":"127.0.0.1:1_solr",   
"base_url":"http://127.0.0.1:1/solr;,   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":2.2333115339279175E-5, 
  "SEARCHER.searcher.numDocs":7}

Stack Trace:
java.util.concurrent.TimeoutException: last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/68)={
  "replicationFactor":"2",
  "pullReplicas":"0",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"2",
  

[jira] [Commented] (LUCENE-7976) Make TieredMergePolicy respect maxSegmentSizeMB and allow singleton merges of very large segments

[Lucene/Solr QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513252#comment-16513252
 ] 

Lucene/Solr QA commented on LUCENE-7976:


| (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 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  7m 
27s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  6m 
58s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red}  1m 49s{color} 
| {color:red} lucene_core generated 3 new + 1 unchanged - 0 fixed = 4 total 
(was 1) {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  2m 27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m 49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m 49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate ref guide {color} | 
{color:green}  1m 49s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 43m 
49s{color} | {color:green} core in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 65m 50s{color} 
| {color:red} core in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 13m 31s{color} 
| {color:red} solrj in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}148m 29s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.rest.TestManagedResourceStorage |
|   | solr.cloud.autoscaling.SearchRateTriggerIntegrationTest |
|   | solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest |
|   | solr.client.solrj.impl.CloudSolrClientTest |
|   | solr.common.util.TestJsonRecordReader |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-7976 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12927680/LUCENE-7976.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  validaterefguide  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 2db2fb3 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 8 2015 |
| Default Java | 1.8.0_172 |
| javac | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/33/artifact/out/diff-compile-javac-lucene_core.txt
 |
| unit | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/33/artifact/out/patch-unit-solr_core.txt
 |
| unit | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/33/artifact/out/patch-unit-solr_solrj.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/33/testReport/ |
| modules | C: lucene/core solr/core solr/solrj solr/solr-ref-guide solr/webapp 
U: . |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/33/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Make TieredMergePolicy respect maxSegmentSizeMB and allow singleton merges of 
> very large segments
> -
>
> Key: LUCENE-7976
> URL: https://issues.apache.org/jira/browse/LUCENE-7976
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, 
> LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, 
> LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, 
> LUCENE-7976.patch, SOLR-7976.patch
>
>
> We're seeing situations "in the wild" where there are very large indexes (on 
> disk) handled quite easily in a single Lucene index. This is particularly 
> true as features like docValues move data into MMapDirectory space. The 
> 

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-9) - Build # 4677 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4677/
Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseParallelGC

7 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([885417A2DD5136CE:B1DAAEE2F2AEFF30]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration(IndexSizeTriggerTest.java:309)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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.IndexSizeTriggerTest.testMixedBounds

Error Message:
failed to create testMixedBounds_collection Live Nodes: [127.0.0.1:10003_solr, 
127.0.0.1:10002_solr] Last available state: 

[jira] [Resolved] (SOLR-12435) Fix bin/solr help and ref guide text to describe ZK_HOST in solr.in.sh/solr.in.cmd as an alternative to -z cmdline param

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe resolved SOLR-12435.
---
   Resolution: Fixed
 Assignee: Steve Rowe
Fix Version/s: master (8.0)
   7.4

> Fix bin/solr help and ref guide text to describe ZK_HOST in 
> solr.in.sh/solr.in.cmd as an alternative to -z cmdline param
> 
>
> Key: SOLR-12435
> URL: https://issues.apache.org/jira/browse/SOLR-12435
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-12435.patch
>
>
> E.g. {{bin/solr start}}'s help text says about the {{-z}} param:
> bq. To launch an embedded Zookeeper instance, don't pass this parameter.
> which is wrong if {{ZK_HOST}} is specified in {{solr.in.sh}}/{{solr.in.cmd}}.



--
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-12435) Fix bin/solr help and ref guide text to describe ZK_HOST in solr.in.sh/solr.in.cmd as an alternative to -z cmdline param

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513195#comment-16513195
 ] 

Steve Rowe commented on SOLR-12435:
---

Patch attached.  Committing shortly.

> Fix bin/solr help and ref guide text to describe ZK_HOST in 
> solr.in.sh/solr.in.cmd as an alternative to -z cmdline param
> 
>
> Key: SOLR-12435
> URL: https://issues.apache.org/jira/browse/SOLR-12435
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Priority: Major
> Attachments: SOLR-12435.patch
>
>
> E.g. {{bin/solr start}}'s help text says about the {{-z}} param:
> bq. To launch an embedded Zookeeper instance, don't pass this parameter.
> which is wrong if {{ZK_HOST}} is specified in {{solr.in.sh}}/{{solr.in.cmd}}.



--
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-12435) Fix bin/solr help and ref guide text to describe ZK_HOST in solr.in.sh/solr.in.cmd as an alternative to -z cmdline param

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated SOLR-12435:
--
Attachment: SOLR-12435.patch

> Fix bin/solr help and ref guide text to describe ZK_HOST in 
> solr.in.sh/solr.in.cmd as an alternative to -z cmdline param
> 
>
> Key: SOLR-12435
> URL: https://issues.apache.org/jira/browse/SOLR-12435
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Priority: Major
> Attachments: SOLR-12435.patch
>
>
> E.g. {{bin/solr start}}'s help text says about the {{-z}} param:
> bq. To launch an embedded Zookeeper instance, don't pass this parameter.
> which is wrong if {{ZK_HOST}} is specified in {{solr.in.sh}}/{{solr.in.cmd}}.



--
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-12008) Settle a location for the "correct" log4j2.xml file.

[Erick Erickson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513164#comment-16513164
 ] 

Erick Erickson commented on SOLR-12008:
---

OK, I'm going to nuke as many of these as possible, at minimum 2 of these 3

./example/resources/log4j2.xml
./server/resources/log4j2.xml
./server/scripts/cloud-scripts/log4j2.xml

I propose that we keep ./server/resources/log4j2.xml.

As for the various test ones, I'll look briefly at what they do and whether 
they seem necessary.

Speak up now about whether these have any known uses so I can be sure and test 
those usages as I may not discover them  on my own.


> Settle a location for the "correct" log4j2.xml file.
> 
>
> Key: SOLR-12008
> URL: https://issues.apache.org/jira/browse/SOLR-12008
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> As part of SOLR-11934 I started looking at log4j.properties files. Waaay back 
> in 2015, the %C in "/solr/server/resources/log4j.properties" was changed to 
> use %c, but the file in "solr/example/resources/log4j.properties" was not 
> changed. That got me to looking around and there are a bunch of 
> log4j.properties files:
> ./solr/core/src/test-files/log4j.properties
> ./solr/example/resources/log4j.properties
> ./solr/solrj/src/test-files/log4j.properties
> ./solr/server/resources/log4j.properties
> ./solr/server/scripts/cloud-scripts/log4j.properties
> ./solr/contrib/dataimporthandler/src/test-files/log4j.properties
> ./solr/contrib/clustering/src/test-files/log4j.properties
> ./solr/contrib/ltr/src/test-files/log4j.properties
> ./solr/test-framework/src/test-files/log4j.properties
> Why do we have so many? After the log4j2 ticket gets checked in (SOLR-7887) I 
> propose the logging configuration files get consolidated. The question is 
> "how far"? 
> I at least want to get rid of the one in solr/example, users should use the 
> one in server/resources. Having to maintain these two separately is asking 
> for trouble.
> [~markrmil...@gmail.com] Do you have any wisdom on the properties file in 
> server/scripts/cloud-scripts?
> Anyone else who has a clue about why the other properties files were created, 
> especially the ones in contrib?
> And what about all the ones in various test-files directories? People didn't 
> create them for no reason, and I don't want to rediscover that it's a real 
> pain to try to re-use the one in server/resources for instance.



--
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-10686) improve pattern in examples' log4j.properties

[Erick Erickson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513163#comment-16513163
 ] 

Erick Erickson commented on SOLR-10686:
---

Can we close this? The pattern in the patch is the one used in 
solr/server/resources/log4j2.xml. Over in SOLR-12008 I'm going to propose 
nuking the config files in 
./solr/example/resources/log4j2.xml
and
./solr/server/scripts/cloud-scripts/log4j2.xml

> improve pattern in examples' log4j.properties 
> --
>
> Key: SOLR-10686
> URL: https://issues.apache.org/jira/browse/SOLR-10686
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-10686.patch
>
>
> At comparison to {{server/resources/log4j.properties}} 
> {{solr/example/resources/log4j.properties}} lacks thread name and uses {{%C}} 
> which is well known performance pitfall.  



--
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-12346) Update ZooKeeper to 3.4.12.

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513162#comment-16513162
 ] 

Steve Rowe commented on SOLR-12346:
---

+1, all Solr tests pass for me.

> Update ZooKeeper to 3.4.12.
> ---
>
> Key: SOLR-12346
> URL: https://issues.apache.org/jira/browse/SOLR-12346
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Attachments: SOLR-12346.patch
>
>




--
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] [Assigned] (SOLR-10686) improve pattern in examples' log4j.properties

[Erick Erickson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson reassigned SOLR-10686:
-

Assignee: Erick Erickson

> improve pattern in examples' log4j.properties 
> --
>
> Key: SOLR-10686
> URL: https://issues.apache.org/jira/browse/SOLR-10686
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-10686.patch
>
>
> At comparison to {{server/resources/log4j.properties}} 
> {{solr/example/resources/log4j.properties}} lacks thread name and uses {{%C}} 
> which is well known performance pitfall.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-Tests-master - Build # 2563 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2563/

2 tests failed.
FAILED:  
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testOverwriteOption

Error Message:
Could not load collection from ZK: overwrite

Stack Trace:
org.apache.solr.common.SolrException: Could not load collection from ZK: 
overwrite
at 
__randomizedtesting.SeedInfo.seed([DAF8EE298DE6E14:E1946F09F68E11C2]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1316)
at 
org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:732)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:148)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:131)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:154)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testOverwriteOption(CloudSolrClientTest.java:158)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[JENKINS-EA] Lucene-Solr-7.x-Windows (64bit/jdk-11-ea+14) - Build # 633 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/633/
Java: 64bit/jdk-11-ea+14 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

21 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.handler.admin.CoreAdminCreateDiscoverTest_AD58FAE9DE8ABFDC-001\tempDir-001\testInstanceDirAsPropertyParam-XYZ:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.handler.admin.CoreAdminCreateDiscoverTest_AD58FAE9DE8ABFDC-001\tempDir-001\testInstanceDirAsPropertyParam-XYZ

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.handler.admin.CoreAdminCreateDiscoverTest_AD58FAE9DE8ABFDC-001\tempDir-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.handler.admin.CoreAdminCreateDiscoverTest_AD58FAE9DE8ABFDC-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\solr-core\test\J1\temp\solr.handler.admin.CoreAdminCreateDiscoverTest_AD58FAE9DE8ABFDC-001\tempDir-001\testInstanceDirAsPropertyParam-XYZ:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.handler.admin.CoreAdminCreateDiscoverTest_AD58FAE9DE8ABFDC-001\tempDir-001\testInstanceDirAsPropertyParam-XYZ
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.handler.admin.CoreAdminCreateDiscoverTest_AD58FAE9DE8ABFDC-001\tempDir-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.handler.admin.CoreAdminCreateDiscoverTest_AD58FAE9DE8ABFDC-001\tempDir-001

at __randomizedtesting.SeedInfo.seed([AD58FAE9DE8ABFDC]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:318)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
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:832)


FAILED:  org.apache.solr.common.util.TestTimeSource.testEpochTime

Error Message:
SimTimeSource:50.0 time diff=2688

Stack Trace:
java.lang.AssertionError: SimTimeSource:50.0 time diff=2688
at 
__randomizedtesting.SeedInfo.seed([C3D8F91FCC8CD87D:FBB48A3A585C7A3B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.common.util.TestTimeSource.doTestEpochTime(TestTimeSource.java:52)
at 
org.apache.solr.common.util.TestTimeSource.testEpochTime(TestTimeSource.java:32)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 

[jira] [Resolved] (SOLR-10430) Add ls command to ZkCLI for listing only sub-directories

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe resolved SOLR-10430.
---
   Resolution: Fixed
Fix Version/s: 6.6

> Add ls command to ZkCLI for listing only sub-directories
> 
>
> Key: SOLR-10430
> URL: https://issues.apache.org/jira/browse/SOLR-10430
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Peter Szantai-Kis
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 6.6
>
> Attachments: SOLR-10430.patch, SOLR-10430.patch, SOLR-10430.patch, 
> SOLR-10430.patch
>
>
> Current list command prints out the whole directory/file tree, which can be 
> too verbose for some situations, especially when the cluster gets bigger over 
> time. 
> Add a "ls" command that would support listing only part of the file tree 
> based on the input path given



--
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 (32bit/jdk1.8.0_172) - Build # 7358 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7358/
Java: 32bit/jdk1.8.0_172 -server -XX:+UseSerialGC

15 tests failed.
FAILED:  org.apache.solr.common.util.TestTimeSource.testEpochTime

Error Message:
SimTimeSource:50.0 time diff=3152

Stack Trace:
java.lang.AssertionError: SimTimeSource:50.0 time diff=3152
at 
__randomizedtesting.SeedInfo.seed([C27BD840B91F481:344BCEA19F4156C7]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.common.util.TestTimeSource.doTestEpochTime(TestTimeSource.java:52)
at 
org.apache.solr.common.util.TestTimeSource.testEpochTime(TestTimeSource.java:32)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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.common.util.TestTimeSource.testEpochTime

Error Message:
SimTimeSource:50.0 time diff=23705000

Stack Trace:
java.lang.AssertionError: SimTimeSource:50.0 time diff=23705000

How do we interpret replicationFactor ?

[Varun Thacker]

While working on SOLR-11676
 a few questions came
that were't obvious

Should a user be allowed to specify replicationFactor and nrtReplicas ?
Today it's possible but my answer was it shouldn't be. What do others
think?

If everyone agrees the two shouldn't be specified then there is one problem
while fixing this - SolrJ

if (nrtReplicas != null) {
  params.set( ZkStateReader.REPLICATION_FACTOR, nrtReplicas);// Keep
both for compatibility?
  params.set( ZkStateReader.NRT_REPLICAS, nrtReplicas);
}

SolrJ sets both replicationFactor and nrtReplicas with the same value.
So if we simply put a check at the server saying "don't allow both
parameters" all SolrJ calls from older clients will fail

The compromise would be the server could check if both nrtReplicas and
replicationFactor are equal then don't error out


Second question, SolrJ doesn't allow a user to specify
replicationFactor but if you're using the API directly it's allowed.

Do we plan on deprecating replicationFactor eventually in favour of
nrtReplicas ? If yes would 7.5 be a good place to start throwing a
warning ?

[jira] [Commented] (SOLR-11578) Solr 7 Admin UI (Cloud > Graph) should reflect the Replica type to give a more accurate representation of the cluster

[Erick Erickson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513017#comment-16513017
 ] 

Erick Erickson commented on SOLR-11578:
---

Patch with CHANGES.txt and Varun's suggestions.

Can't copy from tooltips though.

For some reason the Git commtis aren't coming through And yeah, I didn't squash 
merge master...:

Master: 2db2fb390926ce044c1f6af17068cf0eae51be85, 
ae82bac92827da87ffa5571b4bbb83228040be48

branch 7x: ac43af0011d34425614e0c0bdb3bee6d0183

> Solr 7 Admin UI (Cloud > Graph) should reflect the Replica type to give a 
> more accurate representation of the cluster
> -
>
> Key: SOLR-11578
> URL: https://issues.apache.org/jira/browse/SOLR-11578
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 7.0, 7.1
>Reporter: Rohit
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 7.5
>
> Attachments: NRT_Tooltip.png, OnFirefox.png, OnSafari.png, 
> SOLR-11578.patch, SOLR-11578.patch, SOLR-11578.patch, SOLR-11578.patch, 
> Screen Shot-2.png, Screenshot-1.png, TLOG_Tooltip.png, Updated Graph.png, 
> Updated Legend.png, Updated Radial Graph.png, jquery-ui.min.css, 
> jquery-ui.min.js, jquery-ui.structure.min.css, replica_info.png
>
>
> New replica types were introduced in Solr 7.
> 1. The Solr Admin UI --> Cloud --> Graph mode should be updated to reflect 
> the new replica types (NRT, TLOG, PULL)
> 2. It will give a better overview of the cluster as well as help in 
> troubleshooting and diagnosing issues.



--
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-11578) Solr 7 Admin UI (Cloud > Graph) should reflect the Replica type to give a more accurate representation of the cluster

[Erick Erickson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-11578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson resolved SOLR-11578.
---
   Resolution: Fixed
Fix Version/s: 7.5

Thanks Rohit!

> Solr 7 Admin UI (Cloud > Graph) should reflect the Replica type to give a 
> more accurate representation of the cluster
> -
>
> Key: SOLR-11578
> URL: https://issues.apache.org/jira/browse/SOLR-11578
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 7.0, 7.1
>Reporter: Rohit
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 7.5
>
> Attachments: NRT_Tooltip.png, OnFirefox.png, OnSafari.png, 
> SOLR-11578.patch, SOLR-11578.patch, SOLR-11578.patch, SOLR-11578.patch, 
> Screen Shot-2.png, Screenshot-1.png, TLOG_Tooltip.png, Updated Graph.png, 
> Updated Legend.png, Updated Radial Graph.png, jquery-ui.min.css, 
> jquery-ui.min.js, jquery-ui.structure.min.css, replica_info.png
>
>
> New replica types were introduced in Solr 7.
> 1. The Solr Admin UI --> Cloud --> Graph mode should be updated to reflect 
> the new replica types (NRT, TLOG, PULL)
> 2. It will give a better overview of the cluster as well as help in 
> troubleshooting and diagnosing issues.



--
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-11578) Solr 7 Admin UI (Cloud > Graph) should reflect the Replica type to give a more accurate representation of the cluster

[Erick Erickson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-11578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson updated SOLR-11578:
--
Attachment: SOLR-11578.patch

> Solr 7 Admin UI (Cloud > Graph) should reflect the Replica type to give a 
> more accurate representation of the cluster
> -
>
> Key: SOLR-11578
> URL: https://issues.apache.org/jira/browse/SOLR-11578
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 7.0, 7.1
>Reporter: Rohit
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: NRT_Tooltip.png, OnFirefox.png, OnSafari.png, 
> SOLR-11578.patch, SOLR-11578.patch, SOLR-11578.patch, SOLR-11578.patch, 
> Screen Shot-2.png, Screenshot-1.png, TLOG_Tooltip.png, Updated Graph.png, 
> Updated Legend.png, Updated Radial Graph.png, jquery-ui.min.css, 
> jquery-ui.min.js, jquery-ui.structure.min.css, replica_info.png
>
>
> New replica types were introduced in Solr 7.
> 1. The Solr Admin UI --> Cloud --> Graph mode should be updated to reflect 
> the new replica types (NRT, TLOG, PULL)
> 2. It will give a better overview of the cluster as well as help in 
> troubleshooting and diagnosing issues.



--
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-12437) Document bin/solr config in the ref guide

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe resolved SOLR-12437.
---
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.4

> Document bin/solr config in the ref guide
> -
>
> Key: SOLR-12437
> URL: https://issues.apache.org/jira/browse/SOLR-12437
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-12437.patch
>
>
> {{bin/solr config}} doc is missing from the ref guide



--
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 # 817 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/817/

[...truncated 69 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-Tests-master/2562/consoleText

[repro] Revision: ca35c40f1b16aa79ac5b110ca922443c1185a7eb

[repro] Repro line:  ant test  -Dtestcase=TestTriggerIntegration 
-Dtests.method=testTriggerThrottling -Dtests.seed=76285975331B56D4 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=fr-LU 
-Dtests.timezone=SystemV/CST6 -Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=IndexSizeTriggerTest 
-Dtests.method=testMergeIntegration -Dtests.seed=76285975331B56D4 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=pl-PL 
-Dtests.timezone=America/Caracas -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=CdcrBidirectionalTest 
-Dtests.method=testBiDir -Dtests.seed=76285975331B56D4 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=ar-DZ -Dtests.timezone=Etc/GMT0 
-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: 
228a84fd6db3ef5fc1624d69e1c82a1f02c51352
[repro] git fetch

[...truncated 2 lines...]
[repro] git checkout ca35c40f1b16aa79ac5b110ca922443c1185a7eb

[...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]   TestTriggerIntegration
[repro]   IndexSizeTriggerTest
[repro]   CdcrBidirectionalTest
[repro] ant compile-test

[...truncated 3300 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=15 
-Dtests.class="*.TestTriggerIntegration|*.IndexSizeTriggerTest|*.CdcrBidirectionalTest"
 -Dtests.showOutput=onerror  -Dtests.seed=76285975331B56D4 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=fr-LU -Dtests.timezone=SystemV/CST6 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

[...truncated 18726 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.cloud.cdcr.CdcrBidirectionalTest
[repro]   3/5 failed: 
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration
[repro]   4/5 failed: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest
[repro] git checkout 228a84fd6db3ef5fc1624d69e1c82a1f02c51352

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 5 lines...]

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Pushed annotation changes

[Erick Erickson]

BadApple this week.

I've pushed the changes in the e-mail I sent on Monday. NOTE:

1> I have not removed any AwaitsFix annotations where the underlying
JIRA hasn't been marked as fixed.

2> I'm a little nervous about removing all those BadApple annotations
for tests that haven't failed in the last four weeks, I may be
frantically putting them back.

Erick

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-BadApples-Tests-7.x - Build # 82 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/82/

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestSolrCloudWithHadoopAuthPlugin

Error Message:
Address already in use

Stack Trace:
java.net.BindException: Address already in use
at __randomizedtesting.SeedInfo.seed([CA9304A1DB77A685]:0)
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at 
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:252)
at 
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:49)
at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor.registerHandles(AbstractPollingIoAcceptor.java:525)
at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor.access$200(AbstractPollingIoAcceptor.java:67)
at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.run(AbstractPollingIoAcceptor.java:409)
at 
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:
last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/42)={   
"replicationFactor":"2",   "pullReplicas":"0",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"2",   
"autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0",   
"autoCreated":"true",   "shards":{ "shard2":{   "replicas":{ 
"core_node3":{   
"core":"testSplitIntegration_collection_shard2_replica_n3",   
"leader":"true",   "SEARCHER.searcher.maxDoc":11,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":15740, 
  "node_name":"127.0.0.1:10001_solr",   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":1.4659017324447632E-5,   
"SEARCHER.searcher.numDocs":11}, "core_node4":{   
"core":"testSplitIntegration_collection_shard2_replica_n4",   
"SEARCHER.searcher.maxDoc":11,   "SEARCHER.searcher.deletedDocs":0, 
  "INDEX.sizeInBytes":15740,   "node_name":"127.0.0.1:1_solr",  
 "state":"active",   "type":"NRT",   
"INDEX.sizeInGB":1.4659017324447632E-5,   
"SEARCHER.searcher.numDocs":11}},   "range":"0-7fff",   
"state":"active"}, "shard1":{   "stateTimestamp":"1529002200700671400", 
  "replicas":{ "core_node1":{   
"core":"testSplitIntegration_collection_shard1_replica_n1",   
"leader":"true",   "SEARCHER.searcher.maxDoc":14,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":17240, 
  "node_name":"127.0.0.1:10001_solr",   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":1.605600118637085E-5,   
"SEARCHER.searcher.numDocs":14}, "core_node2":{   
"core":"testSplitIntegration_collection_shard1_replica_n2",   
"SEARCHER.searcher.maxDoc":14,   "SEARCHER.searcher.deletedDocs":0, 
  "INDEX.sizeInBytes":17240,   "node_name":"127.0.0.1:1_solr",  
 "state":"active",   "type":"NRT",   
"INDEX.sizeInGB":1.605600118637085E-5,   
"SEARCHER.searcher.numDocs":14}},   "range":"8000-",   
"state":"inactive"}, "shard1_1":{   "parent":"shard1",   
"stateTimestamp":"1529002200736484250",   "range":"c000-",  
 "state":"active",   "replicas":{ "core_node10":{   
"leader":"true",   
"core":"testSplitIntegration_collection_shard1_1_replica1",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":13740,   "node_name":"127.0.0.1:1_solr",   
"base_url":"http://127.0.0.1:1/solr;,   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":1.2796372175216675E-5, 
  "SEARCHER.searcher.numDocs":7}, "core_node9":{   
"core":"testSplitIntegration_collection_shard1_1_replica0",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":13740,   "node_name":"127.0.0.1:10001_solr",   
"base_url":"http://127.0.0.1:10001/solr;,   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":1.2796372175216675E-5, 
  

[jira] [Commented] (SOLR-12362) JSON loader should save the relationship of children

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512936#comment-16512936
 ] 

David Smiley commented on SOLR-12362:
-

Eek, sorry!  I did run tests before but strangely didn't hit these errors.  
I'll look and try to get a fix in by midnight.

> JSON loader should save the relationship of children
> 
>
> Key: SOLR-12362
> URL: https://issues.apache.org/jira/browse/SOLR-12362
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.5
>
>  Time Spent: 6h
>  Remaining Estimate: 0h
>
> Once _childDocuments in SolrInputDocument is changed to a Map, JsonLoader 
> should add the child document to the map while saving its key name, to 
> maintain the child's relationship to its parent.



--
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-12362) JSON loader should save the relationship of children

[Erick Erickson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512930#comment-16512930
 ] 

Erick Erickson commented on SOLR-12362:
---

The tests Steve reported area also failing for me 4/4 times (without specifying 
any seed):
   [junit4]   - 
org.apache.solr.common.util.TestJsonRecordReader.testClearPreviousRecordFields
   [junit4]   - 
org.apache.solr.common.util.TestJsonRecordReader.testRecursiveWildcard2
   [junit4]   - org.apache.solr.common.util.TestJsonRecordReader.testNestedDocs

> JSON loader should save the relationship of children
> 
>
> Key: SOLR-12362
> URL: https://issues.apache.org/jira/browse/SOLR-12362
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.5
>
>  Time Spent: 6h
>  Remaining Estimate: 0h
>
> Once _childDocuments in SolrInputDocument is changed to a Map, JsonLoader 
> should add the child document to the map while saving its key name, to 
> maintain the child's relationship to its parent.



--
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-12490) referring/excluding clauses from JSON query DSL in JSON facets.

[Mikhail Khludnev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Khludnev updated SOLR-12490:

Summary: referring/excluding clauses from JSON query DSL in JSON facets.   
(was: referring/excluding clauses from query JSON DSL in JSON facets. )

> referring/excluding clauses from JSON query DSL in JSON facets. 
> 
>
> Key: SOLR-12490
> URL: https://issues.apache.org/jira/browse/SOLR-12490
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, faceting
>Reporter: Mikhail Khludnev
>Priority: Major
>
> It's spin off from the 
> [discussion|https://issues.apache.org/jira/browse/SOLR-9685?focusedCommentId=16508720=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16508720].
>  
> h2. Problem
> # after SOLR-9685 we can tag separate clauses in hairish queries like 
> {{parent}}, {{bool}}
> # we can {{domain.excludeTags}}
> # we are looking for child faceting with exclusions, see SOLR-9510, SOLR-8998 
>
> # but we can refer only separate params in {{domain.filter}}, it's not 
> possible to refer separate clauses
> h2. Proposal 
> # tag child clauses multiple times
> {code}
> {
> "query" : {
>   "#top":{
>   "parent": {
>   "query": "sku-title:foo",
>   "filters" : [
>   "scope:sku",
> { "#sku,color" :  "color:black" }, // multiple tags
> { "#sku,size" : "size:L" }
> ],
>   "which": "scope:product"
>}
> }
> }
> }
> {code} 
> # refer to sku clauses, either by 
> ## (1) {{domain.filter.tag}} in addition to {{param}}, or
> ## (2) {{domain.includeTags}} mimicking {{excludeTags}}  
> {code}
> "facet":{
>   "sku_colors_in_prods":{
>   "type" : "terms",
>   "field" : "color",
>"domain" : {
>   "excludeTags":["top","color"],   // we need to drop top-level 
> parent query
>   "filter":[ 
>   {"tag":"sku"}  // (1)
>],
>   "includeTags":"sku"  // (2)
>},
>   "facet":"uniqueBlock(_root_)"
>}
> }
> {code}  
> WDYT, [~osavrasov], [~ysee...@gmail.com]?



--
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-12437) Document bin/solr config in the ref guide

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated SOLR-12437:
--
Attachment: SOLR-12437.patch

> Document bin/solr config in the ref guide
> -
>
> Key: SOLR-12437
> URL: https://issues.apache.org/jira/browse/SOLR-12437
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12437.patch
>
>
> {{bin/solr config}} doc is missing from the ref guide



--
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-12437) Document bin/solr config in the ref guide

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512928#comment-16512928
 ] 

Steve Rowe commented on SOLR-12437:
---

Attached a patch.  I'll commit and backport to 7.4 once precommit passes.

> Document bin/solr config in the ref guide
> -
>
> Key: SOLR-12437
> URL: https://issues.apache.org/jira/browse/SOLR-12437
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12437.patch
>
>
> {{bin/solr config}} doc is missing from the ref guide



--
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-12362) JSON loader should save the relationship of children

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512909#comment-16512909
 ] 

Steve Rowe commented on SOLR-12362:
---

Reproducing {{TestJsonRecordReader}} failures, from Yetus on SOLR-12395 
[https://builds.apache.org/job/PreCommit-SOLR-Build/123/artifact/out/patch-unit-solr_solrj.txt],
 which {{git bisect}} blames on the {{21fe416}} master commit on this issue:

{noformat}
   [junit4] Suite: org.apache.solr.common.util.TestJsonRecordReader
   [junit4]   2> Creating dataDir: 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/solr/build/solr-solrj/test/J1/temp/solr.common.util.TestJsonRecordReader_9BC2BA48D076310E-001/init-core-data-001
   [junit4]   2> 783465 INFO  
(SUITE-TestJsonRecordReader-seed#[9BC2BA48D076310E]-worker) [] 
o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 783466 INFO  
(SUITE-TestJsonRecordReader-seed#[9BC2BA48D076310E]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 783466 INFO  
(SUITE-TestJsonRecordReader-seed#[9BC2BA48D076310E]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> 783517 INFO  
(TEST-TestJsonRecordReader.testOneLevelSplit-seed#[9BC2BA48D076310E]) [] 
o.a.s.SolrTestCaseJ4 ###Starting testOneLevelSplit
   [junit4]   2> 783555 INFO  
(TEST-TestJsonRecordReader.testOneLevelSplit-seed#[9BC2BA48D076310E]) [] 
o.a.s.SolrTestCaseJ4 ###Ending testOneLevelSplit
   [junit4]   2> 783556 INFO  
(TEST-TestJsonRecordReader.testRecursiveWildcard2-seed#[9BC2BA48D076310E]) [
] o.a.s.SolrTestCaseJ4 ###Starting testRecursiveWildcard2
   [junit4]   2> 783557 INFO  
(TEST-TestJsonRecordReader.testRecursiveWildcard2-seed#[9BC2BA48D076310E]) [
] o.a.s.SolrTestCaseJ4 ###Ending testRecursiveWildcard2
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestJsonRecordReader -Dtests.method=testRecursiveWildcard2 
-Dtests.seed=9BC2BA48D076310E -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=mt -Dtests.timezone=America/Jujuy 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.06s J1 | TestJsonRecordReader.testRecursiveWildcard2 <<<
   [junit4]> Throwable #1: java.lang.AssertionError: expected:<6> but 
was:<7>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([9BC2BA48D076310E:CA96D19E65F5AA5B]:0)
   [junit4]>at 
org.apache.solr.common.util.TestJsonRecordReader.testRecursiveWildcard2(TestJsonRecordReader.java:253)
   [junit4]>at java.lang.Thread.run(Thread.java:748)
   [junit4]   2> 783612 INFO  
(TEST-TestJsonRecordReader.testNestedJsonWithFloats-seed#[9BC2BA48D076310E]) [  
  ] o.a.s.SolrTestCaseJ4 ###Starting testNestedJsonWithFloats
   [junit4]   2> 783612 INFO  
(TEST-TestJsonRecordReader.testNestedJsonWithFloats-seed#[9BC2BA48D076310E]) [  
  ] o.a.s.SolrTestCaseJ4 ###Ending testNestedJsonWithFloats
   [junit4]   2> 783613 INFO  
(TEST-TestJsonRecordReader.testRecursiveWildCard-seed#[9BC2BA48D076310E]) [
] o.a.s.SolrTestCaseJ4 ###Starting testRecursiveWildCard
   [junit4]   2> 783614 INFO  
(TEST-TestJsonRecordReader.testRecursiveWildCard-seed#[9BC2BA48D076310E]) [
] o.a.s.SolrTestCaseJ4 ###Ending testRecursiveWildCard
   [junit4]   2> 783700 INFO  
(TEST-TestJsonRecordReader.testSrcField-seed#[9BC2BA48D076310E]) [] 
o.a.s.SolrTestCaseJ4 ###Starting testSrcField
   [junit4]   2> 783759 INFO  
(TEST-TestJsonRecordReader.testSrcField-seed#[9BC2BA48D076310E]) [] 
o.a.s.SolrTestCaseJ4 ###Ending testSrcField
   [junit4]   2> 783846 INFO  
(TEST-TestJsonRecordReader.testArrayOfRootObjects-seed#[9BC2BA48D076310E]) [
] o.a.s.SolrTestCaseJ4 ###Starting testArrayOfRootObjects
   [junit4]   2> 786590 INFO  
(TEST-TestJsonRecordReader.testArrayOfRootObjects-seed#[9BC2BA48D076310E]) [
] o.a.s.SolrTestCaseJ4 ###Ending testArrayOfRootObjects
   [junit4]   2> 786676 INFO  
(TEST-TestJsonRecordReader.testClearPreviousRecordFields-seed#[9BC2BA48D076310E])
 [] o.a.s.SolrTestCaseJ4 ###Starting testClearPreviousRecordFields
   [junit4]   2> 786677 INFO  
(TEST-TestJsonRecordReader.testClearPreviousRecordFields-seed#[9BC2BA48D076310E])
 [] o.a.s.SolrTestCaseJ4 ###Ending testClearPreviousRecordFields
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestJsonRecordReader -Dtests.method=testClearPreviousRecordFields 
-Dtests.seed=9BC2BA48D076310E -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=mt -Dtests.timezone=America/Jujuy 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.09s J1 | 
TestJsonRecordReader.testClearPreviousRecordFields <<<
   [junit4]> 

[JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 666 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/666/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

12 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([185C92493D40768D:4BE5D0F9DF51E377]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:404)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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.IndexSizeTriggerTest.testMixedBounds

Error Message:
failed to create testMixedBounds_collection Live Nodes: [127.0.0.1:10001_solr, 
127.0.0.1:1_solr] Last available state: 

[jira] [Commented] (SOLR-12395) Typo in SignificantTermsQParserPlugin.NAME

[Lucene/Solr QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512854#comment-16512854
 ] 

Lucene/Solr QA commented on SOLR-12395:
---

| (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 4 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  6m 
47s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  6m  
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  6m  
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  5m 12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  4m 58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  4m 58s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 76m 18s{color} 
| {color:red} core in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 13m 49s{color} 
| {color:red} solrj in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}109m 10s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.FullSolrCloudDistribCmdsTest |
|   | solr.cloud.BasicDistributedZkTest |
|   | solr.cloud.autoscaling.sim.TestTriggerIntegration |
|   | solr.cloud.autoscaling.sim.TestLargeCluster |
|   | solr.common.util.TestJsonRecordReader |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12395 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12927598/SOLR-12395.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 / 21fe416 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 8 2015 |
| Default Java | 1.8.0_172 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/123/artifact/out/patch-unit-solr_core.txt
 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/123/artifact/out/patch-unit-solr_solrj.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/123/testReport/ |
| modules | C: solr/core solr/solrj U: solr |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/123/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Typo in SignificantTermsQParserPlugin.NAME
> --
>
> Key: SOLR-12395
> URL: https://issues.apache.org/jira/browse/SOLR-12395
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.5, 7.3.1
>Reporter: Tobias Kässmann
>Assignee: Christine Poerschke
>Priority: Trivial
> Attachments: SOLR-12395.patch, SOLR-12395.patch, SOLR-12395.patch, 
> SOLR-12395.patch
>
>
> I think there is a small typo in the {{SignificantTermsQParserPlugin}}:
> {code:java}
> public static final String NAME = "sigificantTerms";{code}
> should be:
> {code:java}
> public static final String NAME = "significantTerms";{code}
>  See the patch attached.



--
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-12416) router.autoDeleteAge is not accepted in CREATEALIAS command

[David Smiley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated SOLR-12416:

Attachment: SOLR-12416.patch

> router.autoDeleteAge is not accepted in CREATEALIAS command
> ---
>
> Key: SOLR-12416
> URL: https://issues.apache.org/jira/browse/SOLR-12416
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.3.1
> Environment: Experimenting with a freshly downloaded Solr 7.3.1
>Reporter: Joachim Sauer
>Priority: Minor
> Attachments: SOLR-12416.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I've been experimenting with time routed aliases, specifically with the 
> autoDeleteAge feature (SOLR-11925) and notice that the router.autoDeleteAge 
> parameter was silently ignored in the CREATEALIAS command.
>  
> Using ALIASPROP to set it worked just fine.
>  
> The problem seems to be that 
> [TimeRoutedAlias.OPTIONAL_ROUTER_PARAMS|https://github.com/apache/lucene-solr/blob/bf6503ba5871228692ca79f0b2204a935538e00a/solr/core/src/java/org/apache/solr/cloud/api/collections/TimeRoutedAlias.java#L83]
>  has not been updated when the autoDeleteAge property was added.



--
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 # 22250 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22250/
Java: 32bit/jdk1.8.0_172 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.update.MaxSizeAutoCommitTest.deleteTest

Error Message:
Tlog size exceeds the max size bound. Tlog path: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.update.MaxSizeAutoCommitTest_55A691B33D8C39F0-001/init-core-data-001/tlog/tlog.005,
 tlog size: 1276

Stack Trace:
java.lang.AssertionError: Tlog size exceeds the max size bound. Tlog path: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.update.MaxSizeAutoCommitTest_55A691B33D8C39F0-001/init-core-data-001/tlog/tlog.005,
 tlog size: 1276
at 
__randomizedtesting.SeedInfo.seed([55A691B33D8C39F0:45E8744C46220001]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.update.MaxSizeAutoCommitTest.getTlogFileSizes(MaxSizeAutoCommitTest.java:379)
at 
org.apache.solr.update.MaxSizeAutoCommitTest.deleteTest(MaxSizeAutoCommitTest.java:200)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[jira] [Commented] (SOLR-12416) router.autoDeleteAge is not accepted in CREATEALIAS command

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512829#comment-16512829
 ] 

David Smiley commented on SOLR-12416:
-

Ah; this is a trivial fix!

[~jpountz] this is just a one-liner that is very safe.  Can I get this bug fix 
into 7.4?

Longer term, I think we can improve the code to not even need a 
OPTIONAL_ROUTER_PARAMS which needs to be maintained and when we accidentally 
forget to maintain it then what you saw happens.

> router.autoDeleteAge is not accepted in CREATEALIAS command
> ---
>
> Key: SOLR-12416
> URL: https://issues.apache.org/jira/browse/SOLR-12416
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.3.1
> Environment: Experimenting with a freshly downloaded Solr 7.3.1
>Reporter: Joachim Sauer
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I've been experimenting with time routed aliases, specifically with the 
> autoDeleteAge feature (SOLR-11925) and notice that the router.autoDeleteAge 
> parameter was silently ignored in the CREATEALIAS command.
>  
> Using ALIASPROP to set it worked just fine.
>  
> The problem seems to be that 
> [TimeRoutedAlias.OPTIONAL_ROUTER_PARAMS|https://github.com/apache/lucene-solr/blob/bf6503ba5871228692ca79f0b2204a935538e00a/solr/core/src/java/org/apache/solr/cloud/api/collections/TimeRoutedAlias.java#L83]
>  has not been updated when the autoDeleteAge property was added.



--
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-Solaris (64bit/jdk1.8.0) - Build # 1910 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1910/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

12 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([A640AF984D31:42A8E4F04D89D8CB]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:425)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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.IndexSizeTriggerTest.testTrigger

Error Message:
number of ops expected:<2> but was:<1>

Stack Trace:
java.lang.AssertionError: number of ops expected:<2> but was:<1>
at 

[jira] [Resolved] (SOLR-12491) Wrong JTS jar file in Guide

[Cassandra Targett (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cassandra Targett resolved SOLR-12491.
--
Resolution: Duplicate

It's fine to file JIRA issues for any documentation issues you may encounter.

The problem you report here, however, has already been fixed for the upcoming 
7.4 Ref Guide by SOLR-12274.

> Wrong JTS jar file in Guide
> ---
>
> Key: SOLR-12491
> URL: https://issues.apache.org/jira/browse/SOLR-12491
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3.1
>Reporter: Neil Ireson
>Priority: Minor
>
> Not sure if this belongs here as it relates to the Guide rather than the code.
> On the Spatial Search page in the section 
> [https://lucene.apache.org/solr/guide/7_3/spatial-search.html#jts-and-polygons-flat.]
>  It says to download the vividsolutions jts-core. However it is the 
> locationtech jts which is required, this can be found at 
> [http://central.maven.org/maven2/org/locationtech/jts/jts-core/1.15.0/.|http://central.maven.org/maven2/org/locationtech/jts/jts-core/1.15.0/]



--
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 # 816 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/816/

[...truncated 29 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.4/4/consoleText

[repro] Revision: 3ed77ebd8dc85ebda2817033ec20df372735c650

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.4/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=IndexSizeTriggerTest 
-Dtests.method=testSplitIntegration -Dtests.seed=EAB020792311EFCA 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.4/test-data/enwiki.random.lines.txt
 -Dtests.locale=es-CR -Dtests.timezone=America/Godthab -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestDocTermOrdsUninvertLimit 
-Dtests.method=testTriggerUnInvertLimit -Dtests.seed=EAB020792311EFCA 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.4/test-data/enwiki.random.lines.txt
 -Dtests.locale=pt-PT -Dtests.timezone=Africa/Gaborone -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestDocTermOrdsUninvertLimit 
-Dtests.seed=EAB020792311EFCA -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.4/test-data/enwiki.random.lines.txt
 -Dtests.locale=pt-PT -Dtests.timezone=Africa/Gaborone -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=DistribCursorPagingTest 
-Dtests.method=test -Dtests.seed=EAB020792311EFCA -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.4/test-data/enwiki.random.lines.txt
 -Dtests.locale=fr-CH -Dtests.timezone=America/Port-au-Prince 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=PingRequestHandlerTest 
-Dtests.method=testPingInClusterWithNoHealthCheck -Dtests.seed=EAB020792311EFCA 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.4/test-data/enwiki.random.lines.txt
 -Dtests.locale=ar-DZ -Dtests.timezone=Europe/Belfast -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
228a84fd6db3ef5fc1624d69e1c82a1f02c51352
[repro] git fetch

[...truncated 2 lines...]
[repro] git checkout 3ed77ebd8dc85ebda2817033ec20df372735c650

[...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]   TestDocTermOrdsUninvertLimit
[repro]   DistribCursorPagingTest
[repro]   PingRequestHandlerTest
[repro] ant compile-test

[...truncated 3318 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=20 
-Dtests.class="*.IndexSizeTriggerTest|*.TestDocTermOrdsUninvertLimit|*.DistribCursorPagingTest|*.PingRequestHandlerTest"
 -Dtests.showOutput=onerror -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.4/test-data/enwiki.random.lines.txt
 -Dtests.seed=EAB020792311EFCA -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.4/test-data/enwiki.random.lines.txt
 -Dtests.locale=es-CR -Dtests.timezone=America/Godthab -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[...truncated 1628 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   2/5 failed: org.apache.solr.cloud.DistribCursorPagingTest
[repro]   3/5 failed: org.apache.solr.handler.PingRequestHandlerTest
[repro]   5/5 failed: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest
[repro]   5/5 failed: org.apache.solr.uninverting.TestDocTermOrdsUninvertLimit

[repro] Re-testing 100% failures at the tip of branch_7_4
[repro] ant clean

[...truncated 8 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   IndexSizeTriggerTest
[repro]   TestDocTermOrdsUninvertLimit
[repro] ant compile-test

[...truncated 3318 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.IndexSizeTriggerTest|*.TestDocTermOrdsUninvertLimit" 
-Dtests.showOutput=onerror -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.4/test-data/enwiki.random.lines.txt
 -Dtests.seed=EAB020792311EFCA -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 

[jira] [Created] (SOLR-12491) Wrong JTS jar file in Guide

[Neil Ireson (JIRA)]

Neil Ireson created SOLR-12491:
--

 Summary: Wrong JTS jar file in Guide
 Key: SOLR-12491
 URL: https://issues.apache.org/jira/browse/SOLR-12491
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.3.1
Reporter: Neil Ireson


Not sure if this belongs here as it relates to the Guide rather than the code.

On the Spatial Search page in the section 
[https://lucene.apache.org/solr/guide/7_3/spatial-search.html#jts-and-polygons-flat.]
 It says to download the vividsolutions jts-core. However it is the 
locationtech jts which is required, this can be found at 
[http://central.maven.org/maven2/org/locationtech/jts/jts-core/1.15.0/.|http://central.maven.org/maven2/org/locationtech/jts/jts-core/1.15.0/]



--
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-12407) edismax boost performance regression from switch to FunctionScoreQuery

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512724#comment-16512724
 ] 

Hoss Man commented on SOLR-12407:
-

bq. It looks as though BoostedQuery just assumed that all docs had a value, so 
avoided the exists check. I'm not entirely sure that's a safe assumption, but 
from looking at a few ValueSource implementations it does seem that they have 
default return values and so the exists check isn't actually necessary. *So the 
best solution is I think to remove the exists call from 
ValueSource.WrappedDoubleValuesSource and always return true from 
advanceExact()*

I haven't reviewed the "current" (post LUCENE-8099) code that has raised this 
concern, but if i'm understanding the current discussion what you are 
describing sounds sane/desired for this usage/code-path. 
 
In the "boost by function" use cases the "query being boosted" has already 
dictated that docX matches the query, the "boosting ValueSource" is only needed 
to decide how much the boost should be -- it doesn't really matter if the 
ValueSource "exists()" for that particular document, it's still going to match 
the overall query, so it has to return something.  If the VS doesn't "exist()" 
for a doc, then the "implicit default" (typically 0) of the ValueSource impl 
can/should be used ... if users don't want that implicit default, that's what 
the {{def(...)}} wrapper function is for. 

{{exists()}} really only needs to be checked for the case where the ValueSource 
is being used to decide which documents should match -- like the {{frange}} 
query parser -- of in the case where a wrapper ValueSource needs to make 
conditional decisions (see LUCENE-5961)

> edismax boost performance regression from switch to FunctionScoreQuery
> --
>
> Key: SOLR-12407
> URL: https://issues.apache.org/jira/browse/SOLR-12407
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Will Currie
>Priority: Minor
> Attachments: restore-boosted-query.patch, solr-7.2.svg, solr-7.3.svg
>
>
> Assertion: FunctionScoreQuery uses the iterator style API (advanceExact + 
> doubleValue). BoostedQuery uses the "old" api (just a single call to 
> doubleValue). In an edismax boost this means the boost function is called 
> twice for every document being scored in 7.3 instead of once in 7.2.
> I'm seeing ~50% increase in query response time after upgrading from 7.2 to 
> 7.3 (600ms to 900ms). My queries use an edismax boost something like:
> {noformat}
> if(termfreq(type,"A"),product(map(field1,3,3,1.5,1),map(field1,4,4,1.9,1),if(def(field2,false),product(map(field1,1,1,0.6,1),map(field1,2,2,0.7,1),if(not(exists(field1)),0.6,1),map(field3,0,0,1.3,1)),product(map(field1,1,1,0.7,1),map(field1,2,2,1.1,1),if(not(exists(field1)),0.90,1),map(field3,0,0,1.50,1,1){noformat}
> This boost is likely (surely?) suboptimal but LUCENE-8099 appears to have 
> introduced this performance regression (poured proverbial oil on my 
> smouldering fire). If I change ExtendedDismaxQParser back to using the 
> deprecated BoostedQuery I get the 600ms solr 7.2 response time back.
> It appears FunctionScoreQuery invokes the boost function twice for each 
> document. Once with a call to 
> [exists()|https://github.com/apache/lucene-solr/blob/03afeb7766a39996de3c85e8a6ab24d2a352dd1c/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java#L150]
>  from 
> [advanceExact()|https://github.com/apache/lucene-solr/blob/42154387d4f2a6060da09c4236e2a8dbb575c59e/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionScoreQuery.java#L170],
>  then a second time from the call chain following scores.doubleValue().
> I don't know if that's the cause of the slowdown but I'm definitely seeing a 
> slowdown that disappears when I revert part of LUCENE-8099.
> I've attached some flamegraphs comparing 7.2 and 7.3. The frame 
> FunctionScoreQuery$FunctionScoreWeight$1.score in solr-7.3.svg show 2 
> "towers". One for advanceExact (calling exists()), the other for 
> doubleValue() which ends up similar to solr-7.2.svg.



--
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-SmokeRelease-7.4 - Build # 4 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.4/4/

No tests ran.

Build Log:
[...truncated 15 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:862)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1129)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1160)
at hudson.scm.SCM.checkout(SCM.java:495)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1202)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1724)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
--progress git://git.apache.org/lucene-solr.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: unable to connect to git.apache.org:
git.apache.org[0: 54.84.58.65]: errno=Connection refused


at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1996)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1715)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:72)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:405)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:207)
at hudson.remoting.UserRequest.perform(UserRequest.java:53)
at hudson.remoting.Request$2.run(Request.java:358)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
lucene
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1693)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:310)
at hudson.remoting.Channel.call(Channel.java:908)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor884.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy110.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:860)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1129)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1160)
at hudson.scm.SCM.checkout(SCM.java:495)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1202)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1724)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
ERROR: Error fetching remote repo 'origin'
Retrying after 10 seconds
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags 

[GitHub] lucene-solr pull request #404: Augment comments to explain how to use URLCla...

[ohtwadi]

GitHub user ohtwadi opened a pull request:

https://github.com/apache/lucene-solr/pull/404

Augment comments to explain how to use URLClassifyProcessorFactory

URLClassifyProcessorFactory didn't have even a basic example on how to use 
this. I've added that now.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ohtwadi/lucene-solr patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/404.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #404






---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12361) Add solr child documents as values inside SolrInputField

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512676#comment-16512676
 ] 

David Smiley commented on SOLR-12361:
-

We have a bug in AddBlockUpdateTest, NPE in getNewClock.  Something is null in 
this chain: {{return 
h.getCore().getUpdateHandler().getUpdateLog().getVersionInfo().getNewClock();}}

-Dtests.seed=1D7D12D76FA3B2BF

 Can you please look [~moshebla]?

> Add solr child documents as values inside SolrInputField
> 
>
> Key: SOLR-12361
> URL: https://issues.apache.org/jira/browse/SOLR-12361
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.5
>
> Attachments: SOLR-12361.patch, SOLR-12361.patch, SOLR-12361.patch, 
> SOLR-12361.patch
>
>  Time Spent: 10h 10m
>  Remaining Estimate: 0h
>
> During the discussion on SOLR-12298, there was a proposal to remove 
> _childDocuments, and incorporate the relationship between the parent and its 
> child documents, by holding the child documents inside a solrInputField, 
> inside of the document.



--
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-12490) referring/excluding clauses from query JSON DSL in JSON facets.

[Mikhail Khludnev (JIRA)]

Mikhail Khludnev created SOLR-12490:
---

 Summary: referring/excluding clauses from query JSON DSL in JSON 
facets. 
 Key: SOLR-12490
 URL: https://issues.apache.org/jira/browse/SOLR-12490
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Facet Module, faceting
Reporter: Mikhail Khludnev


It's spin off from the 
[discussion|https://issues.apache.org/jira/browse/SOLR-9685?focusedCommentId=16508720=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16508720].
 

h2. Problem
# after SOLR-9685 we can tag separate clauses in hairish queries like 
{{parent}}, {{bool}}
# we can {{domain.excludeTags}}
# we are looking for child faceting with exclusions, see SOLR-9510, SOLR-8998   
 
# but we can refer only separate params in {{domain.filter}}, it's not possible 
to refer separate clauses

h2. Proposal 
# tag child clauses multiple times
{code}
{
"query" : {
  "#top":{
  "parent": {
  "query": "sku-title:foo",
  "filters" : [
  "scope:sku",
  { "#sku,color" :  "color:black" }, // multiple tags
  { "#sku,size" : "size:L" }
],
  "which": "scope:product"
   }
}
}
}
{code} 
# refer to sku clauses, either by 
## (1) {{domain.filter.tag}} in addition to {{param}}, or
## (2) {{domain.includeTags}} mimicking {{excludeTags}}  
{code}
"facet":{
  "sku_colors_in_prods":{
  "type" : "terms",
  "field" : "color",
   "domain" : {
  "excludeTags":["top","color"],   // we need to drop top-level parent 
query
  "filter":[ 
  {"tag":"sku"}  // (1)
   ],
  "includeTags":"sku"  // (2)
   },
  "facet":"uniqueBlock(_root_)"
   }
}
{code}  
WDYT, [~osavrasov], [~ysee...@gmail.com]?







--
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-8355) IW#writeSomeDocValuesUpdates might open a dropped segment

[Lucene/Solr QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512610#comment-16512610
 ] 

Lucene/Solr QA commented on LUCENE-8355:


| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  8s{color} 
| {color:red} LUCENE-8355 does not apply to master. Rebase required? Wrong 
Branch? See 
https://wiki.apache.org/lucene-java/HowToContribute#Contributing_your_work for 
help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8355 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12927571/LUCENE-8355.patch |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/32/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> IW#writeSomeDocValuesUpdates might open a dropped segment
> -
>
> Key: LUCENE-8355
> URL: https://issues.apache.org/jira/browse/LUCENE-8355
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 7.4, master (8.0), 7.5
>Reporter: Nhat Nguyen
>Priority: Major
> Attachments: LUCENE-8355.patch
>
>
> {noformat}
>[junit4] Suite: org.apache.lucene.index.TestIndexWriterWithThreads
>[junit4]   2> Jun 12, 2018 9:09:00 AM 
> com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
>  uncaughtException
>[junit4]   2> WARNING: Uncaught exception in thread: 
> Thread[Thread-927,5,TGRP-TestIndexWriterWithThreads]
>[junit4]   2> java.lang.AssertionError: 
> org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed
>[junit4]   2>  at 
> __randomizedtesting.SeedInfo.seed([F89419D754B7F340]:0)
>[junit4]   2>  at 
> org.apache.lucene.index.TestIndexWriterWithThreads.lambda$testUpdateSingleDocWithThreads$2(TestIndexWriterWithThreads.java:682)
>[junit4]   2>  at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> Caused by: org.apache.lucene.store.AlreadyClosedException: 
> this IndexWriter is closed
>[junit4]   2>  at 
> org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:663)
>[junit4]   2>  at 
> org.apache.lucene.index.IndexWriter.getConfig(IndexWriter.java:982)
>[junit4]   2>  at 
> org.apache.lucene.index.RandomIndexWriter.maybeFlushOrCommit(RandomIndexWriter.java:198)
>[junit4]   2>  at 
> org.apache.lucene.index.RandomIndexWriter.updateDocument(RandomIndexWriter.java:273)
>[junit4]   2>  at 
> org.apache.lucene.index.TestIndexWriterWithThreads.lambda$testUpdateSingleDocWithThreads$2(TestIndexWriterWithThreads.java:679)
>[junit4]   2>  ... 1 more
>[junit4]   2> Caused by: java.io.FileNotFoundException: _a_1.fnm in 
> dir=RAMDirectory@641490af 
> lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@7685b98b
>[junit4]   2>  at 
> org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:750)
>[junit4]   2>  at 
> org.apache.lucene.store.Directory.openChecksumInput(Directory.java:121)
>[junit4]   2>  at 
> org.apache.lucene.store.MockDirectoryWrapper.openChecksumInput(MockDirectoryWrapper.java:1072)
>[junit4]   2>  at 
> org.apache.lucene.codecs.lucene60.Lucene60FieldInfosFormat.read(Lucene60FieldInfosFormat.java:113)
>[junit4]   2>  at 
> org.apache.lucene.index.SegmentReader.initFieldInfos(SegmentReader.java:195)
>[junit4]   2>  at 
> org.apache.lucene.index.SegmentReader.(SegmentReader.java:97)
>[junit4]   2>  at 
> org.apache.lucene.index.ReadersAndUpdates.writeFieldUpdates(ReadersAndUpdates.java:536)
>[junit4]   2>  at 
> org.apache.lucene.index.IndexWriter.writeSomeDocValuesUpdates(IndexWriter.java:610)
>[junit4]   2>  at 
> org.apache.lucene.index.FrozenBufferedUpdates.apply(FrozenBufferedUpdates.java:299)
>[junit4]   2>  at 
> org.apache.lucene.index.IndexWriter.lambda$publishFrozenUpdates$3(IndexWriter.java:2586)
>[junit4]   2>  at 
> org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5056)
>[junit4]   2>  at 
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1596)
>[junit4]   2>  at 
> org.apache.lucene.index.IndexWriter.softUpdateDocument(IndexWriter.java:1653)
>[junit4]   2>  at 
> org.apache.lucene.index.RandomIndexWriter.updateDocument(RandomIndexWriter.java:264)
>[junit4]   2>  ... 2 more
>[junit4]   2> 
>[junit4]   2> Jun 12, 2018 9:09:00 AM 
> com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
>  uncaughtException
>[junit4]   2> WARNING: Uncaught exception in thread: 
> 

[jira] [Commented] (LUCENE-8343) BlendedInfixSuggester bad score calculus for certain suggestion weights

[Michael McCandless (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512583#comment-16512583
 ] 

Michael McCandless commented on LUCENE-8343:


I like the change in the PR; I left small comments there, that we should 
document that having a weight is optional so returning null from {{weight}} 
means there is no weight.

Maybe we should do it only for 8.x since it's a substantial API change?

> BlendedInfixSuggester bad score calculus for certain suggestion weights
> ---
>
> Key: LUCENE-8343
> URL: https://issues.apache.org/jira/browse/LUCENE-8343
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 7.3.1
>Reporter: Alessandro Benedetti
>Priority: Major
> Attachments: LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently the BlendedInfixSuggester return a (long) score to rank the 
> suggestions.
> This score is calculated as a multiplication between :
> long *Weight* : the suggestion weight, coming from a document field, it can 
> be any long value ( including 1, 0,.. )
> double *Coefficient* : 0<=x<=1, calculated based on the position match, 
> earlier the better
> The resulting score is a long, which means that at the moment, any weight<10 
> can bring inconsistencies.
> *Edge cases* 
> Weight =1
> Score = 1( if we have a match at the beginning of the suggestion) or 0 ( for 
> any other match)
> Weight =0
> Score = 0 ( independently of the position match coefficient)



--
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-7976) Make TieredMergePolicy respect maxSegmentSizeMB and allow singleton merges of very large segments

[Michael McCandless (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512580#comment-16512580
 ] 

Michael McCandless commented on LUCENE-7976:


{quote}maybe hop on a Google hangout or something at your convenience and see 
if we can reconcile it all?
{quote}
+1, just reach out when you have a chance?  I'm just confused where TMP is 
currently implementing this.

> Make TieredMergePolicy respect maxSegmentSizeMB and allow singleton merges of 
> very large segments
> -
>
> Key: LUCENE-7976
> URL: https://issues.apache.org/jira/browse/LUCENE-7976
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, 
> LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, 
> LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, 
> LUCENE-7976.patch, SOLR-7976.patch
>
>
> We're seeing situations "in the wild" where there are very large indexes (on 
> disk) handled quite easily in a single Lucene index. This is particularly 
> true as features like docValues move data into MMapDirectory space. The 
> current TMP algorithm allows on the order of 50% deleted documents as per a 
> dev list conversation with Mike McCandless (and his blog here:  
> https://www.elastic.co/blog/lucenes-handling-of-deleted-documents).
> Especially in the current era of very large indexes in aggregate, (think many 
> TB) solutions like "you need to distribute your collection over more shards" 
> become very costly. Additionally, the tempting "optimize" button exacerbates 
> the issue since once you form, say, a 100G segment (by 
> optimizing/forceMerging) it is not eligible for merging until 97.5G of the 
> docs in it are deleted (current default 5G max segment size).
> The proposal here would be to add a new parameter to TMP, something like 
>  (no, that's not serious name, suggestions 
> welcome) which would default to 100 (or the same behavior we have now).
> So if I set this parameter to, say, 20%, and the max segment size stays at 
> 5G, the following would happen when segments were selected for merging:
> > any segment with > 20% deleted documents would be merged or rewritten NO 
> > MATTER HOW LARGE. There are two cases,
> >> the segment has < 5G "live" docs. In that case it would be merged with 
> >> smaller segments to bring the resulting segment up to 5G. If no smaller 
> >> segments exist, it would just be rewritten
> >> The segment has > 5G "live" docs (the result of a forceMerge or optimize). 
> >> It would be rewritten into a single segment removing all deleted docs no 
> >> matter how big it is to start. The 100G example above would be rewritten 
> >> to an 80G segment for instance.
> Of course this would lead to potentially much more I/O which is why the 
> default would be the same behavior we see now. As it stands now, though, 
> there's no way to recover from an optimize/forceMerge except to re-index from 
> scratch. We routinely see 200G-300G Lucene indexes at this point "in the 
> wild" with 10s of  shards replicated 3 or more times. And that doesn't even 
> include having these over HDFS.
> Alternatives welcome! Something like the above seems minimally invasive. A 
> new merge policy is certainly an alternative.



--
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-9685) tag a query in JSON syntax

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512564#comment-16512564
 ] 

Varun Thacker commented on SOLR-9685:
-

{quote}, don't know why git haven't commented here.
{quote}
Just happened to me as well for my doc changes ;) ( 
[https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=a26a1bb249c978ea7ed197f85c9eb8c43ab5c637]
 ) didn't show up on the Jira. Perhaps the bot is down for a short while

> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685-doc.patch, SOLR-9685-doc.patch, 
> SOLR-9685.patch, SOLR-9685.patch, SOLR-9685.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9683) include/exclude filters by tag

[Mikhail Khludnev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512565#comment-16512565
 ] 

Mikhail Khludnev commented on SOLR-9683:


Isn't it done already, [~ysee...@gmail.com]?  

> include/exclude filters by tag
> --
>
> Key: SOLR-9683
> URL: https://issues.apache.org/jira/browse/SOLR-9683
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Priority: Major
>
> When specifying a filter list in JSON syntax, it would be nice to be able to 
> include/exclude filters by tag.



--
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-SmokeRelease-7.x - Build # 241 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/241/

No tests ran.

Build Log:
[...truncated 24201 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 2214 links (1764 relative) to 2989 anchors in 230 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/changes

-dist-keys:
  [get] Getting: http://home.apache.org/keys/group/lucene.asc
  [get] To: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/KEYS

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/solr-7.5.0.tgz
 into 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/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 = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/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 = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/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 = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/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 = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/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 = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/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 = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/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 = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/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 = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/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 = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/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 = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/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 = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

[jira] [Updated] (SOLR-9733) JSON Request filter param should support queries in JSON syntax

[Mikhail Khludnev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Khludnev updated SOLR-9733:
---
Description: 
Currently, the top level "filter" in the JSON Request API is implemented by 
copying those values back to "fq" parameters, since that is what other 
components currently check.

We should do a better job of isolating the creation of filters so other 
components don't have to know/care how they were created (i.e. what parameters 
were used, what syntax was used, etc).

After that, it will be much easier to support filter queries in JSON syntax:
{code}
{
 query : "myquery", 
 filter : [ {term : {field:myfield, val:myval}} , "another filter" ],
 limit : 10
}
{code}

  was:
Currently, the top level "filter" in the JSON Request API is implemented by 
copying those values back to "fq" parameters, since that is what other 
components currently check.

We should do a better job of isolating the creation of filters so other 
components don't have to know/care how they were created (i.e. what parameters 
were used, what syntax was used, etc).

After that, it will be much easier to support filter queries in JSON syntax:
{
 query : "myquery", 
 filter : [ {term : {field:myfield, val:myval} , "another filter" ],
 limit : 10
}



> JSON Request filter param should support queries in JSON syntax
> ---
>
> Key: SOLR-9733
> URL: https://issues.apache.org/jira/browse/SOLR-9733
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: JSON Request API
>Reporter: Yonik Seeley
>Priority: Major
>
> Currently, the top level "filter" in the JSON Request API is implemented by 
> copying those values back to "fq" parameters, since that is what other 
> components currently check.
> We should do a better job of isolating the creation of filters so other 
> components don't have to know/care how they were created (i.e. what 
> parameters were used, what syntax was used, etc).
> After that, it will be much easier to support filter queries in JSON syntax:
> {code}
> {
>  query : "myquery", 
>  filter : [ {term : {field:myfield, val:myval}} , "another filter" ],
>  limit : 10
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9685) tag a query in JSON syntax

[Mikhail Khludnev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512545#comment-16512545
 ] 

Mikhail Khludnev commented on SOLR-9685:


[~ctargett] I've just committed your docs patch into three branches, don't know 
why git haven't commented here.  

> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685-doc.patch, SOLR-9685-doc.patch, 
> SOLR-9685.patch, SOLR-9685.patch, SOLR-9685.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4676 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4676/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

5 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([BFA5FCE0DA7F7A6A:EC1CBE50386EEF90]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:425)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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.IndexSizeTriggerTest.testSplitIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 

[jira] [Commented] (SOLR-12416) router.autoDeleteAge is not accepted in CREATEALIAS command

[Joachim Sauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512506#comment-16512506
 ] 

Joachim Sauer commented on SOLR-12416:
--

[~dsmiley], could you take a look?

> router.autoDeleteAge is not accepted in CREATEALIAS command
> ---
>
> Key: SOLR-12416
> URL: https://issues.apache.org/jira/browse/SOLR-12416
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.3.1
> Environment: Experimenting with a freshly downloaded Solr 7.3.1
>Reporter: Joachim Sauer
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I've been experimenting with time routed aliases, specifically with the 
> autoDeleteAge feature (SOLR-11925) and notice that the router.autoDeleteAge 
> parameter was silently ignored in the CREATEALIAS command.
>  
> Using ALIASPROP to set it worked just fine.
>  
> The problem seems to be that 
> [TimeRoutedAlias.OPTIONAL_ROUTER_PARAMS|https://github.com/apache/lucene-solr/blob/bf6503ba5871228692ca79f0b2204a935538e00a/solr/core/src/java/org/apache/solr/cloud/api/collections/TimeRoutedAlias.java#L83]
>  has not been updated when the autoDeleteAge property was added.



--
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-NightlyTests-7.x - Build # 241 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/241/

3 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:
last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/50)={   
"replicationFactor":"2",   "pullReplicas":"0",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"2",   
"autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0",   
"autoCreated":"true",   "shards":{ "shard2":{   "replicas":{ 
"core_node3":{   
"core":"testSplitIntegration_collection_shard2_replica_n3",   
"leader":"true",   "SEARCHER.searcher.maxDoc":11,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":15740, 
  "node_name":"127.0.0.1:10001_solr",   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":1.4659017324447632E-5,   
"SEARCHER.searcher.numDocs":11}, "core_node4":{   
"core":"testSplitIntegration_collection_shard2_replica_n4",   
"SEARCHER.searcher.maxDoc":11,   "SEARCHER.searcher.deletedDocs":0, 
  "INDEX.sizeInBytes":15740,   "node_name":"127.0.0.1:1_solr",  
 "state":"active",   "type":"NRT",   
"INDEX.sizeInGB":1.4659017324447632E-5,   
"SEARCHER.searcher.numDocs":11}},   "range":"0-7fff",   
"state":"active"}, "shard1":{   "stateTimestamp":"1528975827417324650", 
  "replicas":{ "core_node1":{   
"core":"testSplitIntegration_collection_shard1_replica_n1",   
"leader":"true",   "SEARCHER.searcher.maxDoc":14,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":17240, 
  "node_name":"127.0.0.1:10001_solr",   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":1.605600118637085E-5,   
"SEARCHER.searcher.numDocs":14}, "core_node2":{   
"core":"testSplitIntegration_collection_shard1_replica_n2",   
"SEARCHER.searcher.maxDoc":14,   "SEARCHER.searcher.deletedDocs":0, 
  "INDEX.sizeInBytes":17240,   "node_name":"127.0.0.1:1_solr",  
 "state":"active",   "type":"NRT",   
"INDEX.sizeInGB":1.605600118637085E-5,   
"SEARCHER.searcher.numDocs":14}},   "range":"8000-",   
"state":"inactive"}, "shard1_1":{   "parent":"shard1",   
"stateTimestamp":"1528975827451705050",   "range":"c000-",  
 "state":"active",   "replicas":{ "core_node10":{   
"leader":"true",   
"core":"testSplitIntegration_collection_shard1_1_replica1",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":13740,   "node_name":"127.0.0.1:1_solr",   
"base_url":"http://127.0.0.1:1/solr;,   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":1.2796372175216675E-5, 
  "SEARCHER.searcher.numDocs":7}, "core_node9":{   
"core":"testSplitIntegration_collection_shard1_1_replica0",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":13740,   "node_name":"127.0.0.1:10001_solr",   
"base_url":"http://127.0.0.1:10001/solr;,   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":1.2796372175216675E-5, 
  "SEARCHER.searcher.numDocs":7}}}, "shard1_0":{   "parent":"shard1",   
"stateTimestamp":"1528975827451393300",   "range":"8000-bfff",  
 "state":"active",   "replicas":{ "core_node7":{   
"leader":"true",   
"core":"testSplitIntegration_collection_shard1_0_replica0",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":23980,   "node_name":"127.0.0.1:10001_solr",   
"base_url":"http://127.0.0.1:10001/solr;,   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":2.2333115339279175E-5, 
  "SEARCHER.searcher.numDocs":7}, "core_node8":{   
"core":"testSplitIntegration_collection_shard1_0_replica1",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":23980,   "node_name":"127.0.0.1:1_solr",   
"base_url":"http://127.0.0.1:1/solr;,   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":2.2333115339279175E-5, 
  "SEARCHER.searcher.numDocs":7}

Stack Trace:
java.util.concurrent.TimeoutException: last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/50)={
  "replicationFactor":"2",
  "pullReplicas":"0",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"2",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  

[jira] [Commented] (SOLR-12415) Solr Loadbalancer client LBHttpSolrClient not working as expected, if a Solr node goes down, it is unable to detect when it become live again due to 404 error

[Grzegorz Lebek (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512448#comment-16512448
 ] 

Grzegorz Lebek commented on SOLR-12415:
---

[~elyograg]

There is even more troubles there.

If anyone is using authentication with the user, which is a request parameter, 
the query in the method 'checkZombieServer' will always fail (as it is not 
passing auth params) and assume that the server is still down. It is one more 
reason why zombie server will never come back alive in the client.

> Solr Loadbalancer client LBHttpSolrClient not working as expected, if a Solr 
> node goes down, it is unable to detect when it become live again due to 404 
> error
> --
>
> Key: SOLR-12415
> URL: https://issues.apache.org/jira/browse/SOLR-12415
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 7.2.1, 7.3.1, 7.4
> Environment: Solr 7.2.1
> 2 servers - master and slave.
>Reporter: Grzegorz Lebek
>Priority: Critical
>
> *Context*
>  When LBHttpSolrClient has been constructed using *base root urls*, and when 
> a slave goes down, and then back again, the client is unable to mark it as 
> alive again due to 404 error.
> Logs  below:
> {code:java}
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 >> "GET 
> /solr/select?q=%3A=0=docid+asc=false=javabin=2 
> HTTP/1.1[\r][\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 >> 
> "User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrClient] 
> 1.0[\r][\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 >> "Host: 
> localhost:8984[\r][\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 >> 
> "Connection: Keep-Alive[\r][\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 >> "[\r][\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 << "HTTP/1.1 
> 404 Not Found[\r][\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 << 
> "Cache-Control: must-revalidate,no-cache,no-store[\r][\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 << 
> "Content-Type: text/html;charset=iso-8859-1[\r][\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 << 
> "Content-Length: 243[\r][\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 << "[\r][\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 << "[\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 << "[\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 << " http-equiv="Content-Type" content="text/html;charset=utf-8"/>[\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 << 
> "Error 404 Not Found[\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 << 
> "[\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 << 
> "HTTP ERROR 404[\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 << "Problem 
> accessing /solr/select. Reason:[\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 << " Not 
> Found[\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 << 
> "[\n]"
>  DEBUG [aliveCheckExecutor-1-thread-1] [wire] http-outgoing-83 << 
> "[\n]"{code}
> *Analysis*
>  when using only *base root urls* in a LBHttpSolrClient we need to pass a 
> "*collection*" paramter when sending a request. It works fine except that in 
> a method 
> {code:java}
> private void checkAZombieServer(ServerWrapper zombieServer){code}
> it tries to query a solr without the collection parameter, to check if the 
> server is alive. This causes a html content (apparently dashboard) to be 
> returned, and as a result it will move to the exception clause in the method 
> therefore even if the server is back it will never be marked as alive again.
>  I debugged this and if we pass a collection name there as a second param it 
> will respond in a right manner.
> Suggestion is either to somehow pass the collection name or to change the way 
> zombie servers are pinged.
> *Steps to reproduce*
> Run 2 servers - master and slave. Create client using base urls. Index, test 
> search etc.
> Turn off slave server and after couple of seconds turn it on again.
>  



--
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-8356) Remove StandardFilter

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512446#comment-16512446
 ] 

Alan Woodward commented on LUCENE-8356:
---

It appears in quite a few solr example schemas, and in a couple of tests as 
well.  It should be trivial to remove, I'll put up a patch for that too.

> Remove StandardFilter
> -
>
> Key: LUCENE-8356
> URL: https://issues.apache.org/jira/browse/LUCENE-8356
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8356.patch
>
>
> StandardFilter does literally nothing, and is included all over the place, 
> presumably for historical reasons.  We should just nuke it.



--
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-11676) nrt replicas is always 1 when not specified

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512444#comment-16512444
 ] 

Varun Thacker commented on SOLR-11676:
--

The scope of the patch should be :

- Don't allow replicationFactor and nrtReplicas to be specified on the same API 
call 
- If either nrtReplicas or replicationFactor is specified keep both in sync in 
state.json including modify collections command

> nrt replicas is always 1 when not specified
> ---
>
> Key: SOLR-11676
> URL: https://issues.apache.org/jira/browse/SOLR-11676
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Priority: Major
> Attachments: SOLR-11676.patch, SOLR-11676.patch
>
>
> I created 1 2 shard X 2 replica collection . Here's the log entry for it
> {code}
> 2017-11-27 06:43:47.071 INFO  (qtp159259014-22) [   ] 
> o.a.s.h.a.CollectionsHandler Invoked Collection Action :create with params 
> replicationFactor=2=compositeId=_default=2=test_recovery=compositeId=CREATE=2=json&_=1511764995711
>  and sendToOCPQueue=true
> {code}
> And then when I look at the state.json file I see nrtReplicas is set to 1. 
> Any combination of numShards and replicationFactor without explicitly 
> specifying the "nrtReplicas" param puts the "nrtReplicas" as 1 instead of 
> using the replicationFactor value
> {code}
> {"test_recovery":{
> "pullReplicas":"0",
> "replicationFactor":"2",
> ...
> "nrtReplicas":"1",
> "tlogReplicas":"0",
> ..
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-11823) Incorrect number of replica calculation when using Restore Collection API

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512443#comment-16512443
 ] 

Varun Thacker commented on SOLR-11823:
--

There are multiple issues in play here
 # When you create a collection with replicationFactor = 3, the state.json will 
write out nrtReplicas=1 and replicationFactor=3 . They should be in sync. I 
will firstly fix that on SOLR-11676
 # When restoring a collection the restore parameter is not respected. I filed 
SOLR-12489 for that which needs to be fixed 

Let me fix these two underlying issues first shortly and then see how the 
maxShardsPerNode calculation is broken and how to fix it

> Incorrect number of replica calculation when using Restore Collection API
> -
>
> Key: SOLR-11823
> URL: https://issues.apache.org/jira/browse/SOLR-11823
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 7.1
>Reporter: Ansgar Wiechers
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> I'm running Solr 7.1 (didn't test other versions) in SolrCloud mode ona a 
> 3-node cluster and tried using the backup/restore API for the first time. 
> Backup worked fine, but when trying to restore the backed-up collection I ran 
> into an unexpected problem with the replication factor setting.
> I expected the command below to restore a backup of the collection "demo" 
> with 3 shards, creating 2 replicas per shard. Instead it's trying to create 6 
> replicas per shard:
> {noformat}
> # curl -s -k 
> 'https://localhost:8983/solr/admin/collections?action=restore=demo=/srv/backup/solr/solr-dev=demo=2=2'
> {
>   "error": {
> "code": 400,
> "msg": "Solr cloud with available number of nodes:3 is insufficient for 
> restoring a collection with 3 shards, total replicas per shard 6 and 
> maxShardsPerNode 2. Consider increasing maxShardsPerNode value OR number 
> ofavailable nodes.",
> "metadata": [
>   "error-class",
>   "org.apache.solr.common.SolrException",
>   "root-error-class",
>   "org.apache.solr.common.SolrException"
> ]
>   },
>   "exception": {
> "rspCode": 400,
> "msg": "Solr cloud with available number of nodes:3 is insufficient for 
> restoring a collection with 3 shards, total replicas per shard 6 and 
> maxShardsPerNode 2. Consider increasing maxShardsPerNode value OR number of 
> available nodes."
>   },
>   "Operation restore caused exception:": 
> "org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
> Solr cloud with available number of nodes:3 is insufficient for restoring a 
> collection with 3 shards, total replicas per shard 6 and maxShardsPerNode 2. 
> Consider increasing maxShardsPerNode value OR number of available nodes.",
>   "responseHeader": {
> "QTime": 28,
> "status": 400
>   }
> }
> {noformat}
> Restoring a collection with only 2 shards tries to create 6 replicas as well, 
> so it looks to me like the restore API multiplies the replication factor with 
> the number of nodes, which is not how the replication factor behaves in other 
> contexts. The 
> [documentation|https://lucene.apache.org/solr/guide/7_1/collections-api.html] 
> also didn't lead me to expect this behavior:
> {quote}
> replicationFactor
>The number of replicas to be created for each shard.
> {quote}



--
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-12489) Restore collection does not respect use specified replicationFactore

[Varun Thacker (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Varun Thacker updated SOLR-12489:
-
Summary: Restore collection does not respect use specified 
replicationFactore  (was: Restore collection does not respect use specified 
replicationFactor)

> Restore collection does not respect use specified replicationFactore
> 
>
> Key: SOLR-12489
> URL: https://issues.apache.org/jira/browse/SOLR-12489
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
>  Labels: Backup/Restore
>
> When restoring a collection we can pass in the replicationFactor 
> However while restoring the collection we don't make use of this param and 
> end up using whatever is present  as the nrtReplicas key in the state.json
>  
> {code:java}
> int numNrtReplicas = getInt(message, NRT_REPLICAS, 
> backupCollectionState.getNumNrtReplicas(), 0);
> if (numNrtReplicas == 0) {
>   numNrtReplicas = getInt(message, REPLICATION_FACTOR, 
> backupCollectionState.getReplicationFactor(), 0);
> }{code}
> The tests didn't catch this as the create collection call from SolrJ sets 
> nrtReplicas = replicationFactor and then we never restore with a different 
> replicationFactor



--
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-12489) Restore collection does not respect user specified replicationFactor

[Varun Thacker (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Varun Thacker updated SOLR-12489:
-
Summary: Restore collection does not respect user specified 
replicationFactor  (was: Restore collection does not respect use specified 
replicationFactore)

> Restore collection does not respect user specified replicationFactor
> 
>
> Key: SOLR-12489
> URL: https://issues.apache.org/jira/browse/SOLR-12489
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
>  Labels: Backup/Restore
>
> When restoring a collection we can pass in the replicationFactor 
> However while restoring the collection we don't make use of this param and 
> end up using whatever is present  as the nrtReplicas key in the state.json
>  
> {code:java}
> int numNrtReplicas = getInt(message, NRT_REPLICAS, 
> backupCollectionState.getNumNrtReplicas(), 0);
> if (numNrtReplicas == 0) {
>   numNrtReplicas = getInt(message, REPLICATION_FACTOR, 
> backupCollectionState.getReplicationFactor(), 0);
> }{code}
> The tests didn't catch this as the create collection call from SolrJ sets 
> nrtReplicas = replicationFactor and then we never restore with a different 
> replicationFactor



--
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-12489) Restore collection does not respect use specified replicationFactor

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-12489:


 Summary: Restore collection does not respect use specified 
replicationFactor
 Key: SOLR-12489
 URL: https://issues.apache.org/jira/browse/SOLR-12489
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Varun Thacker
Assignee: Varun Thacker


When restoring a collection we can pass in the replicationFactor 

However while restoring the collection we don't make use of this param and end 
up using whatever is present  as the nrtReplicas key in the state.json

 
{code:java}
int numNrtReplicas = getInt(message, NRT_REPLICAS, 
backupCollectionState.getNumNrtReplicas(), 0);
if (numNrtReplicas == 0) {
  numNrtReplicas = getInt(message, REPLICATION_FACTOR, 
backupCollectionState.getReplicationFactor(), 0);
}{code}
The tests didn't catch this as the create collection call from SolrJ sets 
nrtReplicas = replicationFactor and then we never restore with a different 
replicationFactor



--
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.4

[Alan Woodward]

LUCENE-8357 is in.

> On 14 Jun 2018, at 09:27, Adrien Grand  wrote:
> 
> +1
> 
> Le jeu. 14 juin 2018 à 10:02, Alan Woodward  > a écrit :
> Hi Adrien,
> 
> If possible I’d like to get LUCENE-8357 in, which fixes a regression in 
> Explanations for Solr’s boost queries.
> 
> Alan
> 
> 
>> On 13 Jun 2018, at 20:42, Adrien Grand > > wrote:
>> 
>> It is. In general I trust your judgement to only backport low-risk fixes.
>> 
>> Le mer. 13 juin 2018 à 21:03, Steve Rowe > > a écrit :
>> Crap, I forgot to ask for inclusion of SOLR-12481, a doc-only fix related to 
>> SOLR-12434.  I’m going to assume that it’s okay to backport as well, I’ll go 
>> do that now.  Sorry for the churn.
>> 
>> --
>> Steve
>> www.lucidworks.com 
>> 
>> > On Jun 13, 2018, at 1:49 PM, Steve Rowe > > > wrote:
>> > 
>> > Thanks, done.
>> > 
>> > --
>> > Steve
>> > www.lucidworks.com 
>> > 
>> >> On Jun 13, 2018, at 1:08 PM, Adrien Grand > >> > wrote:
>> >> 
>> >> OK to backport SOLR-12434.
>> >> 
>> >> Le mer. 13 juin 2018 à 18:41, Steve Rowe > >> > a écrit :
>> >> Adrien,
>> >> 
>> >> Are you okay with backporting SOLR-12434 to 7.4?
>> >> 
>> >> --
>> >> Steve
>> >> www.lucidworks.com 
>> >> 
>> >>> On Jun 12, 2018, at 9:37 AM, Steve Rowe > >>> > wrote:
>> >>> 
>> >>> Done, thanks Adrien.
>> >>> 
>> >>> --
>> >>> Steve
>> >>> www.lucidworks.com 
>> >>> 
>>  On Jun 12, 2018, at 9:23 AM, Adrien Grand >  > wrote:
>>  
>>  +1 to backport LUCENE-8278 to 7.4. Thanks Steve.
>>  
>>  Le lun. 11 juin 2018 à 23:21, Steve Rowe >  > a écrit :
>>  Adrien,
>>  
>>  Are you okay with including the fix on LUCENE-8278 in 7.4?
>>  
>>  --
>>  Steve
>>  www.lucidworks.com 
>>  
>> > On Jun 11, 2018, at 11:24 AM, Adrien Grand > > > wrote:
>> > 
>> > No worries Uwe, we'll wait. Enjoy Buzzwords!
>> > 
>> > Le lun. 11 juin 2018 à 17:08, Uwe Schindler > > > a écrit :
>> > I still have this new security issue and to fix it finally everywhere, 
>> > it requires API changes. So please wait, I am working but buzzwords is 
>> > so interesting! 勞
>> > 
>> > Uwe
>> > 
>> > 
>> > Am June 11, 2018 2:45:54 PM UTC schrieb David Smiley 
>> > mailto:david.w.smi...@gmail.com>>:
>> > It'd be nice to get in this bug 
>> > https://issues.apache.org/jira/browse/LUCENE-8344 
>> >  but is pending a 
>> > review.
>> > 
>> > On Tue, Jun 5, 2018 at 4:24 AM Adrien Grand > > > wrote:
>> > Hi all,
>> > 
>> > We released 7.3 two months ago on April 4th and we accumulated quite a 
>> > number of features, enhancements and fixes that are not released yet, 
>> > so I'd like to start working on releasing Lucene/Solr 7.4.0.
>> > 
>> > I propose to create the 7.4 branch later this week and build the first 
>> > RC early next week if that works for everyone. Please let me know if 
>> > that are bug fixes that we think should make it to 7 
>> > .4
>> >  and might not be ready by then.
>> > 
>> > Adrien
>> > -- 
>> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> > LinkedIn: http://linkedin.com/in/davidwsmiley 
>> >  | Book: 
>> > http://www.solrenterprisesearchserver.com 
>> > 
>> > 
>> > --
>> > Uwe Schindler
>> > Achterdiek 19, 28357 Bremen 
>> > 
>> > https://www.thetaphi.de 
>>  
>>  
>>  -
>>  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>>  
>>  For additional commands, e-mail: dev-h...@lucene.apache.org 
>>  
>>  
>> >>> 
>> >> 
>> > 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> 
>> 
> 

[jira] [Resolved] (SOLR-12414) FunctionScoreQuery no longer displays debug output

[Alan Woodward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Woodward resolved SOLR-12414.
--
Resolution: Fixed
  Assignee: Alan Woodward

Resolved by LUCENE-8357

> FunctionScoreQuery no longer displays debug output
> --
>
> Key: SOLR-12414
> URL: https://issues.apache.org/jira/browse/SOLR-12414
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3, 7.3.1
>Reporter: Markus Jelsma
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> I have two documents:
> {code}
> {"text":"some text", "lang":"cn"}
> {"text":"more text", "lang":"en"}
> {code}
> And the following query, a simple edismax with a boost on lang:en:
> {code}http://localhost:8983/solr/test/select?wt=xml=text=edismax=text=true=if(exists(query($bqlang)),2,1)=lang:en
> {code}
> The parsedQuery is now slightly different because of it being wrapped in a 
> FunctionScoreQuery. The problem is the explain for the document, which is:
> {code}
> 0.3971361 = product of:
>   1.0 = boost
>   0.3971361 = boost(if(exists(query(lang:en,def=0.0)),const(2),const(1)))
> {code}
> Which is now unreadable for complicated queries with many clauses. It should 
> resemble the output of 7.2, which was:
> {code}
> 0.36464313 = 
> boost(text:text,if(exists(query(lang:en,def=0.0)),const(2),const(1))), 
> product of:
>   0.18232156 = weight(text:text in 0) [SchemaSimilarity], result of:
> 0.18232156 = score(doc=0,freq=1.0 = termFreq=1.0
> ), product of:
>   0.18232156 = idf, computed as log(1 + (docCount - docFreq + 0.5) / 
> (docFreq + 0.5)) from:
> 2.0 = docFreq
> 2.0 = docCount
>   1.0 = tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b * 
> fieldLength / avgFieldLength)) from:
> 1.0 = termFreq=1.0
> 1.2 = parameter k1
> 0.75 = parameter b
> 2.0 = avgFieldLength
> 2.0 = fieldLength
>   2.0 = if(exists(query(lang:en,def=0.0)=0.6931472),const(2),const(1))
> {code}
> This bug was introduced in Solr/Lucene 7.3.
> Mailing list reference: 
> http://lucene.472066.n3.nabble.com/Solr-7-3-FunctionScoreQuery-no-longer-displays-debug-output-td4389093.html



--
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/jdk-9.0.4) - Build # 632 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/632/
Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseParallelGC

11 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([E08E0D91AB940829:D900B4D1846BC1D7]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration(IndexSizeTriggerTest.java:298)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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.IndexSizeTriggerTest.testSplitIntegration

Error Message:
last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/61)={   
"replicationFactor":"2",   "pullReplicas":"0",   
"router":{"name":"compositeId"},   

[jira] [Comment Edited] (SOLR-11823) Incorrect number of replica calculation when using Restore Collection API

[Ansgar Wiechers (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512383#comment-16512383
 ] 

Ansgar Wiechers edited comment on SOLR-11823 at 6/14/18 12:17 PM:
--

How would SOLR-11807 be a duplicate? I explicitly set maxShardsPerNode=2 for 
the restore, yet I get an error indicating that totalReplicasPerShard seems to 
be (incorrectly) calculated as replicationFactor * availableNodeCount. The 
restore works if I set replicationFactor=1 and maxShardsPerNode=2 for a 2-shard 
collection and 3 nodes (I then end up with 2 shards with 3 replicas per shard). 
For a 3-shard collection and a 3-node cluster I can successfully restore the 
backup with replicationFactor=1 and maxShardsPerNode=3 (producing 3 shards with 
3 replicas per shard).


was (Author: awiechers):
How would SOLR-11807 be a duplicate? I explicitly set maxShardsPerNode=2 for 
the restore, yet I get an error indicating that totalReplicasPerShard seems to 
be (incorrectly) calculated as replicationFactor * availableNodeCount. The 
restore works if I set replicationFactor=1 and maxShardsPerNode=2 for a 2-shard 
collection and 3 nodes (I then end up with 2 shards with 3 replicas per shard).

> Incorrect number of replica calculation when using Restore Collection API
> -
>
> Key: SOLR-11823
> URL: https://issues.apache.org/jira/browse/SOLR-11823
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 7.1
>Reporter: Ansgar Wiechers
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> I'm running Solr 7.1 (didn't test other versions) in SolrCloud mode ona a 
> 3-node cluster and tried using the backup/restore API for the first time. 
> Backup worked fine, but when trying to restore the backed-up collection I ran 
> into an unexpected problem with the replication factor setting.
> I expected the command below to restore a backup of the collection "demo" 
> with 3 shards, creating 2 replicas per shard. Instead it's trying to create 6 
> replicas per shard:
> {noformat}
> # curl -s -k 
> 'https://localhost:8983/solr/admin/collections?action=restore=demo=/srv/backup/solr/solr-dev=demo=2=2'
> {
>   "error": {
> "code": 400,
> "msg": "Solr cloud with available number of nodes:3 is insufficient for 
> restoring a collection with 3 shards, total replicas per shard 6 and 
> maxShardsPerNode 2. Consider increasing maxShardsPerNode value OR number 
> ofavailable nodes.",
> "metadata": [
>   "error-class",
>   "org.apache.solr.common.SolrException",
>   "root-error-class",
>   "org.apache.solr.common.SolrException"
> ]
>   },
>   "exception": {
> "rspCode": 400,
> "msg": "Solr cloud with available number of nodes:3 is insufficient for 
> restoring a collection with 3 shards, total replicas per shard 6 and 
> maxShardsPerNode 2. Consider increasing maxShardsPerNode value OR number of 
> available nodes."
>   },
>   "Operation restore caused exception:": 
> "org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
> Solr cloud with available number of nodes:3 is insufficient for restoring a 
> collection with 3 shards, total replicas per shard 6 and maxShardsPerNode 2. 
> Consider increasing maxShardsPerNode value OR number of available nodes.",
>   "responseHeader": {
> "QTime": 28,
> "status": 400
>   }
> }
> {noformat}
> Restoring a collection with only 2 shards tries to create 6 replicas as well, 
> so it looks to me like the restore API multiplies the replication factor with 
> the number of nodes, which is not how the replication factor behaves in other 
> contexts. The 
> [documentation|https://lucene.apache.org/solr/guide/7_1/collections-api.html] 
> also didn't lead me to expect this behavior:
> {quote}
> replicationFactor
>The number of replicas to be created for each shard.
> {quote}



--
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-11823) Incorrect number of replica calculation when using Restore Collection API

[Ansgar Wiechers (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512383#comment-16512383
 ] 

Ansgar Wiechers edited comment on SOLR-11823 at 6/14/18 12:15 PM:
--

How would SOLR-11807 be a duplicate? I explicitly set maxShardsPerNode=2 for 
the restore, yet I get an error indicating that totalReplicasPerShard seems to 
be (incorrectly) calculated as replicationFactor * availableNodeCount. The 
restore works if I set replicationFactor=1 and maxShardsPerNode=2 for a 2-shard 
collection and 3 nodes (I then end up with 2 shards with 3 replicas per shard).


was (Author: awiechers):
How would SOLR-11807 be a duplicate? I explicitly set maxShardsPerNode to 2 for 
the restore, yet I get an error indicating that totalReplicasPerShard seems to 
be (incorrectly) calculated as replicationFactor * availableNodeCount. The 
restore works if I set replicationFactor=1 and maxShardsPerNode=2 for a 2-shard 
collection and 3 nodes (I then end up with 2 shards with 3 replicas per shard).

> Incorrect number of replica calculation when using Restore Collection API
> -
>
> Key: SOLR-11823
> URL: https://issues.apache.org/jira/browse/SOLR-11823
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 7.1
>Reporter: Ansgar Wiechers
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> I'm running Solr 7.1 (didn't test other versions) in SolrCloud mode ona a 
> 3-node cluster and tried using the backup/restore API for the first time. 
> Backup worked fine, but when trying to restore the backed-up collection I ran 
> into an unexpected problem with the replication factor setting.
> I expected the command below to restore a backup of the collection "demo" 
> with 3 shards, creating 2 replicas per shard. Instead it's trying to create 6 
> replicas per shard:
> {noformat}
> # curl -s -k 
> 'https://localhost:8983/solr/admin/collections?action=restore=demo=/srv/backup/solr/solr-dev=demo=2=2'
> {
>   "error": {
> "code": 400,
> "msg": "Solr cloud with available number of nodes:3 is insufficient for 
> restoring a collection with 3 shards, total replicas per shard 6 and 
> maxShardsPerNode 2. Consider increasing maxShardsPerNode value OR number 
> ofavailable nodes.",
> "metadata": [
>   "error-class",
>   "org.apache.solr.common.SolrException",
>   "root-error-class",
>   "org.apache.solr.common.SolrException"
> ]
>   },
>   "exception": {
> "rspCode": 400,
> "msg": "Solr cloud with available number of nodes:3 is insufficient for 
> restoring a collection with 3 shards, total replicas per shard 6 and 
> maxShardsPerNode 2. Consider increasing maxShardsPerNode value OR number of 
> available nodes."
>   },
>   "Operation restore caused exception:": 
> "org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
> Solr cloud with available number of nodes:3 is insufficient for restoring a 
> collection with 3 shards, total replicas per shard 6 and maxShardsPerNode 2. 
> Consider increasing maxShardsPerNode value OR number of available nodes.",
>   "responseHeader": {
> "QTime": 28,
> "status": 400
>   }
> }
> {noformat}
> Restoring a collection with only 2 shards tries to create 6 replicas as well, 
> so it looks to me like the restore API multiplies the replication factor with 
> the number of nodes, which is not how the replication factor behaves in other 
> contexts. The 
> [documentation|https://lucene.apache.org/solr/guide/7_1/collections-api.html] 
> also didn't lead me to expect this behavior:
> {quote}
> replicationFactor
>The number of replicas to be created for each shard.
> {quote}



--
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-11823) Incorrect number of replica calculation when using Restore Collection API

[Ansgar Wiechers (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512383#comment-16512383
 ] 

Ansgar Wiechers commented on SOLR-11823:


How would SOLR-11807 be a duplicate? I explicitly set maxShardsPerNode to 2 for 
the restore, yet I get an error indicating that totalReplicasPerShard seems to 
be (incorrectly) calculated as replicationFactor * availableNodeCount. The 
restore works if I set replicationFactor=1 and maxShardsPerNode=2 for a 2-shard 
collection and 3 nodes (I then end up with 2 shards with 3 replicas per shard).

> Incorrect number of replica calculation when using Restore Collection API
> -
>
> Key: SOLR-11823
> URL: https://issues.apache.org/jira/browse/SOLR-11823
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 7.1
>Reporter: Ansgar Wiechers
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> I'm running Solr 7.1 (didn't test other versions) in SolrCloud mode ona a 
> 3-node cluster and tried using the backup/restore API for the first time. 
> Backup worked fine, but when trying to restore the backed-up collection I ran 
> into an unexpected problem with the replication factor setting.
> I expected the command below to restore a backup of the collection "demo" 
> with 3 shards, creating 2 replicas per shard. Instead it's trying to create 6 
> replicas per shard:
> {noformat}
> # curl -s -k 
> 'https://localhost:8983/solr/admin/collections?action=restore=demo=/srv/backup/solr/solr-dev=demo=2=2'
> {
>   "error": {
> "code": 400,
> "msg": "Solr cloud with available number of nodes:3 is insufficient for 
> restoring a collection with 3 shards, total replicas per shard 6 and 
> maxShardsPerNode 2. Consider increasing maxShardsPerNode value OR number 
> ofavailable nodes.",
> "metadata": [
>   "error-class",
>   "org.apache.solr.common.SolrException",
>   "root-error-class",
>   "org.apache.solr.common.SolrException"
> ]
>   },
>   "exception": {
> "rspCode": 400,
> "msg": "Solr cloud with available number of nodes:3 is insufficient for 
> restoring a collection with 3 shards, total replicas per shard 6 and 
> maxShardsPerNode 2. Consider increasing maxShardsPerNode value OR number of 
> available nodes."
>   },
>   "Operation restore caused exception:": 
> "org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
> Solr cloud with available number of nodes:3 is insufficient for restoring a 
> collection with 3 shards, total replicas per shard 6 and maxShardsPerNode 2. 
> Consider increasing maxShardsPerNode value OR number of available nodes.",
>   "responseHeader": {
> "QTime": 28,
> "status": 400
>   }
> }
> {noformat}
> Restoring a collection with only 2 shards tries to create 6 replicas as well, 
> so it looks to me like the restore API multiplies the replication factor with 
> the number of nodes, which is not how the replication factor behaves in other 
> contexts. The 
> [documentation|https://lucene.apache.org/solr/guide/7_1/collections-api.html] 
> also didn't lead me to expect this behavior:
> {quote}
> replicationFactor
>The number of replicas to be created for each shard.
> {quote}



--
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 #398: Lucene 8343 data type migration

[mikemccand]

Github user mikemccand commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/398#discussion_r195387148
  
--- Diff: 
lucene/suggest/src/java/org/apache/lucene/search/suggest/Lookup.java ---
@@ -53,7 +53,7 @@
 public final Object highlightKey;
 
 /** the key's weight */
-public final long value;
+public final double value;
--- End diff --

Maybe improve javadocs here, explaining that this is not just the weight 
originally supplied during indexing, for some suggesters?


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr pull request #398: Lucene 8343 data type migration

[mikemccand]

Github user mikemccand commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/398#discussion_r195386599
  
--- Diff: 
lucene/suggest/src/java/org/apache/lucene/search/suggest/InputIterator.java ---
@@ -34,7 +34,7 @@
 public interface InputIterator extends BytesRefIterator {
 
   /** A term's weight, higher numbers mean better suggestions. */
--- End diff --

Maybe add javadocs explaining what `null` means?  Though, why do we need to 
allow for `null`?  Shouldn't the iterator not return a suggestion that has no 
weight?


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-12488) Rewrite exists field value query to leverage DocValuesFieldExistsQuery and NormsFieldExistsQuery

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-12488:


 Summary: Rewrite exists field value query to leverage 
DocValuesFieldExistsQuery and NormsFieldExistsQuery
 Key: SOLR-12488
 URL: https://issues.apache.org/jira/browse/SOLR-12488
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: query parsers
Reporter: Varun Thacker


A few of us were discussing at Buzzwords on how a common use case requirement 
is "match documents which have values for a field"

To do this we need to query "-fq:brand:*" . This query can be slow and can be 
optimized

We can take advantage of NormsFieldExistsQuery and DocValuesFieldExistsQuery to 
speed up this use-case and not have to resort to WildcardQuery 

Today Solr's schema has doc-values enabled for fields that support it and for 
text fields norms are enabled by default so most users would already have the 
necessary indexed structures 



--
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-8357) Fix Explanations on FunctionScoreQuery.boostByQuery and boostByValue

[Markus Jelsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512310#comment-16512310
 ] 

Markus Jelsma commented on LUCENE-8357:
---

Thanks Alan!

> Fix Explanations on FunctionScoreQuery.boostByQuery and boostByValue
> 
>
> Key: LUCENE-8357
> URL: https://issues.apache.org/jira/browse/LUCENE-8357
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.3, 7.3.1
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: LUCENE-8357.patch
>
>
> As noted in SOLR-12414, the replacements for BoostingQuery and BoostedQuery 
> have truncated explanations.



--
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-9.0.4) - Build # 7357 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7357/
Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseParallelGC

32 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestSolrIndexConfig

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrIndexConfig_378A5C8E551B1844-001\init-core-data-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrIndexConfig_378A5C8E551B1844-001\init-core-data-001

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrIndexConfig_378A5C8E551B1844-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrIndexConfig_378A5C8E551B1844-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrIndexConfig_378A5C8E551B1844-001\init-core-data-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrIndexConfig_378A5C8E551B1844-001\init-core-data-001
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrIndexConfig_378A5C8E551B1844-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrIndexConfig_378A5C8E551B1844-001

at __randomizedtesting.SeedInfo.seed([378A5C8E551B1844]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:318)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
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.update.AddBlockUpdateTest.testExceptionThrownChildDocWAnonymousChildren

Error Message:


Stack Trace:
java.lang.NullPointerException
at 
__randomizedtesting.SeedInfo.seed([378A5C8E551B1844:1F3A2E8938F57407]:0)
at 
org.apache.solr.update.AddBlockUpdateTest.id(AddBlockUpdateTest.java:703)
at 
org.apache.solr.update.AddBlockUpdateTest.testExceptionThrownChildDocWAnonymousChildren(AddBlockUpdateTest.java:277)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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)
   

[jira] [Commented] (SOLR-12487) Possible corruption in tlog after restart of Solr

[Lars Gjestang (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512290#comment-16512290
 ] 

Lars Gjestang commented on SOLR-12487:
--

Hi Varun,

On this setup we have used 6.5.1 from the beginning.

> Possible corruption in tlog after restart of Solr
> -
>
> Key: SOLR-12487
> URL: https://issues.apache.org/jira/browse/SOLR-12487
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud, update
>Affects Versions: 6.5.1
> Environment: Windows server 2012
> 12 CPU
> 96GB RAM
> -DzkClientTimeout=45000-DzkRun
> --Xms16g-Xmx16g-Xss256k
>Reporter: Lars Gjestang
>Priority: Major
>
> After restarting Solr we encountered issues replaying tlogs from one of our 
> six shards. The other shards were up and running after a couple hours of 
> replay (due to total tlog of 20gb which we are going to change from "on 
> request" to maxDocs/maxTime). 
> The log first states warnings about "Unexpected log entry or corrupt log" and 
> then we get the following error message:
>  
> java.util.concurrent.ExecutionException: 
> org.apache.solr.common.SolrException: Unable to create core 
> [VCloud_shard1_replica1]
>  at java.util.concurrent.FutureTask.report(Unknown Source)
>  at java.util.concurrent.FutureTask.get(Unknown Source)
>  at org.apache.solr.core.CoreContainer.lambda$load$6(CoreContainer.java:581)
>  at 
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
>  at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
>  at java.util.concurrent.FutureTask.run(Unknown Source)
>  at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>  at java.lang.Thread.run(Unknown Source)
> Caused by: org.apache.solr.common.SolrException: Unable to create core 
> [VCloud_shard1_replica1]
>  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:933)
>  at org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:553)
>  at 
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
>  ... 5 more
> Caused by: org.apache.solr.common.SolrException: Error Instantiating Update 
> Handler, solr.DirectUpdateHandler2 failed to instantiate 
> org.apache.solr.update.UpdateHandler
>  at org.apache.solr.core.SolrCore.(SolrCore.java:965)
>  at org.apache.solr.core.SolrCore.(SolrCore.java:831)
>  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:918)
>  ... 7 more
> Caused by: org.apache.solr.common.SolrException: Error Instantiating Update 
> Handler, solr.DirectUpdateHandler2 failed to instantiate 
> org.apache.solr.update.UpdateHandler
>  at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:775)
>  at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:823)
>  at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1071)
>  at org.apache.solr.core.SolrCore.(SolrCore.java:936)
>  ... 9 more
> Caused by: java.lang.reflect.InvocationTargetException
>  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>  at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
>  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
>  at java.lang.reflect.Constructor.newInstance(Unknown Source)
>  at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:761)
>  ... 12 more
> Caused by: java.lang.StackOverflowError
>  at org.apache.solr.common.util.JavaBinCodec.readVInt(JavaBinCodec.java:998)
>  at org.apache.solr.common.util.JavaBinCodec.readMap(JavaBinCodec.java:612)
>  at org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:298)
> etc..
> ...
> After this happens it won't do any more work on this shard and the main page 
> in solr displays:
> "VCloud_shard1_replica1: 
> org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
> Error Instantiating Update Handler, solr.DirectUpdateHandler2 failed to 
> instantiate org.apache.solr.update.UpdateHandler"
>  
> Based on the execption and the huge repeating StackOverflowError we believe 
> the tlog is corrupt and missing e.g. an end tag. 
>  
>  



--
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-12487) Possible corruption in tlog after restart of Solr

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512279#comment-16512279
 ] 

Varun Thacker commented on SOLR-12487:
--

Hi Lars,

Have you always been on Solr 6.5.1 or did you upgrade recently ?

 

 

> Possible corruption in tlog after restart of Solr
> -
>
> Key: SOLR-12487
> URL: https://issues.apache.org/jira/browse/SOLR-12487
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud, update
>Affects Versions: 6.5.1
> Environment: Windows server 2012
> 12 CPU
> 96GB RAM
> -DzkClientTimeout=45000-DzkRun
> --Xms16g-Xmx16g-Xss256k
>Reporter: Lars Gjestang
>Priority: Major
>
> After restarting Solr we encountered issues replaying tlogs from one of our 
> six shards. The other shards were up and running after a couple hours of 
> replay (due to total tlog of 20gb which we are going to change from "on 
> request" to maxDocs/maxTime). 
> The log first states warnings about "Unexpected log entry or corrupt log" and 
> then we get the following error message:
>  
> java.util.concurrent.ExecutionException: 
> org.apache.solr.common.SolrException: Unable to create core 
> [VCloud_shard1_replica1]
>  at java.util.concurrent.FutureTask.report(Unknown Source)
>  at java.util.concurrent.FutureTask.get(Unknown Source)
>  at org.apache.solr.core.CoreContainer.lambda$load$6(CoreContainer.java:581)
>  at 
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
>  at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
>  at java.util.concurrent.FutureTask.run(Unknown Source)
>  at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>  at java.lang.Thread.run(Unknown Source)
> Caused by: org.apache.solr.common.SolrException: Unable to create core 
> [VCloud_shard1_replica1]
>  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:933)
>  at org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:553)
>  at 
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
>  ... 5 more
> Caused by: org.apache.solr.common.SolrException: Error Instantiating Update 
> Handler, solr.DirectUpdateHandler2 failed to instantiate 
> org.apache.solr.update.UpdateHandler
>  at org.apache.solr.core.SolrCore.(SolrCore.java:965)
>  at org.apache.solr.core.SolrCore.(SolrCore.java:831)
>  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:918)
>  ... 7 more
> Caused by: org.apache.solr.common.SolrException: Error Instantiating Update 
> Handler, solr.DirectUpdateHandler2 failed to instantiate 
> org.apache.solr.update.UpdateHandler
>  at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:775)
>  at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:823)
>  at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1071)
>  at org.apache.solr.core.SolrCore.(SolrCore.java:936)
>  ... 9 more
> Caused by: java.lang.reflect.InvocationTargetException
>  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>  at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
>  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
>  at java.lang.reflect.Constructor.newInstance(Unknown Source)
>  at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:761)
>  ... 12 more
> Caused by: java.lang.StackOverflowError
>  at org.apache.solr.common.util.JavaBinCodec.readVInt(JavaBinCodec.java:998)
>  at org.apache.solr.common.util.JavaBinCodec.readMap(JavaBinCodec.java:612)
>  at org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:298)
> etc..
> ...
> After this happens it won't do any more work on this shard and the main page 
> in solr displays:
> "VCloud_shard1_replica1: 
> org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
> Error Instantiating Update Handler, solr.DirectUpdateHandler2 failed to 
> instantiate org.apache.solr.update.UpdateHandler"
>  
> Based on the execption and the huge repeating StackOverflowError we believe 
> the tlog is corrupt and missing e.g. an end tag. 
>  
>  



--
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-8357) Fix Explanations on FunctionScoreQuery.boostByQuery and boostByValue

[Alan Woodward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Woodward resolved LUCENE-8357.
---
Resolution: Fixed

> Fix Explanations on FunctionScoreQuery.boostByQuery and boostByValue
> 
>
> Key: LUCENE-8357
> URL: https://issues.apache.org/jira/browse/LUCENE-8357
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.3, 7.3.1
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: LUCENE-8357.patch
>
>
> As noted in SOLR-12414, the replacements for BoostingQuery and BoostedQuery 
> have truncated explanations.



--
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-12487) Possible corruption in tlog after restart of Solr

[Lars Gjestang (JIRA)]

Lars Gjestang created SOLR-12487:


 Summary: Possible corruption in tlog after restart of Solr
 Key: SOLR-12487
 URL: https://issues.apache.org/jira/browse/SOLR-12487
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud, update
Affects Versions: 6.5.1
 Environment: Windows server 2012

12 CPU

96GB RAM

-DzkClientTimeout=45000-DzkRun
--Xms16g-Xmx16g-Xss256k
Reporter: Lars Gjestang


After restarting Solr we encountered issues replaying tlogs from one of our six 
shards. The other shards were up and running after a couple hours of replay 
(due to total tlog of 20gb which we are going to change from "on request" to 
maxDocs/maxTime). 

The log first states warnings about "Unexpected log entry or corrupt log" and 
then we get the following error message:

 

java.util.concurrent.ExecutionException: org.apache.solr.common.SolrException: 
Unable to create core [VCloud_shard1_replica1]
 at java.util.concurrent.FutureTask.report(Unknown Source)
 at java.util.concurrent.FutureTask.get(Unknown Source)
 at org.apache.solr.core.CoreContainer.lambda$load$6(CoreContainer.java:581)
 at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
 at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
 at java.util.concurrent.FutureTask.run(Unknown Source)
 at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.solr.common.SolrException: Unable to create core 
[VCloud_shard1_replica1]
 at org.apache.solr.core.CoreContainer.create(CoreContainer.java:933)
 at org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:553)
 at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
 ... 5 more
Caused by: org.apache.solr.common.SolrException: Error Instantiating Update 
Handler, solr.DirectUpdateHandler2 failed to instantiate 
org.apache.solr.update.UpdateHandler
 at org.apache.solr.core.SolrCore.(SolrCore.java:965)
 at org.apache.solr.core.SolrCore.(SolrCore.java:831)
 at org.apache.solr.core.CoreContainer.create(CoreContainer.java:918)
 ... 7 more
Caused by: org.apache.solr.common.SolrException: Error Instantiating Update 
Handler, solr.DirectUpdateHandler2 failed to instantiate 
org.apache.solr.update.UpdateHandler
 at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:775)
 at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:823)
 at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1071)
 at org.apache.solr.core.SolrCore.(SolrCore.java:936)
 ... 9 more
Caused by: java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
 at java.lang.reflect.Constructor.newInstance(Unknown Source)
 at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:761)
 ... 12 more
Caused by: java.lang.StackOverflowError
 at org.apache.solr.common.util.JavaBinCodec.readVInt(JavaBinCodec.java:998)
 at org.apache.solr.common.util.JavaBinCodec.readMap(JavaBinCodec.java:612)
 at org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:298)
etc..

...

After this happens it won't do any more work on this shard and the main page in 
solr displays:
"VCloud_shard1_replica1: 
org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
Error Instantiating Update Handler, solr.DirectUpdateHandler2 failed to 
instantiate org.apache.solr.update.UpdateHandler"

 

Based on the execption and the huge repeating StackOverflowError we believe the 
tlog is corrupt and missing e.g. an end tag. 

 

 



--
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-12407) edismax boost performance regression from switch to FunctionScoreQuery

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512227#comment-16512227
 ] 

Alan Woodward commented on SOLR-12407:
--

I'll work up a patch, but I'd like to get [~hossman]'s opinion on this, as he 
knows more about how ValueSources are used in Solr than I do.

And don't worry about pinging me, I can always ignore emails if need be :)

> edismax boost performance regression from switch to FunctionScoreQuery
> --
>
> Key: SOLR-12407
> URL: https://issues.apache.org/jira/browse/SOLR-12407
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Will Currie
>Priority: Minor
> Attachments: restore-boosted-query.patch, solr-7.2.svg, solr-7.3.svg
>
>
> Assertion: FunctionScoreQuery uses the iterator style API (advanceExact + 
> doubleValue). BoostedQuery uses the "old" api (just a single call to 
> doubleValue). In an edismax boost this means the boost function is called 
> twice for every document being scored in 7.3 instead of once in 7.2.
> I'm seeing ~50% increase in query response time after upgrading from 7.2 to 
> 7.3 (600ms to 900ms). My queries use an edismax boost something like:
> {noformat}
> if(termfreq(type,"A"),product(map(field1,3,3,1.5,1),map(field1,4,4,1.9,1),if(def(field2,false),product(map(field1,1,1,0.6,1),map(field1,2,2,0.7,1),if(not(exists(field1)),0.6,1),map(field3,0,0,1.3,1)),product(map(field1,1,1,0.7,1),map(field1,2,2,1.1,1),if(not(exists(field1)),0.90,1),map(field3,0,0,1.50,1,1){noformat}
> This boost is likely (surely?) suboptimal but LUCENE-8099 appears to have 
> introduced this performance regression (poured proverbial oil on my 
> smouldering fire). If I change ExtendedDismaxQParser back to using the 
> deprecated BoostedQuery I get the 600ms solr 7.2 response time back.
> It appears FunctionScoreQuery invokes the boost function twice for each 
> document. Once with a call to 
> [exists()|https://github.com/apache/lucene-solr/blob/03afeb7766a39996de3c85e8a6ab24d2a352dd1c/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java#L150]
>  from 
> [advanceExact()|https://github.com/apache/lucene-solr/blob/42154387d4f2a6060da09c4236e2a8dbb575c59e/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionScoreQuery.java#L170],
>  then a second time from the call chain following scores.doubleValue().
> I don't know if that's the cause of the slowdown but I'm definitely seeing a 
> slowdown that disappears when I revert part of LUCENE-8099.
> I've attached some flamegraphs comparing 7.2 and 7.3. The frame 
> FunctionScoreQuery$FunctionScoreWeight$1.score in solr-7.3.svg show 2 
> "towers". One for advanceExact (calling exists()), the other for 
> doubleValue() which ends up similar to solr-7.2.svg.



--
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-12407) edismax boost performance regression from switch to FunctionScoreQuery

[Will Currie (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512217#comment-16512217
 ] 

Will Currie commented on SOLR-12407:


Thanks for taking a look! I was reluctant to ping you directly, thinking maybe 
this was too much of an edge case. 



Would it be too risky/rushed to sneak that change into 7.4? From the mailing 
list there's been quite a few "can we wait for X?" requests in 7.4 already.

> edismax boost performance regression from switch to FunctionScoreQuery
> --
>
> Key: SOLR-12407
> URL: https://issues.apache.org/jira/browse/SOLR-12407
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Will Currie
>Priority: Minor
> Attachments: restore-boosted-query.patch, solr-7.2.svg, solr-7.3.svg
>
>
> Assertion: FunctionScoreQuery uses the iterator style API (advanceExact + 
> doubleValue). BoostedQuery uses the "old" api (just a single call to 
> doubleValue). In an edismax boost this means the boost function is called 
> twice for every document being scored in 7.3 instead of once in 7.2.
> I'm seeing ~50% increase in query response time after upgrading from 7.2 to 
> 7.3 (600ms to 900ms). My queries use an edismax boost something like:
> {noformat}
> if(termfreq(type,"A"),product(map(field1,3,3,1.5,1),map(field1,4,4,1.9,1),if(def(field2,false),product(map(field1,1,1,0.6,1),map(field1,2,2,0.7,1),if(not(exists(field1)),0.6,1),map(field3,0,0,1.3,1)),product(map(field1,1,1,0.7,1),map(field1,2,2,1.1,1),if(not(exists(field1)),0.90,1),map(field3,0,0,1.50,1,1){noformat}
> This boost is likely (surely?) suboptimal but LUCENE-8099 appears to have 
> introduced this performance regression (poured proverbial oil on my 
> smouldering fire). If I change ExtendedDismaxQParser back to using the 
> deprecated BoostedQuery I get the 600ms solr 7.2 response time back.
> It appears FunctionScoreQuery invokes the boost function twice for each 
> document. Once with a call to 
> [exists()|https://github.com/apache/lucene-solr/blob/03afeb7766a39996de3c85e8a6ab24d2a352dd1c/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java#L150]
>  from 
> [advanceExact()|https://github.com/apache/lucene-solr/blob/42154387d4f2a6060da09c4236e2a8dbb575c59e/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionScoreQuery.java#L170],
>  then a second time from the call chain following scores.doubleValue().
> I don't know if that's the cause of the slowdown but I'm definitely seeing a 
> slowdown that disappears when I revert part of LUCENE-8099.
> I've attached some flamegraphs comparing 7.2 and 7.3. The frame 
> FunctionScoreQuery$FunctionScoreWeight$1.score in solr-7.3.svg show 2 
> "towers". One for advanceExact (calling exists()), the other for 
> doubleValue() which ends up similar to solr-7.2.svg.



--
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-Solaris (64bit/jdk1.8.0) - Build # 665 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/665/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

11 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testTrigger

Error Message:
should have fired an event

Stack Trace:
java.lang.AssertionError: should have fired an event
at 
__randomizedtesting.SeedInfo.seed([540850587A1D409F:37C366DAE3D233B2]: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.autoscaling.IndexSizeTriggerTest.testTrigger(IndexSizeTriggerTest.java:184)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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.IndexSizeTriggerTest.testMixedBounds

Error Message:
failed to create testMixedBounds_collection Live Nodes: [127.0.0.1:10001_solr, 
127.0.0.1:1_solr] Last available state: 

Re: Lucene/Solr 7.4

[Adrien Grand]

+1

Le jeu. 14 juin 2018 à 10:02, Alan Woodward  a écrit :

> Hi Adrien,
>
> If possible I’d like to get LUCENE-8357 in, which fixes a regression in
> Explanations for Solr’s boost queries.
>
> Alan
>
>
> On 13 Jun 2018, at 20:42, Adrien Grand  wrote:
>
> It is. In general I trust your judgement to only backport low-risk fixes.
>
> Le mer. 13 juin 2018 à 21:03, Steve Rowe  a écrit :
>
>> Crap, I forgot to ask for inclusion of SOLR-12481, a doc-only fix related
>> to SOLR-12434.  I’m going to assume that it’s okay to backport as well,
>> I’ll go do that now.  Sorry for the churn.
>>
>> --
>> Steve
>> www.lucidworks.com
>>
>> > On Jun 13, 2018, at 1:49 PM, Steve Rowe  wrote:
>> >
>> > Thanks, done.
>> >
>> > --
>> > Steve
>> > www.lucidworks.com
>> >
>> >> On Jun 13, 2018, at 1:08 PM, Adrien Grand  wrote:
>> >>
>> >> OK to backport SOLR-12434.
>> >>
>> >> Le mer. 13 juin 2018 à 18:41, Steve Rowe  a écrit :
>> >> Adrien,
>> >>
>> >> Are you okay with backporting SOLR-12434 to 7.4?
>> >>
>> >> --
>> >> Steve
>> >> www.lucidworks.com
>> >>
>> >>> On Jun 12, 2018, at 9:37 AM, Steve Rowe  wrote:
>> >>>
>> >>> Done, thanks Adrien.
>> >>>
>> >>> --
>> >>> Steve
>> >>> www.lucidworks.com
>> >>>
>>  On Jun 12, 2018, at 9:23 AM, Adrien Grand  wrote:
>> 
>>  +1 to backport LUCENE-8278 to 7.4. Thanks Steve.
>> 
>>  Le lun. 11 juin 2018 à 23:21, Steve Rowe  a écrit
>> :
>>  Adrien,
>> 
>>  Are you okay with including the fix on LUCENE-8278 in 7.4?
>> 
>>  --
>>  Steve
>>  www.lucidworks.com
>> 
>> > On Jun 11, 2018, at 11:24 AM, Adrien Grand 
>> wrote:
>> >
>> > No worries Uwe, we'll wait. Enjoy Buzzwords!
>> >
>> > Le lun. 11 juin 2018 à 17:08, Uwe Schindler  a
>> écrit :
>> > I still have this new security issue and to fix it finally
>> everywhere, it requires API changes. So please wait, I am working but
>> buzzwords is so interesting! 勞
>> >
>> > Uwe
>> >
>> >
>> > Am June 11, 2018 2:45:54 PM UTC schrieb David Smiley <
>> david.w.smi...@gmail.com>:
>> > It'd be nice to get in this bug
>> https://issues.apache.org/jira/browse/LUCENE-8344 but is pending a
>> review.
>> >
>> > On Tue, Jun 5, 2018 at 4:24 AM Adrien Grand 
>> wrote:
>> > Hi all,
>> >
>> > We released 7.3 two months ago on April 4th and we accumulated
>> quite a number of features, enhancements and fixes that are not released
>> yet, so I'd like to start working on releasing Lucene/Solr 7.4.0.
>> >
>> > I propose to create the 7.4 branch later this week and build the
>> first RC early next week if that works for everyone. Please let me know if
>> that are bug fixes that we think should make it to 7
>> .4
>> and might not be ready by then.
>> >
>> > Adrien
>> > --
>> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>> >
>> > --
>> > Uwe Schindler
>> > Achterdiek 19, 28357 Bremen
>> 
>> > https://www.thetaphi.de
>> 
>> 
>>  -
>>  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>  For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
>> >>>
>> >>
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>

[jira] [Commented] (SOLR-12407) edismax boost performance regression from switch to FunctionScoreQuery

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512146#comment-16512146
 ] 

Alan Woodward commented on SOLR-12407:
--

I'd missed this, sorry for not picking it up earlier.

It looks as though BoostedQuery just assumed that all docs had a value, so 
avoided the exists check.  I'm not entirely sure that's a safe assumption, but 
from looking at a few ValueSource implementations it does seem that they have 
default return values and so the exists check isn't actually necessary.  So the 
best solution is I think to remove the exists call from 
ValueSource.WrappedDoubleValuesSource and always return true from advanceExact()

> edismax boost performance regression from switch to FunctionScoreQuery
> --
>
> Key: SOLR-12407
> URL: https://issues.apache.org/jira/browse/SOLR-12407
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Will Currie
>Priority: Minor
> Attachments: restore-boosted-query.patch, solr-7.2.svg, solr-7.3.svg
>
>
> Assertion: FunctionScoreQuery uses the iterator style API (advanceExact + 
> doubleValue). BoostedQuery uses the "old" api (just a single call to 
> doubleValue). In an edismax boost this means the boost function is called 
> twice for every document being scored in 7.3 instead of once in 7.2.
> I'm seeing ~50% increase in query response time after upgrading from 7.2 to 
> 7.3 (600ms to 900ms). My queries use an edismax boost something like:
> {noformat}
> if(termfreq(type,"A"),product(map(field1,3,3,1.5,1),map(field1,4,4,1.9,1),if(def(field2,false),product(map(field1,1,1,0.6,1),map(field1,2,2,0.7,1),if(not(exists(field1)),0.6,1),map(field3,0,0,1.3,1)),product(map(field1,1,1,0.7,1),map(field1,2,2,1.1,1),if(not(exists(field1)),0.90,1),map(field3,0,0,1.50,1,1){noformat}
> This boost is likely (surely?) suboptimal but LUCENE-8099 appears to have 
> introduced this performance regression (poured proverbial oil on my 
> smouldering fire). If I change ExtendedDismaxQParser back to using the 
> deprecated BoostedQuery I get the 600ms solr 7.2 response time back.
> It appears FunctionScoreQuery invokes the boost function twice for each 
> document. Once with a call to 
> [exists()|https://github.com/apache/lucene-solr/blob/03afeb7766a39996de3c85e8a6ab24d2a352dd1c/lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java#L150]
>  from 
> [advanceExact()|https://github.com/apache/lucene-solr/blob/42154387d4f2a6060da09c4236e2a8dbb575c59e/lucene/queries/src/java/org/apache/lucene/queries/function/FunctionScoreQuery.java#L170],
>  then a second time from the call chain following scores.doubleValue().
> I don't know if that's the cause of the slowdown but I'm definitely seeing a 
> slowdown that disappears when I revert part of LUCENE-8099.
> I've attached some flamegraphs comparing 7.2 and 7.3. The frame 
> FunctionScoreQuery$FunctionScoreWeight$1.score in solr-7.3.svg show 2 
> "towers". One for advanceExact (calling exists()), the other for 
> doubleValue() which ends up similar to solr-7.2.svg.



--
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-12414) FunctionScoreQuery no longer displays debug output

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512130#comment-16512130
 ] 

Alan Woodward commented on SOLR-12414:
--

I opened LUCENE-8357

> FunctionScoreQuery no longer displays debug output
> --
>
> Key: SOLR-12414
> URL: https://issues.apache.org/jira/browse/SOLR-12414
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3, 7.3.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> I have two documents:
> {code}
> {"text":"some text", "lang":"cn"}
> {"text":"more text", "lang":"en"}
> {code}
> And the following query, a simple edismax with a boost on lang:en:
> {code}http://localhost:8983/solr/test/select?wt=xml=text=edismax=text=true=if(exists(query($bqlang)),2,1)=lang:en
> {code}
> The parsedQuery is now slightly different because of it being wrapped in a 
> FunctionScoreQuery. The problem is the explain for the document, which is:
> {code}
> 0.3971361 = product of:
>   1.0 = boost
>   0.3971361 = boost(if(exists(query(lang:en,def=0.0)),const(2),const(1)))
> {code}
> Which is now unreadable for complicated queries with many clauses. It should 
> resemble the output of 7.2, which was:
> {code}
> 0.36464313 = 
> boost(text:text,if(exists(query(lang:en,def=0.0)),const(2),const(1))), 
> product of:
>   0.18232156 = weight(text:text in 0) [SchemaSimilarity], result of:
> 0.18232156 = score(doc=0,freq=1.0 = termFreq=1.0
> ), product of:
>   0.18232156 = idf, computed as log(1 + (docCount - docFreq + 0.5) / 
> (docFreq + 0.5)) from:
> 2.0 = docFreq
> 2.0 = docCount
>   1.0 = tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b * 
> fieldLength / avgFieldLength)) from:
> 1.0 = termFreq=1.0
> 1.2 = parameter k1
> 0.75 = parameter b
> 2.0 = avgFieldLength
> 2.0 = fieldLength
>   2.0 = if(exists(query(lang:en,def=0.0)=0.6931472),const(2),const(1))
> {code}
> This bug was introduced in Solr/Lucene 7.3.
> Mailing list reference: 
> http://lucene.472066.n3.nabble.com/Solr-7-3-FunctionScoreQuery-no-longer-displays-debug-output-td4389093.html



--
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.4

[Alan Woodward]

Hi Adrien,

If possible I’d like to get LUCENE-8357 in, which fixes a regression in 
Explanations for Solr’s boost queries.

Alan

> On 13 Jun 2018, at 20:42, Adrien Grand  > wrote:
> 
> It is. In general I trust your judgement to only backport low-risk fixes.
> 
> Le mer. 13 juin 2018 à 21:03, Steve Rowe  > a écrit :
> Crap, I forgot to ask for inclusion of SOLR-12481, a doc-only fix related to 
> SOLR-12434.  I’m going to assume that it’s okay to backport as well, I’ll go 
> do that now.  Sorry for the churn.
> 
> --
> Steve
> www.lucidworks.com 
> 
> > On Jun 13, 2018, at 1:49 PM, Steve Rowe  > > wrote:
> > 
> > Thanks, done.
> > 
> > --
> > Steve
> > www.lucidworks.com 
> > 
> >> On Jun 13, 2018, at 1:08 PM, Adrien Grand  >> > wrote:
> >> 
> >> OK to backport SOLR-12434.
> >> 
> >> Le mer. 13 juin 2018 à 18:41, Steve Rowe  >> > a écrit :
> >> Adrien,
> >> 
> >> Are you okay with backporting SOLR-12434 to 7.4?
> >> 
> >> --
> >> Steve
> >> www.lucidworks.com 
> >> 
> >>> On Jun 12, 2018, at 9:37 AM, Steve Rowe  >>> > wrote:
> >>> 
> >>> Done, thanks Adrien.
> >>> 
> >>> --
> >>> Steve
> >>> www.lucidworks.com 
> >>> 
>  On Jun 12, 2018, at 9:23 AM, Adrien Grand   > wrote:
>  
>  +1 to backport LUCENE-8278 to 7.4. Thanks Steve.
>  
>  Le lun. 11 juin 2018 à 23:21, Steve Rowe   > a écrit :
>  Adrien,
>  
>  Are you okay with including the fix on LUCENE-8278 in 7.4?
>  
>  --
>  Steve
>  www.lucidworks.com 
>  
> > On Jun 11, 2018, at 11:24 AM, Adrien Grand  > > wrote:
> > 
> > No worries Uwe, we'll wait. Enjoy Buzzwords!
> > 
> > Le lun. 11 juin 2018 à 17:08, Uwe Schindler  > > a écrit :
> > I still have this new security issue and to fix it finally everywhere, 
> > it requires API changes. So please wait, I am working but buzzwords is 
> > so interesting! 勞
> > 
> > Uwe
> > 
> > 
> > Am June 11, 2018 2:45:54 PM UTC schrieb David Smiley 
> > mailto:david.w.smi...@gmail.com>>:
> > It'd be nice to get in this bug 
> > https://issues.apache.org/jira/browse/LUCENE-8344 
> >  but is pending a 
> > review.
> > 
> > On Tue, Jun 5, 2018 at 4:24 AM Adrien Grand  > > wrote:
> > Hi all,
> > 
> > We released 7.3 two months ago on April 4th and we accumulated quite a 
> > number of features, enhancements and fixes that are not released yet, 
> > so I'd like to start working on releasing Lucene/Solr 7.4.0.
> > 
> > I propose to create the 7.4 branch later this week and build the first 
> > RC early next week if that works for everyone. Please let me know if 
> > that are bug fixes that we think should make it to 7 
> > .4
> >  and might not be ready by then.
> > 
> > Adrien
> > -- 
> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> > LinkedIn: http://linkedin.com/in/davidwsmiley 
> >  | Book: 
> > http://www.solrenterprisesearchserver.com 
> > 
> > 
> > --
> > Uwe Schindler
> > Achterdiek 19, 28357 Bremen
> > https://www.thetaphi.de 
>  
>  
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>  
>  For additional commands, e-mail: dev-h...@lucene.apache.org 
>  
>  
> >>> 
> >> 
> > 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 

[jira] [Commented] (LUCENE-8357) Fix Explanations on FunctionScoreQuery.boostByQuery and boostByValue

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512122#comment-16512122
 ] 

Alan Woodward commented on LUCENE-8357:
---

Patch fixing the issue.

> Fix Explanations on FunctionScoreQuery.boostByQuery and boostByValue
> 
>
> Key: LUCENE-8357
> URL: https://issues.apache.org/jira/browse/LUCENE-8357
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.3, 7.3.1
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: LUCENE-8357.patch
>
>
> As noted in SOLR-12414, the replacements for BoostingQuery and BoostedQuery 
> have truncated explanations.



--
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-8357) Fix Explanations on FunctionScoreQuery.boostByQuery and boostByValue

[Alan Woodward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Woodward updated LUCENE-8357:
--
Attachment: LUCENE-8357.patch

> Fix Explanations on FunctionScoreQuery.boostByQuery and boostByValue
> 
>
> Key: LUCENE-8357
> URL: https://issues.apache.org/jira/browse/LUCENE-8357
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.3, 7.3.1
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: LUCENE-8357.patch
>
>
> As noted in SOLR-12414, the replacements for BoostingQuery and BoostedQuery 
> have truncated explanations.



--
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-SmokeRelease-master - Build # 1046 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1046/

No tests ran.

Build Log:
[...truncated 24157 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 2227 links (1776 relative) to 3120 anchors in 247 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes

-dist-keys:
  [get] Getting: http://home.apache.org/keys/group/lucene.asc
  [get] To: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/KEYS

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-8.0.0.tgz
 into 
/home/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 = 
/home/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 = 
/home/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 = 
/home/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 = 
/home/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 = 
/home/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 = 
/home/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 = 
/home/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 = 
/home/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 = 
/home/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 = 
/home/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 = 

[jira] [Created] (SOLR-12486) Fix Explanations on FunctionScoreQuery.boostByQuery and boostByValue

[Alan Woodward (JIRA)]

Alan Woodward created SOLR-12486:


 Summary: Fix Explanations on FunctionScoreQuery.boostByQuery and 
boostByValue
 Key: SOLR-12486
 URL: https://issues.apache.org/jira/browse/SOLR-12486
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.3.1, 7.3
Reporter: Alan Woodward
Assignee: Alan Woodward
 Fix For: 7.4, master (8.0)


As noted in SOLR-12414, the replacements for BoostingQuery and BoostedQuery 
have truncated explanations.



--
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] [Moved] (LUCENE-8357) Fix Explanations on FunctionScoreQuery.boostByQuery and boostByValue

[Alan Woodward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Woodward moved SOLR-12486 to LUCENE-8357:
--

Fix Version/s: (was: 7.4)
   (was: master (8.0))
   master (8.0)
   7.4
Affects Version/s: (was: 7.3.1)
   (was: 7.3)
   7.3
   7.3.1
 Security: (was: Public)
Lucene Fields: New
   Issue Type: Bug  (was: New Feature)
  Key: LUCENE-8357  (was: SOLR-12486)
  Project: Lucene - Core  (was: Solr)

> Fix Explanations on FunctionScoreQuery.boostByQuery and boostByValue
> 
>
> Key: LUCENE-8357
> URL: https://issues.apache.org/jira/browse/LUCENE-8357
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.3.1, 7.3
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> As noted in SOLR-12414, the replacements for BoostingQuery and BoostedQuery 
> have truncated explanations.



--
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-Solaris (64bit/jdk1.8.0) - Build # 1909 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1909/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

12 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMixedBounds

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([957D4A6B6975BB08:9FFEF5C624CEB052]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMixedBounds(IndexSizeTriggerTest.java:567)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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.IndexSizeTriggerTest.testMixedBounds

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 

[JENKINS] Lucene-Solr-BadApples-7.x-Linux (64bit/jdk-10.0.1) - Build # 50 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-7.x-Linux/50/
Java: 64bit/jdk-10.0.1 -XX:+UseCompressedOops -XX:+UseSerialGC

6 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testTrigger

Error Message:
number of ops expected:<2> but was:<1>

Stack Trace:
java.lang.AssertionError: number of ops expected:<2> but was:<1>
at 
__randomizedtesting.SeedInfo.seed([E80481B2FD54029C:8BCFB730649B71B1]: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.autoscaling.IndexSizeTriggerTest.testTrigger(IndexSizeTriggerTest.java:187)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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.IndexSizeTriggerTest.testSplitIntegration

Error Message:
last state: 

[jira] [Updated] (SOLR-12485) Xml loader should save the relationship of children

[mosh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mosh updated SOLR-12485:

Description: Once SolrInputDocument supports labeled child documents, 
XmlLoader should add the child document to the map while saving its key name, 
to maintain the child's relationship to its parent.  (was: Once _childDocuments 
in SolrInputDocument is changed to a Map, XmlLoader should add the child 
document to the map while saving its key name, to maintain the child's 
relationship to its parent.)

> Xml loader should save the relationship of children
> ---
>
> Key: SOLR-12485
> URL: https://issues.apache.org/jira/browse/SOLR-12485
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Major
>
> Once SolrInputDocument supports labeled child documents, XmlLoader should add 
> the child document to the map while saving its key name, to maintain the 
> child's relationship to its parent.



--
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