[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-10-ea+37) - Build # 21216 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21216/
Java: 64bit/jdk-10-ea+37 -XX:+UseCompressedOops -XX:+UseSerialGC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.io.stream.SelectWithEvaluatorsTest

Error Message:
Error from server at https://127.0.0.1:34537/solr: create the collection time 
out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:34537/solr: create the collection time out:180s
at __randomizedtesting.SeedInfo.seed([473D36A74765BC5A]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.io.stream.SelectWithEvaluatorsTest.setupCluster(SelectWithEvaluatorsTest.java:71)
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$6.evaluate(RandomizedRunner.java:874)
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.sim.TestComputePlanAction.testNodeLost

Error Message:


Stack Trace:
java.util.ConcurrentModificationException
at 
__randomizedtesting.SeedInfo.seed([A41248828EFF34E3:1B07867C0D155165]:0)
at 
java.base/java.util.ArrayList$Itr.checkForComodification(ArrayList.java:937)
at java.base/java.util.ArrayList$Itr.next(ArrayList.java:891)
at 
org.apache.solr.cloud.autoscaling.sim.SimSolrCloudTestCase.tearDown(SimSolrCloudTestCase.java:141)
at jdk.internal.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 

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

[Policeman Jenkins Server]

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

6 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.analysis.snowball.TestSnowballVocab

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\common\test\J0\temp\lucene.analysis.snowball.TestSnowballVocab_65EFBF6AA4A4059F-001\tempDir-017:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\common\test\J0\temp\lucene.analysis.snowball.TestSnowballVocab_65EFBF6AA4A4059F-001\tempDir-017
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\common\test\J0\temp\lucene.analysis.snowball.TestSnowballVocab_65EFBF6AA4A4059F-001\tempDir-017:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\common\test\J0\temp\lucene.analysis.snowball.TestSnowballVocab_65EFBF6AA4A4059F-001\tempDir-017

at __randomizedtesting.SeedInfo.seed([65EFBF6AA4A4059F]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
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.lang.Thread.run(Thread.java:748)


FAILED:  junit.framework.TestSuite.org.apache.lucene.store.TestRAFDirectory

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\misc\test\J0\temp\lucene.store.TestRAFDirectory_252CB0D0D0AE7A03-001\testThreadSafety-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\misc\test\J0\temp\lucene.store.TestRAFDirectory_252CB0D0D0AE7A03-001\testThreadSafety-001

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\misc\test\J0\temp\lucene.store.TestRAFDirectory_252CB0D0D0AE7A03-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\misc\test\J0\temp\lucene.store.TestRAFDirectory_252CB0D0D0AE7A03-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\lucene\build\misc\test\J0\temp\lucene.store.TestRAFDirectory_252CB0D0D0AE7A03-001\testThreadSafety-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\misc\test\J0\temp\lucene.store.TestRAFDirectory_252CB0D0D0AE7A03-001\testThreadSafety-001
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\misc\test\J0\temp\lucene.store.TestRAFDirectory_252CB0D0D0AE7A03-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\misc\test\J0\temp\lucene.store.TestRAFDirectory_252CB0D0D0AE7A03-001

at __randomizedtesting.SeedInfo.seed([252CB0D0D0AE7A03]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
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 

[jira] [Created] (LUCENE-8118) ArrayIndexOutOfBoundsException in TermsHashPerField.writeByte during indexing

[Laura Dietz (JIRA)]

Laura Dietz created LUCENE-8118:
---

 Summary: ArrayIndexOutOfBoundsException in 
TermsHashPerField.writeByte during indexing
 Key: LUCENE-8118
 URL: https://issues.apache.org/jira/browse/LUCENE-8118
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Affects Versions: 7.2
 Environment: Debian/Stretch
java version "1.8.0_144"

   Java(TM) SE Runtime Environment 
(build 1.8.0_144-b01)   

   Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
Reporter: Laura Dietz


Indexing a large collection of about 20 million paragraph-sized documents 
results in an ArrayIndexOutOfBoundsException in 
org.apache.lucene.index.TermsHashPerField.writeByte  (full stack trace below). 


The bug is possibly related to issues described in 
[here|http://lucene.472066.n3.nabble.com/ArrayIndexOutOfBoundsException-65536-td3661945.html]
  and [SOLR-10936|https://issues.apache.org/jira/browse/SOLR-10936] -- but I am 
not using SOLR, I am directly using Lucene Core.

The issue can be reproduced using code from  [GitHub 
trec-car-tools-example|https://github.com/TREMA-UNH/trec-car-tools/tree/lucene-bug/trec-car-tools-example]
 

- compile with `mvn compile assembly:single`
- run with `java -cp 
./target/treccar-tools-example-0.1-jar-with-dependencies.jar 
edu.unh.cs.TrecCarBuildLuceneIndex paragraphs paragraphCorpus.cbor indexDir`

Where paragraphCorpus.cbor is contained in this 
[archive|http://trec-car.cs.unh.edu/datareleases/v2.0-snapshot/archive-paragraphCorpus.tar.xz]



Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -65536 
  at 
org.apache.lucene.index.TermsHashPerField.writeByte(TermsHashPerField.java:198) 

at 
org.apache.lucene.index.TermsHashPerField.writeVInt(TermsHashPerField.java:224) 

at 
org.apache.lucene.index.FreqProxTermsWriterPerField.addTerm(FreqProxTermsWriterPerField.java:159)

   at 
org.apache.lucene.index.TermsHashPerField.add(TermsHashPerField.java:185)   

at 
org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:786)

 at 
org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:430)

at 
org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:392)

 at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocuments(DocumentsWriterPerThread.java:281)

 at 
org.apache.lucene.index.DocumentsWriter.updateDocuments(DocumentsWriter.java:451)

   at 
org.apache.lucene.index.IndexWriter.updateDocuments(IndexWriter.java:1532)  

at 
org.apache.lucene.index.IndexWriter.addDocuments(IndexWriter.java:1508)
at 
edu.unh.cs.TrecCarBuildLuceneIndex.main(TrecCarBuildLuceneIndex.java:55)




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_144) - Build # 1121 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1121/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseSerialGC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.analytics.legacy.facet.LegacyRangeFacetCloudTest

Error Message:
org.apache.http.ParseException: Invalid content type: 

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.http.ParseException: Invalid content type: 
at __randomizedtesting.SeedInfo.seed([C6F3853D14E2CEEA]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:523)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.analytics.legacy.LegacyAbstractAnalyticsCloudTest.setupCollection(LegacyAbstractAnalyticsCloudTest.java:50)
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$6.evaluate(RandomizedRunner.java:874)
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)
Caused by: org.apache.http.ParseException: Invalid content type: 
at org.apache.http.entity.ContentType.parse(ContentType.java:298)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:591)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
... 31 more


FAILED:  
org.apache.solr.cloud.DeleteStatusTest.testProcessAndWaitDeletesAsyncIds

Error Message:
expected same: was not:

Stack Trace:
java.lang.AssertionError: expected same: was not:
at 
__randomizedtesting.SeedInfo.seed([F69AA11A086D076C:CD84DB345D5C0ECB]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotSame(Assert.java:641)
at org.junit.Assert.assertSame(Assert.java:580)
at org.junit.Assert.assertSame(Assert.java:593)
at 
org.apache.solr.cloud.DeleteStatusTest.testProcessAndWaitDeletesAsyncIds(DeleteStatusTest.java:96)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test

Error Message:
Expected 2 of 3 replicas to be active but only found 1; 
[core_node4:{"core":"c8n_1x3_lf_shard1_replica_n1","base_url":"http://127.0.0.1:43438","node_name":"127.0.0.1:43438_","state":"active","type":"NRT","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf//clusterstate.json/27)={   
"pullReplicas":"0",   "replicationFactor":"1",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node4":{   "core":"c8n_1x3_lf_shard1_replica_n1",   
"base_url":"http://127.0.0.1:43438;,   "node_name":"127.0.0.1:43438_",  
 "state":"active",   "type":"NRT",   "leader":"true"},  
   "core_node5":{   "core":"c8n_1x3_lf_shard1_replica_n2",  
 "base_url":"http://127.0.0.1:45981;,   "node_name":"127.0.0.1:45981_", 
  "state":"down",   "type":"NRT"}, "core_node6":{   
"state":"down",   "base_url":"http://127.0.0.1:33388;,   
"core":"c8n_1x3_lf_shard1_replica_n3",   
"node_name":"127.0.0.1:33388_",   "type":"NRT",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"1",   
"autoAddReplicas":"false",   "nrtReplicas":"3",   "tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node4:{"core":"c8n_1x3_lf_shard1_replica_n1","base_url":"http://127.0.0.1:43438","node_name":"127.0.0.1:43438_","state":"active","type":"NRT","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf//clusterstate.json/27)={
  "pullReplicas":"0",
  "replicationFactor":"1",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node4":{
  "core":"c8n_1x3_lf_shard1_replica_n1",
  "base_url":"http://127.0.0.1:43438;,
  "node_name":"127.0.0.1:43438_",
  "state":"active",
  "type":"NRT",
  "leader":"true"},
"core_node5":{
  "core":"c8n_1x3_lf_shard1_replica_n2",
  "base_url":"http://127.0.0.1:45981;,
  "node_name":"127.0.0.1:45981_",
  "state":"down",
  "type":"NRT"},
"core_node6":{
  "state":"down",
  "base_url":"http://127.0.0.1:33388;,
  "core":"c8n_1x3_lf_shard1_replica_n3",
  "node_name":"127.0.0.1:33388_",
  "type":"NRT",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "nrtReplicas":"3",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([49336704300C9DDB:C16758DE9EF0F023]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:169)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:56)
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.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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 

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

[Apache Jenkins Server]

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

12 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest.test

Error Message:
Error from server at https://127.0.0.1:50429/nre: collection already exists: 
testcollection

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:50429/nre: collection already exists: 
testcollection
at 
__randomizedtesting.SeedInfo.seed([CCA613C3F293E2E5:44F22C195C6F8F1D]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1675)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1702)
at 
org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest.test(ChaosMonkeySafeLeaderWithPullReplicasTest.java:225)
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.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestExecutePlanAction.testIntegration

Error Message:


Stack Trace:
java.util.ConcurrentModificationException
at 
__randomizedtesting.SeedInfo.seed([4E4AA54B7F58C1CC:FE2BAB675A6760E9]:0)
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
at java.util.ArrayList$Itr.next(ArrayList.java:859)
at 
org.apache.solr.cloud.autoscaling.sim.SimSolrCloudTestCase.tearDown(SimSolrCloudTestCase.java:141)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
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$10.evaluate(RandomizedRunner.java:992)
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)




Build Log:
[...truncated 11709 lines...]
   [junit4] Suite: org.apache.solr.cloud.autoscaling.sim.TestExecutePlanAction
   [junit4]   2> 170517 INFO  
(SUITE-TestExecutePlanAction-seed#[4E4AA54B7F58C1CC]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> Creating dataDir: 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.cloud.autoscaling.sim.TestExecutePlanAction_4E4AA54B7F58C1CC-001/init-core-data-001
   [junit4] 

[jira] [Commented] (SOLR-11062) Add support for spins metric in Policy

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-11062:
---

{code}
{"replica":1, "shard":"#EACH", "disktype" : "ssd" }
//keep exactly one replica of each shard in an ssd host
{code}


> Add support for spins metric in Policy
> --
>
> Key: SOLR-11062
> URL: https://issues.apache.org/jira/browse/SOLR-11062
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, metrics
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
> Fix For: master (8.0), 7.3
>
>
> SOLR-11061 exposes the spin metrics. This issue is to support this metric in 
> the Policy clauses.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/380/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI

Error Message:
Could not find collection : implicitcoll

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : implicitcoll
at 
__randomizedtesting.SeedInfo.seed([CAC2BAA46622F799:A02334CF5BB841E1]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:118)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:247)
at 
org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI(CustomCollectionTest.java:68)
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.CustomCollectionTest.testRouteFieldForImplicitRouter

Error Message:
Collection not found: withShardField

Stack Trace:

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.response.transform.TestSubQueryTransformerDistrib

Error Message:
Error from server at https://127.0.0.1:34141/solr: Could not fully create 
collection: departments

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:34141/solr: Could not fully create collection: 
departments
at __randomizedtesting.SeedInfo.seed([92A5AC2D1416A827]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.response.transform.TestSubQueryTransformerDistrib.setupCluster(TestSubQueryTransformerDistrib.java:81)
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$6.evaluate(RandomizedRunner.java:874)
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)




Build Log:
[...truncated 11967 lines...]
   [junit4] Suite: 
org.apache.solr.response.transform.TestSubQueryTransformerDistrib
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.response.transform.TestSubQueryTransformerDistrib_92A5AC2D1416A827-001/init-core-data-001
   [junit4]   2> 284038 WARN  
(SUITE-TestSubQueryTransformerDistrib-seed#[92A5AC2D1416A827]-worker) [] 
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=1 numCloses=1
   [junit4]   2> 284038 INFO  
(SUITE-TestSubQueryTransformerDistrib-seed#[92A5AC2D1416A827]-worker) [] 
o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=true
   [junit4]   2> 284039 INFO  

[jira] [Created] (SOLR-11820) Provide a configurable hook to filter config API calls

[Anshum Gupta (JIRA)]

Anshum Gupta created SOLR-11820:
---

 Summary: Provide a configurable hook to filter config API calls
 Key: SOLR-11820
 URL: https://issues.apache.org/jira/browse/SOLR-11820
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Anshum Gupta


It would be good to have a mechanism to hook in custom 
whitelisting/blacklisting logic for config updates via the API.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11714) AddReplicaSuggester endless loop

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-11714:
---

 {code}
{"cluster-preferences":[{
"minimize":"cores",
"precision":1}]}
{code}
this is the preferences and there is no policy specified. This means an 
infinite no:of replicas can be added without breaking any rules. 

the test must add an explicit policy limiting the no:of replicas per node AND 
the ComputeAction must check for something more than just relying on the policy 
framework to return a {{null}} suggestion

> AddReplicaSuggester endless loop
> 
>
> Key: SOLR-11714
> URL: https://issues.apache.org/jira/browse/SOLR-11714
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: 7.2, master (8.0)
>Reporter: Andrzej Bialecki 
>Assignee: Noble Paul
> Attachments: 7.2-disable-search-rate-trigger.diff, SOLR-11714.diff
>
>
> {{SearchRateTrigger}} events are processed by {{ComputePlanAction}} and 
> depending on the condition either a MoveReplicaSuggester or 
> AddReplicaSuggester is selected.
> When {{AddReplicaSuggester}} is selected there's currently a bug in master, 
> due to an API change (Hint.COLL_SHARD should be used instead of Hint.COLL). 
> However, after fixing that bug {{ComputePlanAction}} goes into an endless 
> loop because the suggester endlessly keeps creating new operations.
> Please see the patch that fixes the Hint.COLL_SHARD issue and modifies the 
> unit test to illustrate this failure.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-3888) need beter handling of external add/commit requests during tlog recovery

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-3888:

Component/s: SolrCloud

> need beter handling of external add/commit requests during tlog recovery
> 
>
> Key: SOLR-3888
> URL: https://issues.apache.org/jira/browse/SOLR-3888
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.0
>Reporter: Hoss Man
>Assignee: Yonik Seeley
> Fix For: 4.9, 6.0
>
>
> as noted in SOLR-3884: if Solr suffers an unclean-shutdown with documents in 
> the tlog that have not been hard commited to the index, it is then possible 
> that on the next startup tlog recovery will cause "commits" sent by external 
> clients (ie: after indexing new documents) to be ignored.
> in general, we need to give more thought to edge causes of how updates during 
> tlog recovery should be dealt with...
> * is there a non-solrcloud tlog recovery case we're handling poorly?
> * should all updates be blocked until tlog recovery finishes?
> * should tlog recovery be synchronized on UpdateHandler init so that solr 
> isn't even listing on the port until it finishes?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-3818) TermVectorComponent tfidf is not tf/idf by anyone's definition

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-3818:

Component/s: documentation

> TermVectorComponent tfidf is not tf/idf by anyone's definition
> --
>
> Key: SOLR-3818
> URL: https://issues.apache.org/jira/browse/SOLR-3818
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Reporter: Robert Muir
>
> {quote}
> tv.tf_idf - Calculates tf*idf for each term. Requires the parameters tv.tf 
> and tv.df to be "true". This can be expensive. (not shown in example output) 
> {quote}
> But the current computation is tf/docFreq



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-3806) solrcloud node addresses

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-3806:

Component/s: SolrCloud

> solrcloud node addresses
> 
>
> Key: SOLR-3806
> URL: https://issues.apache.org/jira/browse/SOLR-3806
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.0
>Reporter: Yonik Seeley
>
> On my mac (OS-X Lion), addresses such as http://rogue:8983/solr do not work 
> outside of Java.  This means that when the cloud UI displays clickable nodes, 
> they don't actually work.
> This worked at some point in the far past, when my address was detected and 
> published as "Rogue.local" as opposed to "Rogue".



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-3798) copyField logic in LukeRequestHandler is primitive, doesn't work well with dynamicFields

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-3798:

Component/s: Schema and Analysis

> copyField logic in LukeRequestHandler is primitive, doesn't work well with 
> dynamicFields
> 
>
> Key: SOLR-3798
> URL: https://issues.apache.org/jira/browse/SOLR-3798
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Reporter: Hoss Man
> Attachments: SOLR-3798.patch
>
>
> looking into SOLR-3795 i realized there is a much bigger problem with how 
> LukeRequestHandler tries to get copyfield info for fields and dynamicFields 
> the same way, and it just doesn't work.
> see the patch in SOLR-3795 for a commented out example of a test that still 
> fails (ie: trying to get the "copySource" info for a dynamicField)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-3769) unit test failing in solr4 beta

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-3769:

Component/s: Tests

> unit test failing in solr4 beta
> ---
>
> Key: SOLR-3769
> URL: https://issues.apache.org/jira/browse/SOLR-3769
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Reporter: Gary Yngve
>
> ant test  -Dtestcase=LeaderElectionTest -Dtests.seed=3F5F939070D8F356 
> -Dtests.slow=true -Dtests.locale=sl_SI -Dtests.timezone=Africa/El_Aaiun 
> -Dtests.file.encoding=US-ASCII
> [junit4:junit4] ERROR   0.00s | LeaderElectionTest (suite)
> [junit4:junit4]> Throwable #1: java.lang.AssertionError: ERROR: 
> SolrZkClient opens=33 closes=28
> [junit4:junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3F5F939070D8F356]:0)
> [junit4:junit4]>  at org.junit.Assert.fail(Assert.java:93)
> [junit4:junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.endTrackingZkClients(SolrTestCaseJ4.java:230)
> [junit4:junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:83)
> [junit4:junit4]>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> [junit4:junit4]>  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [junit4:junit4]>  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit4:junit4]>  at java.lang.reflect.Method.invoke(Method.java:601)
> [junit4:junit4]>  at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1995)
> [junit4:junit4]>  at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
> [junit4:junit4]>  at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:754)
> [junit4:junit4]>  at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
> [junit4:junit4]>  at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> [junit4:junit4]>  at 
> org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
> [junit4:junit4]>  at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
> [junit4:junit4]>  at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> [junit4:junit4]>  at 
> org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)
> [junit4:junit4]>  at 
> org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52)
> [junit4:junit4]>  at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36)
> [junit4:junit4]>  at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> [junit4:junit4]>  at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
> [junit4:junit4]>  at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
> [junit4:junit4]>  at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605)
> [junit4:junit4]>  at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132)
> [junit4:junit4]>  at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551)
> [junit4:junit4]>
> [junit4:junit4] Completed in 221.77s, 4 tests, 1 failure, 1 error <<< 
> FAILURES!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-3748) testDistribSearch test timeout (progress stalled)

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-3748:

Component/s: Tests

> testDistribSearch test timeout (progress stalled)
> -
>
> Key: SOLR-3748
> URL: https://issues.apache.org/jira/browse/SOLR-3748
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Reporter: Dawid Weiss
>Priority: Minor
> Attachments: lucene.log
>
>
> This build:
> https://builds.apache.org/job/Lucene-Solr-Tests-4.x-java7/326/
> resulted in JVM crash. Event logs from the crashed JVM are truncated so it 
> really was a JVM crash but what happened before is also interesting -- 
> testDistribSearch stalled without any progress for a looong time as seen in 
> the logs (note the timestamps):
> {code}
> 43076 T971 C105 P31455 UPDATE [oneInstanceCollection23] webapp=/solr 
> path=/update 
> params={waitSearcher=true=true=javabin_end_point=true=false=2}
>  {commit=} 0 133
> 43077 T957 C106 P31455 UPDATE [oneInstanceCollection21] webapp=/solr 
> path=/update 
> params={waitSearcher=true=javabin=true=false=2} 
> {commit=} 0 210
> 7200065 T844 ccr.ThreadLeakControl$2.evaluate WARNING Suite execution timed 
> out: org.apache.solr.cloud.BasicDistributedZkTest
> {code}
> There were about ~70 different threads active at the time the suite timed 
> out, jstack shows the main test thread was pending io on a socket. Grep for 
> "jstack" in the attached log file to see which threads were active and where.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-3736) UIMA requires commons-beanutils

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-3736:

Component/s: contrib - UIMA

> UIMA requires commons-beanutils
> ---
>
> Key: SOLR-3736
> URL: https://issues.apache.org/jira/browse/SOLR-3736
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - UIMA
>Affects Versions: 4.0-BETA
>Reporter: Eric Pugh
> Attachments: uima_ivy.patch
>
>
> UIMA appears to require commons-beanutils, which is used by Velocity.  But if 
> you don't include/load velocity, then you don't get commons-beanutils, which 
> causes a stack trace:
> SEVERE: null:java.lang.RuntimeException: java.lang.NoClassDefFoundError: 
> org/apache/commons/beanutils/DynaProperty
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.sendError(SolrDispatchFilter.java:468)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:296)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)
>   at org.eclipse.jetty.server.Server.handle(Server.java:351)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66)
>   at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534)
>   at java.lang.Thread.run(Thread.java:680)
> Caused by: java.lang.NoClassDefFoundError: 
> org/apache/commons/beanutils/DynaProperty
>   at 
> org.apache.commons.digester.Digester.addBeanPropertySetter(Digester.java:2162)
>   at 
> org.apache.uima.alchemy.digester.keyword.XMLTextKeywordExctractionDigester.parseAlchemyXML(XMLTextKeywordExctractionDigester.java:40)
>   at 
> org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:124)
>   at 
> org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48)
>   at 
> org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377)
>   at 
> org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-3729) ExtendedDismaxQParser (edismax) doesn't parse (*:*) properly

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-3729:
-

bq. Can we close this as a dupe of SOLR-3377?

It's not a dupe AFAICT. It is still reproducible using Solr 7.2.

> ExtendedDismaxQParser (edismax) doesn't parse (*:*) properly
> 
>
> Key: SOLR-3729
> URL: https://issues.apache.org/jira/browse/SOLR-3729
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 4.0-BETA
>Reporter: Jack Krupansky
> Attachments: SOLR-3729.patch
>
>
> I just happen to notice that (\*:\*) is not parsed properly by the edismax 
> (ExtendedDismaxQParser) query parser in 4.0-beta. It appears to require 
> spaces before and after the \*:\*, otherwise it treats the colon as part of a 
> wildcard term (see the escaping below). I haven’t tried other releases yet.
> My original query:
> http://localhost:8983/solr/select/?debugQuery=true=(*:*)=edismax
> Produces this:
> {code}
> (*:*)
> (+DisjunctionMaxQuery((text:*\:*)))/no_coord
> +(text:*\:*)
> ExtendedDismaxQParser
> {code}
> Some variations I tried:
> {code}
> ( *:*)
> (+DisjunctionMaxQuery((text:*\:*)))/no_coord
> +(text:*\:*)
>  
> (*:* )
> (+DisjunctionMaxQuery((text:*\:*)))/no_coord
> +(text:*\:*)
>  
> ( *:* )
> (+MatchAllDocsQuery(*:*))/no_coord
> +*:*
>  
> (*:* -fox)
> 
> (+(DisjunctionMaxQuery((text:*\:*)) 
> -DisjunctionMaxQuery((text:fox/no_coord
> 
> +((text:*\:*) -(text:fox))
>  
> ( *:* -fox)
> 
> (+(MatchAllDocsQuery(*:*) -DisjunctionMaxQuery((text:fox/no_coord
> 
> +(*:* -(text:fox))
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-3724) No highlighting for phrases with stop words when FVH is used

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-3724.
-
Resolution: Won't Fix

Closing as Won't Fix since the UnifiedHighlighter mentioned is now the default, 
and per David, does not have this problem.

> No highlighting for phrases with stop words when FVH is used
> 
>
> Key: SOLR-3724
> URL: https://issues.apache.org/jira/browse/SOLR-3724
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 3.6.1
>Reporter: Igor Motov
>
> To reproduce:
> - Index text "foo and bar" into the field "message" with the following schema 
> :
> {code:xml}
> 
>   
> 
>  positionIncrementGap="100">
>   
> 
>  words="lang/stopwords_en.txt" enablePositionIncrements="true"/>
> 
>   
>   
> 
>  words="lang/stopwords_en.txt" enablePositionIncrements="true"/>
>  ignoreCase="true" expand="true"/>
> 
>   
> 
> 
>   
>   
> 
>  required="true" termVectors="true" termPositions="true" termOffsets="true"/>
> 
>   
>   
> 
> {code}
> - Search for the {{message:"foo and bar"}} with highlighting enabled and 
> {{hl.useFastVectorHighlighter=true}}
> - The text is not highlighted
> Standard highlighter works fine. If I set {{enablePositionIncrements=false}} 
> in the analyzer, FVH starts to highlight the entire phrase. You can find 
> complete schema and test data files that I used to reproduce this issue here: 
> https://gist.github.com/3279879 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Closed] (SOLR-3724) No highlighting for phrases with stop words when FVH is used

[Cassandra Targett (JIRA)]

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

Cassandra Targett closed SOLR-3724.
---

> No highlighting for phrases with stop words when FVH is used
> 
>
> Key: SOLR-3724
> URL: https://issues.apache.org/jira/browse/SOLR-3724
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 3.6.1
>Reporter: Igor Motov
>
> To reproduce:
> - Index text "foo and bar" into the field "message" with the following schema 
> :
> {code:xml}
> 
>   
> 
>  positionIncrementGap="100">
>   
> 
>  words="lang/stopwords_en.txt" enablePositionIncrements="true"/>
> 
>   
>   
> 
>  words="lang/stopwords_en.txt" enablePositionIncrements="true"/>
>  ignoreCase="true" expand="true"/>
> 
>   
> 
> 
>   
>   
> 
>  required="true" termVectors="true" termPositions="true" termOffsets="true"/>
> 
>   
>   
> 
> {code}
> - Search for the {{message:"foo and bar"}} with highlighting enabled and 
> {{hl.useFastVectorHighlighter=true}}
> - The text is not highlighted
> Standard highlighter works fine. If I set {{enablePositionIncrements=false}} 
> in the analyzer, FVH starts to highlight the entire phrase. You can find 
> complete schema and test data files that I used to reproduce this issue here: 
> https://gist.github.com/3279879 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-3722) NPE from NamedList constructor if shard fails to return auxilury data about all docs

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-3722:

Component/s: search

> NPE from NamedList constructor if shard fails to return auxilury data about 
> all docs
> 
>
> Key: SOLR-3722
> URL: https://issues.apache.org/jira/browse/SOLR-3722
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 3.6.1
>Reporter: Hoss Man
>
> Michelle Talley reported a problem on the user w/ distributed search .. root 
> issue isn't understood yet, but a secondary problem was that when adding 
> "debugQuery=true" this NPE was thrown...
> {noformat}
> java.lang.NullPointerException
> at 
> org.apache.solr.common.util.NamedList.nameValueMapToList(NamedList.java:110)
> at 
> org.apache.solr.common.util.NamedList.init(NamedList.java:75)
> at 
> org.apache.solr.common.util.SimpleOrderedMap.init(SimpleOrderedMap.java:58)
> at 
> org.apache.solr.handler.component.DebugComponent.finishStage(DebugComponent.java:130)
> {noformat}
> the cause evidently relating to a mismatch between the rb.resultIds list of 
> ShardDocs, and the score explanation output from each shard.  The pattern of 
> code in DebugComponent is common among several components, and i think we 
> should "fix" NamedList to ignore nulls in it's {{Map.Entry[]}} 
> constructor



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-3693) SimpleFacets leak threads

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-3693:

Component/s: faceting

> SimpleFacets leak threads
> -
>
> Key: SOLR-3693
> URL: https://issues.apache.org/jira/browse/SOLR-3693
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Reporter: Dawid Weiss
>
> {code}
>   static final Executor facetExecutor = new ThreadPoolExecutor(
>   0,
>   Integer.MAX_VALUE,
>   10, TimeUnit.SECONDS, // terminate idle threads after 10 sec
>   new SynchronousQueue()  // directly hand off tasks
>   , new DefaultSolrThreadFactory("facetExectutor")
>   );
> {code}
> This is created once and never shut down. 
> I start wondering if it makes sense to add a filter to ignore things like 
> this (which seems to be legitimate). We can either add longer lingering (10 
> seconds is awfully long though) or we can ignore such cases by thread name 
> (there is a typo in 'facetExecutor' btw).
> Let me know what you think.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-3657) error message only refers to "source" field when problem parsing value for "dest" field of copyField

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-3657:

Component/s: Schema and Analysis

> error message only refers to "source" field when problem parsing value for 
> "dest" field of copyField
> 
>
> Key: SOLR-3657
> URL: https://issues.apache.org/jira/browse/SOLR-3657
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Reporter: Hoss Man
>
> When a client submits a document with a value that is copyFielded into a 
> "dest" field where the value is not suitable (ie: something that is not a 
> number copied into a numeric field) the error message only refers to the 
> original "source" field name, not the "dest" field name.  ideally it should 
> mention both fields



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-3626) CurrencyField with sortMissingLast="true"

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-3626:

Issue Type: Improvement  (was: Bug)

> CurrencyField with sortMissingLast="true"
> -
>
> Key: SOLR-3626
> URL: https://issues.apache.org/jira/browse/SOLR-3626
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Affects Versions: 3.6
>Reporter: Mikhail Mitrofanov
> Fix For: 4.9, 6.0
>
>
> My schema.xml has:
>  precisionStep="8" currencyConfig="currency.xml" defaultCurrency="RUR" />
> ...
> 
> However, the record without specifying a price_r, if you sort appear in the 
> list.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Closed] (SOLR-3606) Set the default timeout of HttpClient to a nonzero value

[Cassandra Targett (JIRA)]

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

Cassandra Targett closed SOLR-3606.
---

> Set the default timeout of HttpClient to a nonzero value
> 
>
> Key: SOLR-3606
> URL: https://issues.apache.org/jira/browse/SOLR-3606
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 6.0
>Reporter: jiangwen wei
> Attachments: SOLR-3606.patch
>
>
> The default timeout of HttpClient in HttpShardHandlerFactory and 
> SolrCmdDistributor is set to zero.
> Zero timeout means infinite timeout, which may cause infinite waiting.
> Considering the following case which is observed in our solr cluster:
> There are two servers A and B in solr cluster with two shards.
> Server A receive a search request from client and send a sub request to 
> server B.
> Server B also receive a search request from client and send a sub request to 
> server A.
> the two requests cannot be completed forever, if the threads of jetty server 
> in server A and server B exhausted.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-3608) Spellchecker: String index out of range: -1

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-3608:

Summary: Spellchecker: String index out of range: -1  (was: Spellcecker: 
String index out of range: -1)

> Spellchecker: String index out of range: -1
> ---
>
> Key: SOLR-3608
> URL: https://issues.apache.org/jira/browse/SOLR-3608
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 3.6, 4.0-ALPHA
> Environment: Ubuntu 11.10 x64
> java version "1.7.0_05"
> Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
> Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)
>Reporter: dalius
>Priority: Minor
>
> Spell check component throws StringIndexOutOfBoundsException on multiterm 
> search.
> Stack trace: 
> {code}
> SEVERE: java.lang.StringIndexOutOfBoundsException: String index out of range: 
> -1
>   at 
> java.lang.AbstractStringBuilder.replace(AbstractStringBuilder.java:789)
>   at java.lang.StringBuilder.replace(StringBuilder.java:266)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:128)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:69)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:179)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:156)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:186)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1376)
> ...
> {code}
> I have dug some debug info at org.apache.solr.spelling.SpellCheckCollator:69
> {code}
>   String collationQueryStr = getCollation(originalQuery, 
> possibility.getCorrections());
> {code}
> originalQuery is "casa saja"
> possibility is "rank=0 casa>cal (-1) saja>sala (-1) casa 
> saja>casa de (-1)"
> The replace function fails on 3rd correction "casa saja>casa de (-1)". I hope 
> this makes any sense.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-3606) Set the default timeout of HttpClient to a nonzero value

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-3606.
-
Resolution: Won't Fix

I think based on Yonik's old comment and the lack of alternate ideas in the 
past 5+ years, this won't be changed.

> Set the default timeout of HttpClient to a nonzero value
> 
>
> Key: SOLR-3606
> URL: https://issues.apache.org/jira/browse/SOLR-3606
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 6.0
>Reporter: jiangwen wei
> Attachments: SOLR-3606.patch
>
>
> The default timeout of HttpClient in HttpShardHandlerFactory and 
> SolrCmdDistributor is set to zero.
> Zero timeout means infinite timeout, which may cause infinite waiting.
> Considering the following case which is observed in our solr cluster:
> There are two servers A and B in solr cluster with two shards.
> Server A receive a search request from client and send a sub request to 
> server B.
> Server B also receive a search request from client and send a sub request to 
> server A.
> the two requests cannot be completed forever, if the threads of jetty server 
> in server A and server B exhausted.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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-10-ea+37) - Build # 1119 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1119/
Java: 64bit/jdk-10-ea+37 -XX:+UseCompressedOops -XX:+UseParallelGC

8 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.analytics.legacy.facet.LegacyQueryFacetCloudTest

Error Message:
Could not find collection:collection1

Stack Trace:
java.lang.AssertionError: Could not find collection:collection1
at __randomizedtesting.SeedInfo.seed([124E9C55B814218]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155)
at 
org.apache.solr.analytics.legacy.LegacyAbstractAnalyticsCloudTest.setupCollection(LegacyAbstractAnalyticsCloudTest.java:51)
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$6.evaluate(RandomizedRunner.java:874)
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:  
junit.framework.TestSuite.org.apache.solr.security.TestAuthorizationFramework

Error Message:
68 threads leaked from SUITE scope at 
org.apache.solr.security.TestAuthorizationFramework: 1) Thread[id=26061, 
name=qtp1339141128-26061, state=TIMED_WAITING, 
group=TGRP-TestAuthorizationFramework] at 
java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@10-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2117)
 at 
app//org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:392)
 at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool.idleJobPoll(QueuedThreadPool.java:563)
 at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool.access$800(QueuedThreadPool.java:48)
 at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
 at java.base@10-ea/java.lang.Thread.run(Thread.java:844)2) 
Thread[id=26133, name=zkCallback-4991-thread-5, state=TIMED_WAITING, 
group=TGRP-TestAuthorizationFramework] at 
java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@10-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@10-ea/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@10-ea/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 

[jira] [Updated] (SOLR-3539) rethink softCommit=true|false param on commits?

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-3539:

Component/s: update

> rethink softCommit=true|false param on commits?
> ---
>
> Key: SOLR-3539
> URL: https://issues.apache.org/jira/browse/SOLR-3539
> Project: Solr
>  Issue Type: Bug
>  Components: update
>Reporter: Hoss Man
>
> I think the current NTR related options when doing a commit, particularly 
> "openSearcher="true|false" and "softCommit=true|false", is confusing, and we 
> should rethink them before they get baked into the user API in 4.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] lucene-solr pull request #298: Add web logging interface auto-refresh toggle...

[tommymh]

GitHub user tommymh opened a pull request:

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

Add web logging interface auto-refresh toggle. 

Our team wanted to be able to pause the logs, to have a bit more time to go 
over stack traces.

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

$ git pull https://github.com/Wisconsin-Historical-Society/lucene-solr 
master

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

https://github.com/apache/lucene-solr/pull/298.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 #298


commit fddd6753c34cee4ddb1bd21bb6d7fc74113148d4
Author: Thomas B. Marshment-Howell 
Date:   2018-01-04T21:08:25Z

Add web app logging interface auto-refresh toggle.

commit 48c472dca7fbdd18fb664a0cff77bdc9eb1d137b
Author: Thomas B. Marshment-Howell 
Date:   2018-01-04T21:12:09Z

Rearrange functions for readability.

commit 1769ff1c60c1a7cf7728d79df9b8a38fe6936f83
Author: Thomas B. Marshment-Howell 
Date:   2018-01-04T21:14:17Z

Adjust html indentation




---

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

[jira] [Updated] (SOLR-10424) /update/docs/json is swallowing all fields

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-10424:
-
Component/s: update

> /update/docs/json is swallowing all fields
> --
>
> Key: SOLR-10424
> URL: https://issues.apache.org/jira/browse/SOLR-10424
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Affects Versions: 6.5, 7.0
>Reporter: Hoss Man
>
> I'm not sure when/how exactly this broke, but sending a list of documents to 
> {{/update/json/docs}} is currently useless -- regardless of what your 
> documents contain, all you get is 3 fields: {{id}}, {{\_version\_}}, and a 
> {{\_src\_}} field containing your original JSON, but none of the fields you 
> specified are added.
> Steps to reproduce...
> {noformat}
> git co releases/lucene-solr/6.5.0
> ...
> ant clean && cd solr && ant server
> ...
> bin/solr -e techproducts
> ...
> curl 'http://localhost:8983/solr/techproducts/update/json/docs?commit=true' 
> --data-binary @example/exampledocs/books.json -H 
> 'Content-type:application/json'
> ...
> curl 'http://localhost:8983/solr/techproducts/query?q=id:978-1933988177'
> {
>   "responseHeader":{
> "status":0,
> "QTime":5,
> "params":{
>   "q":"id:978-1933988177"}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "id":"978-1933988177",
> "_src_":"{\n\"id\" : \"978-1933988177\",\n\"cat\" : 
> [\"book\",\"paperback\"],\n\"name\" : \"Lucene in Action, Second 
> Edition\",\n\"author\" : \"Michael McCandless\",\n\"sequence_i\" : 
> 1,\n\"genre_s\" : \"IT\",\n\"inStock\" : true,\n\"price\" : 
> 30.50,\n\"pages_i\" : 475\n  }",
> "_version_":1563794703530328065}]
>   }}
> {noformat}
> Compare with using {{/update/json}} ...
> {noformat}
> curl 'http://localhost:8983/solr/techproducts/update/json?commit=true' 
> --data-binary @example/exampledocs/books.json -H 
> 'Content-type:application/json'
> ...
> curl 'http://localhost:8983/solr/techproducts/query?q=id:978-1933988177'
> {
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"id:978-1933988177"}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "id":"978-1933988177",
> "cat":["book",
>   "paperback"],
> "name":"Lucene in Action, Second Edition",
> "author":"Michael McCandless",
> "author_s":"Michael McCandless",
> "sequence_i":1,
> "sequence_pi":1,
> "genre_s":"IT",
> "inStock":true,
> "price":30.5,
> "price_c":"30.5,USD",
> "pages_i":475,
> "pages_pi":475,
> "_version_":1563794766373584896}]
>   }}
> {noformat}
> According to the ref-guide, the only diff between these two endpoints should 
> be that {{/update/json/docs}} defaults {{json.command=false}} ... but since 
> the top level JSON structure in books.json is a list ({{"[ ... ]"}}) that 
> shouldn't matter because that's not the solr JSON command syntax.
> 
> If you try to send a singular JSON document tp {{/update/json/docs}}, you get 
> the same problem...
> {noformat}
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"id":"HOSS","popularity":42}' 
> 'http://localhost:8983/solr/techproducts/update/json/docs?commit=true'
> ...
> curl 'http://localhost:8983/solr/techproducts/query?q=id:HOSS'{
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"id:HOSS"}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "id":"HOSS",
> "_src_":"{\"id\":\"HOSS\",\"popularity\":42}",
> "_version_":1563795188162232320}]
>   }}
> {noformat}
> ...even though the same JSON works fine to 
> {{/update/json?json.command=false}} ...
> {noformat}
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"id":"HOSS","popularity":42}' 
> 'http://localhost:8983/solr/techproducts/update/json?commit=true=false'
> ...
> curl 'http://localhost:8983/solr/techproducts/query?q=id:HOSS'{
>   "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
>   "q":"id:HOSS"}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "id":"HOSS",
> "popularity":42,
> "_version_":1563795262581768192}]
>   }}
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-3539) rethink softCommit=true|false param on commits?

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-3539:

Fix Version/s: (was: 6.0)
   (was: 4.9)

> rethink softCommit=true|false param on commits?
> ---
>
> Key: SOLR-3539
> URL: https://issues.apache.org/jira/browse/SOLR-3539
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> I think the current NTR related options when doing a commit, particularly 
> "openSearcher="true|false" and "softCommit=true|false", is confusing, and we 
> should rethink them before they get baked into the user API in 4.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Closed] (SOLR-3482) Cannot index emails, mistakes of configuration file data-config.xml solrconfig.xml, Cannot find tika

[Cassandra Targett (JIRA)]

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

Cassandra Targett closed SOLR-3482.
---

> Cannot index emails, mistakes of configuration file data-config.xml 
> solrconfig.xml, Cannot find tika 
> -
>
> Key: SOLR-3482
> URL: https://issues.apache.org/jira/browse/SOLR-3482
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 4.0-ALPHA
> Environment: windows
>Reporter: Emma Bo Liu
>Priority: Minor
>  Labels: core, email, index, solr, tika
>
> The mail core cannot be brought up. There are mistakes of data-config.xml 
> solrconfig.xml. The example of mail core is not complete, miss files.There is 
> mistake of the sor mailEnitityPorcessor tutorial.
> It cannot find the tika even tough it include the dataimporter-extra jar 
> file. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-3482) Cannot index emails, mistakes of configuration file data-config.xml solrconfig.xml, Cannot find tika

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-3482.
-
Resolution: Cannot Reproduce
  Assignee: (was: Alexandre Rafalovitch)

Resolving this as there really isn't enough info here for someone to reproduce 
it, as evidenced by the last comment. Please reopen if more information can be 
provided.

> Cannot index emails, mistakes of configuration file data-config.xml 
> solrconfig.xml, Cannot find tika 
> -
>
> Key: SOLR-3482
> URL: https://issues.apache.org/jira/browse/SOLR-3482
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 4.0-ALPHA
> Environment: windows
>Reporter: Emma Bo Liu
>Priority: Minor
>  Labels: core, email, index, solr, tika
>
> The mail core cannot be brought up. There are mistakes of data-config.xml 
> solrconfig.xml. The example of mail core is not complete, miss files.There is 
> mistake of the sor mailEnitityPorcessor tutorial.
> It cannot find the tika even tough it include the dataimporter-extra jar 
> file. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-3385) Extended Dismax parser ignores all regular search terms when one search term is using + (dismax behaves differently)

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-3385.
-
Resolution: Duplicate

SOLR-2649 is really long, but I think, from what I gathered there, this is a 
duplicate of that issue.

> Extended Dismax parser ignores all regular search terms when one search term 
> is using + (dismax behaves differently)
> 
>
> Key: SOLR-3385
> URL: https://issues.apache.org/jira/browse/SOLR-3385
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 3.5
>Reporter: Nils Kaiser
> Attachments: select_PLUSsales_dismax_9600results.xml, 
> select_PLUSsales_edismax_9600results.xml, 
> select_dev_PLUSsales_dismax_553results.xml, 
> select_dev_PLUSsales_edismax_9600results.xml, 
> select_dev_PLUSsales_miau_dismax_0results.xml, 
> select_dev_PLUSsales_miau_edismax_9600results.xml, 
> select_dev_sales_miau_edismax_0results.xml
>
>
> When using the extended dismax parser with at least one term using + or -, 
> all other search terms are ignored.
> Example:
> (the terms dev and sales are found in the index, the term miau is not part of 
> the index)
> "dev sales miau", "+dev +sales +miau", "dev +sales +miau" all give me 0 
> results (as expected)
> "dev +sales miau", "dev +sales" or "+sales" return the same number of results 
> (dev and miau terms are ignored)
> The standard dismax parser always treats search terms as +, so "dev sales 
> miau", "+dev +sales miau", "dev +sales miau" return the same number of 
> results. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Closed] (SOLR-3385) Extended Dismax parser ignores all regular search terms when one search term is using + (dismax behaves differently)

[Cassandra Targett (JIRA)]

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

Cassandra Targett closed SOLR-3385.
---

> Extended Dismax parser ignores all regular search terms when one search term 
> is using + (dismax behaves differently)
> 
>
> Key: SOLR-3385
> URL: https://issues.apache.org/jira/browse/SOLR-3385
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 3.5
>Reporter: Nils Kaiser
> Attachments: select_PLUSsales_dismax_9600results.xml, 
> select_PLUSsales_edismax_9600results.xml, 
> select_dev_PLUSsales_dismax_553results.xml, 
> select_dev_PLUSsales_edismax_9600results.xml, 
> select_dev_PLUSsales_miau_dismax_0results.xml, 
> select_dev_PLUSsales_miau_edismax_9600results.xml, 
> select_dev_sales_miau_edismax_0results.xml
>
>
> When using the extended dismax parser with at least one term using + or -, 
> all other search terms are ignored.
> Example:
> (the terms dev and sales are found in the index, the term miau is not part of 
> the index)
> "dev sales miau", "+dev +sales +miau", "dev +sales +miau" all give me 0 
> results (as expected)
> "dev +sales miau", "dev +sales" or "+sales" return the same number of results 
> (dev and miau terms are ignored)
> The standard dismax parser always treats search terms as +, so "dev sales 
> miau", "+dev +sales miau", "dev +sales miau" return the same number of 
> results. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.index.TestBackwardsCompatibility

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_572A867B4BAE81D0-001\4.5.0-nocfs-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_572A867B4BAE81D0-001\4.5.0-nocfs-001

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_572A867B4BAE81D0-001\4.2.0-nocfs-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_572A867B4BAE81D0-001\4.2.0-nocfs-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\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_572A867B4BAE81D0-001\4.5.0-nocfs-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_572A867B4BAE81D0-001\4.5.0-nocfs-001
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_572A867B4BAE81D0-001\4.2.0-nocfs-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_572A867B4BAE81D0-001\4.2.0-nocfs-001

at __randomizedtesting.SeedInfo.seed([572A867B4BAE81D0]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
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.lang.Thread.run(Thread.java:748)


FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.component.TermVectorComponentTest

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.component.TermVectorComponentTest_615A0EE3216D0837-001\init-core-data-001\spellcheckerMultipleFields:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.handler.component.TermVectorComponentTest_615A0EE3216D0837-001\init-core-data-001\spellcheckerMultipleFields

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.handler.component.TermVectorComponentTest_615A0EE3216D0837-001\init-core-data-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.handler.component.TermVectorComponentTest_615A0EE3216D0837-001\init-core-data-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.component.TermVectorComponentTest_615A0EE3216D0837-001\init-core-data-001\spellcheckerMultipleFields:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.handler.component.TermVectorComponentTest_615A0EE3216D0837-001\init-core-data-001\spellcheckerMultipleFields
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.handler.component.TermVectorComponentTest_615A0EE3216D0837-001\init-core-data-001:
 

[jira] [Updated] (SOLR-3243) eDismax and non-fielded range query

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-3243:

Priority: Major  (was: Critical)

Bumping priority down from Critical since it's clearly not 5+ years into its 
life.

I also duplicated the issue (without trying the earlier patch) and noticed that 
the query is expanded only to the default search fields (df fields) for the 
request handler. I point this out only to note that users with lots of fields 
defined for df would have a worse time with this behavior than users who don't 
have a lot of fields defined.

> eDismax and non-fielded range query
> ---
>
> Key: SOLR-3243
> URL: https://issues.apache.org/jira/browse/SOLR-3243
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 3.1, 3.2, 3.3, 3.4, 3.5
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 4.9, 6.0
>
> Attachments: SOLR-3243.patch
>
>
> Reported by Bill Bell in SOLR-3085:
> If you enter a non-fielded open-ended range in the search box, like [* TO *], 
> eDismax will expand it to all fields:
> {noformat}
> +DisjunctionMaxQuery((content:[* TO *]^2.0 | id:[* TO *]^50.0 | author:[* TO 
> *]^15.0 | meta:[* TO *]^10.0 | name:[* TO *]^20.0))
> {noformat}
> This does not make sense, and a side effect is that range queries for strings 
> are very expensive, open-ended even more, and you can totally crash the 
> search server by hammering something like ([* TO *] OR [* TO *] OR [* TO *]) 
> a few times...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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_144) - Build # 21213 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21213/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test

Error Message:
Timeout occured while waiting response from server at: http://127.0.0.1:44333

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:44333
at 
__randomizedtesting.SeedInfo.seed([A84CFEDDEB87E6EF:2018C107457B8B17]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:320)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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] [Closed] (SOLR-3321) replicationFailedAtList showing Erroneous Results

[Cassandra Targett (JIRA)]

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

Cassandra Targett closed SOLR-3321.
---

> replicationFailedAtList  showing Erroneous Results
> --
>
> Key: SOLR-3321
> URL: https://issues.apache.org/jira/browse/SOLR-3321
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 3.5
> Environment: AMD 8 Core Machine with 14Gb RAM
>Reporter: Shubham Kumar Srivastava
>Priority: Minor
>  Labels: patch
>   Original Estimate: 6h
>  Remaining Estimate: 6h
>
> I was looking at the replication details through the below URL
> http://slave-host:slave-port/hotels/replication?command=details
> I found that replicationFailedAtList to be a bit inconsistent with the actual 
> failures.
> I got my master down for couple of minutes and then saw the same url it still 
> didn't show the time in the replicationFailedAtList.
> Tried it couple of times on different time instances but problem still 
> remains.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-3321) replicationFailedAtList showing Erroneous Results

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-3321.
-
   Resolution: Cannot Reproduce
Fix Version/s: (was: 3.5)

There aren't details here on what is actually inconsistent about the response, 
and no new information has been provided in the last 5+ years to let anyone 
know what should be done here.

> replicationFailedAtList  showing Erroneous Results
> --
>
> Key: SOLR-3321
> URL: https://issues.apache.org/jira/browse/SOLR-3321
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 3.5
> Environment: AMD 8 Core Machine with 14Gb RAM
>Reporter: Shubham Kumar Srivastava
>Priority: Minor
>  Labels: patch
>   Original Estimate: 6h
>  Remaining Estimate: 6h
>
> I was looking at the replication details through the below URL
> http://slave-host:slave-port/hotels/replication?command=details
> I found that replicationFailedAtList to be a bit inconsistent with the actual 
> failures.
> I got my master down for couple of minutes and then saw the same url it still 
> didn't show the time in the replicationFailedAtList.
> Tried it couple of times on different time instances but problem still 
> remains.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-3320) Large numbers of executeWithRetry INFO messages in Catalina

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-3320.
-
   Resolution: Cannot Reproduce
Fix Version/s: (was: 3.5)

Closing this as I think it would be impossible to duplicate: there weren't 
steps to reproduce given 5+ years ago, it uses Tomcat which we no longer 
support, and it's using 3.5.

> Large numbers of executeWithRetry INFO messages in Catalina
> ---
>
> Key: SOLR-3320
> URL: https://issues.apache.org/jira/browse/SOLR-3320
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 3.5
> Environment: AMD 8 Core Machine with 14Gb RAM
>Reporter: Shubham Kumar Srivastava
>Priority: Minor
>  Labels: patch
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
> I am getting the below log's in catalina.out
> Apr 5, 2012 6:27:59 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: I/O exception (org.apache.commons.httpclient.NoHttpResponseException) 
> caught when processing request: The server 192.168.6.135 failed to respond
> Apr 5, 2012 6:27:59 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: Retrying request
> Apr 5, 2012 6:28:39 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: I/O exception (org.apache.commons.httpclient.NoHttpResponseException) 
> caught when processing request: The server 192.168.6.135 failed to respond
> Apr 5, 2012 6:28:39 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: Retrying request
> Apr 5, 2012 6:30:39 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: I/O exception (org.apache.commons.httpclient.NoHttpResponseException) 
> caught when processing request: The server 192.168.6.135 failed to respond
> Apr 5, 2012 6:30:39 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: Retrying request
> Apr 5, 2012 6:31:59 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: I/O exception (org.apache.commons.httpclient.NoHttpResponseException) 
> caught when processing request: The server 192.168.6.135 failed to respond
> Apr 5, 2012 6:31:59 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: Retrying request
> Apr 5, 2012 6:32:59 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: I/O exception (org.apache.commons.httpclient.NoHttpResponseException) 
> caught when processing request: The server 192.168.6.135 failed to respond
> Apr 5, 2012 6:32:59 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> every now and then and on every slave randomly. However I haven't seen any 
> issues with replication of Master-Slave as such , validated with Index 
> Version and Generated numbers as well as the data.
> I am using solr3.5 with 5Slaves + 1Master. Polling interval being 20seconds 
> and docs are updated(delta-import) every 60 seconds through Master. Slaves 
> only are for read.
> I am running solr with tomcat 6.0.35 + Java 6 and below is the connection 
> settings
>  maxThreads="200" minSpareThreads="25" maxSpareThreads="75"
> enableLookups="false" redirectPort="8443" acceptCount="100"
> connectionTimeout="2" disableUploadTimeout="true" />
> Heap size is 1Gb( Xms=Xmx=1024m). 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Closed] (SOLR-3320) Large numbers of executeWithRetry INFO messages in Catalina

[Cassandra Targett (JIRA)]

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

Cassandra Targett closed SOLR-3320.
---

> Large numbers of executeWithRetry INFO messages in Catalina
> ---
>
> Key: SOLR-3320
> URL: https://issues.apache.org/jira/browse/SOLR-3320
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 3.5
> Environment: AMD 8 Core Machine with 14Gb RAM
>Reporter: Shubham Kumar Srivastava
>Priority: Minor
>  Labels: patch
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
> I am getting the below log's in catalina.out
> Apr 5, 2012 6:27:59 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: I/O exception (org.apache.commons.httpclient.NoHttpResponseException) 
> caught when processing request: The server 192.168.6.135 failed to respond
> Apr 5, 2012 6:27:59 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: Retrying request
> Apr 5, 2012 6:28:39 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: I/O exception (org.apache.commons.httpclient.NoHttpResponseException) 
> caught when processing request: The server 192.168.6.135 failed to respond
> Apr 5, 2012 6:28:39 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: Retrying request
> Apr 5, 2012 6:30:39 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: I/O exception (org.apache.commons.httpclient.NoHttpResponseException) 
> caught when processing request: The server 192.168.6.135 failed to respond
> Apr 5, 2012 6:30:39 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: Retrying request
> Apr 5, 2012 6:31:59 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: I/O exception (org.apache.commons.httpclient.NoHttpResponseException) 
> caught when processing request: The server 192.168.6.135 failed to respond
> Apr 5, 2012 6:31:59 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: Retrying request
> Apr 5, 2012 6:32:59 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: I/O exception (org.apache.commons.httpclient.NoHttpResponseException) 
> caught when processing request: The server 192.168.6.135 failed to respond
> Apr 5, 2012 6:32:59 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> every now and then and on every slave randomly. However I haven't seen any 
> issues with replication of Master-Slave as such , validated with Index 
> Version and Generated numbers as well as the data.
> I am using solr3.5 with 5Slaves + 1Master. Polling interval being 20seconds 
> and docs are updated(delta-import) every 60 seconds through Master. Slaves 
> only are for read.
> I am running solr with tomcat 6.0.35 + Java 6 and below is the connection 
> settings
>  maxThreads="200" minSpareThreads="25" maxSpareThreads="75"
> enableLookups="false" redirectPort="8443" acceptCount="100"
> connectionTimeout="2" disableUploadTimeout="true" />
> Heap size is 1Gb( Xms=Xmx=1024m). 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-4198) Allow codecs to index term impacts

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-4198:
-
Attachment: LUCENE-4198.patch

OK, new iteration. I integrated LUCENE-8116, started to fix corner-cases and 
I've been looking into ways to make the API nicer. Current take is to add 
{{PostingsEnum.setMinCompetitiveScore}} which defaults to a no-op, and 
{{TermsEnum.topPostings(SimScorer)}} which returns a postings that should be 
able to skip low-scoring documents and delegates to {{TermsEnum.postings(null, 
PostingsEnum.FREQS)}} by default.

I still need to work on tests and stop creating a new IndexInput slice for 
every term at index-time. I suppose I could implement getMergeInstance on 
{{Lucene70NormsProducer}} to reuse the same slice across invocations to 
getNorms on the same field.

I'll keep working on this in the next days.

> Allow codecs to index term impacts
> --
>
> Key: LUCENE-4198
> URL: https://issues.apache.org/jira/browse/LUCENE-4198
> Project: Lucene - Core
>  Issue Type: Sub-task
>  Components: core/index
>Reporter: Robert Muir
> Attachments: LUCENE-4198.patch, LUCENE-4198.patch, 
> LUCENE-4198_flush.patch
>
>
> Subtask of LUCENE-4100.
> Thats an example of something similar to impact indexing (though, his 
> implementation currently stores a max for the entire term, the problem is the 
> same).
> We can imagine other similar algorithms too: I think the codec API should be 
> able to support these.
> Currently it really doesnt: Stefan worked around the problem by providing a 
> tool to 'rewrite' your index, he passes the IndexReader and Similarity to it. 
> But it would be better if we fixed the codec API.
> One problem is that the Postings writer needs to have access to the 
> Similarity. Another problem is that it needs access to the term and 
> collection statistics up front, rather than after the fact.
> This might have some cost (hopefully minimal), so I'm thinking to experiment 
> in a branch with these changes and see if we can make it work well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11819) The schema api reference manual page should not use hyphens in the example field name

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-11819:
--

+1, good catch. 

> The schema api reference manual page should not use hyphens in the example 
> field name
> -
>
> Key: SOLR-11819
> URL: https://issues.apache.org/jira/browse/SOLR-11819
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-11819.patch
>
>
> Since we specifically recommend that field names follow these rules:
> "Field names should consist of alphanumeric or underscore characters only and 
> not start with a digit."
> we shouldn't model different behavior.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8117) advanceExact does not work on sorted numeric dvs with Lucene54DocValuesProducer

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8117:
--

+1 patch looks good, great catch!

I see we had some tests in CheckIndex for advanceExact, but they only check 
whether the return value is expected, not whether we then produce the expected 
values. Probably something we should look into beefing up, I'm now wondering 
some other codecs could have similar issues.

> advanceExact does not work on sorted numeric dvs with 
> Lucene54DocValuesProducer 
> 
>
> Key: LUCENE-8117
> URL: https://issues.apache.org/jira/browse/LUCENE-8117
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.2
>Reporter: Jim Ferenczi
> Attachments: LUCENE-8117.patch
>
>
> DocValues are iterators now so old doc values (produced with 
> Lucene54DocValues) also implements advance and advanceExact. Though sorted 
> numerics produced by Lucene54DocValues are not working as expected when 
> advanceExact is used. 
> In such case, the docValueCount is as expected but the values returned by the 
> iterator for the document are invalid. This is due to a bug in the 
> implementation of advanceExact in the producer that does not set the offset 
> of the current doc when the function is used.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8099) Deprecate CustomScoreQuery, BoostedQuery and BoostingQuery

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-8099:
--

bq. Re testing, replacement tests had already been committed as part of another 
issue

Cool -- thank you for clarifying, that wasn't obvious to me when skimming these 
particular commits.

bq.  Maybe we should add some static methods to FunctionScoreQuery to allow for 
simple boosting? 

+1

As i mentioned, I think it would be nice for backcompat if we could keep the 
old {{new FOO(xxx)}} constructors working as trivial subclasses of 
FunctionScoreQuery -- but I get your point about wanting to reduce 
confusion/ambiguity in the names.   A one line drop in replacement for each of 
the 3 previous constructors that's easy for people to batch replace on upgrade 
should be adequate.

As i alluded to in my earlier comment, the one other concern I have is about 
the relative performance of the old classes vs using the FunctionScoreQuery. I 
haven't wrapped my head around the old code vs new code enough to have any 
concrete concerns/objections -- I'm just looking for some explicit "vote of 
confidence" from folks like you who _have_ looked at it in depth that you've 
thought about it and don't see any reason why the new cosolidated impl would be 
slower then the old impls.  

(The one thing that jumped out at me the other day was the use of a compiled 
expressions like {{"score * context"}} in each query instance in the suggested 
replacement code for some queries -- but it's not clear to me if that would 
still be involved based on your latest patch)

> Deprecate CustomScoreQuery, BoostedQuery and BoostingQuery
> --
>
> Key: LUCENE-8099
> URL: https://issues.apache.org/jira/browse/LUCENE-8099
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 7.3
>
> Attachments: LUCENE-8099-2.patch, LUCENE-8099.patch, LUCENE-8099.patch
>
>
> After LUCENE-7998, these three queries can all be replaced by a 
> FunctionScoreQuery.  Using lucene-expressions makes them much easier to use 
> as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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.1) - Build # 7093 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7093/
Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

8 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_CDC035AE2D7A0F8C-001\testPostingsFormat-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_CDC035AE2D7A0F8C-001\testPostingsFormat-001

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_CDC035AE2D7A0F8C-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_CDC035AE2D7A0F8C-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\lucene\build\codecs\test\J0\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_CDC035AE2D7A0F8C-001\testPostingsFormat-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_CDC035AE2D7A0F8C-001\testPostingsFormat-001
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_CDC035AE2D7A0F8C-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_CDC035AE2D7A0F8C-001

at __randomizedtesting.SeedInfo.seed([CDC035AE2D7A0F8C]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
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:  
junit.framework.TestSuite.org.apache.lucene.codecs.blockterms.TestVarGapFixedIntervalPostingsFormat

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestVarGapFixedIntervalPostingsFormat_CDC035AE2D7A0F8C-001\testPostingsFormat-002:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestVarGapFixedIntervalPostingsFormat_CDC035AE2D7A0F8C-001\testPostingsFormat-002

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestVarGapFixedIntervalPostingsFormat_CDC035AE2D7A0F8C-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestVarGapFixedIntervalPostingsFormat_CDC035AE2D7A0F8C-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\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestVarGapFixedIntervalPostingsFormat_CDC035AE2D7A0F8C-001\testPostingsFormat-002:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestVarGapFixedIntervalPostingsFormat_CDC035AE2D7A0F8C-001\testPostingsFormat-002
   

[jira] [Commented] (LUCENE-8117) advanceExact does not work on sorted numeric dvs with Lucene54DocValuesProducer

[Jim Ferenczi (JIRA)]

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

Jim Ferenczi commented on LUCENE-8117:
--

This issue is only on 7x (where advanceExact has been added) since it is not 
possible to use an index with Lucene54DocValuesProducer in 8x.

> advanceExact does not work on sorted numeric dvs with 
> Lucene54DocValuesProducer 
> 
>
> Key: LUCENE-8117
> URL: https://issues.apache.org/jira/browse/LUCENE-8117
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.2
>Reporter: Jim Ferenczi
> Attachments: LUCENE-8117.patch
>
>
> DocValues are iterators now so old doc values (produced with 
> Lucene54DocValues) also implements advance and advanceExact. Though sorted 
> numerics produced by Lucene54DocValues are not working as expected when 
> advanceExact is used. 
> In such case, the docValueCount is as expected but the values returned by the 
> iterator for the document are invalid. This is due to a bug in the 
> implementation of advanceExact in the producer that does not set the offset 
> of the current doc when the function is used.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-8117) advanceExact does not work on sorted numeric dvs with Lucene54DocValuesProducer

[Jim Ferenczi (JIRA)]

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

Jim Ferenczi updated LUCENE-8117:
-
Attachment: LUCENE-8117.patch

Here is a simple patch

> advanceExact does not work on sorted numeric dvs with 
> Lucene54DocValuesProducer 
> 
>
> Key: LUCENE-8117
> URL: https://issues.apache.org/jira/browse/LUCENE-8117
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.2
>Reporter: Jim Ferenczi
> Attachments: LUCENE-8117.patch
>
>
> DocValues are iterators now so old doc values (produced with 
> Lucene54DocValues) also implements advance and advanceExact. Though sorted 
> numerics produced by Lucene54DocValues are not working as expected when 
> advanceExact is used. 
> In such case, the docValueCount is as expected but the values returned by the 
> iterator for the document are invalid. This is due to a bug in the 
> implementation of advanceExact in the producer that does not set the offset 
> of the current doc when the function is used.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (LUCENE-8117) advanceExact does not work on sorted numeric dvs with Lucene54DocValuesProducer

[Jim Ferenczi (JIRA)]

Jim Ferenczi created LUCENE-8117:


 Summary: advanceExact does not work on sorted numeric dvs with 
Lucene54DocValuesProducer 
 Key: LUCENE-8117
 URL: https://issues.apache.org/jira/browse/LUCENE-8117
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 7.2
Reporter: Jim Ferenczi


DocValues are iterators now so old doc values (produced with Lucene54DocValues) 
also implements advance and advanceExact. Though sorted numerics produced by 
Lucene54DocValues are not working as expected when advanceExact is used. 
In such case, the docValueCount is as expected but the values returned by the 
iterator for the document are invalid. This is due to a bug in the 
implementation of advanceExact in the producer that does not set the offset of 
the current doc when the function is used.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

SolrCmdDistributor retries.

[Erick Erickson]

Down in SolrCmdDistibuted.doRetriesIfNeeded there are a series of specific
codes that we retry on, here:

if (isRetry) {
  if (rspCode == 404 || rspCode == 403 || rspCode == 503) {
doRetry = true;
  }

...

Absent is a 401. What I think I'm seeing
in the field is that there's a timeout with
this reported during a distributed update.


Invalid key request timestamp: 1513273351295 ,
received timestamp: 1513273356700 , TTL: 5000

This appears to only happen very occasionally.

The problem is that this leads to a the leader putting the

follower into LIR and all the problems that entails.


Certainly the timeout can be lengthened with:
-Dpkiauth.ttl=1

or whatever, but my question is whether it makes

sense to retry in this case in SolrCmdDistributor.

NOTE: I only have logs from 6.3 for this, but see

no evidence this has been changed since then.

Comments?

[jira] [Commented] (SOLR-11809) QueryComponent.prepare rq parameter parsing fails under SOLR 7.2

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11809:
-

I suspect that the right solution is for "rq" to be parsed without care for 
whatever defType is. The rationale is that defType is almost exclusively for 
the "q" parameter; other parameters use the default of "lucene".  Also note 
that RQ must produce a query of a certain type, which is more evidence that 
defType is irrelevant.  I can appreciate that "hl.q" param is an exception 
since when used it's a tweak of "q" in some way.

> QueryComponent.prepare rq parameter parsing fails under SOLR 7.2
> 
>
> Key: SOLR-11809
> URL: https://issues.apache.org/jira/browse/SOLR-11809
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2
> Environment: Windows 10, java version "1.8.0_151"
>Reporter: Dariusz Wojtas
> Attachments: SOLR-11809.patch, ltr-sample.zip
>
>
> The LTR functionality that works under SOLR 7.0 and 7.1 stopped working in 
> 7.2.
> From the solr-user mailing list it appears it might be related to SOLR-11501 .
> I am attaching the minimal working collection definition (attached 
> [^ltr-sample.zip]) that shows the problem.
> Please deploy the collection (unpack under "server/solr"), run solr and 
> invoke the URL below.
>   http://localhost:8983/solr/ltr-sample/select?q=*:*
> Behaviour:
> * under 7.0 and 7.1 - empty resultset is returned (there is no data in the 
> collection)
> * under 7.2 - error: "rq parameter must be a RankQuery". The stacktrace
> {code}
> 2018-01-02 20:51:06.807 INFO  (qtp205125520-20) [   x:ltr-sample] 
> o.a.s.c.S.Request [ltr-sample]  webapp=/solr path=/select 
> params={q=*:*&_=1514909140928} status=400 QTime=23
> 2018-01-02 21:04:27.293 ERROR (qtp205125520-17) [   x:ltr-sample] 
> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: rq parameter 
> must be a RankQuery
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:183)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:269)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2503)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:710)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
>   [..]
> {code}
> i have checked - the same issue exists when I try to invoke the _rerank_ 
> query parser.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11815) TLOG leaders going down and rejoining as a replica do fullCopy when not needed

[Shaun Sabo (JIRA)]

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

Shaun Sabo commented on SOLR-11815:
---

We spun a test up with isIndexStale commented out and found that the following 
block was causing us to still trigger a full re-replication as well when the 
checksum mismatch is discovered. We don't think that this check is necessary 
anymore either. 

https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/IndexFetcher.java#L1136-L1141

> TLOG leaders going down and rejoining as a replica do fullCopy when not needed
> --
>
> Key: SOLR-11815
> URL: https://issues.apache.org/jira/browse/SOLR-11815
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Affects Versions: 7.2
> Environment: Oracle JDK 1.8
> Ubuntu 16.04
>Reporter: Shaun Sabo
>Assignee: Ishan Chattopadhyaya
>
> I am running a collection with a persistent high volume of writes. When the 
> leader goes down and recovers, it joins as a replica and asks the new leader 
> for the files to Sync. The isIndexStale check is finding that some files 
> differ in size and checksum which forces a fullCopy. Since our indexes are 
> rather large, a rolling restart is resulting in large amounts of data 
> transfer, and in some cases disk space contention issues.
> I do not believe the fullCopy is necessary given the circumstances. 
> Repro Steps:
> 1. collection/shard with 1 leader and 1 replica are accepting writes
> - Pull interval is 30 seconds
> - Hard Commit interval is 60 seconds
> 2. Replica executes an index pull and completes. 
> 3. Leader process Hard Commits (replica index is delayed)
> 4. leader process is killed (SIGTERM)
> 5. Replica takes over as new leader
> 6. New leader applies TLOG since last pull (cores are binary-divergent now)
> 7. Former leader comes back as New Replica
> 8. New replica initiates recovery
> - Recovery detects that the generation and version are behind and a check 
> is necessary
> 9. isIndexStale() detects that a segment exists on both the New Replica and 
> New Leader but that the size and checksum differ. 
> - This triggers fullCopy to be flagged on
> 10. Entirety of index is pulled regardless of changes
> The majority of files should not have changes, but everything gets pulled 
> because of the first file it finds with a mismatched checksum. 
> Relevant Code:
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/IndexFetcher.java#L516-L518
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/IndexFetcher.java#L1105-L1126



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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 # 373 - Still Unstable!

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestExecutePlanAction.testIntegration

Error Message:


Stack Trace:
java.util.ConcurrentModificationException
at 
__randomizedtesting.SeedInfo.seed([C48B7B3B457DBD72:74EA751760421C57]:0)
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
at java.util.ArrayList$Itr.next(ArrayList.java:859)
at 
org.apache.solr.cloud.autoscaling.sim.SimSolrCloudTestCase.tearDown(SimSolrCloudTestCase.java:141)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
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$10.evaluate(RandomizedRunner.java:992)
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.sim.TestTriggerIntegration.testNodeAddedTriggerRestoreState

Error Message:


Stack Trace:
java.util.ConcurrentModificationException
at 
__randomizedtesting.SeedInfo.seed([C48B7B3B457DBD72:4CB6F2447FBD5CDF]:0)
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
at java.util.ArrayList$Itr.next(ArrayList.java:859)
at 
org.apache.solr.cloud.autoscaling.sim.SimSolrCloudTestCase.tearDown(SimSolrCloudTestCase.java:141)
at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown 

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_144) - Build # 21212 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21212/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseParallelGC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at __randomizedtesting.SeedInfo.seed([D3A18F89BF7FEFE8]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1261)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.waitForState(CloudSolrClient.java:449)
at 
org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest.setupCluster(DistribDocExpirationUpdateProcessorTest.java:63)
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$6.evaluate(RandomizedRunner.java:874)
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)




Build Log:
[...truncated 12390 lines...]
   [junit4] Suite: org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.DistribDocExpirationUpdateProcessorTest_D3A18F89BF7FEFE8-001/init-core-data-001
   [junit4]   2> 0INFO  
(SUITE-DistribDocExpirationUpdateProcessorTest-seed#[D3A18F89BF7FEFE8]-worker) 
[] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 39   INFO  
(SUITE-DistribDocExpirationUpdateProcessorTest-seed#[D3A18F89BF7FEFE8]-worker) 
[] o.e.j.u.log Logging initialized @991ms
   [junit4]   2> 43   INFO  
(SUITE-DistribDocExpirationUpdateProcessorTest-seed#[D3A18F89BF7FEFE8]-worker) 
[] o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 170  INFO  
(SUITE-DistribDocExpirationUpdateProcessorTest-seed#[D3A18F89BF7FEFE8]-worker) 
[] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> 175  INFO  
(SUITE-DistribDocExpirationUpdateProcessorTest-seed#[D3A18F89BF7FEFE8]-worker) 
[] o.a.s.c.MiniSolrCloudCluster Starting cluster of 2 servers in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.DistribDocExpirationUpdateProcessorTest_D3A18F89BF7FEFE8-001/tempDir-001
   [junit4]   2> 181  INFO  
(SUITE-DistribDocExpirationUpdateProcessorTest-seed#[D3A18F89BF7FEFE8]-worker) 
[] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 183  INFO  (Thread-1) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   

[jira] [Updated] (SOLR-11817) Move Collections API classes to it's own package

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-11817:
-
Attachment: SOLR-11817.patch

tests pass. I'll run it a few more times as it touches a lot of files but 
what's the general feedback on this approach?

> Move Collections API classes to it's own package
> 
>
> Key: SOLR-11817
> URL: https://issues.apache.org/jira/browse/SOLR-11817
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-11817.patch, SOLR-11817.patch
>
>
> Today all collections api classes and tests are in the 
> {{org.apache.solr.cloud}} package.
> We should create a {{org.apache.solr.cloud.api.collections}} package and move 
> the respected classes under that.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11819) The schema api reference manual page should not use hyphens in the example field name

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-11819:
--
Summary: The schema api reference manual page should not use hyphens in the 
example field name  (was: The schema api ref page shold not use hyphens in the 
example field name)

> The schema api reference manual page should not use hyphens in the example 
> field name
> -
>
> Key: SOLR-11819
> URL: https://issues.apache.org/jira/browse/SOLR-11819
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-11819.patch
>
>
> Since we specifically recommend that field names follow these rules:
> "Field names should consist of alphanumeric or underscore characters only and 
> not start with a digit."
> we shouldn't model different behavior.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11819) The schema api ref page shold not use hyphens in the example field name

[Erick Erickson (JIRA)]

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

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

Trivial patch fixing the one case I stumbled across, if anyone else knows of 
any other such examples please let me know.

If I don't hear anything by the weekend I'll commit.

Just changes sell-by to sell_by.

> The schema api ref page shold not use hyphens in the example field name
> ---
>
> Key: SOLR-11819
> URL: https://issues.apache.org/jira/browse/SOLR-11819
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-11819.patch
>
>
> Since we specifically recommend that field names follow these rules:
> "Field names should consist of alphanumeric or underscore characters only and 
> not start with a digit."
> we shouldn't model different behavior.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11819) The schema api ref page shold not use hyphens in the example field name

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-11819:
-

 Summary: The schema api ref page shold not use hyphens in the 
example field name
 Key: SOLR-11819
 URL: https://issues.apache.org/jira/browse/SOLR-11819
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Erick Erickson
Priority: Minor


Since we specifically recommend that field names follow these rules:

"Field names should consist of alphanumeric or underscore characters only and 
not start with a digit."

we shouldn't model different behavior.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-11819) The schema api ref page shold not use hyphens in the example field name

[Erick Erickson (JIRA)]

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

Erick Erickson reassigned SOLR-11819:
-

Assignee: Erick Erickson

> The schema api ref page shold not use hyphens in the example field name
> ---
>
> Key: SOLR-11819
> URL: https://issues.apache.org/jira/browse/SOLR-11819
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
>
> Since we specifically recommend that field names follow these rules:
> "Field names should consist of alphanumeric or underscore characters only and 
> not start with a digit."
> we shouldn't model different behavior.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11544) spell-check does not return collations when using search query with filter

[James Dyer (JIRA)]

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

James Dyer resolved SOLR-11544.
---
Resolution: Not A Problem

> spell-check does not return collations when using search query with filter
> --
>
> Key: SOLR-11544
> URL: https://issues.apache.org/jira/browse/SOLR-11544
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3
>Reporter: jIraiya
>Priority: Trivial
>
> Please refer to this thread for more information:
> http://lucene.472066.n3.nabble.com/spell-check-does-not-return-collations-when-using-search-query-with-filter-td4357739.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11798) remove very deprecated code path in HighlightingComponent.inform

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-11798:
---
Fix Version/s: 7.3
   master (8.0)

> remove very deprecated code path in HighlightingComponent.inform
> 
>
> Key: SOLR-11798
> URL: https://issues.apache.org/jira/browse/SOLR-11798
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11798.patch
>
>
> SOLR-1696 https://svn.apache.org/viewvc?view=revision=899572 in 2010 
> deprecated top-level {{}} syntax in {{solrconfig.xml}} in 
> favour of {{}} equivalent syntax.
> The {{SolrConfig.java}} code to read the top-level highlighting syntax 
> _seems_ to be gone but {{HighlightComponent.inform}} itself still supports 
> {{SolrHighlighter}} {{PluginInfo}}.
> This ticket is to formally deprecate the old syntax from Solr 7.3.0 onwards 
> and to stop supporting it from luceneMatchVersion 7.3.0 onwards.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11798) remove very deprecated code path in HighlightingComponent.inform

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-11798:


bq. ... and remove it altogether in master (8x) ...

Yes, indeed. Done as a separate commit for clarity. I think there is no need 
for a separate entry in the 8.0 section of CHANGES.txt as it's just removal of 
deprecated code on master (8x).

> remove very deprecated code path in HighlightingComponent.inform
> 
>
> Key: SOLR-11798
> URL: https://issues.apache.org/jira/browse/SOLR-11798
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11798.patch
>
>
> SOLR-1696 https://svn.apache.org/viewvc?view=revision=899572 in 2010 
> deprecated top-level {{}} syntax in {{solrconfig.xml}} in 
> favour of {{}} equivalent syntax.
> The {{SolrConfig.java}} code to read the top-level highlighting syntax 
> _seems_ to be gone but {{HighlightComponent.inform}} itself still supports 
> {{SolrHighlighter}} {{PluginInfo}}.
> This ticket is to formally deprecate the old syntax from Solr 7.3.0 onwards 
> and to stop supporting it from luceneMatchVersion 7.3.0 onwards.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11798) remove very deprecated code path in HighlightingComponent.inform

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11798:


Commit 5a08fa8bbb1cf26b4af5b71549671c31e1427f44 in lucene-solr's branch 
refs/heads/master from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5a08fa8 ]

SOLR-11798: Remove support for deprecated top-level  syntax in 
solrconfig.xml.
(master branch for 8x only)


> remove very deprecated code path in HighlightingComponent.inform
> 
>
> Key: SOLR-11798
> URL: https://issues.apache.org/jira/browse/SOLR-11798
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11798.patch
>
>
> SOLR-1696 https://svn.apache.org/viewvc?view=revision=899572 in 2010 
> deprecated top-level {{}} syntax in {{solrconfig.xml}} in 
> favour of {{}} equivalent syntax.
> The {{SolrConfig.java}} code to read the top-level highlighting syntax 
> _seems_ to be gone but {{HighlightComponent.inform}} itself still supports 
> {{SolrHighlighter}} {{PluginInfo}}.
> This ticket is to formally deprecate the old syntax from Solr 7.3.0 onwards 
> and to stop supporting it from luceneMatchVersion 7.3.0 onwards.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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 # 1605 - Still Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.sim.TestLargeCluster.testBasic

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at 
__randomizedtesting.SeedInfo.seed([7EACF3E71F19C19C:D556EEF2C0C547B2]:0)
at 
org.apache.solr.cloud.autoscaling.sim.SimSolrCloudTestCase.waitForState(SimSolrCloudTestCase.java:280)
at 
org.apache.solr.cloud.autoscaling.sim.TestLargeCluster.testBasic(TestLargeCluster.java:168)
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)




Build Log:
[...truncated 11752 lines...]
   [junit4] Suite: org.apache.solr.cloud.autoscaling.sim.TestLargeCluster
   [junit4]   2> Creating dataDir: 

[jira] [Resolved] (SOLR-11801) support customisation of the "highlighting" query response element

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-11801.

   Resolution: Fixed
Fix Version/s: 7.3
   master (8.0)

Thanks everyone!

> support customisation of the "highlighting" query response element
> --
>
> Key: SOLR-11801
> URL: https://issues.apache.org/jira/browse/SOLR-11801
> Project: Solr
>  Issue Type: New Feature
>  Components: highlighter
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11801.patch, SOLR-11801.patch, SOLR-11801.patch, 
> SOLR-11801.patch
>
>
> The objective and use case behind the proposed changes is to be able to 
> receive not the out-of-the-box highlighting map
> {code}
> {
>   ...
>   "highlighting" : {
> "MA147LL/A" : {
>   "manu" : [
> "Apple Computer Inc."
>   ]
> }
>   }
> }
> {code}
> as illustrated in 
> https://lucene.apache.org/solr/guide/7_2/highlighting.html#highlighting-in-the-query-response
>  but to be able to alternatively name and customise the highlighting element 
> of the query response to (for example) be like this
> {code}
> {
>   ...
>   "custom_highlighting" : [
> {
>   "id" : "MA147LL/A",
>   "snippets" : {
> "manu" : [
>   "Apple Computer Inc."
> ]
>   }
> }
>   ]
> }
> {code}
> where the highlighting element itself is a list and where the keys of each 
> list element are 'knowable' in advance i.e. they are not 'unknowable' 
> document ids.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11801) support customisation of the "highlighting" query response element

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11801:


Commit b09ee29ba2efad2fb2f0cc452a16142b3b99842e in lucene-solr's branch 
refs/heads/branch_7x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b09ee29 ]

SOLR-11801: Support customisation of the highlighting query response element.
(Ramsey Haddad, Pranav Murugappan, David Smiley, Christine Poerschke)


> support customisation of the "highlighting" query response element
> --
>
> Key: SOLR-11801
> URL: https://issues.apache.org/jira/browse/SOLR-11801
> Project: Solr
>  Issue Type: New Feature
>  Components: highlighter
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11801.patch, SOLR-11801.patch, SOLR-11801.patch, 
> SOLR-11801.patch
>
>
> The objective and use case behind the proposed changes is to be able to 
> receive not the out-of-the-box highlighting map
> {code}
> {
>   ...
>   "highlighting" : {
> "MA147LL/A" : {
>   "manu" : [
> "Apple Computer Inc."
>   ]
> }
>   }
> }
> {code}
> as illustrated in 
> https://lucene.apache.org/solr/guide/7_2/highlighting.html#highlighting-in-the-query-response
>  but to be able to alternatively name and customise the highlighting element 
> of the query response to (for example) be like this
> {code}
> {
>   ...
>   "custom_highlighting" : [
> {
>   "id" : "MA147LL/A",
>   "snippets" : {
> "manu" : [
>   "Apple Computer Inc."
> ]
>   }
> }
>   ]
> }
> {code}
> where the highlighting element itself is a list and where the keys of each 
> list element are 'knowable' in advance i.e. they are not 'unknowable' 
> document ids.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11798) remove very deprecated code path in HighlightingComponent.inform

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11798:


Commit fe6f887f47d5d3c2d43bb97ef27267287966d7a9 in lucene-solr's branch 
refs/heads/branch_7x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fe6f887 ]

SOLR-11798: Formally deprecate top-level  syntax in 
solrconfig.xml in favour of  equivalent syntax.


> remove very deprecated code path in HighlightingComponent.inform
> 
>
> Key: SOLR-11798
> URL: https://issues.apache.org/jira/browse/SOLR-11798
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11798.patch
>
>
> SOLR-1696 https://svn.apache.org/viewvc?view=revision=899572 in 2010 
> deprecated top-level {{}} syntax in {{solrconfig.xml}} in 
> favour of {{}} equivalent syntax.
> The {{SolrConfig.java}} code to read the top-level highlighting syntax 
> _seems_ to be gone but {{HighlightComponent.inform}} itself still supports 
> {{SolrHighlighter}} {{PluginInfo}}.
> This ticket is to formally deprecate the old syntax from Solr 7.3.0 onwards 
> and to stop supporting it from luceneMatchVersion 7.3.0 onwards.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11798) remove very deprecated code path in HighlightingComponent.inform

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11798:


Commit 5d4f029fdd0b916d631d2432e4fd0216c91c8703 in lucene-solr's branch 
refs/heads/master from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5d4f029 ]

SOLR-11798: Formally deprecate top-level  syntax in 
solrconfig.xml in favour of  equivalent syntax.


> remove very deprecated code path in HighlightingComponent.inform
> 
>
> Key: SOLR-11798
> URL: https://issues.apache.org/jira/browse/SOLR-11798
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11798.patch
>
>
> SOLR-1696 https://svn.apache.org/viewvc?view=revision=899572 in 2010 
> deprecated top-level {{}} syntax in {{solrconfig.xml}} in 
> favour of {{}} equivalent syntax.
> The {{SolrConfig.java}} code to read the top-level highlighting syntax 
> _seems_ to be gone but {{HighlightComponent.inform}} itself still supports 
> {{SolrHighlighter}} {{PluginInfo}}.
> This ticket is to formally deprecate the old syntax from Solr 7.3.0 onwards 
> and to stop supporting it from luceneMatchVersion 7.3.0 onwards.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11801) support customisation of the "highlighting" query response element

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11801:


Commit 65c842f9faed1c9de9dce38a247a43c36b82873f in lucene-solr's branch 
refs/heads/master from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=65c842f ]

SOLR-11801: Support customisation of the highlighting query response element.
(Ramsey Haddad, Pranav Murugappan, David Smiley, Christine Poerschke)


> support customisation of the "highlighting" query response element
> --
>
> Key: SOLR-11801
> URL: https://issues.apache.org/jira/browse/SOLR-11801
> Project: Solr
>  Issue Type: New Feature
>  Components: highlighter
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11801.patch, SOLR-11801.patch, SOLR-11801.patch, 
> SOLR-11801.patch
>
>
> The objective and use case behind the proposed changes is to be able to 
> receive not the out-of-the-box highlighting map
> {code}
> {
>   ...
>   "highlighting" : {
> "MA147LL/A" : {
>   "manu" : [
> "Apple Computer Inc."
>   ]
> }
>   }
> }
> {code}
> as illustrated in 
> https://lucene.apache.org/solr/guide/7_2/highlighting.html#highlighting-in-the-query-response
>  but to be able to alternatively name and customise the highlighting element 
> of the query response to (for example) be like this
> {code}
> {
>   ...
>   "custom_highlighting" : [
> {
>   "id" : "MA147LL/A",
>   "snippets" : {
> "manu" : [
>   "Apple Computer Inc."
> ]
>   }
> }
>   ]
> }
> {code}
> where the highlighting element itself is a list and where the keys of each 
> list element are 'knowable' in advance i.e. they are not 'unknowable' 
> document ids.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8197) Make zero counts in heatmap PNG transparent

[Neil Ireson (JIRA)]

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

Neil Ireson commented on SOLR-8197:
---

Thanks for the reply.

Originally I developed a system to explore UK crime statistics, more recently 
this is being used to plot (100+ million) GPS points from a mobile tracking 
app. The heatmap is used to show stop and transition points for various types 
of users and transportation. I was using the fact Solr could send PNG to handle 
the case when the local client or communication speed is limiting the 
responsiveness of the UI. The user can chose where the image is created. 
However due to the sensitivity of the tracking data we use a proxy NodeJS 
server between the client and Solr server, so I could remove the functionality 
to directly present the Solr PNG and instead provide the option to create the 
heatmap image on the proxy server. 

That said I think mapping zero to the transparent value would be useful for 
anyone who wishes to display the PNG, as a "cheap" way to view the heatmap. 



> Make zero counts in heatmap PNG transparent
> ---
>
> Key: SOLR-8197
> URL: https://issues.apache.org/jira/browse/SOLR-8197
> Project: Solr
>  Issue Type: Improvement
>  Components: spatial
>Reporter: Neil Ireson
>Priority: Minor
> Attachments: transparency.patch
>
>
> It would be useful to have transparent zero values so that I can overlay the 
> image as a layer on a map.
> The change just requires altering two methods in SpatialHeatmapFacets.java as 
> follows:
> {code}
> static void writeCountAtColumnRow(BufferedImage image, int rows, int c, int 
> r, int val)
> {
>   image.setRGB(c, rows - 1 - r, val == 0 ? 0 : val ^ 0xFF_00_00_00);
> }
> static int getCountAtColumnRow(BufferedImage image, int rows, int c, int r)
> {
>   int val = image.getRGB(c, rows - 1 - r);
>   return val == 0 ? 0 : val ^ 0xFF_00_00_00;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1117/
Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseG1GC

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.BasicZkTest

Error Message:
SolrCore.getOpenCount()==2

Stack Trace:
java.lang.RuntimeException: SolrCore.getOpenCount()==2
at __randomizedtesting.SeedInfo.seed([806A985CC3249C02]:0)
at org.apache.solr.util.TestHarness.close(TestHarness.java:379)
at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:792)
at 
org.apache.solr.cloud.AbstractZkTestCase.azt_afterClass(AbstractZkTestCase.java:147)
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$7.evaluate(RandomizedRunner.java:897)
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:  junit.framework.TestSuite.org.apache.solr.cloud.BasicZkTest

Error Message:
SolrCore.getOpenCount()==2

Stack Trace:
java.lang.RuntimeException: SolrCore.getOpenCount()==2
at __randomizedtesting.SeedInfo.seed([806A985CC3249C02]:0)
at org.apache.solr.util.TestHarness.close(TestHarness.java:379)
at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:792)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:288)
at jdk.internal.reflect.GeneratedMethodAccessor36.invoke(Unknown Source)
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$7.evaluate(RandomizedRunner.java:897)
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 

[jira] [Commented] (SOLR-11714) AddReplicaSuggester endless loop

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-11714:
---

The infinite loop is because of wrong usage. AddReplica always return non null 
operation as long as there are no policy constraints

> AddReplicaSuggester endless loop
> 
>
> Key: SOLR-11714
> URL: https://issues.apache.org/jira/browse/SOLR-11714
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: 7.2, master (8.0)
>Reporter: Andrzej Bialecki 
>Assignee: Noble Paul
> Attachments: 7.2-disable-search-rate-trigger.diff, SOLR-11714.diff
>
>
> {{SearchRateTrigger}} events are processed by {{ComputePlanAction}} and 
> depending on the condition either a MoveReplicaSuggester or 
> AddReplicaSuggester is selected.
> When {{AddReplicaSuggester}} is selected there's currently a bug in master, 
> due to an API change (Hint.COLL_SHARD should be used instead of Hint.COLL). 
> However, after fixing that bug {{ComputePlanAction}} goes into an endless 
> loop because the suggester endlessly keeps creating new operations.
> Please see the patch that fixes the Hint.COLL_SHARD issue and modifies the 
> unit test to illustrate this failure.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8116) Similarity scores should depend only on freq and norm

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-8116:
-

Commit 8fd7ead940f69a892dfc951a1aa042e8cae806c1 in lucene-solr's branch 
refs/heads/master from [~jpountz]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8fd7ead ]

LUCENE-8116: SimScorer now only takes a frequency and a norm as per-document 
scoring factors.


> Similarity scores should depend only on freq and norm
> -
>
> Key: LUCENE-8116
> URL: https://issues.apache.org/jira/browse/LUCENE-8116
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
> Fix For: master (8.0)
>
> Attachments: LUCENE-8116.patch
>
>
> I would like to enforce that scores only depend on the freq and the norm so 
> that we can index impacts into postings list (LUCENE-4198) and make 
> TermScorer leverage them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (LUCENE-8116) Similarity scores should depend only on freq and norm

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-8116.
--
   Resolution: Fixed
Fix Version/s: master (8.0)

> Similarity scores should depend only on freq and norm
> -
>
> Key: LUCENE-8116
> URL: https://issues.apache.org/jira/browse/LUCENE-8116
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
> Fix For: master (8.0)
>
> Attachments: LUCENE-8116.patch
>
>
> I would like to enforce that scores only depend on the freq and the norm so 
> that we can index impacts into postings list (LUCENE-4198) and make 
> TermScorer leverage them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21211/
Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

5 tests failed.
FAILED:  org.apache.solr.cloud.AliasIntegrationTest.test

Error Message:
Expected collection2 to be created with 1 shard and 1 replica null Live Nodes: 
[127.0.0.1:38537_solr, 127.0.0.1:46795_solr] Last available state: 
DocCollection(collection2//collections/collection2/state.json/3)={   
"pullReplicas":"0",   "replicationFactor":"1",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   
"replicas":{"core_node2":{   "core":"collection2_shard1_replica_n1",
   "base_url":"http://127.0.0.1:46795/solr;,   
"node_name":"127.0.0.1:46795_solr",   "state":"down",   
"type":"NRT",   "leader":"true",   "router":{"name":"compositeId"}, 
  "maxShardsPerNode":"1",   "autoAddReplicas":"false",   "nrtReplicas":"1",   
"tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: Expected collection2 to be created with 1 shard and 1 
replica
null
Live Nodes: [127.0.0.1:38537_solr, 127.0.0.1:46795_solr]
Last available state: 
DocCollection(collection2//collections/collection2/state.json/3)={
  "pullReplicas":"0",
  "replicationFactor":"1",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{"core_node2":{
  "core":"collection2_shard1_replica_n1",
  "base_url":"http://127.0.0.1:46795/solr;,
  "node_name":"127.0.0.1:46795_solr",
  "state":"down",
  "type":"NRT",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "nrtReplicas":"1",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([1C787C0A4478F3D5:942C43D0EA849E2D]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269)
at 
org.apache.solr.cloud.AliasIntegrationTest.test(AliasIntegrationTest.java:185)
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 

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1444 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1444/

14 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.index.TestIndexWriterOnVMError

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([83CDDBF8966A8CD]:0)


FAILED:  
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection

Error Message:
Timeout occured while waiting response from server at: http://127.0.0.1:33154

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:33154
at 
__randomizedtesting.SeedInfo.seed([FAF9F879769FC66B:E99ACA1647F07FCD]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:423)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:339)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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 

[jira] [Commented] (LUCENE-8116) Similarity scores should depend only on freq and norm

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-8116:
-

+1, this is a nice cleanup.

> Similarity scores should depend only on freq and norm
> -
>
> Key: LUCENE-8116
> URL: https://issues.apache.org/jira/browse/LUCENE-8116
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
> Attachments: LUCENE-8116.patch
>
>
> I would like to enforce that scores only depend on the freq and the norm so 
> that we can index impacts into postings list (LUCENE-4198) and make 
> TermScorer leverage them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-11062) Add support for spins metric in Policy

[Noble Paul (JIRA)]

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

Noble Paul reassigned SOLR-11062:
-

Assignee: Noble Paul

> Add support for spins metric in Policy
> --
>
> Key: SOLR-11062
> URL: https://issues.apache.org/jira/browse/SOLR-11062
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, metrics
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
> Fix For: master (8.0), 7.3
>
>
> SOLR-11061 exposes the spin metrics. This issue is to support this metric in 
> the Policy clauses.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11063) Policy should accept disk space as a hint

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-11063:
---

why should this be a hint? does it not belong to policy?


> Policy should accept disk space as a hint
> -
>
> Key: SOLR-11063
> URL: https://issues.apache.org/jira/browse/SOLR-11063
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: master (8.0), 7.3
>
>
> The policy should accept minimum disk space required as a hint and therefore 
> refuse to suggest operations if the hint cannot be satisfied.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-11063) Policy should accept disk space as a hint

[Noble Paul (JIRA)]

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

Noble Paul reassigned SOLR-11063:
-

Assignee: Noble Paul

> Policy should accept disk space as a hint
> -
>
> Key: SOLR-11063
> URL: https://issues.apache.org/jira/browse/SOLR-11063
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
> Fix For: master (8.0), 7.3
>
>
> The policy should accept minimum disk space required as a hint and therefore 
> refuse to suggest operations if the hint cannot be satisfied.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-8116) Similarity scores should depend only on freq and norm

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-8116:
-
Attachment: LUCENE-8116.patch

Here is a patch:
 - It changes the signature from {{score(int doc, float freq)}} to 
{{score(float freq, long norm)}}. 
 - Since SimScorer is no longer tied to a single leaf, SimWeight and SimScorer 
have been merged together.

> Similarity scores should depend only on freq and norm
> -
>
> Key: LUCENE-8116
> URL: https://issues.apache.org/jira/browse/LUCENE-8116
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
> Attachments: LUCENE-8116.patch
>
>
> I would like to enforce that scores only depend on the freq and the norm so 
> that we can index impacts into postings list (LUCENE-4198) and make 
> TermScorer leverage them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (LUCENE-8116) Similarity scores should depend only on freq and norm

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-8116:


 Summary: Similarity scores should depend only on freq and norm
 Key: LUCENE-8116
 URL: https://issues.apache.org/jira/browse/LUCENE-8116
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand


I would like to enforce that scores only depend on the freq and the norm so 
that we can index impacts into postings list (LUCENE-4198) and make TermScorer 
leverage them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-9.0.1) - Build # 1116 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1116/
Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  org.apache.solr.cloud.MoveReplicaHDFSTest.testFailedMove

Error Message:
No live SolrServers available to handle this 
request:[https://127.0.0.1:39465/solr/MoveReplicaHDFSTest_failed_coll_true, 
https://127.0.0.1:41507/solr/MoveReplicaHDFSTest_failed_coll_true]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[https://127.0.0.1:39465/solr/MoveReplicaHDFSTest_failed_coll_true, 
https://127.0.0.1:41507/solr/MoveReplicaHDFSTest_failed_coll_true]
at 
__randomizedtesting.SeedInfo.seed([FD858D7A0D048398:57485E88BAD75648]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:462)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:991)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at 
org.apache.solr.cloud.MoveReplicaTest.testFailedMove(MoveReplicaTest.java:306)
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 

[nag][VOTE] Release PyLucene 7.2.0 (rc1)

[Andi Vajda]

Two more PMC votes are needed to make this release !
Thanks !

-- Forwarded message --
Date: Thu, 21 Dec 2017 03:50:08 -0800 (PST)
From: Andi Vajda 
To: pylucene-dev@lucene.apache.org
Cc: gene...@lucene.apache.org
Subject: [VOTE] Release PyLucene 7.2.0 (rc1)


The PyLucene 7.2.0 (rc1) release tracking the upcoming release of
Apache Lucene 7.2.0 is ready.

A release candidate is available from:
  https://dist.apache.org/repos/dist/dev/lucene/pylucene/7.2.0-rc1/

PyLucene 7.2.0 is built with JCC 3.1 included in these release artifacts.

JCC 3.1 supports Python 3.3+ (in addition to Python 2.3+).
PyLucene may be built with Python 2 or Python 3.

Please vote to release these artifacts as PyLucene 7.2.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

[jira] [Updated] (LUCENE-8115) fail precommit on unnecessary {@inheritDoc} use

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated LUCENE-8115:

Attachment: LUCENE-8115-step2.patch

bq. ... do i have that correct?

Yes, you do. Attached patch clarifies the message associated with the check to 
_"\{@inheritDoc\} on its own is unnecessary"_.

bq. I feel like i'm missing some context/background info here ...

The context here is that an automatic style check and enforcement like this 
seemed to me to be a logical follow-on from [~dsmiley]'s 
[comment|https://issues.apache.org/jira/browse/SOLR-11801?focusedCommentId=16306388=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16306388]
 on SOLR-11801 i.e. if tools can pick up on things like this then human code 
reviewers can focus more on other things and/or code readers are not distracted 
by the unnecessary @inheritDoc clutter and/or code writers are encouraged to 
add supplemental information alongside the @inheritDoc.

> fail precommit on unnecessary {@inheritDoc} use
> ---
>
> Key: LUCENE-8115
> URL: https://issues.apache.org/jira/browse/LUCENE-8115
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-8115-step2.patch, LUCENE-8115-step2.patch
>
>
> * Step 1: identify and remove existing unnecessary {{\{@inheritDoc\}}} use 
> e.g. via IDE tooling or {{git grep -C 1 inheritDoc}}.
> * Step 2: change {{ant validate}} so that precommit fails if/when any new 
> unnecessary {{\{@inheritDoc\}}} are introduced.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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.1) - Build # 380 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/380/
Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseSerialGC

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.rest.schema.TestFieldTypeResource

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.rest.schema.TestFieldTypeResource_24F6D41EE9EF49EC-001\tempDir-001\cores:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.rest.schema.TestFieldTypeResource_24F6D41EE9EF49EC-001\tempDir-001\cores

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.rest.schema.TestFieldTypeResource_24F6D41EE9EF49EC-001\tempDir-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.rest.schema.TestFieldTypeResource_24F6D41EE9EF49EC-001\tempDir-001

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.rest.schema.TestFieldTypeResource_24F6D41EE9EF49EC-001\tempDir-001\cores\core:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.rest.schema.TestFieldTypeResource_24F6D41EE9EF49EC-001\tempDir-001\cores\core

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.rest.schema.TestFieldTypeResource_24F6D41EE9EF49EC-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.rest.schema.TestFieldTypeResource_24F6D41EE9EF49EC-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.rest.schema.TestFieldTypeResource_24F6D41EE9EF49EC-001\tempDir-001\cores:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.rest.schema.TestFieldTypeResource_24F6D41EE9EF49EC-001\tempDir-001\cores
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.rest.schema.TestFieldTypeResource_24F6D41EE9EF49EC-001\tempDir-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.rest.schema.TestFieldTypeResource_24F6D41EE9EF49EC-001\tempDir-001
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.rest.schema.TestFieldTypeResource_24F6D41EE9EF49EC-001\tempDir-001\cores\core:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.rest.schema.TestFieldTypeResource_24F6D41EE9EF49EC-001\tempDir-001\cores\core
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.rest.schema.TestFieldTypeResource_24F6D41EE9EF49EC-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.rest.schema.TestFieldTypeResource_24F6D41EE9EF49EC-001

at __randomizedtesting.SeedInfo.seed([24F6D41EE9EF49EC]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
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:  
junit.framework.TestSuite.org.apache.solr.search.facet.DistributedFacetSimpleRefinementLongTailTest

Error Message:
Could not remove the following files (in the order of attempts):

[jira] [Commented] (SOLR-11501) Depending on the parser, QParser should not parse local-params

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-11501:


ticket cross-reference: SOLR-11809 - it seems QueryComponent's {{rq}} parameter 
parsing can be affected by this change

> Depending on the parser, QParser should not parse local-params
> --
>
> Key: SOLR-11501
> URL: https://issues.apache.org/jira/browse/SOLR-11501
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 7.2
>
> Attachments: SOLR_11501_limit_local_params_parsing.patch, 
> SOLR_11501_limit_local_params_parsing.patch
>
>
> Solr should not parse local-params (and thus be able to switch the query 
> parser) in certain circumstances.  _Perhaps_ it is when the QParser.getParser 
> is passed "lucene" for the {{defaultParser}}?  This particular approach is 
> just a straw-man; I suspect certain valid embedded queries could no longer 
> work if this is done incorrectly.  Whatever the solution, I don't think we 
> should assume 'q' is special, as it's valid and useful to build up queries 
> containing user input in other ways, e.g. {{q= +field:value +\{!dismax 
> v=$qq\}=user input}}  and we want to protect the user input there 
> similarly from unwelcome query parsing switching.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11809) QueryComponent.prepare rq parameter parsing fails under SOLR 7.2

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-11809:
---
Summary: QueryComponent.prepare rq parameter parsing fails under SOLR 7.2  
(was: LTR does not work under SOLR 7.2)

> QueryComponent.prepare rq parameter parsing fails under SOLR 7.2
> 
>
> Key: SOLR-11809
> URL: https://issues.apache.org/jira/browse/SOLR-11809
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2
> Environment: Windows 10, java version "1.8.0_151"
>Reporter: Dariusz Wojtas
> Attachments: SOLR-11809.patch, ltr-sample.zip
>
>
> The LTR functionality that works under SOLR 7.0 and 7.1 stopped working in 
> 7.2.
> From the solr-user mailing list it appears it might be related to SOLR-11501 .
> I am attaching the minimal working collection definition (attached 
> [^ltr-sample.zip]) that shows the problem.
> Please deploy the collection (unpack under "server/solr"), run solr and 
> invoke the URL below.
>   http://localhost:8983/solr/ltr-sample/select?q=*:*
> Behaviour:
> * under 7.0 and 7.1 - empty resultset is returned (there is no data in the 
> collection)
> * under 7.2 - error: "rq parameter must be a RankQuery". The stacktrace
> {code}
> 2018-01-02 20:51:06.807 INFO  (qtp205125520-20) [   x:ltr-sample] 
> o.a.s.c.S.Request [ltr-sample]  webapp=/solr path=/select 
> params={q=*:*&_=1514909140928} status=400 QTime=23
> 2018-01-02 21:04:27.293 ERROR (qtp205125520-17) [   x:ltr-sample] 
> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: rq parameter 
> must be a RankQuery
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:183)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:269)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2503)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:710)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
>   [..]
> {code}
> i have checked - the same issue exists when I try to invoke the _rerank_ 
> query parser.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11809) LTR does not work under SOLR 7.2

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-11809:
---
Attachment: SOLR-11809.patch

Hello [~dwoj...@gmail.com] - thanks for noticing and reporting this problem, 
first on the [mailing list|http://apache.markmail.org/thread/rnj6wlncka7lblrh] 
and then with attachment here.

Please find attached a draft patch which would (probably) fix the issue.

next steps (help welcome):
(1) code review input and confirmation the draft patch solves the issue
(2) decide on name for the new parameter and create/use relevant constant
(3) update [Solr Ref 
Guide|https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide] to 
mention new parameter where 'rq' parameter is mentioned in general and 
specifically for the rerank and ltr parser entries

> LTR does not work under SOLR 7.2
> 
>
> Key: SOLR-11809
> URL: https://issues.apache.org/jira/browse/SOLR-11809
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2
> Environment: Windows 10, java version "1.8.0_151"
>Reporter: Dariusz Wojtas
> Attachments: SOLR-11809.patch, ltr-sample.zip
>
>
> The LTR functionality that works under SOLR 7.0 and 7.1 stopped working in 
> 7.2.
> From the solr-user mailing list it appears it might be related to SOLR-11501 .
> I am attaching the minimal working collection definition (attached 
> [^ltr-sample.zip]) that shows the problem.
> Please deploy the collection (unpack under "server/solr"), run solr and 
> invoke the URL below.
>   http://localhost:8983/solr/ltr-sample/select?q=*:*
> Behaviour:
> * under 7.0 and 7.1 - empty resultset is returned (there is no data in the 
> collection)
> * under 7.2 - error: "rq parameter must be a RankQuery". The stacktrace
> {code}
> 2018-01-02 20:51:06.807 INFO  (qtp205125520-20) [   x:ltr-sample] 
> o.a.s.c.S.Request [ltr-sample]  webapp=/solr path=/select 
> params={q=*:*&_=1514909140928} status=400 QTime=23
> 2018-01-02 21:04:27.293 ERROR (qtp205125520-17) [   x:ltr-sample] 
> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: rq parameter 
> must be a RankQuery
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:183)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:269)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2503)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:710)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
>   [..]
> {code}
> i have checked - the same issue exists when I try to invoke the _rerank_ 
> query parser.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9.0.1) - Build # 21210 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21210/
Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.autoscaling.SystemLogListenerTest

Error Message:
Error from server at https://127.0.0.1:36641/solr: create the collection time 
out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:36641/solr: create the collection time out:180s
at __randomizedtesting.SeedInfo.seed([832CD6F5EBD17C46]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.cloud.autoscaling.SystemLogListenerTest.setupCluster(SystemLogListenerTest.java:84)
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$6.evaluate(RandomizedRunner.java:874)
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)




Build Log:
[...truncated 12256 lines...]
   [junit4] Suite: org.apache.solr.cloud.autoscaling.SystemLogListenerTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.autoscaling.SystemLogListenerTest_832CD6F5EBD17C46-001/init-core-data-001
   [junit4]   2> 660244 WARN  
(SUITE-SystemLogListenerTest-seed#[832CD6F5EBD17C46]-worker) [] 
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=95 numCloses=95
   [junit4]   2> 660244 INFO  
(SUITE-SystemLogListenerTest-seed#[832CD6F5EBD17C46]-worker) [] 
o.a.s.SolrTestCaseJ4 Using TrieFields (NUMERIC_POINTS_SYSPROP=false) 
w/NUMERIC_DOCVALUES_SYSPROP=true
   [junit4]   2> 660245 INFO  
(SUITE-SystemLogListenerTest-seed#[832CD6F5EBD17C46]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: 

[jira] [Commented] (SOLR-11813) Reuse a NodeStateProvider in a session

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11813:


Commit 37d8bcdfa3bd74b53b9d2ab0ec04f8753274009a in lucene-solr's branch 
refs/heads/branch_7x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=37d8bcd ]

SOLR-11813: Reuse a NodeStateProvider in a session


> Reuse a NodeStateProvider in a session
> --
>
> Key: SOLR-11813
> URL: https://issues.apache.org/jira/browse/SOLR-11813
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-11813.patch
>
>
> now for each session/each node a new NodeStateProvider is created. This makes 
> policy computations extremely slow and sometimes wrong (if the node values 
> change in between)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11813) Reuse a NodeStateProvider in a session

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11813:


Commit 8836fda95f005294960ee4df807d55eafb41f68e in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8836fda ]

SOLR-11813: Reuse a NodeStateProvider in a session


> Reuse a NodeStateProvider in a session
> --
>
> Key: SOLR-11813
> URL: https://issues.apache.org/jira/browse/SOLR-11813
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-11813.patch
>
>
> now for each session/each node a new NodeStateProvider is created. This makes 
> policy computations extremely slow and sometimes wrong (if the node values 
> change in between)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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.1) - Build # 7092 - Still Unstable!

[Policeman Jenkins Server]

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

6 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestGenericDistributedQueue.testDistributedQueue

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([EBC06C30F396FC73]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.autoscaling.sim.TestGenericDistributedQueue

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([EBC06C30F396FC73]:0)


FAILED:  org.apache.solr.handler.TestSQLHandler.doTest

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([EBC06C30F396FC73:4C84D4949E2DEFCA]:0)
at 
org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:196)
at org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:82)
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.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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