[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-9.0.1) - Build # 7090 - Still Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_668051C2F85B7732-001\tempDir-001\collection1\conf:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_668051C2F85B7732-001\tempDir-001\collection1\conf

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_668051C2F85B7732-001\tempDir-001\collection1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_668051C2F85B7732-001\tempDir-001\collection1

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_668051C2F85B7732-001\tempDir-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_668051C2F85B7732-001\tempDir-001

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_668051C2F85B7732-001\tempDir-001\collection1\conf\en-test-sent.bin:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_668051C2F85B7732-001\tempDir-001\collection1\conf\en-test-sent.bin

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_668051C2F85B7732-001\tempDir-001\collection1\conf\en-test-tokenizer.bin:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_668051C2F85B7732-001\tempDir-001\collection1\conf\en-test-tokenizer.bin

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_668051C2F85B7732-001\tempDir-001\collection1\conf\en-test-ner-person.bin:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_668051C2F85B7732-001\tempDir-001\collection1\conf\en-test-ner-person.bin

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_668051C2F85B7732-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_668051C2F85B7732-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_668051C2F85B7732-001\tempDir-001\collection1\conf:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_668051C2F85B7732-001\tempDir-001\collection1\conf
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_668051C2F85B7732-001\tempDir-001\collection1:
 java.nio.file.DirectoryNotEmptyException: 

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.schema.ManagedSchemaRoundRobinCloudTest

Error Message:
Error from server at https://127.0.0.1:41313/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:41313/solr: create the collection time out:180s
at __randomizedtesting.SeedInfo.seed([627E21C664583B7F]: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.schema.ManagedSchemaRoundRobinCloudTest.setupCluster(ManagedSchemaRoundRobinCloudTest.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)


FAILED:  org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest.test

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

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:41615/ofs
at 
__randomizedtesting.SeedInfo.seed([627E21C664583B7F:EA2A1E1CCAA45687]: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 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Error from server at 
https://127.0.0.1:61463/solr/awhollynewcollection_0_shard1_replica_n1: 
ClusterState says we are the leader 
(https://127.0.0.1:61463/solr/awhollynewcollection_0_shard1_replica_n1), but 
locally we don't think so. Request came from null

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at 
https://127.0.0.1:61463/solr/awhollynewcollection_0_shard1_replica_n1: 
ClusterState says we are the leader 
(https://127.0.0.1:61463/solr/awhollynewcollection_0_shard1_replica_n1), but 
locally we don't think so. Request came from null
at 
__randomizedtesting.SeedInfo.seed([98ED1ADA2EBE5D42:D0986E6E288D72D7]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:550)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1013)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:460)
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 

[jira] [Updated] (SOLR-11653) create next time collection based on a fixed time gap

[David Smiley (JIRA)]

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

David Smiley updated SOLR-11653:

Attachment: SOLR-11653.patch

New patch...
* renamed "head" terminology to "mostRecent"
* URP:
** No longer will retry 5 times if makes no progress. This is probably best and 
it simplifies understanding the loop.  As long as the alias is getting updated 
after createCollectionAfter is called (thus it appears we're making progress), 
we retry.
** refactored a updateParsedCollectionAliases method out of 
findTargetCollectionGivenTimestamp so we can call it separately.
** createCollectionAfter now forces an update to the aliases to ensure we'll 
see changes (if there were any).  Otherwise, it's possible the ZK watcher is 
slow to update and we may think no alias state progress has occurred when it's 
imminent
** added a locking mechanism in the URP to avoid needless concurrent messages 
to the Overseer from the same JVM to add another collection
* added parallel updates to test
* Improved the OverseerTaskProcessor flow I referred to before

I beasted the test a bit; and it has survived.  Earlier I was stumped by 
consistently getting a failure "collection already exists: myalias_2017-10-24" 
whenever tests.iters was > 1.  This is the first collection the test creates 
that is not ultimately deleted.  Yet I thought it wasn't necessary to clean up 
unused collections in tests... so maybe there is a test infrastructure bug 
here?  I found some other similar but simpler test, ConfigSetsAPITest, and 
tried to see if it fails similarly but it does not.  I haven't dug into why but 
it's at least easy to deal with -- just clean up when done.

I wonder what would happen if the collection is partially created but not 
completely for whatever reason (e.g. overloaded system).  Would it ultimately 
recover?  Probably not; you'd have to manually (via e.g. HTTP API call) delete 
the collection that was never ultimately added to the alias.

> create next time collection based on a fixed time gap
> -
>
> Key: SOLR-11653
> URL: https://issues.apache.org/jira/browse/SOLR-11653
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR-11653.patch, SOLR-11653.patch, SOLR-11653.patch
>
>
> For time series collections (as part of a collection Alias with certain 
> metadata), we want to automatically add new collections. In this issue, this 
> is about creating the next collection based on a configurable fixed time gap. 
>  And we will also add this collection synchronously once a document flowing 
> through the URP chain exceeds the gap, as opposed to asynchronously in 
> advance.  There will be some Alias metadata to define in this issue.  The 
> preponderance of the implementation will be in TimePartitionedUpdateProcessor 
> or perhaps a helper to this URP.
> note: other issues will implement pre-emptive creation and capping 
> collections by size.



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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testEventQueue

Error Message:
action wasn't interrupted

Stack Trace:
java.lang.AssertionError: action wasn't interrupted
at 
__randomizedtesting.SeedInfo.seed([5BFC67CD2302993B:924925632A655FCE]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testEventQueue(TriggerIntegrationTest.java:711)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  org.apache.solr.metrics.reporters.solr.SolrShardReporterTest.test

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

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:44667

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly

Error Message:
Unexpected number of elements in the group for intGSF: 8

Stack Trace:
java.lang.AssertionError: Unexpected number of elements in the group for 
intGSF: 8
at 
__randomizedtesting.SeedInfo.seed([CDE0861F80EE206D:565BE847CDB61233]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly(DocValuesNotIndexedTest.java:377)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 11633 lines...]
   [junit4] Suite: org.apache.solr.cloud.DocValuesNotIndexedTest
   [junit4]   2> Creating dataDir: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/solr/build/solr-core/test/J1/temp/solr.cloud.DocValuesNotIndexedTest_CDE0861F80EE206D-001/init-core-data-001
   [junit4]   

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

[Policeman Jenkins Server]

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

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

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at 
__randomizedtesting.SeedInfo.seed([4A6ABB09D249B2AC:C23E84D37CB5DF54]: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.TestLeaderElectionWithEmptyReplica.test(TestLeaderElectionWithEmptyReplica.java:97)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  org.apache.solr.schema.TestCloudSchemaless.test

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

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response 

[jira] [Commented] (SOLR-11783) Rename core in solr standalone mode is not persisted

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-11783:
---

Fair point, I'll try to remember that in the future. But yeah, I agree that 
this would be part of a larger effort.


> Rename core in solr standalone mode is not persisted
> 
>
> Key: SOLR-11783
> URL: https://issues.apache.org/jira/browse/SOLR-11783
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server
>Affects Versions: 7.1
>Reporter: Michael Dürr
>Assignee: Erick Erickson
> Fix For: 7.3
>
>
> After I upgraded from solr 6.3.0 to 7.1.0 I recognized that the RENAME admin 
> command does not persist the new core name to the core.properties file.
> I'm not very familiar with the solr internals, but it seems like the 
> {quote}CorePropertiesLocator.buildCoreProperties(CoreDescriptor cd){quote} 
> method uses an invalid core descriptor to initialize the core properties that 
> get written to the core properties file.
> Best regards,
> Michael



--
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-896) Solr Query Parser Plugin for Mark Miller's Qsol Parser

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-896.
-
Resolution: Won't Fix

As Mark hasn't maintained this for a long time and it's ancient, I'm closing. 
We can open a new JIRA if anyone's still interested.

> Solr Query Parser Plugin for Mark Miller's Qsol Parser
> --
>
> Key: SOLR-896
> URL: https://issues.apache.org/jira/browse/SOLR-896
> Project: Solr
>  Issue Type: New Feature
>  Components: query parsers
>Reporter: Chris Harris
> Attachments: SOLR-896.patch, SOLR-896.patch, SOLR-896.patch
>
>
> An extremely basic plugin to get the Qsol query parser 
> (http://www.myhardshadow.com/qsol.php) working in Solr.



--
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-4313) null:org.eclipse.jetty.io.EofException

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-4313.
--
Resolution: Won't Fix

Closing since jetty has moved forward quite a bit since Solr 4.0, we can reopen 
if necessar.

> null:org.eclipse.jetty.io.EofException
> --
>
> Key: SOLR-4313
> URL: https://issues.apache.org/jira/browse/SOLR-4313
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 4.0
> Environment: CentOs, SolrCloud on 4x Systems, 2x Leaders with 2x 
> Replicas, zooKeeper standalone (Two shard cluster with shard replicas and 
> zookeeper ensemble), internal jetty
>Reporter: Ota Mares
>
> Our Solr dashboard logging overview is spammed every few seconds with 
> following SEVERE Exception message:
> SEVERE
> SolrDispatchFilter
> null:org.eclipse.jetty.io.EofException
> Exception Stack Trace:
> SEVERE: null:org.eclipse.jetty.io.EofException
> at 
> org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:952)
> at 
> org.eclipse.jetty.http.AbstractGenerator.flush(AbstractGenerator.java:438)
> at org.eclipse.jetty.server.HttpOutput.flush(HttpOutput.java:94)
> at 
> org.eclipse.jetty.server.AbstractHttpConnection$Output.flush(AbstractHttpConnection.java:1022)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at org.apache.solr.util.FastWriter.flush(FastWriter.java:137)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.writeResponse(SolrDispatchFilter.java:412)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:289)
> 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)
> Unfortunately i currently dont have more information to provide, but am 
> willing to lookup further details if someone can point me into the right 
> direction.



--
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-11810) Upgrade Jetty to 9.4.x

[Varun Thacker (JIRA)]

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

Varun Thacker reassigned SOLR-11810:


Assignee: Varun Thacker

> Upgrade Jetty to 9.4.x 
> ---
>
> Key: SOLR-11810
> URL: https://issues.apache.org/jira/browse/SOLR-11810
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Attachments: SOLR-11810.patch
>
>
> Jetty 9.4.x was released over a year back : 
> https://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00097.html .  Solr 
> doesn't use any of the major improvements listed on the announce thread but 
> it's the version that's in active development. 
> We should upgrade to Jetty 9.4.x series from 9.3.x
> The latest version right now is 9.4.8.v20171121 . Upgrading it locally 
> required a few compile time changes only. 
> Under "Default Sessions" in 
> https://www.eclipse.org/jetty/documentation/9.4.x/upgrading-jetty.html#_upgrading_from_jetty_9_3_x_to_jetty_9_4_0
>   it states that "In previous versions of Jetty this was referred to as 
> "hash" session management." . 
> The patch fixes all the compile time issues.
> Currently two tests are failing:
> TestRestManager
> TestManagedSynonymGraphFilterFactory
> Steps to upgrade the Jetty version were :
> 1. Modify {{ivy-versions.properties}} to reflect the new version number
> 2. Run {{ant jar-checksums}} to generate new JAR checksums



--
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-11810) Upgrade Jetty to 9.4.x

[Varun Thacker (JIRA)]

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

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

> Upgrade Jetty to 9.4.x 
> ---
>
> Key: SOLR-11810
> URL: https://issues.apache.org/jira/browse/SOLR-11810
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
> Attachments: SOLR-11810.patch
>
>
> Jetty 9.4.x was released over a year back : 
> https://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00097.html .  Solr 
> doesn't use any of the major improvements listed on the announce thread but 
> it's the version that's in active development. 
> We should upgrade to Jetty 9.4.x series from 9.3.x
> The latest version right now is 9.4.8.v20171121 . Upgrading it locally 
> required a few compile time changes only. 
> Under "Default Sessions" in 
> https://www.eclipse.org/jetty/documentation/9.4.x/upgrading-jetty.html#_upgrading_from_jetty_9_3_x_to_jetty_9_4_0
>   it states that "In previous versions of Jetty this was referred to as 
> "hash" session management." . 
> The patch fixes all the compile time issues.
> Currently two tests are failing:
> TestRestManager
> TestManagedSynonymGraphFilterFactory
> Steps to upgrade the Jetty version were :
> 1. Modify {{ivy-versions.properties}} to reflect the new version number
> 2. Run {{ant jar-checksums}} to generate new JAR checksums



--
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-11810) Upgrade Jetty to 9.4.x

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-11810:


 Summary: Upgrade Jetty to 9.4.x 
 Key: SOLR-11810
 URL: https://issues.apache.org/jira/browse/SOLR-11810
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Varun Thacker


Jetty 9.4.x was released over a year back : 
https://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00097.html .  Solr 
doesn't use any of the major improvements listed on the announce thread but 
it's the version that's in active development. 

We should upgrade to Jetty 9.4.x series from 9.3.x

The latest version right now is 9.4.8.v20171121 . Upgrading it locally required 
a few compile time changes only. 


Under "Default Sessions" in 
https://www.eclipse.org/jetty/documentation/9.4.x/upgrading-jetty.html#_upgrading_from_jetty_9_3_x_to_jetty_9_4_0
  it states that "In previous versions of Jetty this was referred to as "hash" 
session management." . 

The patch fixes all the compile time issues.
Currently two tests are failing:
TestRestManager
TestManagedSynonymGraphFilterFactory

Steps to upgrade the Jetty version were :
1. Modify {{ivy-versions.properties}} to reflect the new version number
2. Run {{ant jar-checksums}} to generate new JAR checksums




--
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-9145) Support Jetty 9.3.9.v20160517

[Varun Thacker (JIRA)]

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

Varun Thacker resolved SOLR-9145.
-
Resolution: Won't Fix
  Assignee: Varun Thacker

We're currently on 9.3.20.v20170531 which was done as part of SOLR-11249 . So 
we can close out this issue

> Support Jetty 9.3.9.v20160517
> -
>
> Key: SOLR-9145
> URL: https://issues.apache.org/jira/browse/SOLR-9145
> Project: Solr
>  Issue Type: Bug
>Reporter: Bill Bell
>Assignee: Varun Thacker
>
> Jetty new version is released. Do we support on 5.5 and 6.0 ?
> 9.3.9.v20160517



--
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/jdk1.8.0_144) - Build # 1105 - Still Unstable!

[Policeman Jenkins Server]

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

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

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=12549, name=jetty-launcher-5501-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)   
 2) Thread[id=12559, name=jetty-launcher-5501-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=12549, name=jetty-launcher-5501-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 

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

[Policeman Jenkins Server]

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

21 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.analysis.TestLuceneMatchVersion

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\J0\temp\solr.analysis.TestLuceneMatchVersion_1BE7A5B52248A002-001\init-core-data-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.analysis.TestLuceneMatchVersion_1BE7A5B52248A002-001\init-core-data-001

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.analysis.TestLuceneMatchVersion_1BE7A5B52248A002-001\init-core-data-001\spellchecker1:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.analysis.TestLuceneMatchVersion_1BE7A5B52248A002-001\init-core-data-001\spellchecker1

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.analysis.TestLuceneMatchVersion_1BE7A5B52248A002-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.analysis.TestLuceneMatchVersion_1BE7A5B52248A002-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\J0\temp\solr.analysis.TestLuceneMatchVersion_1BE7A5B52248A002-001\init-core-data-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.analysis.TestLuceneMatchVersion_1BE7A5B52248A002-001\init-core-data-001
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.analysis.TestLuceneMatchVersion_1BE7A5B52248A002-001\init-core-data-001\spellchecker1:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.analysis.TestLuceneMatchVersion_1BE7A5B52248A002-001\init-core-data-001\spellchecker1
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.analysis.TestLuceneMatchVersion_1BE7A5B52248A002-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.analysis.TestLuceneMatchVersion_1BE7A5B52248A002-001

at __randomizedtesting.SeedInfo.seed([1BE7A5B52248A002]: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.cloud.TestPullReplica

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.cloud.TestPullReplica_1BE7A5B52248A002-001\tempDir-001\zookeeper\server1\data\version-2:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestPullReplica_1BE7A5B52248A002-001\tempDir-001\zookeeper\server1\data\version-2

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestPullReplica_1BE7A5B52248A002-001\tempDir-001\zookeeper\server1\data:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestPullReplica_1BE7A5B52248A002-001\tempDir-001\zookeeper\server1\data

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

[Policeman Jenkins Server]

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

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

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

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:39415
at 
__randomizedtesting.SeedInfo.seed([9ADC4EA09FD73476:1288717A312B598E]: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 
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)
   

[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=16308740#comment-16308740
 ] 

Hoss Man commented on LUCENE-8099:
--

I'm coming at this kind of late -- but I have to say i'm -1 to this change.

What exactly is the motivation here?

If the goal is to reduce "similar" code in Lucene, then that's fine -- we 
can/should certainly refactor these classes to consolidate their implementation 
-- but why deprecate/remove them completely?

Look at this example of a suggested replcament in the javadocs...

{noformat}
 * Query balancedQuery = new BoostingQuery(positiveQuery, negativeQuery, 
0.01f);
...
 * Clients should instead use FunctionScoreQuery and the lucene-expressions 
library:
 * 
 *   SimpleBindings bindings = new SimpleBindings();
 *   bindings.add("score", DoubleValuesSource.SCORES);
 *   bindings.add("context", DoubleValuesSource.fromQuery(new 
ConstantScoreQuery(myContextQuery, boost)));
 *   Expression expr = JavascriptCompiler.compile("score * context");
 *   FunctionScoreQuery q = new FunctionScoreQuery(inputQuery, 
expr.getDoubleValuesSource(bindings));
 * 
{noformat}

...even if that new code is just as efficient as the old code (Is it???) why 
make our users replace 1 line with 7?  Why should a "novice" user who wants to 
use a simple concept like a "boosted query" need to dig into understanding 
"Expression Bindings" and ValueSources??

Why aren't we just refactoring the *internals* of classes like 
{{BoostingQuery}} so that they subclass FunctionScoreQuery and provide (simple) 
backcompat constructors?



Also: Why does this change flat out remove all the existing test code of these 
deprecated/removed classes?  

Even if the classes are being removed, shouldn't the eisting tests be 
refactored to assert that the "new" way of doing things (via 
FunctionScoreQuery) produces the same "expected" results?

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

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

[Dariusz Wojtas (JIRA)]

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

Dariusz Wojtas updated SOLR-11809:
--
Description: 
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.

  was:
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}


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

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

[Dariusz Wojtas (JIRA)]

Dariusz Wojtas created SOLR-11809:
-

 Summary: 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: 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}



--
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/jdk1.8.0_144) - Build # 7089 - Still Unstable!

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.codecs.memory.TestMemoryPostingsFormat

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

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

at __randomizedtesting.SeedInfo.seed([B5D6AE7BB991AEAB]: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.TestMmapDirectory

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestMmapDirectory_81E8713CF1423D64-001\tempDir-006:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestMmapDirectory_81E8713CF1423D64-001\tempDir-006
 

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\core\test\J1\temp\lucene.store.TestMmapDirectory_81E8713CF1423D64-001\tempDir-006:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestMmapDirectory_81E8713CF1423D64-001\tempDir-006

at __randomizedtesting.SeedInfo.seed([81E8713CF1423D64]: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 

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 917 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 28246 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 491 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.11 sec (2.2 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-8.0.0-src.tgz...
   [smoker] 30.1 MB in 0.08 sec (362.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.tgz...
   [smoker] 72.2 MB in 0.26 sec (278.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.zip...
   [smoker] 82.7 MB in 0.15 sec (558.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6229 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6229 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] 
   [smoker] command "export JAVA_HOME="/home/jenkins/tools/java/latest1.8" 
PATH="/home/jenkins/tools/java/latest1.8/bin:$PATH" 
JAVACMD="/home/jenkins/tools/java/latest1.8/bin/java"; ant clean test 
-Dtests.slow=false" failed:
   [smoker] Buildfile: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-8.0.0/build.xml
   [smoker] 
   [smoker] clean:
   [smoker][delete] Deleting directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-8.0.0/build
   [smoker] 
   [smoker] ivy-availability-check:
   [smoker] [loadresource] Do not set property disallowed.ivy.jars.list as its 
length is 0.
   [smoker] 
   [smoker] -ivy-fail-disallowed-ivy-version:
   [smoker] 
   [smoker] ivy-fail:
   [smoker] 
   [smoker] ivy-configure:
   [smoker] [ivy:configure] :: Apache Ivy 2.4.0 - 20141213170938 :: 
http://ant.apache.org/ivy/ ::
   [smoker] [ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-8.0.0/top-level-ivy-settings.xml
   [smoker] 
   [smoker] -clover.load:
   [smoker] 
   [smoker] resolve-groovy:
   [smoker] [ivy:cachepath] :: resolving dependencies :: 
org.codehaus.groovy#groovy-all-caller;working
   [smoker] [ivy:cachepath] confs: [default]
   [smoker] [ivy:cachepath] found org.codehaus.groovy#groovy-all;2.4.12 in 
public
   [smoker] [ivy:cachepath] :: resolution report :: resolve 912ms :: artifacts 
dl 3ms
   [smoker] 
-
   [smoker] |  |modules||   
artifacts   |
   [smoker] |   conf   | number| search|dwnlded|evicted|| 
number|dwnlded|
   [smoker] 
-
   [smoker] |  default |   1   |   0   |   0   |   0   ||   1   |   
0   |
   [smoker] 
-
   [smoker] 
   [smoker] -init-totals:
   [smoker] 
   [smoker] test-core:
   [smoker] 
   [smoker] -clover.disable:
   [smoker] 
   [smoker] ivy-availability-check:
   [smoker] [loadresource] Do not set property disallowed.ivy.jars.list as its 
length is 0.
   [smoker] 
   [smoker] -ivy-fail-disallowed-ivy-version:
   [smoker] 
   [smoker] ivy-fail:
   [smoker] 
   [smoker] ivy-configure:
   [smoker] [ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-8.0.0/top-level-ivy-settings.xml
   [smoker] 
   [smoker] -clover.load:
   [smoker] 
   [smoker] 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.security.TestAuthorizationFramework.authorizationFrameworkTest

Error Message:
Timeout occured while waiting response from server at: https://127.0.0.1:43539

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: https://127.0.0.1:43539
at 
__randomizedtesting.SeedInfo.seed([CB22707201955A52:858105A1104E4B42]: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 

[jira] [Commented] (SOLR-11653) create next time collection based on a fixed time gap

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11653:
-

* I don't believe this patch exposes ROUTEDALIAS_CREATECOLL through v1 or v2; 
it takes internal code to invoke it.  Notice there is no reference to it in 
CollectionsHandler.  Eventually I do think it will be a useful command but I 
don't want to lengthen this issue with documenting it, ensuring v1 & v2, and 
thinking about it's API which might need work.  The first patch iteration 
exposed it but 2nd patch removed it from CollectionsHandler for the above 
reasons.
* RE Why the "extra layer":  Very good question; I should add some explanatory 
docs. I think you are wondering why does RoutedAliasCreateCollectionCmd exist 
as such when our URP could do the same actions? In my work for the Harvard BOP 
project, I approached it that way in fact.  The reason is that by adding an 
Overseer command, I can get code to operate in a mutex/lock by the alias name, 
thus ensuring that the choice of the next collection name & it's creation and 
addition to the alias happens atomically.  This isn't critical at the moment 
because the next collection name is deterministic, and thus could be handled at 
the URP with retries.  But eventually we'd like to have it be more dynamic like 
when a size threshold is reached, or simply because the user wants to (calls an 
API to make it happen on-demand).  Without a lock, I think it's impossible to 
support that.
** It does seem to be a shame that I need to create an Overseer command just to 
get a cluster lock on the alias name... not that it's *that* big a deal. I 
suppose using ZooKeeper directly (or probably better Curator) but unless other 
parts of Solr are doing this (I don't think so?), I don't want time routed 
aliases to be the first to break the mold.
** BTW I think it's silly that all the alias operations are Overseer commands 
since they merely do atomic operations against ZooKeeper (that compare the 
version) so what's the point?
* RE "+1SECOND" sure that's perhaps not realistic but I'm not sure we want to 
insist you can't do it.  We already round away unnecessary _00 suffixes of 
seconds, minutes, and hours.
* RE create collection loop: What is not clear in the patch is that 
parsedCollectionAliases is going to be updated with every new collection (since 
it gets prepended to the alias).  I want to improve the clarity of the logic to 
instead have it examine the head collection name to see that it's different.  
And maybe we don't need 5 retries; maybe none or make it configurable?
* Yes in SOLR-11722 please add maxFutureMS.  But I don't think that issue 
should create more than the initial collection.
* In a couple cases you've mentioned creating the next collection in advance of 
it being needed.  Yes absolutely, LucidWorks' Fusion appropriately calls this 
"preemptive" creation BTW. But I want to make that a separate feature we can 
work on later, these issues open now have enough to do without worrying about 
that :-)
* Ah, I really like your suggestion of "most recent" naming... thus I'll do 
some renames even if it's more wordy.

> create next time collection based on a fixed time gap
> -
>
> Key: SOLR-11653
> URL: https://issues.apache.org/jira/browse/SOLR-11653
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR-11653.patch, SOLR-11653.patch
>
>
> For time series collections (as part of a collection Alias with certain 
> metadata), we want to automatically add new collections. In this issue, this 
> is about creating the next collection based on a configurable fixed time gap. 
>  And we will also add this collection synchronously once a document flowing 
> through the URP chain exceeds the gap, as opposed to asynchronously in 
> advance.  There will be some Alias metadata to define in this issue.  The 
> preponderance of the implementation will be in TimePartitionedUpdateProcessor 
> or perhaps a helper to this URP.
> note: other issues will implement pre-emptive creation and capping 
> collections by size.



--
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-8115) fail precommit on unnecessary {@inheritDoc} use

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-8115:
--

sorry -- i think i answered my own question by re-reading the regex in the 
patch a few more times and thinking it through...

IIUC this issue is not about defining *any* use of \@inheritDoc as 
unneccessary, it's about identifying and preventing the specific situation of 
\@inheritDoc usage that is fundementally unneccessary because there is no other 
content in the javadoc.

Ie:  {{/\*\* \{@inheritDoc\} \*/}} is an "unneccessary" use of the tag, because 
we get the same effect by eliminating the javadoc completley.  Meanwhile 
something like {{/\*\* Just like our parent but better \{@inheritDoc\} \*/}} 
would still be allowed.

do i have that correct?

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

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

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-8115:
--

I feel like i'm missing some context/background info here (possible because i'm 
very behind on my email and this jira just happened to catch my eye)...

when/why/how has it been decided that using \@inheritDoc is unnecessary?

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

[jira] [Commented] (SOLR-11783) Rename core in solr standalone mode is not persisted

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-11783:
-

[~erickerickson], small nitpick that's probably not actually so small:

I noticed that there's new code using File.  Although there seems to be plenty 
of old code using it also.

IMHO, it all ought to be replaced with nio2.  This might be part of a much 
larger overhaul affecting a LOT of code.  I believe that such an overhaul has 
already happened in critical parts of Lucene.


> Rename core in solr standalone mode is not persisted
> 
>
> Key: SOLR-11783
> URL: https://issues.apache.org/jira/browse/SOLR-11783
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server
>Affects Versions: 7.1
>Reporter: Michael Dürr
>Assignee: Erick Erickson
> Fix For: 7.3
>
>
> After I upgraded from solr 6.3.0 to 7.1.0 I recognized that the RENAME admin 
> command does not persist the new core name to the core.properties file.
> I'm not very familiar with the solr internals, but it seems like the 
> {quote}CorePropertiesLocator.buildCoreProperties(CoreDescriptor cd){quote} 
> method uses an invalid core descriptor to initialize the core properties that 
> get written to the core properties file.
> Best regards,
> Michael



--
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-8107) GeoExactCircleTest.RandomPointBearingCardinalTest failures

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-8107:
---
Fix Version/s: (was: 7.2)
   7.3

> GeoExactCircleTest.RandomPointBearingCardinalTest failures
> --
>
> Key: LUCENE-8107
> URL: https://issues.apache.org/jira/browse/LUCENE-8107
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Karl Wright
> Fix For: 6.7, master (8.0), 7.3
>
> Attachments: LUCENE-8107.patch
>
>
> I hit some reproducing failures over the weekend:
> {noformat}
> ant test  -Dtestcase=GeoExactCircleTest 
> -Dtests.method=RandomPointBearingCardinalTest -Dtests.seed=30B96A8700F32D8F 
> -Dtests.slow=true -Dtests.locale=ar-SD -Dtests.timezone=Turkey 
> -Dtests.asserts=true -Dtests.file.encoding=UTF8
> [junit4] FAILURE 0.01s J0 | GeoExactCircleTest.RandomPointBearingCardinalTest 
> {seed=[30B96A8700F32D8F:475E54A204015A1C]} <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> PlanetModel(ab=1.7929995623606008 c=1.1596251282) 0.022823921875714692 
> 2.6270976802297388
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([30B96A8700F32D8F:475E54A204015A1C]:0)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.checkBearingPoint(GeoExactCircleTest.java:117)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.RandomPointBearingCardinalTest(GeoExactCircleTest.java:109)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=478, maxMBSortInHeap=5.961909961194244, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@179f38fb),
>  locale=ar-SD, timezone=Turkey
>[junit4]   2> NOTE: Linux 4.4.0-1043-aws amd64/Oracle Corporation 
> 1.8.0_151 (64-bit)/cpus=4,threads=1,free=269120312,total=319291392
>[junit4]   2> NOTE: All tests run in this JVM: [XYZSolidTest, 
> TestGeo3DDocValues, GeoExactCircleTest]
> ant test  -Dtestcase=GeoExactCircleTest 
> -Dtests.method=RandomPointBearingCardinalTest -Dtests.seed=30B96A8700F32D8F 
> -Dtests.slow=true -Dtests.locale=ar-SD -Dtests.timezone=Turkey 
> -Dtests.asserts=true -Dtests.file.encoding=UTF8
>[junit4] FAILURE 0.02s J2 | 
> GeoExactCircleTest.RandomPointBearingCardinalTest 
> {seed=[8C1E53DFCE9646F5:8DCCE74ADEC6D907]} <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> PlanetModel(ab=1.0366200558773102 c=0.6736249299915238) 0.0011591580078804675 
> 2.649410126114567
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([8C1E53DFCE9646F5:8DCCE74ADEC6D907]:0)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.checkBearingPoint(GeoExactCircleTest.java:117)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.RandomPointBearingCardinalTest(GeoExactCircleTest.java:109)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=1185, maxMBSortInHeap=5.925083864677718, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@6a7f1f9),
>  locale=en-AU, timezone=CNT
>[junit4]   2> NOTE: Linux 2.6.32-696.6.3.el6.x86_64 amd64/Oracle 
> Corporation 1.8.0_151 (64-bit)/cpus=4,threads=1,free=207196520,total=251658240
>[junit4]   2> NOTE: All tests run in this JVM: [TestGeo3DDocValues, 
> GeoCircleTest, GeoExactCircleTest]
>[junit4] Completed [11/16 (1!)] on J2 in 1.60s, 311 tests, 1 failure <<< 
> FAILURES!
> {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

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

[Policeman Jenkins Server]

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

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

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=32124, name=jetty-launcher-8334-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=32124, name=jetty-launcher-8334-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)
at __randomizedtesting.SeedInfo.seed([9FDD6D638E5433F9]:0)




Build Log:
[...truncated 13461 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation
   [junit4]   2> 3230640 INFO  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[9FDD6D638E5433F9]-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-7.x-Solaris/solr/build/solr-core/test/J0/temp/solr.cloud.TestSolrCloudWithSecureImpersonation_9FDD6D638E5433F9-001/init-core-data-001
   [junit4]   2> 3230640 WARN  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[9FDD6D638E5433F9]-worker) [   
 ] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=12 numCloses=12
   [junit4]   2> 3230641 INFO  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[9FDD6D638E5433F9]-worker) [   
 ] o.a.s.SolrTestCaseJ4 Using TrieFields (NUMERIC_POINTS_SYSPROP=false) 
w/NUMERIC_DOCVALUES_SYSPROP=true
   [junit4]   2> 3230642 INFO  

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestSystemCollAutoCreate

Error Message:
45 threads leaked from SUITE scope at 
org.apache.solr.handler.TestSystemCollAutoCreate: 1) Thread[id=4172, 
name=org.eclipse.jetty.server.session.HashSessionManager@2080dbbfTimer, 
state=TIMED_WAITING, group=TGRP-TestSystemCollAutoCreate] at 
java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9.0.1/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@9.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2104)
 at 
java.base@9.0.1/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.base@9.0.1/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092)
 at 
java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
 at 
java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
 at java.base@9.0.1/java.lang.Thread.run(Thread.java:844)2) 
Thread[id=4236, name=zkCallback-861-thread-5, state=TIMED_WAITING, 
group=TGRP-TestSystemCollAutoCreate] at 
java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9.0.1/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@9.0.1/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@9.0.1/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@9.0.1/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1091)
 at 
java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
 at 
java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
 at java.base@9.0.1/java.lang.Thread.run(Thread.java:844)3) 
Thread[id=4235, name=zkCallback-861-thread-4, state=TIMED_WAITING, 
group=TGRP-TestSystemCollAutoCreate] at 
java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9.0.1/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@9.0.1/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@9.0.1/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@9.0.1/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1091)
 at 
java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
 at 
java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
 at java.base@9.0.1/java.lang.Thread.run(Thread.java:844)4) 
Thread[id=4196, name=qtp942820476-4196, state=TIMED_WAITING, 
group=TGRP-TestSystemCollAutoCreate] at 
java.base@9.0.1/java.lang.Thread.sleep(Native Method) at 
app//org.apache.solr.cloud.ZkController.waitForShardId(ZkController.java:1562)  
   at 
app//org.apache.solr.cloud.ZkController.doGetShardIdAndNodeNameProcess(ZkController.java:1513)
 at 
app//org.apache.solr.cloud.ZkController.preRegister(ZkController.java:1622) 
at 
app//org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1036)
 at 
app//org.apache.solr.core.CoreContainer.create(CoreContainer.java:954) 
at 
app//org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
 at 
app//org.apache.solr.handler.admin.CoreAdminOperation$$Lambda$281/625867734.execute(Unknown
 Source) at 
app//org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:384)
 at 
app//org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:389)
 at 
app//org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
 at 
app//org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
 at 
app//org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:736)
 at 
app//org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:717)
 at 

[jira] [Comment Edited] (LUCENE-7966) build mr-jar and use some java 9 methods if available

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on LUCENE-7966 at 1/2/18 6:46 PM:
---

Sorry for silence on this. I wanted to improve the patch tomorrow.

[~mikemccand]:

bq. I retested w/ Uwe's patch:

By reading the Java mailing lists, I have an idea what could cause Mike's 
differences: Are you sure that you used the same garbage collector in Java 8 
and Java 9? By default Java 9 uses G1GC, which Java 8 uses the good old 
ParallelGC by default. On the mailinglist jdk-dev there was a discussion that 
suddenly computing-intensive stuff was significantly slower with Java 9. The 
reason was the Garbage Collector! So be sure to use the same one (give it 
explicit on command line). G1GC adds additional barriers and because of them 
the number of free CPU registers is lowered by 1. This causes some algorithms 
to behave worse as missing CPU registers don't allow to do everything in the 
CPU ([~dweiss] has seen a sigicficant slowdown for some of his code). More than 
10% slowdown is possible! This also affects code that has no garbage collection 
and barriers because of G1. It's just limited resources causing this. 
Interestingly the person complaining was talking about LZ4 compression: 
http://openjdk.5641.n7.nabble.com/Reduced-performance-in-Java-9-0-1-vs-8u152-td322825.html

Could you compare Java 8 and Java 9 with same garbage collector? (a) G1GC on 
both and (b) ParallelGC and/or CMS ?
Uwe


was (Author: thetaphi):
Sorry for silence on this. I wanted to improve the patch tomorrow.

[~mikemccand]:

bq. I retested w/ Uwe's patch:

By reading the Java mailing lists, I have an idea what could cause Mike's 
differences: Are you sure that you used the same garbage collector in Java 8 
and Java 9? By default Java 9 uses G1GC, which Java 8 uses the good old 
ParallelGC by default. On the mailinglist jdk-dev there was a discussion that 
suddenly computing-intensive stuff was significantly slower with Java 9. The 
reason was the Garbage Collector! So be sure to use the same one (give it 
explicit on command line). G1GC adds additional barriers and because of them 
the number of free CPU registers is lowered by 1. This causes some algorithms 
to behave worse as missing CPU registers don't allow to do everything in the 
CPU ([~dweiss] has seen a sigicficant slowdown for some of his code). More than 
10% slowdown is possible! This also affects code that has no garbage collection 
and barriers because of G1. It's just limited resources causing this.

Could you compare Java 8 and Java 9 with same garbage collector? (a) G1GC on 
both and (b) ParallelGC and/or CMS ?
Uwe

> build mr-jar and use some java 9 methods if available
> -
>
> Key: LUCENE-7966
> URL: https://issues.apache.org/jira/browse/LUCENE-7966
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other, general/build
>Reporter: Robert Muir
>  Labels: Java9
> Attachments: LUCENE-7966.patch, LUCENE-7966.patch, LUCENE-7966.patch, 
> LUCENE-7966.patch, LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking 
> methods in java 9 for example, without waiting for lucene 10 or something. If 
> we build an MR-jar, we can start migrating our code to use java 9 methods 
> right now, it will use optimized methods from java 9 when thats available, 
> otherwise fall back to java 8 code.  
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java 
> methods. This way, we can simply directly replace call sites with java 9 
> methods when java 9 is a minimum. Simple 1-1 mappings mean also that we only 
> have to worry about testing that our java 8 fallback methods work.
> I found that many of the current byte array methods today are willy-nilly and 
> very lenient for example, passing invalid offsets at times and relying on 
> compare methods not throwing exceptions, etc. I fixed all the instances in 
> core/codecs but have not looked at the problems with AnalyzingSuggester. Also 
> SimpleText still uses a silly method in ArrayUtil in similar crazy way, have 
> not removed that one yet.



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

-
To unsubscribe, e-mail: 

[jira] [Comment Edited] (LUCENE-7966) build mr-jar and use some java 9 methods if available

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on LUCENE-7966 at 1/2/18 6:42 PM:
---

Sorry for silence on this. I wanted to improve the patch tomorrow.

[~mikemccand]:

bq. I retested w/ Uwe's patch:

By reading the Java mailing lists, I have an idea what could cause Mike's 
differences: Are you sure that you used the same garbage collector in Java 8 
and Java 9? By default Java 9 uses G1GC, which Java 8 uses the good old 
ParallelGC by default. On the mailinglist jdk-dev there was a discussion that 
suddenly computing-intensive stuff was significantly slower with Java 9. The 
reason was the Garbage Collector! So be sure to use the same one (give it 
explicit on command line). G1GC adds additional barriers and because of them 
the number of free CPU registers is lowered by 1. This causes some algorithms 
to behave worse as missing CPU registers don't allow to do everything in the 
CPU ([~dweiss] has seen a sigicficant slowdown for some of his code). More than 
10% slowdown is possible! This also affects code that has no garbage collection 
and barriers because of G1. It's just limited resources causing this.

Could you compare Java 8 and Java 9 with same garbage collector? (a) G1GC on 
both and (b) ParallelGC and/or CMS ?
Uwe


was (Author: thetaphi):
Sorry for silence on this. I wanted to improve the patch tomorrow.

[~mikemccand]:

bq. I retested w/ Uwe's patch:

By reading the Java mailing lists, I have an idea what could cause Mike's 
differences: Are you sure that you used the same garbage collector in Java 8 
and Java 9. By default Java 9 uses G1GC, which Java 8 uses the good old 
ParallelGC by default. On the mailinglist jdk-dev there was a discussion that 
suddenly computing-intensive stuff was significantly slower with Java 9. The 
reason was the Garbage Collector! So be sure to use the same one (give it 
explicit on command line). G1GC adds additional barriers and because of them 
the number of free CPU registers is lowered by 1. This causes some algorithms 
to behave worse as missing CPU registers don't allow to do everything in the 
CPU ([~dweiss] has seen a sigicficant slowdown for some of his code). More than 
10% slowdown is possible! This also affects code that has no garbage collection 
and barriers because of G1. It's just limited resources causing this.

Could you compare Java 8 and Java 9 with same garbage collector? (a) G1GC on 
both and (b) ParallelGC and/or CMS ?
Uwe

> build mr-jar and use some java 9 methods if available
> -
>
> Key: LUCENE-7966
> URL: https://issues.apache.org/jira/browse/LUCENE-7966
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other, general/build
>Reporter: Robert Muir
>  Labels: Java9
> Attachments: LUCENE-7966.patch, LUCENE-7966.patch, LUCENE-7966.patch, 
> LUCENE-7966.patch, LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking 
> methods in java 9 for example, without waiting for lucene 10 or something. If 
> we build an MR-jar, we can start migrating our code to use java 9 methods 
> right now, it will use optimized methods from java 9 when thats available, 
> otherwise fall back to java 8 code.  
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java 
> methods. This way, we can simply directly replace call sites with java 9 
> methods when java 9 is a minimum. Simple 1-1 mappings mean also that we only 
> have to worry about testing that our java 8 fallback methods work.
> I found that many of the current byte array methods today are willy-nilly and 
> very lenient for example, passing invalid offsets at times and relying on 
> compare methods not throwing exceptions, etc. I fixed all the instances in 
> core/codecs but have not looked at the problems with AnalyzingSuggester. Also 
> SimpleText still uses a silly method in ArrayUtil in similar crazy way, have 
> not removed that one yet.



--
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-7966) build mr-jar and use some java 9 methods if available

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7966:
---

Sorry for silence on this. I wanted to improve the patch tomorrow.

[~mikemccand]:

bq. I retested w/ Uwe's patch:

By reading the Java mailing lists, I have an idea what could cause Mike's 
differences: Are you sure that you used the same garbage collector in Java 8 
and Java 9. By default Java 9 uses G1GC, which Java 8 uses the good old 
ParallelGC by default. On the mailinglist jdk-dev there was a discussion that 
suddenly computing-intensive stuff was significantly slower with Java 9. The 
reason was the Garbage Collector! So be sure to use the same one (give it 
explicit on command line). G1GC adds additional barriers and because of them 
the number of free CPU registers is lowered by 1. This causes some algorithms 
to behave worse as missing CPU registers don't allow to do everything in the 
CPU ([~dweiss] has seen a sigicficant slowdown for some of his code). More than 
10% slowdown is possible! This also affects code that has no garbage collection 
and barriers because of G1. It's just limited resources causing this.

Could you compare Java 8 and Java 9 with same garbage collector? (a) G1GC on 
both and (b) ParallelGC and/or CMS ?
Uwe

> build mr-jar and use some java 9 methods if available
> -
>
> Key: LUCENE-7966
> URL: https://issues.apache.org/jira/browse/LUCENE-7966
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other, general/build
>Reporter: Robert Muir
>  Labels: Java9
> Attachments: LUCENE-7966.patch, LUCENE-7966.patch, LUCENE-7966.patch, 
> LUCENE-7966.patch, LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking 
> methods in java 9 for example, without waiting for lucene 10 or something. If 
> we build an MR-jar, we can start migrating our code to use java 9 methods 
> right now, it will use optimized methods from java 9 when thats available, 
> otherwise fall back to java 8 code.  
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java 
> methods. This way, we can simply directly replace call sites with java 9 
> methods when java 9 is a minimum. Simple 1-1 mappings mean also that we only 
> have to worry about testing that our java 8 fallback methods work.
> I found that many of the current byte array methods today are willy-nilly and 
> very lenient for example, passing invalid offsets at times and relying on 
> compare methods not throwing exceptions, etc. I fixed all the instances in 
> core/codecs but have not looked at the problems with AnalyzingSuggester. Also 
> SimpleText still uses a silly method in ArrayUtil in similar crazy way, have 
> not removed that one yet.



--
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-11448) Implement an option in collection commands to wait for command results

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11448:
-

Okay.

bq. and it's usually acceptable to user that the cluster state may still 
undergo changes as replicas gradually recover and become active.

So long as such changes don't impact the apparent usability of the collection 
(ability to search and add docs without error) then I agree, otherwise I don't. 
 If we don't then do you mean _sometimes_ the user may not care?  Well that's 
what async is for; no?

It seems like a wart to see CollectionsHandler check that a collection creation 
is being performed and then call a waitForActiveCollection... this is an 
exceptional case instead of being agnostic of the command.  I think you'd see 
what I mean if you look over there in CollectionsHandler.  Instead, I propose 
CreateCollectionCmd actually waits sufficiently long for the collection to be 
usable at the point it returns (thus move this method over there).  Would it 
need a new parameter to know when to *not* wait or does "async" imply as much?  
But even in async case... it might as well wait for things to complete so that 
if the async status is finally done then the collection is truly usable.

> Implement an option in collection commands to wait for command results
> --
>
> Key: SOLR-11448
> URL: https://issues.apache.org/jira/browse/SOLR-11448
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: 7.2
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11448.diff
>
>
> In order to reliably track results and impact of executing collection-level 
> commands in the autoscaling framework we need an option to execute the 
> requested operation (eg. move replica) and then wait for the operation 
> results to actually take effect (the replica has been moved AND it became 
> active).
> This is different than executing commands synchronously, in which case the 
> API only waits for the operation itself to be completed (eg. moving the 
> replica succeeded) but it does not wait for the final effects of this 
> operation to take place (eg. the replica becomes active).



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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1103/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseG1GC

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

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

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:38249
at 
__randomizedtesting.SeedInfo.seed([3C248CD33396D812:B470B3099D6AB5EA]: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 

[JENKINS] Lucene-Solr-Tests-master - Build # 2248 - Still unstable

[Apache Jenkins Server]

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

13 tests failed.
FAILED:  org.apache.solr.cloud.HttpPartitionTest.test

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:49663/_jcf/d

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:49663/_jcf/d
at 
__randomizedtesting.SeedInfo.seed([D9D7500777D18398:51836FDDD92DEE60]: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:414)
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 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[jira] [Commented] (SOLR-11448) Implement an option in collection commands to wait for command results

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-11448:
--

bq. why wouldn't we always want to wait for final state (assuming this isn't an 
async call)?
[~dsmiley] the purpose of the {{waitForFinalState}} flag is somewhat different 
- it just ensures that all shards have leaders, OR that any replicas that were 
being moved have indeed been moved successfully and became active. The reason 
for this flag is to make sure the autoscaling actions leave collections in 
stable state when they report success (or failure) - reporting success 
prematurely, while some replicas are still recovering, would cause the 
subsequent autoscaling actions to work with a cluster state that is bound to 
change while the autoscaling plan is being computed (which itself may take 
several seconds) - ultimately causing the newly computed plan to be either 
invalid or suboptimal.

When collection commands are issued manually this timing is not so important - 
in fact, defaulting to false allows the command to report success sooner, and 
it's usually acceptable to user that the cluster state may still undergo 
changes as replicas gradually recover and become active.

> Implement an option in collection commands to wait for command results
> --
>
> Key: SOLR-11448
> URL: https://issues.apache.org/jira/browse/SOLR-11448
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: 7.2
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11448.diff
>
>
> In order to reliably track results and impact of executing collection-level 
> commands in the autoscaling framework we need an option to execute the 
> requested operation (eg. move replica) and then wait for the operation 
> results to actually take effect (the replica has been moved AND it became 
> active).
> This is different than executing commands synchronously, in which case the 
> API only waits for the operation itself to be completed (eg. moving the 
> replica succeeded) but it does not wait for the final effects of this 
> operation to take place (eg. the replica becomes active).



--
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-11430) Add lerp and akima Stream Evaluators to support linear and akima spline interpolation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11430:


Commit 4618f9a919cef150f66aa3db19f4376ddc348baf in lucene-solr's branch 
refs/heads/branch_7x from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4618f9a ]

SOLR-11430: Add lerp and akima Stream Evaluators to support linear and akima 
spline interpolation


> Add lerp and akima Stream Evaluators to support linear and akima spline 
> interpolation
> -
>
> Key: SOLR-11430
> URL: https://issues.apache.org/jira/browse/SOLR-11430
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.3
>
> Attachments: SOLR-11430.patch
>
>
> The lerp Stream Evaluator performs linear interpolation:
> {code}
> interp = lerp(xvec, yvec)
> {code}
> The akima Stream Evaluator performs Akima spline interpolation:
> {code}
> interp = akima(xvec, yvec)
> {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] [Commented] (SOLR-11430) Add lerp and akima Stream Evaluators to support linear and akima spline interpolation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11430:


Commit a9258476842f5ba61f4f081c6dc13261a47eb767 in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a925847 ]

SOLR-11430: Add lerp and akima Stream Evaluators to support linear and akima 
spline interpolation


> Add lerp and akima Stream Evaluators to support linear and akima spline 
> interpolation
> -
>
> Key: SOLR-11430
> URL: https://issues.apache.org/jira/browse/SOLR-11430
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.3
>
> Attachments: SOLR-11430.patch
>
>
> The lerp Stream Evaluator performs linear interpolation:
> {code}
> interp = lerp(xvec, yvec)
> {code}
> The akima Stream Evaluator performs Akima spline interpolation:
> {code}
> interp = akima(xvec, yvec)
> {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] [Updated] (SOLR-11430) Add lerp and akima Stream Evaluators to support linear and akima spline interpolation

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11430:
--
Description: 
The lerp Stream Evaluator performs linear interpolation:

{code}
interp = lerp(xvec, yvec)
{code}

The akima Stream Evaluator performs Akima spline interpolation:

{code}
interp = akima(xvec, yvec)
{code}

  was:
The lerp Stream Evaluator supports Linear interpolation:

{code}
yvec = lerp(xvec, yvec)
{code}


> Add lerp and akima Stream Evaluators to support linear and akima spline 
> interpolation
> -
>
> Key: SOLR-11430
> URL: https://issues.apache.org/jira/browse/SOLR-11430
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.3
>
> Attachments: SOLR-11430.patch
>
>
> The lerp Stream Evaluator performs linear interpolation:
> {code}
> interp = lerp(xvec, yvec)
> {code}
> The akima Stream Evaluator performs Akima spline interpolation:
> {code}
> interp = akima(xvec, yvec)
> {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-11790) Add akima Stream Evaluator to support akima splines

[Joel Bernstein (JIRA)]

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

Joel Bernstein resolved SOLR-11790.
---
Resolution: Duplicate

> Add akima Stream Evaluator to support akima splines
> ---
>
> Key: SOLR-11790
> URL: https://issues.apache.org/jira/browse/SOLR-11790
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.3
>
>
> This ticket adds support for Akima splines to the Streaming Expression 
> statistical function library.



--
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-11430) Add lerp and akima Stream Evaluators to support linear and akima spline interpolation

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11430:
--
Summary: Add lerp and akima Stream Evaluators to support linear and akima 
spline interpolation  (was: Add lerp and akima Stream Evaluator to support 
linear and akima spline interpolation)

> Add lerp and akima Stream Evaluators to support linear and akima spline 
> interpolation
> -
>
> Key: SOLR-11430
> URL: https://issues.apache.org/jira/browse/SOLR-11430
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.3
>
> Attachments: SOLR-11430.patch
>
>
> The lerp Stream Evaluator supports Linear interpolation:
> {code}
> yvec = lerp(xvec, yvec)
> {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] [Updated] (SOLR-11430) Add lerp and akima Stream Evaluator to support linear and akima spline interpolation

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11430:
--
Summary: Add lerp and akima Stream Evaluator to support linear and akima 
spline interpolation  (was: Add lerp Stream Evaluator to support linear 
interpolation)

> Add lerp and akima Stream Evaluator to support linear and akima spline 
> interpolation
> 
>
> Key: SOLR-11430
> URL: https://issues.apache.org/jira/browse/SOLR-11430
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.3
>
> Attachments: SOLR-11430.patch
>
>
> The lerp Stream Evaluator supports Linear interpolation:
> {code}
> yvec = lerp(xvec, yvec)
> {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] [Updated] (SOLR-11430) Add lerp Stream Evaluator to support linear interpolation

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11430:
--
Attachment: SOLR-11430.patch

> Add lerp Stream Evaluator to support linear interpolation
> -
>
> Key: SOLR-11430
> URL: https://issues.apache.org/jira/browse/SOLR-11430
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.3
>
> Attachments: SOLR-11430.patch
>
>
> The lerp Stream Evaluator supports Linear interpolation:
> {code}
> yvec = lerp(xvec, yvec)
> {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-MacOSX (64bit/jdk-9) - Build # 375 - Still Unstable!

[Policeman Jenkins Server]

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

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

Error Message:
did not finish processing changes

Stack Trace:
java.lang.AssertionError: did not finish processing changes
at 
__randomizedtesting.SeedInfo.seed([D6A597F2D5DB4579:714A8A511A96CA61]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.sim.TestLargeCluster.testAddNode(TestLargeCluster.java:297)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 1735 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/core/test/temp/junit4-J0-20180102_132303_03611496602337465376302.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java 

[jira] [Commented] (SOLR-11597) Implement RankNet.

[Michael A. Alcorn (JIRA)]

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

Michael A. Alcorn commented on SOLR-11597:
--

The additional tests look good to me, [~cpoerschke].

Thanks for the feedback, [~yuyano].

bq. The name of "nonlinearity" is a bit curious for me because we call these 
functions as "activation function". How about using "activation" instead of 
''nonlinearity" to represent it?

"Nonlinearity" and "activation function" are used more or less interchangeably 
when talking about neural networks. See, e.g., [this Stanford 
course|http://cs231n.github.io/neural-networks-1/], "In other words, each 
neuron performs a dot product with the input and its weights, adds the bias and 
applies the non-linearity (or activation function)". Because the two terms are 
interchangeable, I'm OK with either being used.

bq. If we think to apply this to more complex neural networks in the future, we 
will need to support layers (ex. convolutional and pooling) other than the full 
connected layer (ex. ReLU).

In my opinion, if this is a route Solr eventually wants to go, I think a better 
strategy would be to just add a dependency on 
[Deeplearning4j|https://deeplearning4j.org/]. New types of architectural 
designs are constantly coming out (e.g., 
[attention|http://www.wildml.com/2016/01/attention-and-memory-in-deep-learning-and-nlp/],
 which I believe [Deeplearning4j still does not even 
support|https://deeplearning4j.org/roadmap]), and there are so many subtle ways 
to vary neural networks that it would be a ton of work to try and maintain what 
has effectively already been done in other libraries like Deeplearning4j.

> Implement RankNet.
> --
>
> Key: SOLR-11597
> URL: https://issues.apache.org/jira/browse/SOLR-11597
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Reporter: Michael A. Alcorn
>
> Implement RankNet as described in [this 
> tutorial|https://github.com/airalcorn2/Solr-LTR].



--
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-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 updated SOLR-11801:
---
Attachment: SOLR-11801.patch

Polished patch as nit-pick suggested. I agree that less-is-more w.r.t. 
javadocs; LUCENE-8115 proposes to fail precommit on unnecessary @inheritDoc use.

> 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] [Created] (LUCENE-8115) fail precommit on unnecessary {@inheritDoc} use

[Christine Poerschke (JIRA)]

Christine Poerschke created LUCENE-8115:
---

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


* 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

[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

Proposed patch for step 2.

> 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
>
>
> * 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-Linux (64bit/jdk1.8.0_144) - Build # 1102 - Still Unstable!

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=28551, name=jetty-launcher-7667-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)   
 2) Thread[id=28547, name=jetty-launcher-7667-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=28551, name=jetty-launcher-7667-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 

[jira] [Commented] (LUCENE-8012) Improve Explanation class

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8012: LTR contrib needs to use float values in explanations


> Improve Explanation class
> -
>
> Key: LUCENE-8012
> URL: https://issues.apache.org/jira/browse/LUCENE-8012
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>  Labels: newdev
> Fix For: master (8.0)
>
> Attachments: LUCENE-8012.patch, LUCENE-8012.patch
>
>
> Explanation class is currently nice and simple, and float matches the scoring 
> api, but this does not work well for debugging numerical errors of internal 
> calculations (it usually makes practical sense to use 64-bit double to avoid 
> issues).
> Also it makes for nasty formatting of integral values such as number of 
> tokens in the collection or even document's length, its just noise to see 
> {{10.0}} there instead of {{10}}, and scientific notation for e.g. number of 
> documents is just annoying. 
> One idea is to take Number instead of float? Then you could pass in the 
> correct numeric type (int,long,double,float) for internal calculations, 
> parameters, statistics, etc, and output would look nice.



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

Re: [1/2] lucene-solr:master: LUCENE-8010: GroupingSearchTest assumes longer fields = lower scores

[Adrien Grand]

Thanks, Alan!

Le mar. 2 janv. 2018 à 12:07,  a écrit :

> Repository: lucene-solr
> Updated Branches:
>   refs/heads/master ca29722b2 -> 6dd9dbf27
>
>
> LUCENE-8010: GroupingSearchTest assumes longer fields = lower scores
>
>
> Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
> Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/6dd9dbf2
> Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/6dd9dbf2
> Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/6dd9dbf2
>
> Branch: refs/heads/master
> Commit: 6dd9dbf2758c1fad2f10f0eba96998411aa43fd0
> Parents: c1030ee
> Author: Alan Woodward 
> Authored: Tue Jan 2 11:06:45 2018 +
> Committer: Alan Woodward 
> Committed: Tue Jan 2 11:06:59 2018 +
>
> --
>  .../test/org/apache/lucene/search/grouping/GroupingSearchTest.java | 2 ++
>  1 file changed, 2 insertions(+)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/6dd9dbf2/lucene/grouping/src/test/org/apache/lucene/search/grouping/GroupingSearchTest.java
> --
> diff --git
> a/lucene/grouping/src/test/org/apache/lucene/search/grouping/GroupingSearchTest.java
> b/lucene/grouping/src/test/org/apache/lucene/search/grouping/GroupingSearchTest.java
> index d13bfd7..d09513c 100644
> ---
> a/lucene/grouping/src/test/org/apache/lucene/search/grouping/GroupingSearchTest.java
> +++
> b/lucene/grouping/src/test/org/apache/lucene/search/grouping/GroupingSearchTest.java
> @@ -31,6 +31,7 @@ import org.apache.lucene.search.IndexSearcher;
>  import org.apache.lucene.search.Query;
>  import org.apache.lucene.search.Sort;
>  import org.apache.lucene.search.TermQuery;
> +import org.apache.lucene.search.similarities.BM25Similarity;
>  import org.apache.lucene.store.Directory;
>  import org.apache.lucene.util.BytesRef;
>  import org.apache.lucene.util.LuceneTestCase;
> @@ -115,6 +116,7 @@ public class GroupingSearchTest extends LuceneTestCase
> {
>  w.addDocument(doc);
>
>  IndexSearcher indexSearcher = newSearcher(w.getReader());
> +indexSearcher.setSimilarity(new BM25Similarity());
>  w.close();
>
>  Sort groupSort = Sort.RELEVANCE;
>
>

[jira] [Resolved] (SOLR-11748) Remove action throttle

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved SOLR-11748.
--
   Resolution: Fixed
Fix Version/s: master (8.0)

> Remove action throttle
> --
>
> Key: SOLR-11748
> URL: https://issues.apache.org/jira/browse/SOLR-11748
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11748.patch
>
>
> The cool down period and action throttle seem a bit redundant. They both 
> accomplish the same thing today. We should just get rid of the action 
> throttle in favor of the cool down period.



--
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-11748) Remove action throttle

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11748:


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

SOLR-11748: Remove Autoscaling action throttle

(cherry picked from commit caa731a)


> Remove action throttle
> --
>
> Key: SOLR-11748
> URL: https://issues.apache.org/jira/browse/SOLR-11748
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 7.3
>
> Attachments: SOLR-11748.patch
>
>
> The cool down period and action throttle seem a bit redundant. They both 
> accomplish the same thing today. We should just get rid of the action 
> throttle in favor of the cool down period.



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

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

[Alan Woodward]

This is LUCENE-8012 I think, digging now.

> On 2 Jan 2018, at 13:20, Policeman Jenkins Server  wrote:
> 
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4360/
> Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC
> 
> 2 tests failed.
> FAILED:  
> org.apache.solr.ltr.TestLTRQParserExplain.testRerankedExplainSameBetweenDifferentDocsWithSameFeatures
> 
> Error Message:
> mismatch: ' 3.5116758 = 
> LinearModel(name=6029760550880411648,featureWeights=[title=0.0,description=0.1,keywords=0.2,popularity=0.3,text=0.4,queryIntentPerson=0.1231231,queryIntentCompany=0.12121211])
>  model applied to features, sum of:   0.0 = prod of: 0.0 = weight on 
> feature 1.0 = ValueFeature [name=title, params={value=1}]   0.2 = prod 
> of: 0.1 = weight on feature 2.0 = ValueFeature [name=description, 
> params={value=2}]   0.4 = prod of: 0.2 = weight on feature 2.0 = 
> ValueFeature [name=keywords, params={value=2}]   0.09 = prod of: 0.3 = 
> weight on feature 0.3 = normalized using 
> MinMaxNormalizer(min=0.0,max=10.0)   3.0 = ValueFeature [name=popularity, 
> params={value=3}]   1.6 = prod of: 0.4 = weight on feature 4.0 = 
> ValueFeature [name=text, params={value=4}]   0.6156155 = prod of: 
> 0.1231231 = weight on feature 5.0 = ValueFeature [name=queryIntentPerson, 
> params={value=5}]   0.60606056 = prod of: 0.12121211 = weight on feature  
>5.0 = ValueFeature [name=queryIntentCompany, params={value=5}] '!=' 
> 3.5116758 = 
> LinearModel(name=6029760550880411648,featureWeights=[title=0.0,description=0.1,keywords=0.2,popularity=0.3,text=0.4,queryIntentPerson=0.1231231,queryIntentCompany=0.12121211])
>  model applied to features, sum of:   0.0 = prod of: 0.0 = weight on 
> feature 1.0 = ValueFeature [name=title, params={value=1}]   
> 0.2000298023224 = prod of: 0.1 = weight on feature 2.0 = 
> ValueFeature [name=description, params={value=2}]   0.400059604645 = prod 
> of: 0.2 = weight on feature 2.0 = ValueFeature [name=keywords, 
> params={value=2}]   0.0900715255752 = prod of: 0.3 = weight on 
> feature 0.3 = normalized using MinMaxNormalizer(min=0.0,max=10.0)   
> 3.0 = ValueFeature [name=popularity, params={value=3}]   1.60023841858 = 
> prod of: 0.4 = weight on feature 4.0 = ValueFeature [name=text, 
> params={value=4}]   0.6156155094504356 = prod of: 0.1231231 = weight on 
> feature 5.0 = ValueFeature [name=queryIntentPerson, params={value=5}]   
> 0.6060605496168137 = prod of: 0.12121211 = weight on feature 5.0 = 
> ValueFeature [name=queryIntentCompany, params={value=5}] ' @ debug/explain/7
> 
> Stack Trace:
> java.lang.RuntimeException: mismatch: '
> 3.5116758 = 
> LinearModel(name=6029760550880411648,featureWeights=[title=0.0,description=0.1,keywords=0.2,popularity=0.3,text=0.4,queryIntentPerson=0.1231231,queryIntentCompany=0.12121211])
>  model applied to features, sum of:
>  0.0 = prod of:
>0.0 = weight on feature
>1.0 = ValueFeature [name=title, params={value=1}]
>  0.2 = prod of:
>0.1 = weight on feature
>2.0 = ValueFeature [name=description, params={value=2}]
>  0.4 = prod of:
>0.2 = weight on feature
>2.0 = ValueFeature [name=keywords, params={value=2}]
>  0.09 = prod of:
>0.3 = weight on feature
>0.3 = normalized using MinMaxNormalizer(min=0.0,max=10.0)
>  3.0 = ValueFeature [name=popularity, params={value=3}]
>  1.6 = prod of:
>0.4 = weight on feature
>4.0 = ValueFeature [name=text, params={value=4}]
>  0.6156155 = prod of:
>0.1231231 = weight on feature
>5.0 = ValueFeature [name=queryIntentPerson, params={value=5}]
>  0.60606056 = prod of:
>0.12121211 = weight on feature
>5.0 = ValueFeature [name=queryIntentCompany, params={value=5}]
> '!='
> 3.5116758 = 
> LinearModel(name=6029760550880411648,featureWeights=[title=0.0,description=0.1,keywords=0.2,popularity=0.3,text=0.4,queryIntentPerson=0.1231231,queryIntentCompany=0.12121211])
>  model applied to features, sum of:
>  0.0 = prod of:
>0.0 = weight on feature
>1.0 = ValueFeature [name=title, params={value=1}]
>  0.2000298023224 = prod of:
>0.1 = weight on feature
>2.0 = ValueFeature [name=description, params={value=2}]
>  0.400059604645 = prod of:
>0.2 = weight on feature
>2.0 = ValueFeature [name=keywords, params={value=2}]
>  0.0900715255752 = prod of:
>0.3 = weight on feature
>0.3 = normalized using MinMaxNormalizer(min=0.0,max=10.0)
>  3.0 = ValueFeature [name=popularity, params={value=3}]
>  1.60023841858 = prod of:
>0.4 = weight on feature
>4.0 = ValueFeature [name=text, params={value=4}]
>  0.6156155094504356 = prod of:
>0.1231231 = weight on feature
>5.0 = ValueFeature [name=queryIntentPerson, params={value=5}]
>  0.6060605496168137 = prod of:
>0.12121211 = weight on feature
>5.0 = ValueFeature [name=queryIntentCompany, 

[jira] [Commented] (SOLR-11748) Remove action throttle

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11748:


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

SOLR-11748: Remove Autoscaling action throttle


> Remove action throttle
> --
>
> Key: SOLR-11748
> URL: https://issues.apache.org/jira/browse/SOLR-11748
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 7.3
>
> Attachments: SOLR-11748.patch
>
>
> The cool down period and action throttle seem a bit redundant. They both 
> accomplish the same thing today. We should just get rid of the action 
> throttle in favor of the cool down period.



--
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-11748) Remove action throttle

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-11748:
-
Attachment: SOLR-11748.patch

Patch which removes action throttle. It includes changes to ref guide and the 
upgrade notes.

> Remove action throttle
> --
>
> Key: SOLR-11748
> URL: https://issues.apache.org/jira/browse/SOLR-11748
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 7.3
>
> Attachments: SOLR-11748.patch
>
>
> The cool down period and action throttle seem a bit redundant. They both 
> accomplish the same thing today. We should just get rid of the action 
> throttle in favor of the cool down period.



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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.ltr.TestLTRQParserExplain.testRerankedExplainSameBetweenDifferentDocsWithSameFeatures

Error Message:
mismatch: ' 3.5116758 = 
LinearModel(name=6029760550880411648,featureWeights=[title=0.0,description=0.1,keywords=0.2,popularity=0.3,text=0.4,queryIntentPerson=0.1231231,queryIntentCompany=0.12121211])
 model applied to features, sum of:   0.0 = prod of: 0.0 = weight on 
feature 1.0 = ValueFeature [name=title, params={value=1}]   0.2 = prod of:  
   0.1 = weight on feature 2.0 = ValueFeature [name=description, 
params={value=2}]   0.4 = prod of: 0.2 = weight on feature 2.0 = 
ValueFeature [name=keywords, params={value=2}]   0.09 = prod of: 0.3 = 
weight on feature 0.3 = normalized using MinMaxNormalizer(min=0.0,max=10.0) 
  3.0 = ValueFeature [name=popularity, params={value=3}]   1.6 = prod of:   
  0.4 = weight on feature 4.0 = ValueFeature [name=text, params={value=4}]  
 0.6156155 = prod of: 0.1231231 = weight on feature 5.0 = ValueFeature 
[name=queryIntentPerson, params={value=5}]   0.60606056 = prod of: 
0.12121211 = weight on feature 5.0 = ValueFeature [name=queryIntentCompany, 
params={value=5}] '!=' 3.5116758 = 
LinearModel(name=6029760550880411648,featureWeights=[title=0.0,description=0.1,keywords=0.2,popularity=0.3,text=0.4,queryIntentPerson=0.1231231,queryIntentCompany=0.12121211])
 model applied to features, sum of:   0.0 = prod of: 0.0 = weight on 
feature 1.0 = ValueFeature [name=title, params={value=1}]   
0.2000298023224 = prod of: 0.1 = weight on feature 2.0 = 
ValueFeature [name=description, params={value=2}]   0.400059604645 = prod 
of: 0.2 = weight on feature 2.0 = ValueFeature [name=keywords, 
params={value=2}]   0.0900715255752 = prod of: 0.3 = weight on feature  
   0.3 = normalized using MinMaxNormalizer(min=0.0,max=10.0)   3.0 = 
ValueFeature [name=popularity, params={value=3}]   1.60023841858 = prod of: 
0.4 = weight on feature 4.0 = ValueFeature [name=text, 
params={value=4}]   0.6156155094504356 = prod of: 0.1231231 = weight on 
feature 5.0 = ValueFeature [name=queryIntentPerson, params={value=5}]   
0.6060605496168137 = prod of: 0.12121211 = weight on feature 5.0 = 
ValueFeature [name=queryIntentCompany, params={value=5}] ' @ debug/explain/7

Stack Trace:
java.lang.RuntimeException: mismatch: '
3.5116758 = 
LinearModel(name=6029760550880411648,featureWeights=[title=0.0,description=0.1,keywords=0.2,popularity=0.3,text=0.4,queryIntentPerson=0.1231231,queryIntentCompany=0.12121211])
 model applied to features, sum of:
  0.0 = prod of:
0.0 = weight on feature
1.0 = ValueFeature [name=title, params={value=1}]
  0.2 = prod of:
0.1 = weight on feature
2.0 = ValueFeature [name=description, params={value=2}]
  0.4 = prod of:
0.2 = weight on feature
2.0 = ValueFeature [name=keywords, params={value=2}]
  0.09 = prod of:
0.3 = weight on feature
0.3 = normalized using MinMaxNormalizer(min=0.0,max=10.0)
  3.0 = ValueFeature [name=popularity, params={value=3}]
  1.6 = prod of:
0.4 = weight on feature
4.0 = ValueFeature [name=text, params={value=4}]
  0.6156155 = prod of:
0.1231231 = weight on feature
5.0 = ValueFeature [name=queryIntentPerson, params={value=5}]
  0.60606056 = prod of:
0.12121211 = weight on feature
5.0 = ValueFeature [name=queryIntentCompany, params={value=5}]
'!='
3.5116758 = 
LinearModel(name=6029760550880411648,featureWeights=[title=0.0,description=0.1,keywords=0.2,popularity=0.3,text=0.4,queryIntentPerson=0.1231231,queryIntentCompany=0.12121211])
 model applied to features, sum of:
  0.0 = prod of:
0.0 = weight on feature
1.0 = ValueFeature [name=title, params={value=1}]
  0.2000298023224 = prod of:
0.1 = weight on feature
2.0 = ValueFeature [name=description, params={value=2}]
  0.400059604645 = prod of:
0.2 = weight on feature
2.0 = ValueFeature [name=keywords, params={value=2}]
  0.0900715255752 = prod of:
0.3 = weight on feature
0.3 = normalized using MinMaxNormalizer(min=0.0,max=10.0)
  3.0 = ValueFeature [name=popularity, params={value=3}]
  1.60023841858 = prod of:
0.4 = weight on feature
4.0 = ValueFeature [name=text, params={value=4}]
  0.6156155094504356 = prod of:
0.1231231 = weight on feature
5.0 = ValueFeature [name=queryIntentPerson, params={value=5}]
  0.6060605496168137 = prod of:
0.12121211 = weight on feature
5.0 = ValueFeature [name=queryIntentCompany, params={value=5}]
' @ debug/explain/7
at 
__randomizedtesting.SeedInfo.seed([BF50F24C695B12A1:1B79AC8849EBA0FF]:0)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:248)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192)
  

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates

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

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:36735/solr: create the collection time out:180s
at __randomizedtesting.SeedInfo.seed([A99A0EC0EE9811FC]: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.TestStressCloudBlindAtomicUpdates.createMiniSolrCloudCluster(TestStressCloudBlindAtomicUpdates.java:132)
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.TestAuthenticationFramework.testBasics

Error Message:
Error from server at 
https://127.0.0.1:40875/solr/testcollection_shard1_replica_n2: Expected mime 
type application/octet-stream but got text/html.Error 
404HTTP ERROR: 404 Problem accessing 
/solr/testcollection_shard1_replica_n2/update. Reason: Can not find: 
/solr/testcollection_shard1_replica_n2/update http://eclipse.org/jetty;>Powered by Jetty:// 9.3.20.v20170531 
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at https://127.0.0.1:40875/solr/testcollection_shard1_replica_n2: 
Expected mime type application/octet-stream but got text/html. 


Error 404 


HTTP ERROR: 404
Problem accessing /solr/testcollection_shard1_replica_n2/update. Reason:
Can not find: 

[jira] [Updated] (LUCENE-8113) Allow terms dictionary lookups to be lazy when scores are not needed

[Alan Woodward (JIRA)]

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

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

This patch folds LazyTermContext back into TermContext itself.

The ScoreMode changes are in SpanQueries.  Previously we only needed to know 
about score mode at the top of the tree, because stats were collected by 
SpanTermQuery regardless, but now STQ can lazily collect term states so 
ScoreMode needs to be propagated down.  This does fix a bug where SpanNotQuery 
was taking into account terms from its exclusion query when scoring.

The name is confusing, I agree.  How about IndexTermStates, given it's 
basically a wrapper around an array of TermState objects for a specific index?

> Allow terms dictionary lookups to be lazy when scores are not needed
> 
>
> Key: LUCENE-8113
> URL: https://issues.apache.org/jira/browse/LUCENE-8113
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
> Attachments: LUCENE-8113.patch, LUCENE-8113.patch
>
>
> LUCENE-7311 made it possible to avoid loading TermStates in cached 
> TermQueries.  It would be useful to extend this to other queries that use the 
> terms dictionary.



--
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-8113) Allow terms dictionary lookups to be lazy when scores are not needed

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-8113:
-

Can we fold this into TermContext directly rather than subclassing? 

I think this class is already too complicated for any performance benefits it 
brings us. If we add subclassing it sets it over the edge a bit. 

Can we also try to think of a better name for it? I really like this change in 
the patch:

{noformat}
- public TermState get(int ord) {
+ public TermState get(LeafReaderContext ctx) throws IOException {
{noformat}

But because both things are named *Context (which to me is a meaningless name), 
it leads to confusing looking code such as:
{noformat}
TermState termState = termContext.get(context);
{noformat}

Also there are quite a few changes to how ScoreModes are passed during query 
construction in the patch. Looks correct, but is that supposed to be here?

> Allow terms dictionary lookups to be lazy when scores are not needed
> 
>
> Key: LUCENE-8113
> URL: https://issues.apache.org/jira/browse/LUCENE-8113
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
> Attachments: LUCENE-8113.patch
>
>
> LUCENE-7311 made it possible to avoid loading TermStates in cached 
> TermQueries.  It would be useful to extend this to other queries that use the 
> terms dictionary.



--
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-8107) GeoExactCircleTest.RandomPointBearingCardinalTest failures

[Karl Wright (JIRA)]

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

Karl Wright resolved LUCENE-8107.
-
   Resolution: Fixed
Fix Version/s: 7.2
   master (8.0)
   6.7

> GeoExactCircleTest.RandomPointBearingCardinalTest failures
> --
>
> Key: LUCENE-8107
> URL: https://issues.apache.org/jira/browse/LUCENE-8107
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Karl Wright
> Fix For: 6.7, master (8.0), 7.2
>
> Attachments: LUCENE-8107.patch
>
>
> I hit some reproducing failures over the weekend:
> {noformat}
> ant test  -Dtestcase=GeoExactCircleTest 
> -Dtests.method=RandomPointBearingCardinalTest -Dtests.seed=30B96A8700F32D8F 
> -Dtests.slow=true -Dtests.locale=ar-SD -Dtests.timezone=Turkey 
> -Dtests.asserts=true -Dtests.file.encoding=UTF8
> [junit4] FAILURE 0.01s J0 | GeoExactCircleTest.RandomPointBearingCardinalTest 
> {seed=[30B96A8700F32D8F:475E54A204015A1C]} <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> PlanetModel(ab=1.7929995623606008 c=1.1596251282) 0.022823921875714692 
> 2.6270976802297388
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([30B96A8700F32D8F:475E54A204015A1C]:0)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.checkBearingPoint(GeoExactCircleTest.java:117)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.RandomPointBearingCardinalTest(GeoExactCircleTest.java:109)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=478, maxMBSortInHeap=5.961909961194244, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@179f38fb),
>  locale=ar-SD, timezone=Turkey
>[junit4]   2> NOTE: Linux 4.4.0-1043-aws amd64/Oracle Corporation 
> 1.8.0_151 (64-bit)/cpus=4,threads=1,free=269120312,total=319291392
>[junit4]   2> NOTE: All tests run in this JVM: [XYZSolidTest, 
> TestGeo3DDocValues, GeoExactCircleTest]
> ant test  -Dtestcase=GeoExactCircleTest 
> -Dtests.method=RandomPointBearingCardinalTest -Dtests.seed=30B96A8700F32D8F 
> -Dtests.slow=true -Dtests.locale=ar-SD -Dtests.timezone=Turkey 
> -Dtests.asserts=true -Dtests.file.encoding=UTF8
>[junit4] FAILURE 0.02s J2 | 
> GeoExactCircleTest.RandomPointBearingCardinalTest 
> {seed=[8C1E53DFCE9646F5:8DCCE74ADEC6D907]} <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> PlanetModel(ab=1.0366200558773102 c=0.6736249299915238) 0.0011591580078804675 
> 2.649410126114567
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([8C1E53DFCE9646F5:8DCCE74ADEC6D907]:0)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.checkBearingPoint(GeoExactCircleTest.java:117)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.RandomPointBearingCardinalTest(GeoExactCircleTest.java:109)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=1185, maxMBSortInHeap=5.925083864677718, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@6a7f1f9),
>  locale=en-AU, timezone=CNT
>[junit4]   2> NOTE: Linux 2.6.32-696.6.3.el6.x86_64 amd64/Oracle 
> Corporation 1.8.0_151 (64-bit)/cpus=4,threads=1,free=207196520,total=251658240
>[junit4]   2> NOTE: All tests run in this JVM: [TestGeo3DDocValues, 
> GeoCircleTest, GeoExactCircleTest]
>[junit4] Completed [11/16 (1!)] on J2 in 1.60s, 311 tests, 1 failure <<< 
> FAILURES!
> {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] [Commented] (LUCENE-8107) GeoExactCircleTest.RandomPointBearingCardinalTest failures

[ASF subversion and git services (JIRA)]

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

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

Commit 5c0c22d96985cde6ce011236c35dc402869fff5d in lucene-solr's branch 
refs/heads/branch_7x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5c0c22d ]

LUCENE-8107: Fix test to not pick too large a distance. Committed on behalf of 
Ignacio Vera.


> GeoExactCircleTest.RandomPointBearingCardinalTest failures
> --
>
> Key: LUCENE-8107
> URL: https://issues.apache.org/jira/browse/LUCENE-8107
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Karl Wright
> Fix For: 6.7, master (8.0), 7.2
>
> Attachments: LUCENE-8107.patch
>
>
> I hit some reproducing failures over the weekend:
> {noformat}
> ant test  -Dtestcase=GeoExactCircleTest 
> -Dtests.method=RandomPointBearingCardinalTest -Dtests.seed=30B96A8700F32D8F 
> -Dtests.slow=true -Dtests.locale=ar-SD -Dtests.timezone=Turkey 
> -Dtests.asserts=true -Dtests.file.encoding=UTF8
> [junit4] FAILURE 0.01s J0 | GeoExactCircleTest.RandomPointBearingCardinalTest 
> {seed=[30B96A8700F32D8F:475E54A204015A1C]} <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> PlanetModel(ab=1.7929995623606008 c=1.1596251282) 0.022823921875714692 
> 2.6270976802297388
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([30B96A8700F32D8F:475E54A204015A1C]:0)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.checkBearingPoint(GeoExactCircleTest.java:117)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.RandomPointBearingCardinalTest(GeoExactCircleTest.java:109)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=478, maxMBSortInHeap=5.961909961194244, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@179f38fb),
>  locale=ar-SD, timezone=Turkey
>[junit4]   2> NOTE: Linux 4.4.0-1043-aws amd64/Oracle Corporation 
> 1.8.0_151 (64-bit)/cpus=4,threads=1,free=269120312,total=319291392
>[junit4]   2> NOTE: All tests run in this JVM: [XYZSolidTest, 
> TestGeo3DDocValues, GeoExactCircleTest]
> ant test  -Dtestcase=GeoExactCircleTest 
> -Dtests.method=RandomPointBearingCardinalTest -Dtests.seed=30B96A8700F32D8F 
> -Dtests.slow=true -Dtests.locale=ar-SD -Dtests.timezone=Turkey 
> -Dtests.asserts=true -Dtests.file.encoding=UTF8
>[junit4] FAILURE 0.02s J2 | 
> GeoExactCircleTest.RandomPointBearingCardinalTest 
> {seed=[8C1E53DFCE9646F5:8DCCE74ADEC6D907]} <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> PlanetModel(ab=1.0366200558773102 c=0.6736249299915238) 0.0011591580078804675 
> 2.649410126114567
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([8C1E53DFCE9646F5:8DCCE74ADEC6D907]:0)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.checkBearingPoint(GeoExactCircleTest.java:117)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.RandomPointBearingCardinalTest(GeoExactCircleTest.java:109)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=1185, maxMBSortInHeap=5.925083864677718, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@6a7f1f9),
>  locale=en-AU, timezone=CNT
>[junit4]   2> NOTE: Linux 2.6.32-696.6.3.el6.x86_64 amd64/Oracle 
> Corporation 1.8.0_151 (64-bit)/cpus=4,threads=1,free=207196520,total=251658240
>[junit4]   2> NOTE: All tests run in this JVM: [TestGeo3DDocValues, 
> GeoCircleTest, GeoExactCircleTest]
>[junit4] Completed [11/16 (1!)] on J2 in 1.60s, 311 tests, 1 failure <<< 
> FAILURES!
> {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] [Commented] (LUCENE-8107) GeoExactCircleTest.RandomPointBearingCardinalTest failures

[ASF subversion and git services (JIRA)]

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

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

Commit b190877d5f67ba4cecc4198a3daf22e1a79932a8 in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b190877 ]

LUCENE-8107: Fix test to not pick too large a distance. Committed on behalf of 
Ignacio Vera.


> GeoExactCircleTest.RandomPointBearingCardinalTest failures
> --
>
> Key: LUCENE-8107
> URL: https://issues.apache.org/jira/browse/LUCENE-8107
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Karl Wright
> Attachments: LUCENE-8107.patch
>
>
> I hit some reproducing failures over the weekend:
> {noformat}
> ant test  -Dtestcase=GeoExactCircleTest 
> -Dtests.method=RandomPointBearingCardinalTest -Dtests.seed=30B96A8700F32D8F 
> -Dtests.slow=true -Dtests.locale=ar-SD -Dtests.timezone=Turkey 
> -Dtests.asserts=true -Dtests.file.encoding=UTF8
> [junit4] FAILURE 0.01s J0 | GeoExactCircleTest.RandomPointBearingCardinalTest 
> {seed=[30B96A8700F32D8F:475E54A204015A1C]} <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> PlanetModel(ab=1.7929995623606008 c=1.1596251282) 0.022823921875714692 
> 2.6270976802297388
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([30B96A8700F32D8F:475E54A204015A1C]:0)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.checkBearingPoint(GeoExactCircleTest.java:117)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.RandomPointBearingCardinalTest(GeoExactCircleTest.java:109)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=478, maxMBSortInHeap=5.961909961194244, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@179f38fb),
>  locale=ar-SD, timezone=Turkey
>[junit4]   2> NOTE: Linux 4.4.0-1043-aws amd64/Oracle Corporation 
> 1.8.0_151 (64-bit)/cpus=4,threads=1,free=269120312,total=319291392
>[junit4]   2> NOTE: All tests run in this JVM: [XYZSolidTest, 
> TestGeo3DDocValues, GeoExactCircleTest]
> ant test  -Dtestcase=GeoExactCircleTest 
> -Dtests.method=RandomPointBearingCardinalTest -Dtests.seed=30B96A8700F32D8F 
> -Dtests.slow=true -Dtests.locale=ar-SD -Dtests.timezone=Turkey 
> -Dtests.asserts=true -Dtests.file.encoding=UTF8
>[junit4] FAILURE 0.02s J2 | 
> GeoExactCircleTest.RandomPointBearingCardinalTest 
> {seed=[8C1E53DFCE9646F5:8DCCE74ADEC6D907]} <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> PlanetModel(ab=1.0366200558773102 c=0.6736249299915238) 0.0011591580078804675 
> 2.649410126114567
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([8C1E53DFCE9646F5:8DCCE74ADEC6D907]:0)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.checkBearingPoint(GeoExactCircleTest.java:117)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.RandomPointBearingCardinalTest(GeoExactCircleTest.java:109)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=1185, maxMBSortInHeap=5.925083864677718, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@6a7f1f9),
>  locale=en-AU, timezone=CNT
>[junit4]   2> NOTE: Linux 2.6.32-696.6.3.el6.x86_64 amd64/Oracle 
> Corporation 1.8.0_151 (64-bit)/cpus=4,threads=1,free=207196520,total=251658240
>[junit4]   2> NOTE: All tests run in this JVM: [TestGeo3DDocValues, 
> GeoCircleTest, GeoExactCircleTest]
>[junit4] Completed [11/16 (1!)] on J2 in 1.60s, 311 tests, 1 failure <<< 
> FAILURES!
> {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] [Commented] (LUCENE-8107) GeoExactCircleTest.RandomPointBearingCardinalTest failures

[ASF subversion and git services (JIRA)]

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

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

Commit bdfbe433a35f359b26fe20cb310150bc3d2b2da1 in lucene-solr's branch 
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bdfbe43 ]

LUCENE-8107: Fix test to not pick too large a distance. Committed on behalf of 
Ignacio Vera.


> GeoExactCircleTest.RandomPointBearingCardinalTest failures
> --
>
> Key: LUCENE-8107
> URL: https://issues.apache.org/jira/browse/LUCENE-8107
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Karl Wright
> Attachments: LUCENE-8107.patch
>
>
> I hit some reproducing failures over the weekend:
> {noformat}
> ant test  -Dtestcase=GeoExactCircleTest 
> -Dtests.method=RandomPointBearingCardinalTest -Dtests.seed=30B96A8700F32D8F 
> -Dtests.slow=true -Dtests.locale=ar-SD -Dtests.timezone=Turkey 
> -Dtests.asserts=true -Dtests.file.encoding=UTF8
> [junit4] FAILURE 0.01s J0 | GeoExactCircleTest.RandomPointBearingCardinalTest 
> {seed=[30B96A8700F32D8F:475E54A204015A1C]} <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> PlanetModel(ab=1.7929995623606008 c=1.1596251282) 0.022823921875714692 
> 2.6270976802297388
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([30B96A8700F32D8F:475E54A204015A1C]:0)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.checkBearingPoint(GeoExactCircleTest.java:117)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.RandomPointBearingCardinalTest(GeoExactCircleTest.java:109)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=478, maxMBSortInHeap=5.961909961194244, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@179f38fb),
>  locale=ar-SD, timezone=Turkey
>[junit4]   2> NOTE: Linux 4.4.0-1043-aws amd64/Oracle Corporation 
> 1.8.0_151 (64-bit)/cpus=4,threads=1,free=269120312,total=319291392
>[junit4]   2> NOTE: All tests run in this JVM: [XYZSolidTest, 
> TestGeo3DDocValues, GeoExactCircleTest]
> ant test  -Dtestcase=GeoExactCircleTest 
> -Dtests.method=RandomPointBearingCardinalTest -Dtests.seed=30B96A8700F32D8F 
> -Dtests.slow=true -Dtests.locale=ar-SD -Dtests.timezone=Turkey 
> -Dtests.asserts=true -Dtests.file.encoding=UTF8
>[junit4] FAILURE 0.02s J2 | 
> GeoExactCircleTest.RandomPointBearingCardinalTest 
> {seed=[8C1E53DFCE9646F5:8DCCE74ADEC6D907]} <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> PlanetModel(ab=1.0366200558773102 c=0.6736249299915238) 0.0011591580078804675 
> 2.649410126114567
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([8C1E53DFCE9646F5:8DCCE74ADEC6D907]:0)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.checkBearingPoint(GeoExactCircleTest.java:117)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.RandomPointBearingCardinalTest(GeoExactCircleTest.java:109)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=1185, maxMBSortInHeap=5.925083864677718, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@6a7f1f9),
>  locale=en-AU, timezone=CNT
>[junit4]   2> NOTE: Linux 2.6.32-696.6.3.el6.x86_64 amd64/Oracle 
> Corporation 1.8.0_151 (64-bit)/cpus=4,threads=1,free=207196520,total=251658240
>[junit4]   2> NOTE: All tests run in this JVM: [TestGeo3DDocValues, 
> GeoCircleTest, GeoExactCircleTest]
>[junit4] Completed [11/16 (1!)] on J2 in 1.60s, 311 tests, 1 failure <<< 
> FAILURES!
> {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] (LUCENE-8107) GeoExactCircleTest.RandomPointBearingCardinalTest failures

[Ignacio Vera (JIRA)]

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

Ignacio Vera updated LUCENE-8107:
-
Attachment: LUCENE-8107.patch

Hi [~daddywri],

The issue on the test is that distance is too big for those planet models. I 
attached a patch that make sure tat distance is lower than planet model minimum 
pole distance.

Happy new year!

> GeoExactCircleTest.RandomPointBearingCardinalTest failures
> --
>
> Key: LUCENE-8107
> URL: https://issues.apache.org/jira/browse/LUCENE-8107
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Karl Wright
> Attachments: LUCENE-8107.patch
>
>
> I hit some reproducing failures over the weekend:
> {noformat}
> ant test  -Dtestcase=GeoExactCircleTest 
> -Dtests.method=RandomPointBearingCardinalTest -Dtests.seed=30B96A8700F32D8F 
> -Dtests.slow=true -Dtests.locale=ar-SD -Dtests.timezone=Turkey 
> -Dtests.asserts=true -Dtests.file.encoding=UTF8
> [junit4] FAILURE 0.01s J0 | GeoExactCircleTest.RandomPointBearingCardinalTest 
> {seed=[30B96A8700F32D8F:475E54A204015A1C]} <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> PlanetModel(ab=1.7929995623606008 c=1.1596251282) 0.022823921875714692 
> 2.6270976802297388
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([30B96A8700F32D8F:475E54A204015A1C]:0)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.checkBearingPoint(GeoExactCircleTest.java:117)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.RandomPointBearingCardinalTest(GeoExactCircleTest.java:109)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=478, maxMBSortInHeap=5.961909961194244, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@179f38fb),
>  locale=ar-SD, timezone=Turkey
>[junit4]   2> NOTE: Linux 4.4.0-1043-aws amd64/Oracle Corporation 
> 1.8.0_151 (64-bit)/cpus=4,threads=1,free=269120312,total=319291392
>[junit4]   2> NOTE: All tests run in this JVM: [XYZSolidTest, 
> TestGeo3DDocValues, GeoExactCircleTest]
> ant test  -Dtestcase=GeoExactCircleTest 
> -Dtests.method=RandomPointBearingCardinalTest -Dtests.seed=30B96A8700F32D8F 
> -Dtests.slow=true -Dtests.locale=ar-SD -Dtests.timezone=Turkey 
> -Dtests.asserts=true -Dtests.file.encoding=UTF8
>[junit4] FAILURE 0.02s J2 | 
> GeoExactCircleTest.RandomPointBearingCardinalTest 
> {seed=[8C1E53DFCE9646F5:8DCCE74ADEC6D907]} <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> PlanetModel(ab=1.0366200558773102 c=0.6736249299915238) 0.0011591580078804675 
> 2.649410126114567
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([8C1E53DFCE9646F5:8DCCE74ADEC6D907]:0)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.checkBearingPoint(GeoExactCircleTest.java:117)
>[junit4]>  at 
> org.apache.lucene.spatial3d.geom.GeoExactCircleTest.RandomPointBearingCardinalTest(GeoExactCircleTest.java:109)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
> docValues:{}, maxPointsInLeafNode=1185, maxMBSortInHeap=5.925083864677718, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@6a7f1f9),
>  locale=en-AU, timezone=CNT
>[junit4]   2> NOTE: Linux 2.6.32-696.6.3.el6.x86_64 amd64/Oracle 
> Corporation 1.8.0_151 (64-bit)/cpus=4,threads=1,free=207196520,total=251658240
>[junit4]   2> NOTE: All tests run in this JVM: [TestGeo3DDocValues, 
> GeoCircleTest, GeoExactCircleTest]
>[junit4] Completed [11/16 (1!)] on J2 in 1.60s, 311 tests, 1 failure <<< 
> FAILURES!
> {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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testNodeMarkersRegistration

Error Message:
Path /autoscaling/nodeAdded/127.0.0.1:36645_solr wasn't created

Stack Trace:
java.lang.AssertionError: Path /autoscaling/nodeAdded/127.0.0.1:36645_solr 
wasn't created
at 
__randomizedtesting.SeedInfo.seed([999AE2567DAB0BB6:81206A5A739EC659]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testNodeMarkersRegistration(TriggerIntegrationTest.java:936)
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 13736 lines...]
   [junit4] Suite: org.apache.solr.cloud.autoscaling.TriggerIntegrationTest
   [junit4]   2> 2256617 INFO  

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.rest.schema.analysis.TestManagedSynonymFilterFactory.testManagedSynonyms

Error Message:
Unable to delete directory 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.rest.schema.analysis.TestManagedSynonymFilterFactory_AC744C4F1871A189-001\tempDir-001\collection1.

Stack Trace:
java.io.IOException: Unable to delete directory 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.rest.schema.analysis.TestManagedSynonymFilterFactory_AC744C4F1871A189-001\tempDir-001\collection1.
at 
__randomizedtesting.SeedInfo.seed([AC744C4F1871A189:1E04F3259805E5AD]:0)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1581)
at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2372)
at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1679)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1575)
at 
org.apache.solr.rest.schema.analysis.TestManagedSynonymFilterFactory.after(TestManagedSynonymFilterFactory.java:64)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
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 
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 

[jira] [Resolved] (LUCENE-8012) Improve Explanation class

[Alan Woodward (JIRA)]

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

Alan Woodward resolved LUCENE-8012.
---
   Resolution: Fixed
Fix Version/s: master (8.0)

Thanks for the review [~jpountz]

> Improve Explanation class
> -
>
> Key: LUCENE-8012
> URL: https://issues.apache.org/jira/browse/LUCENE-8012
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>  Labels: newdev
> Fix For: master (8.0)
>
> Attachments: LUCENE-8012.patch, LUCENE-8012.patch
>
>
> Explanation class is currently nice and simple, and float matches the scoring 
> api, but this does not work well for debugging numerical errors of internal 
> calculations (it usually makes practical sense to use 64-bit double to avoid 
> issues).
> Also it makes for nasty formatting of integral values such as number of 
> tokens in the collection or even document's length, its just noise to see 
> {{10.0}} there instead of {{10}}, and scientific notation for e.g. number of 
> documents is just annoying. 
> One idea is to take Number instead of float? Then you could pass in the 
> correct numeric type (int,long,double,float) for internal calculations, 
> parameters, statistics, etc, and output would look nice.



--
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-8012) Improve Explanation class

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8012: Explanation takes Number rather than float


> Improve Explanation class
> -
>
> Key: LUCENE-8012
> URL: https://issues.apache.org/jira/browse/LUCENE-8012
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>  Labels: newdev
> Fix For: master (8.0)
>
> Attachments: LUCENE-8012.patch, LUCENE-8012.patch
>
>
> Explanation class is currently nice and simple, and float matches the scoring 
> api, but this does not work well for debugging numerical errors of internal 
> calculations (it usually makes practical sense to use 64-bit double to avoid 
> issues).
> Also it makes for nasty formatting of integral values such as number of 
> tokens in the collection or even document's length, its just noise to see 
> {{10.0}} there instead of {{10}}, and scientific notation for e.g. number of 
> documents is just annoying. 
> One idea is to take Number instead of float? Then you could pass in the 
> correct numeric type (int,long,double,float) for internal calculations, 
> parameters, statistics, etc, and output would look nice.



--
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-8010) fix or sandbox similarities in core with problems

[ASF subversion and git services (JIRA)]

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

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

Commit 6dd9dbf2758c1fad2f10f0eba96998411aa43fd0 in lucene-solr's branch 
refs/heads/master from [~romseygeek]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6dd9dbf ]

LUCENE-8010: GroupingSearchTest assumes longer fields = lower scores


> fix or sandbox similarities in core with problems
> -
>
> Key: LUCENE-8010
> URL: https://issues.apache.org/jira/browse/LUCENE-8010
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: master (8.0)
>
> Attachments: LUCENE-8010.patch
>
>
> We want to support scoring optimizations such as LUCENE-4100 and LUCENE-7993, 
> which put very minimal requirements on the similarity impl. Today 
> similarities of various quality are in core and tests. 
> The ones with problems currently have warnings in the javadocs about their 
> bugs, and if the problems are severe enough, then they are also disabled in 
> randomized testing too.
> IMO lucene core should only have practical functions that won't return 
> {{NaN}} scores at times or cause relevance to go backwards if the user's 
> stopfilter isn't configured perfectly. Also it is important for unit tests to 
> not deal with broken or semi-broken sims, and the ones in core should pass 
> all unit tests.
> I propose we move the buggy ones to sandbox and deprecate them. If they can 
> be fixed we can put them back in core, otherwise bye-bye.
> FWIW tests developed in LUCENE-7997 document the following requirements:
>* scores are non-negative and finite.
>* score matches the explanation exactly.
>* internal explanations calculations are sane (e.g. sum of: and so on 
> actually compute sums)
>* scores don't decrease as term frequencies increase: e.g. score(freq=N + 
> 1) >= score(freq=N)
>* scores don't decrease as documents get shorter, e.g. score(len=M) >= 
> score(len=M+1)
>* scores don't decrease as terms get rarer, e.g. score(term=N) >= 
> score(term=N+1)
>* scoring works for floating point frequencies (e.g. sloppy phrase and 
> span queries will work)
>* scoring works for reasonably large 64-bit statistic values (e.g. 
> distributed search will work)
>* scoring works for reasonably large boost values (0 .. Integer.MAX_VALUE, 
> e.g. query boosts will work)
>* scoring works for parameters randomized within valid ranges



--
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-8114) Grouping module should not depend on queries module

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-8114:
---

[~martijn.v.groningen] said:

bq. I think for the grouping module, for now, the ValueSourceGroupSelector 
class should be moved to the solr-core module and then the dependency on the 
queries module that the grouping module has can be removed, which is a big win 
on its own.

I'm a bit reluctant to just remove the functionality entirely.  On the other 
hand, we could just deprecate it in 7.3 and see if anyone complains...

> Grouping module should not depend on queries module
> ---
>
> Key: LUCENE-8114
> URL: https://issues.apache.org/jira/browse/LUCENE-8114
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>
> Spin-off of LUCENE-8104



--
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-8104) Facet module should no longer depend on Queries module (ValueSource)

[Alan Woodward (JIRA)]

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

Alan Woodward resolved LUCENE-8104.
---
   Resolution: Fixed
Fix Version/s: 7.3

I opened LUCENE-8114 to deal with grouping

> Facet module should no longer depend on Queries module (ValueSource)
> 
>
> Key: LUCENE-8104
> URL: https://issues.apache.org/jira/browse/LUCENE-8104
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/grouping
>Reporter: David Smiley
> Fix For: 7.3
>
> Attachments: LUCENE-8104.patch
>
>
> The Grouping module depends on the Queries module in GroupingSearch / 
> ValueSourceGroupSelector to use the ValueSource framework.  It should instead 
> use the newer DoubleValueSource or LongValueSource framework in Core.  As I 
> write this, this appears to be the last part of Lucene to refer to the 
> ValueSource framework, and I think we should then remove it -- for another 
> issue of course.



--
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-8114) Grouping module should not depend on queries module

[Alan Woodward (JIRA)]

Alan Woodward created LUCENE-8114:
-

 Summary: Grouping module should not depend on queries module
 Key: LUCENE-8114
 URL: https://issues.apache.org/jira/browse/LUCENE-8114
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Alan Woodward






--
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-8114) Grouping module should not depend on queries module

[Alan Woodward (JIRA)]

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

Alan Woodward updated LUCENE-8114:
--
Description: Spin-off of LUCENE-8104

> Grouping module should not depend on queries module
> ---
>
> Key: LUCENE-8114
> URL: https://issues.apache.org/jira/browse/LUCENE-8114
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>
> Spin-off of LUCENE-8104



--
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-8104) Facet module should no longer depend on Queries module (ValueSource)

[Alan Woodward (JIRA)]

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

Alan Woodward updated LUCENE-8104:
--
Summary: Facet module should no longer depend on Queries module 
(ValueSource)  (was: Grouping module should no longer depend on Queries module 
(ValueSource))

> Facet module should no longer depend on Queries module (ValueSource)
> 
>
> Key: LUCENE-8104
> URL: https://issues.apache.org/jira/browse/LUCENE-8104
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/grouping
>Reporter: David Smiley
> Attachments: LUCENE-8104.patch
>
>
> The Grouping module depends on the Queries module in GroupingSearch / 
> ValueSourceGroupSelector to use the ValueSource framework.  It should instead 
> use the newer DoubleValueSource or LongValueSource framework in Core.  As I 
> write this, this appears to be the last part of Lucene to refer to the 
> ValueSource framework, and I think we should then remove it -- for another 
> issue of course.



--
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-8012) Improve Explanation class

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8012:
--

I'm +1 on merging, this is good progress already. We can deal with making 
CheckHits/CheckExplanations more picky in follow-up issues.

> Improve Explanation class
> -
>
> Key: LUCENE-8012
> URL: https://issues.apache.org/jira/browse/LUCENE-8012
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>  Labels: newdev
> Attachments: LUCENE-8012.patch, LUCENE-8012.patch
>
>
> Explanation class is currently nice and simple, and float matches the scoring 
> api, but this does not work well for debugging numerical errors of internal 
> calculations (it usually makes practical sense to use 64-bit double to avoid 
> issues).
> Also it makes for nasty formatting of integral values such as number of 
> tokens in the collection or even document's length, its just noise to see 
> {{10.0}} there instead of {{10}}, and scientific notation for e.g. number of 
> documents is just annoying. 
> One idea is to take Number instead of float? Then you could pass in the 
> correct numeric type (int,long,double,float) for internal calculations, 
> parameters, statistics, etc, and output would look nice.



--
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-8113) Allow terms dictionary lookups to be lazy when scores are not needed

[Alan Woodward (JIRA)]

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

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

Here's a patch that introduces a LazyTermContext object.  TermContext.build() 
now takes an extra 'needsStats' parameter, and returns a lazy-loading 
TermContext if it is false.  TermContext.get() needs to take a 
LeafReaderContext rather than an integer.

PhraseQuery and SpanTermQuery can now avoid disk seeks if they're being used 
directly from the query cache, and it simplifies the logic in TermWeight as 
well.

> Allow terms dictionary lookups to be lazy when scores are not needed
> 
>
> Key: LUCENE-8113
> URL: https://issues.apache.org/jira/browse/LUCENE-8113
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
> Attachments: LUCENE-8113.patch
>
>
> LUCENE-7311 made it possible to avoid loading TermStates in cached 
> TermQueries.  It would be useful to extend this to other queries that use the 
> terms dictionary.



--
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-8113) Allow terms dictionary lookups to be lazy when scores are not needed

[Alan Woodward (JIRA)]

Alan Woodward created LUCENE-8113:
-

 Summary: Allow terms dictionary lookups to be lazy when scores are 
not needed
 Key: LUCENE-8113
 URL: https://issues.apache.org/jira/browse/LUCENE-8113
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Alan Woodward


LUCENE-7311 made it possible to avoid loading TermStates in cached TermQueries. 
 It would be useful to extend this to other queries that use the terms 
dictionary.



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

[Policeman Jenkins Server]

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

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

Error Message:
Error from server at https://127.0.0.1:34041/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:34041/solr: create the collection time out:180s
at __randomizedtesting.SeedInfo.seed([BECDE8E1CEEB4A04]: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.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)


FAILED:  
org.apache.solr.cloud.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete

Error Message:
Error from server at 
http://127.0.0.1:35015/solr/testcollection_shard1_replica_n3: Expected mime 
type application/octet-stream but got text/html.Error 
404HTTP ERROR: 404 Problem accessing 
/solr/testcollection_shard1_replica_n3/update. Reason: Can not find: 
/solr/testcollection_shard1_replica_n3/update http://eclipse.org/jetty;>Powered by Jetty:// 9.3.20.v20170531 
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:35015/solr/testcollection_shard1_replica_n3: 
Expected mime type application/octet-stream but got text/html. 


Error 404 


HTTP ERROR: 404
Problem accessing 

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

[Policeman Jenkins Server]

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

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

at __randomizedtesting.SeedInfo.seed([25945CC58EE69610]: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.EchoParamsTest

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

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

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

at __randomizedtesting.SeedInfo.seed([546F5921B3825801]: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